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

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

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

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
[off-list ref] wrote:

Eric Miao venit, vidit, dixit 05.11.2012 03:26:

quoted

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

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

On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber
[off-list ref] wrote:

Eric Miao venit, vidit, dixit 05.11.2012 15:12:

quoted

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?

Am 11/6/2012 1:58, schrieb Eric Miao:

On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber
[off-list ref] wrote:

quoted

Eric Miao venit, vidit, dixit 05.11.2012 15:12:

quoted

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

On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt [off-list ref] wrote:

Am 11/6/2012 1:58, schrieb Eric Miao:

quoted

On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber
[off-list ref] wrote:

quoted

Eric Miao venit, vidit, dixit 05.11.2012 15:12:

quoted

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

Am 11/6/2012 7:56, schrieb Eric Miao:

On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt [off-list ref] wrote:

quoted

Am 11/6/2012 1:58, schrieb Eric Miao:

quoted

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

On Tue, Nov 6, 2012 at 3:44 PM, Johannes Sixt [off-list ref] wrote:

Am 11/6/2012 7:56, schrieb Eric Miao:

quoted

On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt [off-list ref] wrote:

quoted

Am 11/6/2012 1:58, schrieb Eric Miao:

quoted

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"?

quoted

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

On Tue, Nov 06, 2012 at 08:58:35AM +0800, Eric Miao wrote:

quoted

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

On Fri, Nov 9, 2012 at 3:09 AM, Jeff King [off-list ref] wrote:

On Tue, Nov 06, 2012 at 08:58:35AM +0800, Eric Miao wrote:

quoted

quoted

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.

<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 

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 [off-list ref] 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