Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Oct 16, 2009, 05:03 UTC
Message-ID: <20091016050312.GB9233@atjola.homenet>
In-Reply-To: <885649360910151647v27a15334x63fe3b6f5035dbd2@mail.gmail.com>

On 2009.10.15 16:47:57 -0700, James Pickens wrote:

Show 23 quoted lines

> On Thu, Oct 15, 2009 at 3:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> >>     $ git checkout origin/next ;# ditto
> >>     $ git symbolic-ref HEAD
> >>     refs/remotes/origin/next
> >
> > Ok, after reading Daniel's message to remind us that "git fetch" after
> > this will get us into trouble, I agree that detaching HEAD is inevitable.
> 
> Some people liked the idea, so let's not give up just yet.  Here are a few
> things Git could do when a fetch wants to update the currently checked out
> branch:
> 
> 1. Refuse the fetch.
> 2. Update the ref, leaving the user with a work tree and index that don't
>    match their HEAD.
> 3. Detach the HEAD, then update the ref.
> 4. Update the ref, then check it out.
> 
> Option 1 is ok, as long as the "next step" is not too complicated.  It's no
> good if the user has to checkout a different branch, then fetch, then
> checkout the original branch again.

Not good. It makes "git fetch; git log ..origin/foo" impossible. And that's IMHO a very useful thing for people that just want to follow things and look at what happens.

> Option 2 is crap.

Agreed.

> Option 3 seems reasonable, but it might be just as scary/confusing to
> newbies as the current behavior, so I don't think it should be the default.

Doesn't seem very good to me. The idea was to stop people from accidently getting on a detached HEAD, if common operations like "fetch" now suddenly detach HEAD, that's _worse_ than before. And for a single-branch remote, even "git pull" may detach HEAD then:

git init; git remote add -f -t master origin git://... git checkout origin/master *wait* git pull # Will work, as the fetch refspec is not a glob

But that "pull" does: git fetch origin refs/heads/master:refs/remotes/origin/master

Which detaches HEAD before merging/fast-forwarding.

Bad.

And seeing that the requests for "clone just a single branch" seem to increase in #git, I guess that such non-globbing refspecs for remote.origin.fetch might become more common in the future.

> Option 4 also seems reasonable, but you run into problems if the user had
> changed the index or work tree.  In that case Git could do 'checkout
> --merge' automatically.  This option is also less "pure" since it lets 'git
> fetch' modify the index and work tree.

Same as for option 1, it kills "git fetch; git log ..origin/foo". And that would basically turn "fetch" into a hypothetical "pull --reset". That's IMHO better done in a separate command.

Show 5 quoted lines

> So how about this:
> * 'git fetch' refuses the fetch by default.
> * 'git fetch --detach' detaches HEAD, then updates the ref
> * 'git pull' detaches HEAD, updates the ref, then checks out the new ref
>   with --merge.

"fetch --detach" doesn't feel right to me. Wrong class of commands to have such an option. And I'm not sure about adding a third mode to "pull" (besides "merge" and "rebase") that only triggers for special cases. Again, I'd prefer a separate command.

If we store "where did I come from" instead of just "where am I" in HEAD when detached, those problems don't seem to show up (but just storing that information correctly seems hard enough, see the other mail I wrote a few minutes ago).

"git fetch" just updates the remote tracking branch, you stay at where you are, "git log ..origin/foo" keeps working. It could give a special hint that you might want to use "git checkout origin/foo" or "git new-command" to update your working tree to the newest version, when your working tree is based upon an old version of that remote tracking branch.

And "git pull" might perform a fast-forward automatically (figuring out the right remote from the extra info in HEAD), but refuse to do merges (if upstream has been rewritten), pointing the user to "git checkout" or "git new-command". (Interestingly, "pull --rebase" wouldn't suffer from such history rewriting, as it looks at the reflog for the remote tracking branch, but I guess a working "git pull --rebase" while "git pull" fails is bound to cause major user confusion).

"git new-command" could act like "svn up", doing a fetch and a "checkout --merge <remote_tracking_branch>" to just get the user up-to-date keeping local uncommitted modifications. I can't tell why, but my feeling is that this should be a new command, and not part of pull, as said above.

Björn