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

Re: [PATCH v3 6/7] rebase: write better reflog messages

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 24, 2013, 07:57 UTC
Message-ID
<7vtxkoc557.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CALkWK0kj3UOx8sq+h=L0giUC-vn+h3by9o_6YbjA8ArRXZfgZw@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
Show 8 quoted lines
>>> +     # always reset GIT_REFLOG_ACTION before calling any external
>>> +     # scripts; they have no idea about our base_reflog_action
>>> +     GIT_REFLOG_ACTION="$base_reflog_action"
>>>       git am $git_am_opt --rebasing --resolvemsg="$resolvemsg"
>>
>> Why does this reroll still use this base_reflog_action convention?
>
> Because it's simple and it makes sense.

Without $base_reflog_action hack, you have to make sure GIT_REFLOG_ACTION is reasonably pristine when you call out other people. Even with $base_reflog_action, you still have to do the same "keep GIT_REFLOG_ACTION pristine" like this one. And in addition, you have to maintain $base_reflog_action as if it is a read-only variable [*1*].

So you are forcing people to maintain _two_ variables, instead of just _one_, without making anything simpler.

What's so hard to understand why it is a wrong design?
> ... and we're discussing absolutely trivial inconsequential rubbish
> once again.  In any case, I've given up on arguing with you as it is
> clear that I can't possibly win.  Do whatever you want.
It is not about winning or losing.

If you truly think this is "inconsequential", that unfortunately convinces me that you cannot yet be trusted enough to give you latitude to design interfaces that span multiple programs X-<.

[Footnote]

*1* The original orig_reflog_action you borrowed from was bad enough but it had an excuse that it was confined within the leaf level of the callchain. It was merely done as a way to stash the vanilla action name (e.g. "rebase -i" before it is specialized into "rebase -i pick" etc) away, so that it can easily "lose" the speciailzation from GIT_REFLOG_ACTION while preparing for the next operation.

Previous: Ramkumar RamachandraNext: Ramkumar Ramachandra
Message 12 of 14 in “Re-roll rr/rebase-checkout-reflog”
  1. 0/7 Re-roll rr/rebase-checkout-reflogRamkumar Ramachandra, Jun 19, 2013
  2. 1/7 t/t7512-status-help: test "HEAD detached from"Ramkumar Ramachandra, Jun 19, 2013
  3. 2/7 wt-status: remove unused field in grab_1st_switch_cbdataRamkumar Ramachandra, Jun 19, 2013
  4. 3/7 t/t2012-checkout-last: test "checkout -" after a rebaseRamkumar Ramachandra, Jun 19, 2013
  5. Johannes SixtJun 19, 2013
  6. Ramkumar RamachandraJun 19, 2013
  7. 4/7 status: do not depend on rebase reflog messagesRamkumar Ramachandra, Jun 19, 2013
  8. 5/7 checkout: respect GIT_REFLOG_ACTIONRamkumar Ramachandra, Jun 19, 2013
  9. 6/7 rebase: write better reflog messagesRamkumar Ramachandra, Jun 19, 2013
  10. Junio C HamanoJun 24, 2013
  11. Ramkumar RamachandraJun 24, 2013
  12. Junio C HamanoJun 24, 2013
  13. Ramkumar RamachandraJun 24, 2013
  14. 7/7 rebase -i: write better reflog messagesRamkumar Ramachandra, Jun 19, 2013

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.