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

On 05/03/2015 04:09 AM, Junio C Hamano wrote:

Michael Haggerty [off-list ref] writes:

quoted

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.

quoted

* 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.

quoted

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