Bryan Turner <bturner@xxxxxxxxxxxxx> writes:
> I've witnessed the following behavior in both git 1.7.6 and 1.7.10.4.
>
> Assume I have a bare clone, some-repo.git. If I run:
> - git clone --shared --no-checkout /path/to/some-repo.git shared-repo
> - cd shared-repo
> - git status
I do not recall we *designed* it in such a way that you would commit
an empty tree if you run "git commit" immediately after making such
a clone. But I do not think it is a bug, either.
I think the most likely reason nobody even noticed this is because
the expected use scenario for --no-checkout is when user does not
know (and does not care to find out) what branch is checked out (if
nonbare) or marked as the primary (if bare) in the repository she is
cloning from, and will checkout the branch she wants to work on
immediately after cloning, i.e.
git clone -n $over_there here
cd here
# she knows she wants to fork from 'nitfol'
git checkout -t -b frotz origin/nitfol
Not having anything in the $GIT_DIR/index (which is why you see
"everything is removed from the index, you will commit an empty
tree" in the status output) does not matter in this scenario,
because the first command she invokes will be "git checkout".
If you populated $GIT_DIR/index from the tree of HEAD, you would see
everything is deleted in the working tree. You can simulate it by
doing this:
git clone -n $over_there here
cd here
git read-tree HEAD
git status
But it would not help people who want to check another branch out
immediately after cloning with -n, which is the whole point of the
option, so...
--
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