Re: [PATCH 00/18] Improve handling of D/F conflicts

[Michael Haggerty <mhagger@alum.mit.edu>]

On 05/03/2015 04:09 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> 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@alum.mit.edu