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

[Eric Miao <eric.y.miao@gmail.com>]

On Fri, Nov 9, 2012 at 3:09 AM, Jeff King <peff@peff.net> wrote:
> 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).

Thanks Jeff, this is the answer I'm looking for, really appreciated to
get it explained so clearly.

>
> 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.

Sure, I completely understand and agree we should keep git simple enough.