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

Re: [PATCH v6 1/7] refs.c: add err arguments to reflog functions

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Jul 9, 2015, 06:47 UTC
Message-ID
<559E1917.6000205@alum.mit.edu>
In-Reply-To
<xmqqr3oiy3pm.fsf@gitster.dls.corp.google.com>
On 07/08/2015 07:11 PM, Junio C Hamano wrote:
Show 38 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> I think your v7 of this patch goes too far, by turning a failure to
>> write to the reflog into a failure of the whole transaction. The problem
>> is that this failure comes too late, in the commit phase of the
>> transaction. Aborting at this late stage can leave some references
>> changed and others rolled back, violating the promise of atomicity.
> 
> Yeah, that sounds problematic.
> 
>> The old code reported a failure to write the reflog to stderr but didn't
>> fail the transaction. I think that behavior is more appropriate. The
>> reflog is of lower importance than the references themselves. Junio, do
>> you agree?
> 
> That is actually a loaded question.
> 
> Do I agree that the current (i.e. before this change) behaviour is
> more appropriate given the current choice of representation of refs
> and reflogs on the filesystem, treating a failure to update reflog
> as lower importance event and accept it as a limitation that it
> cannot abort the whole transaction atomically?  Compared to leaving
> the repository in a half-updated state where some refs and their
> logs are updated already, other remaining proposed updates are
> ignored, and the transaction claims to have failed even though some
> things have already changed and we cannot rollback, I would say that
> is a better compromise to treat reflog update as a lower importance.
> 
> Do I agree that reflog writing should stay to be best-effort in the
> longer term?  Not really.  If we are moving the ref API in the
> direction where we can plug a backend that is different from the
> traditional filesystem based one for storing refs, I think the
> backend should also be responsible for storing logs for the refs it
> stores, and if the backend wants to promise atomicity, then we
> should be able to fail the whole transaction when updates to refs
> could proceed but updates to the log of one of these updated refs
> cannot.  So I do not agree to cast in stone "the reflog is of lower
> importance" as a general rule.
Junio,

You make a good distinction. I was describing a compromise that we have to make now due to the limitations of the current ref/reflog backend. But I agree 100% that a future storage backend that can do correct rollback of refs *and* reflogs can fail a transaction if the reflog updates cannot be committed.

Thanks, Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
Previous: Junio C HamanoNext: David Turner
Message 7 of 31 in “refs backend preamble”
  1. 0/7 refs backend preambleDavid Turner, Jun 29, 2015
  2. 1/7 refs.c: add err arguments to reflog functionsDavid Turner, Jun 29, 2015
  3. Michael HaggertyJul 6, 2015
  4. David TurnerJul 7, 2015
  5. Michael HaggertyJul 8, 2015
  6. Junio C HamanoJul 8, 2015
  7. Michael HaggertyJul 9, 2015
  8. 2/7 cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refsDavid Turner, Jun 29, 2015
  9. Michael HaggertyJul 6, 2015
  10. 3/7 bisect: treat BISECT_HEAD as a refDavid Turner, Jun 29, 2015
  11. 4/7 refs: Break out check for reflog autocreationDavid Turner, Jun 29, 2015
  12. 5/7 refs: new public ref function: safe_create_reflogDavid Turner, Jun 29, 2015
  13. Michael HaggertyJul 6, 2015
  14. David TurnerJul 7, 2015
  15. Michael HaggertyJul 8, 2015
  16. 6/7 git-reflog: add create and exists functionsDavid Turner, Jun 29, 2015
  17. Eric SunshineJun 30, 2015
  18. David TurnerJun 30, 2015
  19. Junio C HamanoJun 30, 2015
  20. Eric SunshineJun 30, 2015
  21. Junio C HamanoJun 30, 2015
  22. David TurnerJun 30, 2015
  23. Junio C HamanoJun 30, 2015
  24. Michael HaggertyJul 6, 2015
  25. David TurnerJul 8, 2015
  26. Michael HaggertyJul 8, 2015
  27. David TurnerJul 8, 2015
  28. 7/7 git-stash: use git-reflog instead of creating filesDavid Turner, Jun 29, 2015
  29. Junio C HamanoJun 29, 2015
  30. Junio C HamanoJun 29, 2015
  31. David TurnerJun 29, 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.