Re: Support for a series of patches, i.e. patchset or changeset?
- From
Eric Miao <eric.y.miao@gmail.com>
- Date
- Nov 6, 2012, 06:56 UTC
- Message-ID
- <CAMPhdO_yK02r4c5tTZxFGikmcPiG4G=PMzsPrYOtKCR51Ep0sw@mail.gmail.com>
- In-Reply-To
- <5098B09B.7060501@viscovery.net>
On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
Show 30 quoted lines
> Am 11/6/2012 1:58, schrieb Eric Miao: >> On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber >> <git@drmicha.warpmail.net> wrote: >>> Eric Miao venit, vidit, dixit 05.11.2012 15:12: >>>> The problem is, most cases we have no idea of the base rev1, and commit rev2 >>>> which it's leading up to. E.g. for a single patch which is between >>>> commit rev1..rev2, >>>> how do we find out rev1 and rev2. >> >> 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?
But this still looks like be inferred basing on a branch head, and I'm afraid this may not be applicable in every case.
> > -- Hannes