On 05/03/2015 04:09 AM, Junio C Hamano wrote: > 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. Good point. I will clarify this. >> * 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? Yes, thanks. >> 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... OK, I will rebase this branch onto "master", and simultaneously check how much work it would be to implement a version of ref-lock-avoid-running-out-of-fds on top of 2.3 and/or 2.2. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx -- 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