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, 14:30 UTC
Message-ID: <20091016143041.GA11821@atjola.homenet>
In-Reply-To: <alpine.LNX.2.00.0910161311460.28491@reaper.quantumfyre.co.uk>

On 2009.10.16 13:15:35 +0100, Julian Phillips wrote:

Show 24 quoted lines

> 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