On Feb 5, 2008, at 10:07 AM, Johannes Schindelin wrote:
Hi,
On Tue, 5 Feb 2008, Rhodes, Kate wrote:
If you have a file that exists in two branches in the same repo,
make a
change to it without committing, then switch branches the changes
carry
over, but if you make changes to a file that exists in only one of
the
repos and try and switch branches Git complains that the file isn't
uptodate. The latter behavior seems correct to me.
It is slightly different: if you change a file without committing _-
and-
the switch to another branch does not touch the file, git does not
complain.
The rationale: git should refuse to switch branches _only_ if
uncommitted
changes would be lost.
However, if you change a file whose content is different in the other
branch (and "not existing" qualifies), the uncommitted changes would
be
lost, and git should complain.
That makes sense, but I wonder if the distinction isn't a little too
subtle for most users to pick up on without being told, and if letting
uncommitted changes cross branches without some explicit user approval
is a good idea. I assume that once someone becomes really used to
working with multiple branches within the same repo you'd build up
subconscious safeguards against accidentally pulling changes into a
branch you didn't mean to, but I worry that it's going to be
problematic for users starting out with git.
To me it's like the difference between -d and -D in git-branch. It's
generally a good idea to use -d by default and have git warn you that
you're about to do something that could screw you up.
-kate == masukomi
-
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
