Re: Support for a series of patches, i.e. patchset or changeset?
- From
Johannes Sixt <j.sixt@viscovery.net>
- Date
- Nov 6, 2012, 07:44 UTC
- Message-ID
- <5098BFC0.6040709@viscovery.net>
- In-Reply-To
- <CAMPhdO_yK02r4c5tTZxFGikmcPiG4G=PMzsPrYOtKCR51Ep0sw@mail.gmail.com>
Am 11/6/2012 7:56, schrieb Eric Miao:
Show 26 quoted lines
> On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt <j.sixt@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?
-- Hannes