On Thu, Jul 16, 2015 at 1:24 AM, Duy Nguyen wrote:
> On Thu, Jul 16, 2015 at 6:13 AM, Junio C Hamano 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
On Thu, Jul 16, 2015 at 6:13 AM, Junio C Hamano 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 allowed".
>
>
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: equityinvest
On Wed, Jul 15, 2015 at 3:00 PM, Mike Rappazzo 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
> here](https://support.google.com/accou
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 wrote:
> On Wed, Jul 15, 2015 at 6:24 PM, Keller, Jacob E
> wrote:
>> On Tue, 2015-07-14 at 13:34 -0700, Stefan Beller wrote:
>>> On Tue, Jul 14, 2015
On Wed, Jul 15, 2015 at 6:24 PM, Keller, Jacob E
wrote:
> On Tue, 2015-07-14 at 13:34 -0700, Stefan Beller wrote:
>> On Tue, Jul 14, 2015 at 9:42 AM, wrote:
>> > From: Beat Bolli
>> >
>> > When referencing earlier commits in new commit messages or other
>> > text,
>> > one of the established fo
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 chec
On Tue, 2015-07-14 at 13:34 -0700, Stefan Beller wrote:
> On Tue, Jul 14, 2015 at 9:42 AM, wrote:
> > From: Beat Bolli
> >
> > When referencing earlier commits in new commit messages or other
> > text,
> > one of the established formats is
> >
> > commit ("", )
>
> That sounds like I wo
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 o
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 = https://kernel
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
> 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
Jeff King 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
On Wed, Jul 15, 2015 at 11:17 AM, 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"
Oh, in that case I say NAK NAK NAK.
That would be totally horrible, and completely unacceptable.
I do "git log -p" all
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
Linus Torvalds writes:
> On Wed, Jul 15, 2015 at 10:58 AM, Junio C Hamano 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
>>
On Wed, Jul 15, 2015 at 10:58 AM, Junio C Hamano 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 reverts back
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 oth
Linus Torvalds 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" does).
> And "-m"? We s
On Wed, Jul 15, 2015 at 9:29 AM, Junio C Hamano 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 relative to it
Linus Torvalds 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 " does show them. And you kind of
> have to know a lot about git to know the "--cc" option.
>
> In
David Turner 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 LMDB access
> ...
> b
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
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 ca
On Wed, Jul 15, 2015 at 1:48 PM, Eric Sunshine 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 st_mode and readlink(
On Tue, Jul 14, 2015 at 11:42 PM, Torsten Bögershausen 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
> directory.t7812-grep-icase-n
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 --ve
27 matches
Mail list logo
