On Tue, Nov 6, 2012 at 3:44 PM, Johannes Sixt <j.s...@viscovery.net> wrote: > Am 11/6/2012 7:56, schrieb Eric Miao: >> On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt <j.s...@viscovery.net> wrote: >>> Am 11/6/2012 1:58, schrieb Eric Miao: >>>> 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? >>> >>> You can use git name-rev. For example: >>> >>> $ git name-rev 9284bdae3 >>> 9284bdae3 remotes/origin/pu~2^2~7 >>> >>> This tell you that the series was merged two commits before origin/pu, and >>> then it is the 7th from the tip of the series. Now you can >>> >>> $ git log origin/pu~2^..origin/pu~2^2 >>> >>> to see the whole series. >> >> I'm just curious how this is implemented in git, are we keeping the info >> of the series that's applied in a whole? > > If the maintainer did his job well, then everything that you had in [PATCH > 01/08] ... [PATCH 08/08] is in the commits of the series, and [PATCH > 00/08] (the cover letter) is in the commit that merged the series. > > Anything else that I didn't mention but you consider as "the info of the > series"? > >> But this still looks like be inferred basing on a branch head, and I'm >> afraid this may not be applicable in every case. > > What's the problem? That it's inferred? Or that it needs a branch head?
Take kernel development for example, sub-maintainers not always keep a patchset in a single branch, instead, there could be a mix of patchset and single fixing patches on a same branch: ---A1---A2---A3---B---C---D---E1---E2---E3---E4---F---G---H---> branch When we identify a specific patch, e.g. E3, is it possible to figure out the whole patchset of E<n>? > > -- Hannes -- 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
