Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
- From
Julian Phillips <julian@quantumfyre.co.uk>
- Date
- Oct 16, 2009, 17:31 UTC
- Message-ID
- <alpine.LNX.2.00.0910161821230.30589@reaper.quantumfyre.co.uk>
- In-Reply-To
- <20091016143041.GA11821@atjola.homenet>
On Fri, 16 Oct 2009, Bj?rn Steinbrink wrote:
Show 32 quoted lines
> 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.
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.
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.
Now as a user I know that I have tried to do something a bit unusual, but I don't have to run to the mailing list or #git saying "I just did X Y Z and everything is now FUBARed". I can even proceed to do the unusal thing, as git itself has given me the information I need to sort things out afterwards.
Show 7 quoted lines
> 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.
-- Julian --- Captain: "Catalyzer's a nothing part, captain." Mal: "It's nothing until you don't got one. Then it appears to be everything." --Episode #8, "Out of Gas"