Ramkumar Ramachandra <artag...@gmail.com> writes:
> Why does it search for a submodule with a trailing slash in the index?
> You make it sound like it's doing something unnatural; in reality, it
> does this because it executes lstat() on the filesystem path
> specified, and the stat mode matches S_ISDIR (because it _is_ a
> directory on the filesystem). It is stored in the index as an entry
> (without a trailing slash) with the mode 160000, gitlink.
>
> What happens if I attempt to git mv oldpath/ newpath/ (with the
> literal slashes, probably because I'm using a stupid shell
> completion)?
I think it should work.
mkdir a && >a/f && git add a/f && git mv a/ b/
>> Fix that by searching for the name without a trailing slash and continue
>> if it is a submodule.
>
> So, the correct solution is not to "search for a name without a
> trailing slash", but rather to handle the gitlink entry in the index
> appropriately.
For moving an entire directory's contents, because the index is
flat, you would look for "name/", because you know all of the paths
contained in it will share that prefix.
But when dealing with a submodule, you need to see if the path that
found to be a directory in the working tree is a gitlink in the
index. And the way to do so is to look for it without trailing
slash, because there is nothing hanging under it in the index.
So the right implementation of "handle appropriately" is to "search
without slash". They are saying the same thing, and the latter is a
more specific way to point out in what way the existing code that
wanted to delegate moving to "submodule mv" and not having to worry
about gitlinks was unprepared for it, and what change is needed to
make it "handle appropriately".
So I think there is no need to rephrase here, but your comment makes
me wonder if the patch covers the case where you have a submodule at
"a/x" and the user does "git mv a/ b/". The src_is_dir thing will
notice "a/" is a directory, finds all the paths inside a/ including
"a/x" (and we won't see any paths inside the submodule's working
tree) to "b/", and update the cache entries and the working tree.
Does the adjusting of the path for that moved submodule, which is a
theme for [PATCH 3/3], cover that case, too?
Another thing to wonder is if we correctly reject "git mv a/x/f here"
in the same example where a/x is a directory. The path is beyond
the lower boundary of our working tree and should not be touched.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
