On Mon, May 23, 2011 at 10:37:17PM +0200, Renà Scharfe wrote:
> $ echo 1 >a
> $ git add a
> $ git commit -m.
> [master (root-commit) b0e60d3] .
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 a
>
> $ git branch x
> $ echo uncommitted >a
> $ echo untracked >b
>
> $ git checkout x
> M a
> Switched to branch 'x'
But you're not actually switching trees here, so there is by definition
no merge that needs to happen, and the changes stay in place.
> $ cat a
> uncommitted
> $ cat b
> untracked
And here, there is no contention over "b" since git would never need to
write it at all.
A better test would be:
git init repo && cd repo
echo 1 >a && git add a && git commit -m a1
echo 2 >a && git add a && git commit -m a2
git checkout -b check-uncommitted master^
# should fail because we would have to merge
echo 3 >a && git checkout master
git checkout -f master
echo 4 >b && git add b && git commit -m b4
git checkout -b check-untracked master^
echo untracked >b
# should fail because we would overwrite untracked b
git checkout master
And indeed, testing with v1.7.3., both of my "should fail" checkouts do
fail, with the following messages respectively:
error: Your local changes to the following files would be overwritten by checkout:
a
Please, commit your changes or stash them before you can switch branches.
Aborting
and
error: The following untracked working tree files would be overwritten by checkout:
b
Please move or remove them before you can switch branches.
Aborting
So I still don't know what the bug is.
-Peff
--
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