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