Re: [PATCH 0/4] ack recoding in commit log

[Fabian Ruch <bafain@gmail.com>]

Hi Michael,

On 05/18/2014 11:17 PM, Michael S. Tsirkin wrote:
> As a maintainer, I often get patches by mail, then
> acked-by,reviewed-by etc responses are sent by separate
> mail.
> 
> I like making acks commits,
> this way they are easy to keep track of
> as part of git history.

In order to fully understand your additions, I think, I need some
clarification on the term "ack commit". What is an ack commit exactly?
Suppose our principal commit has the commit message

    Some changes

    The changes are...

    Signed-off-by: A U Thor <author@example.com>

and we receive an email from Somebody saying

    > Some changes
    >
    > The changes are...
    >
    > Signed-off-by: A U Thor <author@example.com>

    Reviewed-by: Somebody <somebody@example.com>

. Now, if I understand correctly, we create an empty commit on top of
the principal commit using the following commit message.

    Some changes

    Reviewed-by: Somebody <somebody@example.com>

Is this commit then called an ack commit?

Can an ack commit be non-empty?

Is a commit still an ack if its description mentions additional text
between the subject and the tag lines?

Maybe the ack command for todo lists and ack commits have little to do
with one another. If we stick to the term "ack commit", then the command
name suggests that it takes the tags from some commit b and appends them
to the list of tags in the previous commit's (a) message:

    pick a A commit
    ack  b The next commit

However, this obviously does not work by just appending messages. For
instance, there could be additional text before or after some tag line
in either commit message. If we treat the workflow you described as a
very specific use case of the ack command instead, it seems reasonable
to add such a todo list functionality for melding commits by silently
appending messages. However, we might consider parametrizing a single
squash command instead of defining just another name that one has to
keep in mind for melding commits:

    pick             a A commit
    squash --no-edit b The next commit

> Since response mail happens to have appropriate
> subject matching the patch, it's a natural fit to
> then use git rebase mechanics if we want to smash
> these acks into the original commit.
> 
> I have been using these patches without any problems
> for a while now, and find the approach very convenient.
> 
> Included:
> 	rebase: new ack! action to handle ack commits
> 		this part seems ready for merge to me,
> 		please review and comment
> 
> 	git-ack: new tool to record an ack
> 		this does not have proper documentation
> 		and tests yet, I definitely intend to
> 		do this but wanted to see whether people
> 		like the UI first.
> 		posting for early review and feedback
> 
> [..]

Thanks for your time,
   Fabian