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

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2009.10.15 16:47:57 -0700, James Pickens wrote:
> 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.

> 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