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