Re: Support for a series of patches, i.e. patchset or changeset?

[Jeff King <peff@peff.net>]

On Tue, Nov 06, 2012 at 08:58:35AM +0800, Eric Miao wrote:

> > So, then the question is: What do you know/have? Is your patch the
> > output of "git format-patch", "git diff", or just some sort of diff
> > without any git information?
> 
> That doesn't matter, all the info can be obtained from the SHA1 id, the
> question is: do we have a mechanism in git (or hopefully we could add)
> to record the patchset or series the patch belongs to, without people to
> guess heuristically.
> 
> E.g. when we merged a series of patches:
> 
>   [PATCH 00/08]
>   [PATCH 01/08]
>   ...
>   [PATCH 08/08]
> 
> How do we know this whole series after merged when only one of these
> commits are known?

Others have described how you can infer this structure from the history
graph, but as you noted, the graph does not always match the series that
was sent, nor does it contain some of the meta information about the
cover letter, associated discussions, etc.

If you want to track the mapping between mailed patches (or any other
form of changeset id) to commits, you can put it in git in one of two
places:

  1. In a pseudo-header at the end of the commit message. E.g., you
     could use the message-id of the cover letter as a unique identifier
     for the changeset, and put "Changeset: $MID" at the end of each
     commit message. Then you can use "--grep" to find other entries
     from the same changeset.

  2. You can use git-notes to store the same information outside of the
     commit message. This doesn't get pushed around automatically with
     the history, but it means your commit messages are not polluted,
     and you can make annotations after the commits are set in stone.

I do not use Gerrit, but I recall that they do something like (1) to
mark changesets. For git development, one of the contributors does (2)
to point notes at mailing list threads (I think he uses a script to
match up mails and commits after the fact).

But fundamentally the idea of "this is a set of logical changes" is not
represented in git's DAG. It's up to you to store changeset tokens
if you care about them.

-Peff