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

Re: [PATCH v2] pull: handle --log=<n>

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
May 19, 2015, 13:35 UTC
Message-ID
<6b905c01c9b57abc05fb49117c28c10e@www.dscho.org>
In-Reply-To
<xmqq617pda0r.fsf@gitster.dls.corp.google.com>
Hi Junio,
On 2015-05-18 20:18, Junio C Hamano wrote:
Show 18 quoted lines
> I have been in love-hate relation with test_commit for a long time.
> It is very nice that it gives us ticks (i.e. reproducible object
> names) automatically and reduces the chance for new tests to forget
> to do so, but I found it extremely annoying that it wants to always
> add a light-weight tag to every commit it creates.
> 
> I suspect that this design decision largely comes from the fact that
> back then we did not exactly trust the syntax like "master~3" and
> wanted to have a set of fixed points, but often these auto-generated
> tags get in the way by either contaminating the refs namespaces (and
> we are testing pull here, which worries me that test authors need to
> be aware that these tags may be transferred to the destination) or
> anchoring the objects in the object database (e.g. when writing
> "reset --hard branch branch~3 && prune" tests, you need to remember
> to kill these tags).
> 
> So I dunno.  I really wish test_commit didn't create tags and either
> left the tagging to the calling script.
Yeah, light-weight tags with `test_commit` can be very annoying. IIRC the reason was not because we did not trust master~3, but that it is really unreadable. You have to be a Git nerd to find those tests intuitive that refer to master~3 which later is master~17 and then after a `git reset HEAD~5^2~3` is master~1 instead. The idea was that you could refer to the commits in question by their commit message.
I guess that I should clean up this mess and remove the tagging facility. We could use the :/<subject prefix> syntax instead, for example.
Or maybe just add a --tag flag to `test_commit` and use that in all cases where the tags were actually needed. Yeah, I think I like that option best.

Ciao, Dscho

Previous: Junio C HamanoNext: Junio C Hamano
Message 4 of 22 in “pull: handle --log=<n>”
  1. pull: handle --log=<n>Paul Tan, May 18, 2015
  2. Johannes SchindelinMay 18, 2015
  3. Junio C HamanoMay 18, 2015
  4. Johannes SchindelinMay 19, 2015
  5. Junio C HamanoMay 19, 2015
  6. Dennis KaarsemakerMay 19, 2015
  7. Stefan BellerMay 19, 2015
  8. Dennis KaarsemakerMay 19, 2015
  9. Junio C HamanoMay 19, 2015
  10. Dennis KaarsemakerMay 19, 2015
  11. Junio C HamanoMay 19, 2015
  12. Dennis KaarsemakerMay 19, 2015
  13. Junio C HamanoMay 19, 2015
  14. Junio C HamanoMay 20, 2015
  15. Dennis KaarsemakerMay 20, 2015
  16. Junio C HamanoMay 20, 2015
  17. Dennis KaarsemakerMay 20, 2015
  18. pull: handle --log=<n>Paul Tan, May 21, 2015
  19. Junio C HamanoMay 21, 2015
  20. Paul TanMay 22, 2015
  21. Paul TanMay 18, 2015
  22. Johannes SchindelinMay 18, 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.