linux-kernel - Re: [ANNOUNCE] git-series: track changes to a patch series over time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 31 Jul 2016 15:09:36 +0100
From:	Richard Ipsum <richard.ipsum@...ethink.co.uk>
To:	Stefan Beller <sbeller@...gle.com>
Cc:	Josh Triplett <josh@...htriplett.org>,
	"git@...r.kernel.org" <git@...r.kernel.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	Dave Borowitz <dborowitz@...gle.com>
Subject: Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Fri, Jul 29, 2016 at 09:59:08AM -0700, Stefan Beller wrote:
> On Fri, Jul 29, 2016 at 5:44 AM, Richard Ipsum
> <richard.ipsum@...ethink.co.uk> wrote:
> >>
> >> These definitely seem like a family of related problems.  I'd like to
> >> use git-series as a format for storing iterations on things like GitHub
> >> pull-requests or Gerrit patch versions (in the latter case, overcoming
> >> Gerrit's limitations on only handling one patch at a time).  Integrating
> >> reviews with that seems helpful.
> >
> > Worth noting here that Gerrit's one patch per change format isn't
> > intrinsic to Notedb, since we just need to track the sha we want
> > to merge and optionally the branch we intend to merge into.
> 
> Note that Gerrit started to lose the "one patch at a time" notion.
> It is possible to at least submit multiple changes coupled together
> (even across project boundaries) via the topic. Some sort of cover
> letter is missing though, that could be used e.g. for the merge commit.

Potentially my misuse of the format but git-candidate puts the cover
letter into the body of the commit message before the footers begin,
for each new patchset added to the change. This has the advantage
that you can track each version of the cover letter,
since there's one per patchset.