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:
>> On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber
>> <g...@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
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

Reply via email to