From: Julian Phillips Date: Sat, 17 Oct 2009 15:02:26 GMT Subject: Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was Message-ID: In-Reply-To: <20091017075551.GA5474@atjola.homenet> On Sat, 17 Oct 2009, Bj?rn Steinbrink wrote: > 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. My entire argument was in the context of the mail that I orginally replied to, i.e. assuming that the decision to not detach had been taken. If that is not the case, then everything I had said is irrelevant. I wasn't arguing against detaching, but rather trying to say that _if_ we are not going to detach then I think it would better like this than that. I don't personally have any input on the detach or not, as I have been using git for too long to know if detaching is a problem for others. I can tell from my bash prompt if I'm detached or on a branch - and that's fine for me. -- Julian --- Wedding is destiny, and hanging likewise. -- John Heywood