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

Re: [PATCH 1/4] rebase -i: add ack action

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 12, 2016, 16:07 UTC
Message-ID
<xmqqd1pustdp.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<vpqr3ebnc9w.fsf@anie.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 9 quoted lines
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>
>> Interesting. An empty commit would be rather easy to create on any
>> branch, not just the current one, using git-commit-tree.
>
> This "modify a branch without checking-it out" makes me think of "git
> notes". It may make sense to teach "git rebase -i" to look for notes in
> rebased commits and append them to the commit message when applying.
> Just an idea, not necessarily a good one ;-).

Yeah that may actually fly well, as a note is designed to attach to an exact commit, not to a branch, so that feels more natural.

As to the "use commit-tree", well, personally I am not interested in a solution that can work well in my workflow ONLY if I further script it. That's half-solution and unless that half is done very well, I'd rather do a full solution better.

	Note: this is a continuation of "I personally would not use
	it, even though other people might" discussion.

I was also wondering if I should just script around filter-branch, if all I am futzing with is the data in the trailer block, doing the munging of the trailer block with interpret-trailers, naturally.

In any case, a recent occasion that I had to do something related to this topic may illustrate the boundary of requirements:

    Two developers, Michael and David, are involved.  David sends a
    24-patch series, some of which were written by Michael and
    others by David.  The in-body "From:" lines are set right and
    the resulting patches record authorship correctly.
    Michael reminds David that patches authored by Michael still
    need to be signed-off by David.  David sends a single message
    "those by Michael in this series are signed off by me".
    Michael also says that he reviewed all patches authored by
    David, i.e. "Add Acked-by Michael to all patches in this series
    authored by David".

Now this is an extreme case where a simple "OK I received an e-mailed Ack, so I can rely on the subject line matching to mark it to be squashed" approach will never work (i.e. if we were automating it I'd expect that the script in DSL to the automation machinery to take at last as many (conceptual) bits as the above problem description).

Previous: Michael S. TsirkinNext: Michael S. Tsirkin
Message 11 of 17 in “support for ack commits”
  1. 0/4 support for ack commitsMichael S. Tsirkin, Apr 10, 2016
  2. 1/4 rebase -i: add ack actionMichael S. Tsirkin, Apr 10, 2016
  3. Johannes SchindelinApr 11, 2016
  4. Michael S. TsirkinApr 11, 2016
  5. Johannes SchindelinApr 11, 2016
  6. Michael S. TsirkinApr 11, 2016
  7. Junio C HamanoApr 11, 2016
  8. Michael S. TsirkinApr 11, 2016
  9. Matthieu MoyApr 11, 2016
  10. Michael S. TsirkinApr 12, 2016
  11. Junio C HamanoApr 12, 2016
  12. Michael S. TsirkinApr 12, 2016
  13. Junio C HamanoApr 12, 2016
  14. Christian NeukirchenApr 11, 2016
  15. 2/4 git-rebase: document ackMichael S. Tsirkin, Apr 10, 2016
  16. 3/4 rebase: test ackMichael S. Tsirkin, Apr 10, 2016
  17. 4/4 git-ack: record an ackMichael S. Tsirkin, Apr 10, 2016

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.