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

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

On 2009.10.16 18:31:23 +0100, Julian Phillips wrote:
> On Fri, 16 Oct 2009, Bj?rn Steinbrink wrote:
> >On 2009.10.16 13:15:35 +0100, Julian Phillips wrote:
> >>How about:
> >>
> >>$ git checkout origin/master
> >>$ git fetch
> >>Refusing to fetch, as it would update a checkedout branch
> >>"git fetch -f" will force the update, but you will need to run "git
> >>reset --hard HEAD" to update your checkout to match.
> >
> >That would redefine -f (currently means "allow non-fast-forward
> >updates"), the flag that allows the checked out branch head to be
> >updated is -u, --update-head-ok, and is for internal use only.
> >
> >And suggesting "reset --hard" seems wrong, that just kills any
> >uncommitted changes.
> 
> Ok, so the commands were wrong.  Not important.
> 
> It was the approach that I was trying to suggest rather than the
> actual commands.  The point I was trying to make was how, as a user,
> I would be happy to git behave.

Your approach explicitly included "mess up the index/worktree state",
otherwise, "git fetch" would not have to tell the user that he has to do
a "git reset --hard HEAD". I honestly can't believe that you would be
happy with git messing up your work.

> So, I try to run fetch, git says "ooh, now that would be dangerous -
> you can force it happen by running "git foo", but you will then be
> in situation X, which you can then recover from by running "git
> bar", though you may need to run "git stash" to save any edits you
> have made" or something similar.

But why make "git fetch" with non-"obscure" refspecs dangerous to begin
with? If we detach but keep some extra information, there's no need to
make "git fetch" dangerous, _and_ we can still provide a command that
just fetches the most recent version of the "checked out" remote
tracking branch and checks that out. May it be another mode of operation
for "git pull" or some "git up" command or whatever.

> >And such uncommitted changes would be lost in the big "undo the fetch
> >update" diff. So you'd have to do:
> >git reset --soft HEAD@{1}
> >git checkout --merge HEAD@{1}
> >
> >to keep them, while updating to the new state of the remote tracking
> >branch. Not quite intuitive, is it?
> 
> I don't care what git has to do, I'm talking about the user
> experience - if we have to write some new code to support it, that
> really isn't a terribly hard thing to do.  UIs should be driven down
> from the user interaction not up from the implementation.

Those commands are those that git would have to show to you, instead of
"git reset --hard HEAD", i.e. they're what you, as the user, have to do.
And while "git reset --hard HEAD" might be remotely understandable to
the user, that command sequence is very unlikely to be understood by
most. And providing a command that does just this sequence is insane,
it's just a bandaid for git doing crap to your worktree/index state. So
let's better not start with git doing that crap at all.

My current "idea" (I don't think I'll have time to implement that any
time soon) is:

Keep some extra information in HEAD (or somewhere else) when HEAD is
detached about the ref that HEAD is "weakly" bound to. For example, "git
checkout origin/master" might create a weak binding to
refs/remotes/origin/master (for other [corner] cases, see the other
mail I wrote, in which I outlined some cases I considered interesting).

"git update" can use the branch.<name>.{remote,merge} setup, or
alternatively the "weak binding" information, to fetch from the right
remote, and checks whether a fast-forward of HEAD to the according
upstream branch head is possible. If so, it does a "git checkout --merge
<upstream>" (possibly leaving conflicts for the uncommitted changes,
just like "svn update"). If a fast-forward is not possible, it
complains, telling the user that he needs to use "git merge/rebase/pull"
instead, and might want to create a branch head, in case of a detached
HEAD.

If there's also going to be a rule that forbids commits on some kind of
detached HEAD, than the command could also tell the user (when a
fast-forward is not possible) that upstream possibly rewrote history,
and that the user might want to use "git checkout --merge <upstream>"
(or maybe "git update -f"?) to just go to the new upstream version (not
sure if that hint should be shown in addition to or instead of the "git
merge/rebase/pull" hint).

Björn