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