Support for a series of patches, i.e. patchset or changeset?

Support for a series of patches, i.e. patchset or changeset?

[Eric Miao]

Hi All,

Does anyone know if git has sort of support for a series of patches, i.e.
a patchset or changeset? So whenever we know the SHA1 id of a single
patch/commit, we know the patchset it belongs to. This is normal when
we do big changes and split that into smaller pieces and doing only one
simple thing in a single commit.

This will be especially useful when tracking and cherry-picking changes,
i.e. monitoring on the changes of some specific files, and if a specific
patch is interesting, we may want to apply the whole changeset, not only
that specific one.

Ideas?
- eric

Re: Support for a series of patches, i.e. patchset or changeset?

[Michael J Gruber]

Eric Miao venit, vidit, dixit 05.11.2012 03:26:
> Hi All,
> 
> Does anyone know if git has sort of support for a series of patches, i.e.
> a patchset or changeset? So whenever we know the SHA1 id of a single
> patch/commit, we know the patchset it belongs to. This is normal when
> we do big changes and split that into smaller pieces and doing only one
> simple thing in a single commit.
> 
> This will be especially useful when tracking and cherry-picking changes,
> i.e. monitoring on the changes of some specific files, and if a specific
> patch is interesting, we may want to apply the whole changeset, not only
> that specific one.

First of all, if you know the sha1 of a commit, then all its ancestors
are determined by that. If you want to describe a set of patches, say
based on rev1 and leading up to rev2, then the expression

rev2 ^rev1

describes that set uniquely. Often you can do without ^rev1, e.g. if you
know that all patch series are developed bases on origin/master, then
specifying rev2 is enough as "git rev-list rev2 ^origin/master" will
give you all commits in the series (unless they have been integrated,
i.e. merged).

Or are you thinking about patches "independent" of a base?

Cheers,
Michael

Re: Support for a series of patches, i.e. patchset or changeset?

[Eric Miao]

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.

On Mon, Nov 5, 2012 at 9:39 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Eric Miao venit, vidit, dixit 05.11.2012 03:26:
>> Hi All,
>>
>> Does anyone know if git has sort of support for a series of patches, i.e.
>> a patchset or changeset? So whenever we know the SHA1 id of a single
>> patch/commit, we know the patchset it belongs to. This is normal when
>> we do big changes and split that into smaller pieces and doing only one
>> simple thing in a single commit.
>>
>> This will be especially useful when tracking and cherry-picking changes,
>> i.e. monitoring on the changes of some specific files, and if a specific
>> patch is interesting, we may want to apply the whole changeset, not only
>> that specific one.
>
> First of all, if you know the sha1 of a commit, then all its ancestors
> are determined by that. If you want to describe a set of patches, say
> based on rev1 and leading up to rev2, then the expression
>
> rev2 ^rev1
>
> describes that set uniquely. Often you can do without ^rev1, e.g. if you
> know that all patch series are developed bases on origin/master, then
> specifying rev2 is enough as "git rev-list rev2 ^origin/master" will
> give you all commits in the series (unless they have been integrated,
> i.e. merged).
>
> Or are you thinking about patches "independent" of a base?
>
> Cheers,
> Michael
>

Re: Support for a series of patches, i.e. patchset or changeset?

[Michael J Gruber]

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.

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?

Michael

Re: Support for a series of patches, i.e. patchset or changeset?

[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.
>
> 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?

Re: Support for a series of patches, i.e. patchset or changeset?

[Johannes Sixt]

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.

-- Hannes

Re: Support for a series of patches, i.e. patchset or changeset?

[Eric Miao]

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:
>> 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

Re: Support for a series of patches, i.e. patchset or changeset?

[Johannes Sixt]

Am 11/6/2012 7:56, schrieb Eric Miao:
> 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

Re: Support for a series of patches, i.e. patchset or changeset?

[Eric Miao]

On Tue, Nov 6, 2012 at 3:44 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 11/6/2012 7:56, schrieb Eric Miao:
>> 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?

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

Re: Support for a series of patches, i.e. patchset or changeset?

[Jeff King]

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).

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.

-Peff

Re: Support for a series of patches, i.e. patchset or changeset?

[Eric Miao]

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

Re: Support for a series of patches, i.e. patchset or changeset?

[Enrico Weigelt]

<snip>

yet another idea:

you coud always put your patchsets into separate branches,
rebase them ontop target branch before merging, and then
do an non-ff-merge, which will make the history look like:

* merged origin/feature_foo
|\
| * first preparation fo feature foo
| * part a
| * part b
|/
* merged origin/bugfix_blah
|\
| * fixing bug blah
|/
*


cu
-- 
Mit freundlichen Grüßen / Kind regards 

Enrico Weigelt 
VNC - Virtual Network Consult GmbH 
Head Of Development 

Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59

enrico.weigelt@vnc.biz; www.vnc.de 

Re: Support for a series of patches, i.e. patchset or changeset?

[Eric Miao]

Yeah, that's a very clean way I'd always want to follow, yet the
kernel upstream isn't doing so.

On Sat, Nov 10, 2012 at 4:52 PM, Enrico Weigelt <enrico.weigelt@vnc.biz> wrote:
> <snip>
>
> yet another idea:
>
> you coud always put your patchsets into separate branches,
> rebase them ontop target branch before merging, and then
> do an non-ff-merge, which will make the history look like:
>
> * merged origin/feature_foo
> |\
> | * first preparation fo feature foo
> | * part a
> | * part b
> |/
> * merged origin/bugfix_blah
> |\
> | * fixing bug blah
> |/
> *
>
>
> cu
> --
> Mit freundlichen Grüßen / Kind regards
>
> Enrico Weigelt
> VNC - Virtual Network Consult GmbH
> Head Of Development
>
> Pariser Platz 4a, D-10117 Berlin
> Tel.: +49 (30) 3464615-20
> Fax: +49 (30) 3464615-59
>
> enrico.weigelt@vnc.biz; www.vnc.de