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

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

On 2009.10.16 13:15:35 +0100, Julian Phillips wrote:
> On Thu, 15 Oct 2009, Daniel Barkalow wrote:
> 
> >On Thu, 15 Oct 2009, James Pickens wrote:
> >
> >>How about not detaching the head at all if the user checks out any ref, and
> >>reject commits if he checked out a tag or remote branch.  For example:
> >>
> >>$ git checkout origin/master
> >>$ git status
> >># On branch origin/master
> >>$ git commit ;# complain
> >
> >$ git checkout origin/master
> >$ git fetch
> >$ git checkout origin/next
> >Uncommited file '...' would be overwritten.
> 
> 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.

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?

Björn