Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > We currently don't handle D/F conflicts very well. > > A "D/F conflict" is what we call a conflict between references like > "refs/foo" and "refs/foo/bar". Could you phrase that slightly differently, so that readers can tell between the usual D/F conflict that is between directory and file in the tracked contents (i.e. conflict between the branches being merged, killing of a directory necessary when checking out a file, etc.) and this thing? They are similar in nature, but "D/F conflict" has been used to refer to the clashes that happen to the user contents, not refnames. Starting a paragraph with "... don't handle D/F conflicts in refnames very well" and then using "D/F conflict" as a short-hand for "D/F conflict in refnames" throughout the rest of the message is perfectly fine, as long as the message never talks about the D/F conflict in the traditional sense. > * D/F conflicts between references being created in a single > transaction used to be detected too late, possibly after part of the > transaction had already been committed. > > * D/F errors against loose references were typically reported as Be consistent by s/errors/conflicts/ perhaps? > This patch series applies on top of > mh/ref-lock-avoid-running-out-of-fds. I did it that way because I > expected significant conflicts between the series, and the older > series is simple/mature enough that I expect it to be merged early in > the post-2.4 cycle. But in retrospect it turns out that there are only > minor conflicts between the two series. So if you would like me to > rebase this series to another starting point, please let me know. Thanks for being considerate about back-porting necessity. As I have written, I actually would prefer to see that the other topic, ref-lock-avoid-running-out-of-fds, to be made applicable to older maintenance tracks. 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