git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
May 3, 2015, 02:09 UTC
Message-ID
<xmqqy4l6wgwm.fsf@gitster.dls.corp.google.com>
In-Reply-To
<1430483158-14349-1-git-send-email-mhagger@alum.mit.edu>
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.

Show 5 quoted lines
> * 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?
Show 7 quoted lines
> 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...

Previous: Michael HaggertyNext: Michael Haggerty
Message 24 of 25 in “Improve handling of D/F conflicts”
  1. 00/18 Improve handling of D/F conflictsMichael Haggerty, May 1, 2015
  2. 01/18 t1404: new tests of D/F conflicts within ref transactionsMichael Haggerty, May 1, 2015
  3. Eric SunshineMay 5, 2015
  4. Michael HaggertyMay 5, 2015
  5. 02/18 is_refname_available(): explain the reason for an early exitMichael Haggerty, May 1, 2015
  6. Stefan BellerMay 1, 2015
  7. Michael HaggertyMay 5, 2015
  8. 03/18 is_refname_available(): avoid shadowing "dir" variableMichael Haggerty, May 1, 2015
  9. 04/18 is_refname_available(): convert local variable "dirname" to strbufMichael Haggerty, May 1, 2015
  10. 05/18 entry_matches(): inline functionMichael Haggerty, May 1, 2015
  11. 06/18 report_refname_conflict(): inline functionMichael Haggerty, May 1, 2015
  12. 07/18 struct nonmatching_ref_data: store a refname instead of a ref_entryMichael Haggerty, May 1, 2015
  13. 08/18 is_refname_available(): use dirname in first loopMichael Haggerty, May 1, 2015
  14. 09/18 ref_transaction_commit(): use a string_list for detecting duplicatesMichael Haggerty, May 1, 2015
  15. 10/18 refs: check for D/F conflicts among refs processed in a transactionMichael Haggerty, May 1, 2015
  16. 11/18 verify_refname_available(): rename functionMichael Haggerty, May 1, 2015
  17. 12/18 verify_refname_available(): report errors via a "struct strbuf *err"Michael Haggerty, May 1, 2015
  18. 13/18 lock_ref_sha1_basic(): report errors via a "struct strbuf *err"Michael Haggerty, May 1, 2015
  19. 14/18 lock_ref_sha1_basic(): improve diagnostics for D/F conflictsMichael Haggerty, May 1, 2015
  20. 15/18 rename_ref(): integrate lock_ref_sha1_basic() errors into oursMichael Haggerty, May 1, 2015
  21. 16/18 ref_transaction_commit(): provide better error messagesMichael Haggerty, May 1, 2015
  22. 17/18 ref_transaction_commit(): delete extra "the" from error messageMichael Haggerty, May 1, 2015
  23. 18/18 reflog_expire(): integrate lock_ref_sha1_basic() errors into oursMichael Haggerty, May 1, 2015
  24. Junio C HamanoMay 3, 2015
  25. Michael HaggertyMay 5, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.