On Wed, Jul 15, 2015 at 3:00 PM, Mike Rappazzo rappa...@gmail.com wrote:
I believe that this is due to gmail not allowing the email. I think
there are two ways to fix this:
1. Temporarily enable less secure apps for your gmail account while
you send the email [see
On Thu, Jul 16, 2015 at 1:24 AM, Duy Nguyen pclo...@gmail.com wrote:
On Thu, Jul 16, 2015 at 6:13 AM, Junio C Hamano gits...@pobox.com wrote:
I've tried to set up a non-bare clone of git.git at ~/w/src and
attached one of its branches to a separate work tree at ~/w/rerere
~/w/src$ git
Sir,
We Provide assistance with International Loans, Project Finance and Funding.
Currently, Equity Investments and Loans Company (UK) Plc, London, United
Kingdom gives out Personal Loans and Business Loans.
For Further Enquiries, Contact Us only via our email as below;
E-mail:
On Thu, Jul 16, 2015 at 6:13 AM, Junio C Hamano gits...@pobox.com wrote:
I've tried to set up a non-bare clone of git.git at ~/w/src and
attached one of its branches to a separate work tree at ~/w/rerere
~/w/src$ git worktree add ../rerere jc/rerere
Then I tried the multiple checkout not
Agreed. I haven't seen commit used much in the past, and you can
easily type that out as it is.
On Wed, Jul 15, 2015 at 4:58 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, Jul 15, 2015 at 6:24 PM, Keller, Jacob E
jacob.e.kel...@intel.com wrote:
On Tue, 2015-07-14 at 13:34 -0700,
I reported this before, but now I have a nice topic to hang it on -
I have re-reproduced the bug using a build from master as of today,
using the new worktree commands.
Reproduction:
Creating a repo `foo`, checkout --to'ing it to ../bar, then try to
clone both resulting repositories..
$ git
On Tue, Jul 14, 2015 at 11:42 PM, Torsten Bögershausen tbo...@web.de wrote:
(I haven't been able to do more debugging yet,
but this doesn't fully work on my Mac OS X box:)
Initialized empty Git repository in
/Users/tb/NoBackup/projects/git/tb.150714_Duy_grep_utf8/t/trash
On Wed, Jul 15, 2015 at 1:48 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
- check_linked_checkout() when trying to decide what branch is
checked out assumes HEAD is always a regular file, but I do not
think we have dropped the support of SYMLINK_HEAD yet. It needs
to check
On Mon, Jul 13, 2015 at 2:36 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
This series eliminates git-checkout from the picture by instead
employing git reset --hard[2] to populate the new worktree initially.
A few comments on things I noticed while
Linus Torvalds torva...@linux-foundation.org writes:
...
So the whole don't show diffs for merges by default actually made a
lot of sense originally, because our merge diffs were not very useful.
I agree with most of your analysis of the history, but not with -m
(rather, a part of what -m
Linus Torvalds torva...@linux-foundation.org writes:
On Wed, Jul 15, 2015 at 10:58 AM, Junio C Hamano gits...@pobox.com wrote:
* When '-p' is given, we show only diff with first-parent by
default, regardless of the traversal (i.e. --first-parent option
currently controls both
Hi Christoph,
On 2015-07-14 23:04, Christoph Murczek wrote:
thanks for explaining why re-installing fixed my problem. Although I
still can't wrap my head around why it happened in the first place. It
could only be caused by Windows moving the base address of one, but
not the other thus
On Wed, Jul 15, 2015 at 11:17:50AM -0700, Junio C Hamano wrote:
So this is a suggested change to -p -m behavior?
Not really. This is a suggested behaviour for git log -p; I
wasn't very enthused by the idea to turn --cc when user said -p
without telling them what we are doing. In other
On Wed, Jul 15, 2015 at 11:17 AM, Junio C Hamano gits...@pobox.com wrote:
So this is a suggested change to -p -m behavior?
Not really. This is a suggested behaviour for git log -p
Oh, in that case I say NAK NAK NAK.
That would be totally horrible, and completely unacceptable.
I do git log
Jeff King p...@peff.net writes:
On Wed, Jul 15, 2015 at 11:17:50AM -0700, Junio C Hamano wrote:
So this is a suggested change to -p -m behavior?
Not really. This is a suggested behaviour for git log -p; I
wasn't very enthused by the idea to turn --cc when user said -p
without telling
I don't see any way around it, except dropping all the tests. I don't
think there is a way for us to test regex locale support at runtime.
(I don't think dropping all tests is a good way forward)
Either there is runtime code similar to test-regex.c,
or how about something like this:
commit
On Wed, Jul 15, 2015 at 9:29 AM, Junio C Hamano gits...@pobox.com wrote:
I would think git log -p that implies --cc would be a good
change, as long as there is an easy escape hatch to let us do what
we have to do with a rather lengthy git log -p --first-parent -m
(i.e. show the change
On Wed, 2015-07-15 at 09:24 -0700, Junio C Hamano wrote:
On reflection, I think that this would also be a reasonable approach to
take for stash, which does not fall into any of the listed categories.
It's not a pseudoref because it's not all-caps and it starts with refs/.
Unlike other
On Wed, Jul 15, 2015 at 10:58 AM, Junio C Hamano gits...@pobox.com wrote:
* When '-p' is given, we show only diff with first-parent by
default, regardless of the traversal (i.e. --first-parent option
currently controls both traversal and patch display, but in the
new world order, it
I've tried to set up a non-bare clone of git.git at ~/w/src and
attached one of its branches to a separate work tree at ~/w/rerere
~/w/src$ git worktree add ../rerere jc/rerere
Then I tried the multiple checkout not allowed.
~/w/src$ git checkout jc/rerere
fatal: 'jc/rerere' is already
On Wed, Jul 15, 2015 at 6:24 PM, Keller, Jacob E
jacob.e.kel...@intel.com wrote:
On Tue, 2015-07-14 at 13:34 -0700, Stefan Beller wrote:
On Tue, Jul 14, 2015 at 9:42 AM, dev+...@drbeat.li wrote:
From: Beat Bolli dev+...@drbeat.li
When referencing earlier commits in new commit messages or
I believe that this is due to gmail not allowing the email. I think
there are two ways to fix this:
1. Temporarily enable less secure apps for your gmail account while
you send the email [see
here](https://support.google.com/accounts/answer/6010255?hl=en).
2. Setup multi-factor authentication
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports
The latest maintenance release Git v2.4.6 is now available at
the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.4.6'
tag and the 'maint' branch that the tag points at:
url =
On Tue, 2015-07-14 at 13:34 -0700, Stefan Beller wrote:
On Tue, Jul 14, 2015 at 9:42 AM, dev+...@drbeat.li wrote:
From: Beat Bolli dev+...@drbeat.li
When referencing earlier commits in new commit messages or other
text,
one of the established formats is
commit abbrev-sha
On Wed, Jul 15, 2015 at 11:40:18AM +0200, Bjørnar Snoksrud wrote:
I reported this before, but now I have a nice topic to hang it on -
I have re-reproduced the bug using a build from master as of today,
using the new worktree commands.
Something like the following patch should work if you
David Turner dtur...@twopensource.com writes:
So I am thinking instead that backends should be required to manage
updates to HEAD themselves, and that some functions from refs-be-files
would be made generic to help with this.
...
For the LMDB backend, I could put most of that code at the
Linus Torvalds torva...@linux-foundation.org writes:
That said, I do wonder if we should just make -p imply --cc. Right
now we have the kind of odd situation that git log -p doesn't show
merge patches, but git show cmit does show them. And you kind of
have to know a lot about git to know the
28 matches
Mail list logo
