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

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

From
Jeff King <peff@peff.net>
Date
Feb 17, 2017, 19:43 UTC
Message-ID
<20170217194350.prhp5joh33cbvwsd@sigill.intra.peff.net>
In-Reply-To
<xmqqk28ou2o1.fsf@gitster.mtv.corp.google.com>
On Fri, Feb 17, 2017 at 09:50:54AM -0800, Junio C Hamano wrote:
Show 18 quoted lines
> > I see we actually already have a "logmsg" parameter. It already says
> > "Branch: renamed %s to %s". Could we just reuse that? I know that this
> > step is technically just the deletion, but I think it more accurately
> > describes the whole operation that the deletion is part of.
> 
> True, but stepping back a bit,...
> 
> Do we even want these "internal" delete_ref() invocations to be
> logged in HEAD's reflog?  I understand that this is inside the
> implementation of renaming an old ref to a new ref, and reflog
> message given to delete_ref() would matter only if the HEAD happens
> to be pointing at old ref---but then HEAD will be repointed to the
> new ref by somebody else [*1*] that called this function to rename
> old to new and it _will_ log it.  So I am not sure if it is a good
> thing to describe the deletion more readably with a message (which
> is what this patch does) in the first place.  If we can just say
> "don't log this deletion event in HEAD's reflog", wouldn't that be
> more desirable?

Yes. I think the options are basically (in order of decreasing preference in my opinion):

  1. Log a rename entry (same sha1, but note the rename in the free-form
     text).
  2. Log a delete (sha1 goes to null) followed by a creation (from null
     back to the original sha1).
  3. Log nothing at all for HEAD.

This does half of (2). If we do the second half, then I'd prefer it to (3). But if we can do (1), that is better still (IMHO).

> *1* Is the reason why the code in files_rename_ref() we are looking
>     at does not adjust HEAD to point at the new ref is because it is
>     just handing one ref-store and obviouvious to symrefs in other
>     backends?

I'm actually confused about which bit of code is updating HEAD. I do not see it either in files_rename_ref() or in the caller. Yet it clearly happens. But that is the code that would know enough to do (1) or the second half of (2) above.

-Peff
Previous: Junio C HamanoNext: Jeff King
Message 18 of 36 in “HEAD's reflog entry for a renamed branch”
  1. Kyle MeyerJan 16, 2017
  2. Jeff KingJan 26, 2017
  3. Junio C HamanoJan 26, 2017
  4. Jeff KingJan 26, 2017
  5. 0/3 delete_ref(): support reflog messagesKyle Meyer, Feb 17, 2017
  6. 1/3 delete_refs(): accept a reflog message argumentKyle Meyer, Feb 17, 2017
  7. Jeff KingFeb 17, 2017
  8. Junio C HamanoFeb 17, 2017
  9. Kyle MeyerFeb 17, 2017
  10. 2/3 update-ref: pass reflog message argument to delete_refsKyle Meyer, Feb 17, 2017
  11. Jeff KingFeb 17, 2017
  12. Junio C HamanoFeb 17, 2017
  13. Kyle MeyerFeb 17, 2017
  14. Jeff KingFeb 17, 2017
  15. 3/3 rename_ref: replace empty deletion message in HEAD's logKyle Meyer, Feb 17, 2017
  16. Jeff KingFeb 17, 2017
  17. Junio C HamanoFeb 17, 2017
  18. Jeff KingFeb 17, 2017
  19. Jeff KingFeb 17, 2017
  20. Junio C HamanoFeb 17, 2017
  21. Kyle MeyerFeb 17, 2017
  22. Kyle MeyerFeb 17, 2017
  23. Jeff KingFeb 17, 2017
  24. Junio C HamanoFeb 17, 2017
  25. Jeff KingFeb 17, 2017
  26. 0/4 delete_ref: support reflog messagesKyle Meyer, Feb 21, 2017
  27. 1/4 delete_ref: accept a reflog message argumentKyle Meyer, Feb 21, 2017
  28. Duy NguyenFeb 23, 2017
  29. Junio C HamanoFeb 23, 2017
  30. Kyle MeyerFeb 25, 2017
  31. 2/4 update-ref: pass reflog message to delete_ref()Kyle Meyer, Feb 21, 2017
  32. 4/4 branch: record creation of renamed branch in HEAD's logKyle Meyer, Feb 21, 2017
  33. 3/4 rename_ref: replace empty message in HEAD's logKyle Meyer, Feb 21, 2017
  34. Jeff KingFeb 21, 2017
  35. Junio C HamanoFeb 21, 2017
  36. Kyle MeyerFeb 21, 2017

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.