[This is becoming off-topic. Sorry about that. We could take further
follow-ups off the list.]
Martin Bähr <<mbaehr[at]email.archlab.tuwien.ac.at>> wrote:
> [git] only barks if you have changes to a file in branch a but the
> file does not even exist in branch b, because then it wants to wipe
> the file which would cause your changes to be lost, /.../
Oh, I see. That could explain it. In my case it'd be better if it just
left the file alone and instead treated it as untracked after the
switch.
> in either case you can tell it to merge the changes with git
> checkout -m
Thanks for the tip. It works for switching from a to b, but it gets
complicated to switch back again since the new file is considered a
merge conflict that needs to be resolved first:
kolon:~/Pike/git> git checkout -m a
foo: needs merge
I don't want to add it to b so I resolve the conflict with "git rm
--cached", but then it complains about overwriting the file when
switching back:
kolon:~/Pike/git> git checkout a
error: Untracked working tree file 'foo' would be overwritten by merge.
What I'd like in this case is of course that git just leaves my
working copy untouched, so a later diff again shows the differences
between it an the head on branch a.
> how do you keep track of which branch you have checked out in which
> directory? i think that can get messy quickly.
Keeping track of it is just a matter of storing more state in .git.
It's solvable.
From cvs I'm used to dealing with different branches in different
directories, and I don't think it gets particularly messy. More modern
tools like svn and git which tracks trees have problems with that, and
I guess there are a set of fringe cases, like directory
moves/deletes/etc, that needs special attention. But I believe it
should be possible to work out, at least as long as the relevant
directories stays in place.
> but why do you need to check out a branch to quickly check
> something?
I usually have a working tree which has assorted small changes spread
out in many places, but not (any significant) in this particular
directory. I then want to take a look at some older version there,
typically to track down a bug. I usually want to rewind all the files
in it since they relate to each other.
I know I can use stashing to get conflicting changes in other parts
out of the way, but that's cumbersome. What I want is to operate on
this directory only - git has no business messing around with the rest
of the working tree.
After fixing the bug I'd like to forward the directory to HEAD again,
so that git rebases my fix and I can check it in.
|