Martin Erik Werner <martinerikwer...@gmail.com> writes:
> When symlinks in the working tree are manipulated using the absolute
> path, git dereferences them, and tries to manipulate the link target
> instead.
The above may a very good description of the root cause, but
can we have description of a symptom that is visible by end-users
that is caused by the bug being fixed with the series here, by
ending the above like so:
... link target instead. This causes "git foo bar" to
misbehave in this and that way.
Testing the low-level underlying machinery like this patch does is
not wrong per-se, but I suspect that this series was triggered by
somebody noticing breakage in a end-user command "git foo $path"
with $path being a full pathname to an in-tree symbolic link. It
wouldn't be like somebody who was bored and ran "test-path-utils"
for fun noticed the root cause without realizing how the fix would
affect the behaviour that would be visible to end-users, right?
Can we have that "git foo $path" to the testsuite as well? That is
the breakage we do not want to repeat in the future by regressing.
I am guessing "foo" is "add", but I wasn't closely following the
progression of the series.
Thanks.
--
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
