On Fri, 16 Oct 2009, Bj?rn Steinbrink wrote:
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.
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"
--
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