Re: Support for a series of patches, i.e. patchset or changeset?
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 wrote: > > > 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.weig...@vnc.biz; www.vnc.de -- 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
Re: Support for a series of patches, i.e. patchset or changeset?
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.weig...@vnc.biz; www.vnc.de -- 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
Re: Support for a series of patches, i.e. patchset or changeset?
On Fri, Nov 9, 2012 at 3:09 AM, Jeff King 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. -- 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
Re: Support for a series of patches, i.e. patchset or changeset?
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 -- 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
Re: Support for a series of patches, i.e. patchset or changeset?
On Tue, Nov 6, 2012 at 3:44 PM, Johannes Sixt wrote: > Am 11/6/2012 7:56, schrieb Eric Miao: >> On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt 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? > > -- 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
Re: Support for a series of patches, i.e. patchset or changeset?
Am 11/6/2012 7:56, schrieb Eric Miao: > On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt 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 -- 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
Re: Support for a series of patches, i.e. patchset or changeset?
On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt wrote: > Am 11/6/2012 1:58, schrieb Eric Miao: >> On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber >> 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
Re: Support for a series of patches, i.e. patchset or changeset?
Am 11/6/2012 1:58, schrieb Eric Miao: > On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber > 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 -- 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
Re: Support for a series of patches, i.e. patchset or changeset?
On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber 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? -- 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
Re: Support for a series of patches, i.e. patchset or changeset?
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 -- 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
Re: Support for a series of patches, i.e. patchset or changeset?
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 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 > -- 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
Re: Support for a series of patches, i.e. patchset or changeset?
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 -- 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
