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