Carlos Martín Nieto <cmn <at> elego.de> writes:
> I have not seen a revert command in any of your messages. If a revert on
> one branch changes another one, that would be a bug, but you haven't
> shown this to happen.
Sorry, it was in prose in the original post (near the end)
"At this point, reverting the master with "checkout --" also wipes out the
changes on the other branch. It's like the merge symlinked the two branches
rather than, well, merging them."
Based on the explanations here, and the git *st* message, it wiping out the
other branch is to be expected, because it's "the working directory", not
"the branch".
>git st
# On branch foo
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: file1.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
What makes this really interesting though is this: I tried to switch to
master to see if that gave the same warning, and NOW, I get the correct
error.
>git co master
error: Your local changes to the following files would be overwritten by
checkout:
file1.txt
Please, commit your changes or stash them before you can switch branches.
Aborting
I'm sure if I thought about it enough (ie re-read Andreas's post a couple
more times) I'd be able to understand why git gets it right sometimes but
not other times, but I'm too tired right now. Even when I *am* awake and
grok it properly, I'm still going to be annoyed that it's so inconsistent,
but I can live with that if I have to.
> The reason this happens both in svn and git is that the most likely
> cause for someone to change a branch mid-edit is that they decide
> they're doing the changes on the wrong branch.
Lucky you. :P The most likely reason for me is, I'm working on something
and I get interrupted and have to switch. Since the code may well not even
compile at this point, the last thing I want to do is commit it. git's
ability for that commit to be local is half the reason I'm trying to switch
to it. (I'm not particularly keen on having to commit broken code to even a
local repo, but that's still a hell of a lot better than having it pushed
upstream as well).
> svn doesn't tell you about the modifications being carried over
> (presumably you're meant to use status and diff to figure out what's
> going on). Therefore, the same workflow (with the only difference being
> how to create and switch branches) works for svn and git in this case.
I expect part of my confusion comes from using different workdirs for svn
branches, ie "clone" rather than "branch", because branching in svn is such
a PITA I just don't bother with it unless the branch is going to be
"heavyweight" enough to warrant a "proper" branch.
Good to be reminded of though, thanks.
--
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