Re: [BUG] git checkout <branch> allowed with uncommitted changes

On Thu, 2011-10-13 at 15:53 +0000, arQon wrote:

Carlos Martín Nieto <cmn <at> elego.de> writes:

quoted

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".

quoted

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.

quoted

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.

If file1.txt in the foo branch is different from the one in the master
branch, git will refuse to switch branches. 'git diff foo master' should
show that those two files are different.

quoted

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).

Yes, this is a great feature of distributed systems. A local repo is
where you experiment. Treat it as your own personal space to play around
with things. Committing non-working code is fine, as long as you don't
push it out.

quoted

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.

Then the issue is that you've changed the workflow but haven't adjusted
for it. You can do this as well with the git-new-workdir. As I mentioned
it has a few rough edges, but if you're going to use it to have a
checkout of a particular branch, it shouldn't present any problems. That
would be like your current workflow.

Another option is to clone with a reference which will create a brand
new clone but will use the objects that you've already downloaded (or
just clone locally). This can be more comfortable than using the
new-workdir and will hardly put any strain on the filesystem.

The bigger problem seems to be your reluctance to accept that git is
different from subversion, as you keep saying "that's just how git is"
to back your claim that you can't trust git on a feature where
subversion behaves the same way. If you'd rather use different
directories for different branches, you can. That is not an aspect which
you can point to and say that you can't migrate to git for that reason.
If you're more comfortable with subversion, that's fine also, it's an
excellent piece of software[0], but don't go around saying that git
corrupts branches when that's blatantly not true.

   cmn

[0] Whatever one may think about the merits of CVCS vs DVCS; that
shouldn't come into the quality of the software.