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@xxxxxxxxxxx>
and we receive an email from Somebody saying
> Some changes
>
> The changes are...
>
> Signed-off-by: A U Thor <author@xxxxxxxxxxx>
Reviewed-by: Somebody <somebody@xxxxxxxxxxx>
. 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@xxxxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html