[This is becoming off-topic. Sorry about that. We could take further follow-ups off the list.]
Martin Bähr <[email protected]> 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.
