Martin Erik Werner <> 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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to