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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html