"Luck, Tony" <[EMAIL PROTECTED]> writes:
>>In the meantime, warning the user about the issue and suggesting
>>how to do the fast-forwarding of the working tree himself in the
>>warning message might be the safest and the most sensible thing
>>to do.
>
> Yes please ... a big fat warning with colour
>I am tempted to move this logic to "git fetch" instead, because
>it has the same issue. Tony's "linus" branch example has been
>updated to do a "git fetch" instead of "git pull" from the
>earlier description in his howto, but if he happens to be on the
>"linus" branch, he would still have this sa
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> I like it. As Linus stated, the index originally had a different role from
> what it has now, so it really should be an internal git thing, i.e. the
> git user should not expect the index not to change when pulling.
Actually the issue and the wa
Hi,
On Thu, 25 Aug 2005, Junio C Hamano wrote:
> This patch is to show my current thinking. Please let me know
> what you think.
I like it. As Linus stated, the index originally had a different role from
what it has now, so it really should be an internal git thing, i.e. the
git user should n
Earlier, I said:
Subject: Re: cache status after git pull
Date: Thu, 25 Aug 2005 13:26:07 -0700
Message-ID: <[EMAIL PROTECTED]>
> 1) Updated my "linus" branch:
>
> $ git checkout linus && git pull linus
The second command, "git pull linus", would internally run "git
5 matches
Mail list logo
