Martin Erik Werner <martinerikwerner@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html