{"thread":{"id":"42957","subject":"[ANNOUNCE] git-series: track changes to a patch series over time","startedAt":"2016-07-29T06:41:44Z","lastAt":"2016-08-24T10:58:06Z","messageCount":23,"participants":["Josh Triplett","Richard Ipsum","Stefan Beller","Christian Couder","Eric Wong","Stephen Warren","Simon Glass","Jakub Narębski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"292494","messageId":"20160729064055.GB25331@x","threadId":"42957","inReplyTo":null,"subject":"[ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-07-29T06:40:55Z","receivedAt":"2016-07-29T06:41:44Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"I'd like to announce a project I've been working on for a while:\n\ngit-series provides a tool for managing patch series with git, tracking\nthe \"history of history\". git series tracks changes to the patch series\nover time, including rebases and other non-fast-forwarding changes. git\nseries also tracks a cover letter for the patch series, formats the\nseries for email, and prepares pull requests.\n\nThis makes it easier to collaborate on a patch series, distribution\npackage, backport, or any other development process that includes\nrebasing or non-fast-forward development.\n\nA patch series typically goes through multiple iterations before\nsubmission; the path from idea to RFC to [PATCHv12 1/8] includes many\ninvocations of git rebase -i. However, while Git tracks and organizes\ncommits quite well, it doesn't actually track changes to a patch series\nat all, outside of the ephemeral reflog. This makes it a challenge to\ncollaborate on a patch series, distribution package, backport, or any\nother development process that includes rebasing or non-fast-forward\ndevelopment.\n\nTypically, tracking the evolution of a patch series over time involves\nmoving part of the version control outside of git. You can move the\npatch series from git into quilt or a distribution package, and then\nversion the patch files with git, losing the power of git's tools. Or,\nyou can keep the patch series in git, and version it via multiple named\nbranches; however, names like feature-v2, feature-v3-typofix, and\nfeature-v8-rebased-4.6-alice-fix sound like filenames from corporate\nemail, not modern version control. And either way, git doesn't track\nyour cover letter at all.\n\ngit-series tracks both a patch series and its evolution within the same\ngit repository. git-series works entirely with existing git features,\nallowing git to push and pull a series to any git repository along with\nother branches and tags. Each time you change the patch series, whether\nfast-forwarding or not, you can \"git series commit\" a new version of the\npatch series, complete with commit message.\n\nYou can rebase a patch series with \"git series rebase -i\", format it for\nsubmission with \"git series format\", or send a \"please pull\" request with\n\"git series req\".  git-series knows the base of your series, so you\ndon't need to count patches or find a commit hash to run rebase or\nformat.\n\nIf you're interested in trying git-series, see\nhttps://github.com/git-series/git-series for installation instructions\nand a \"getting started\" guide.\n\nI've also documented the internal storage format of git-series at\nhttps://github.com/git-series/git-series/blob/master/INTERNALS.md ,\nincluding the details for how git-series ensures git can always reach,\npush, and pull a series.\n\nI'd welcome any feedback, whether on the interface and workflow, the\ninternals and collaboration, ideas on presenting diffs of patch series,\nor anything else.\n\n- Josh Triplett\n"},{"id":"292505","messageId":"20160729101011.GA3469@salo","threadId":"42957","inReplyTo":"20160729064055.GB25331@x","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Richard Ipsum","fromEmail":"richard.ipsum@codethink.co.uk","sentAt":"2016-07-29T10:10:11Z","receivedAt":"2016-07-29T10:10:50Z","isPatch":false,"sender":{"key":"richard.ipsum@codethink.co.uk","avatar":null},"body":"On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:\n[snip]\n> \n> I'd welcome any feedback, whether on the interface and workflow, the\n> internals and collaboration, ideas on presenting diffs of patch series,\n> or anything else.\n> \n\nThis looks awesome!\n\nI've been working on some similar stuff for a while also.[1][2]\n\nI'm particularly interested in trying to establish a standard for\nstoring review data in git. I've got a prototype for doing that[3],\nand an example tool that uses it[4]. The tool is still incomplete/buggy though.\n\nThere seem to be a number of us trying to solve this in our different ways,\nit would be great to coordinate our efforts.\n\nThe prototype library I have is partly the result of some discussion and work\nwith the Gerrit folks, since they were thinking about this problem\nbefore I even started writing git-candidate, and solved it with Notedb.[5]\n\nLet me know if you'd like to work together on this,\nI've been considering taking the perl-notedb prototype and writing\na C library for it with bindings for other languages (i.e. Rust).\n\n[1]: http://www.mail-archive.com/git%40vger.kernel.org/msg79461.html\n[2]: http://www.mail-archive.com/git%40vger.kernel.org/msg80972.html\n\n[3]: https://bitbucket.org/richardipsum/perl-notedb\n[4]: https://bitbucket.org/richardipsum/git-candidate\n\n[5]: https://storage.googleapis.com/gerrit-talks/summit/2015/NoteDB.pdf\n"},{"id":"292507","messageId":"20160729110426.GA2945@x","threadId":"42957","inReplyTo":"20160729101011.GA3469@salo","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-07-29T11:04:26Z","receivedAt":"2016-07-29T11:05:05Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Fri, Jul 29, 2016 at 11:10:11AM +0100, Richard Ipsum wrote:\n> On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:\n> [snip]\n> > \n> > I'd welcome any feedback, whether on the interface and workflow, the\n> > internals and collaboration, ideas on presenting diffs of patch series,\n> > or anything else.\n> > \n> \n> This looks awesome!\n> \n> I've been working on some similar stuff for a while also.[1][2]\n> \n> I'm particularly interested in trying to establish a standard for\n> storing review data in git. I've got a prototype for doing that[3],\n> and an example tool that uses it[4]. The tool is still incomplete/buggy though.\n\nLooks promising, though!\n\n> There seem to be a number of us trying to solve this in our different ways,\n> it would be great to coordinate our efforts.\n\nThese definitely seem like a family of related problems.  I'd like to\nuse git-series as a format for storing iterations on things like GitHub\npull-requests or Gerrit patch versions (in the latter case, overcoming\nGerrit's limitations on only handling one patch at a time).  Integrating\nreviews with that seems helpful.\n\n> The prototype library I have is partly the result of some discussion and work\n> with the Gerrit folks, since they were thinking about this problem\n> before I even started writing git-candidate, and solved it with Notedb.[5]\n> \n> Let me know if you'd like to work together on this,\n\nI'd love to.\n\nI'll be presenting git-series at LinuxCon North America; will you be\nthere by any chance?  If not, perhaps we could meet by IRC or some other\nmedium and talk about this family of problems.\n\nI hope to use git notes with git-series in the future, by putting\nanother gitlink under the git-series for notes related to the series.\nI'd intended that for more persistent notes; putting them in the series\nsolves some of the problems related to notes refs, pushing/pulling, and\ncollaboration.  Using notes for review comments makes sense as well,\nwhether in a series or in a separate ref.\n\n> I've been considering taking the perl-notedb prototype and writing\n> a C library for it with bindings for other languages (i.e. Rust).\n\nA C library based on libgit2 seems like a good idea; ideally the\nbindings could interoperate with git2-rs.  (Alternatively, Rust can\n*export* a C interface, so you could write directly with git2-rs. :) )\n\nOne of the items on my long-term TODO list is a completely federated\nGitHub; I've been looking at other aspects of that, but federated\nreviews/comments/etc seem critical to that as well.\n\n- Josh Triplett\n"},{"id":"292511","messageId":"20160729124443.GA3686@salo","threadId":"42957","inReplyTo":"20160729110426.GA2945@x","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Richard Ipsum","fromEmail":"richard.ipsum@codethink.co.uk","sentAt":"2016-07-29T12:44:44Z","receivedAt":"2016-07-29T12:45:07Z","isPatch":false,"sender":{"key":"richard.ipsum@codethink.co.uk","avatar":null},"body":"On Fri, Jul 29, 2016 at 04:04:26AM -0700, Josh Triplett wrote:\n[snip]\n> \n> These definitely seem like a family of related problems.  I'd like to\n> use git-series as a format for storing iterations on things like GitHub\n> pull-requests or Gerrit patch versions (in the latter case, overcoming\n> Gerrit's limitations on only handling one patch at a time).  Integrating\n> reviews with that seems helpful.\n\nWorth noting here that Gerrit's one patch per change format isn't\nintrinsic to Notedb, since we just need to track the sha we want\nto merge and optionally the branch we intend to merge into.\n\n> \n> > The prototype library I have is partly the result of some discussion and work\n> > with the Gerrit folks, since they were thinking about this problem\n> > before I even started writing git-candidate, and solved it with Notedb.[5]\n> > \n> > Let me know if you'd like to work together on this,\n> \n> I'd love to.\n> \n> I'll be presenting git-series at LinuxCon North America; will you be\n> there by any chance?  If not, perhaps we could meet by IRC or some other\n> medium and talk about this family of problems.\n\nCool :)\n\nI didn't plan to be at LinuxCon North America,\nbut I can certainly send contact details out of band.\n\n> \n> I hope to use git notes with git-series in the future, by putting\n> another gitlink under the git-series for notes related to the series.\n> I'd intended that for more persistent notes; putting them in the series\n> solves some of the problems related to notes refs, pushing/pulling, and\n> collaboration.  Using notes for review comments makes sense as well,\n> whether in a series or in a separate ref.\n\nSounds interesting, can you explain how this works in more detail?\nI ended up solving the push/pull issue with a custom merge driver\nthat effectively runs the Notedb parser on each side of the merge\nand emits the union of the two sets of change notes.\n\n> \n> > I've been considering taking the perl-notedb prototype and writing\n> > a C library for it with bindings for other languages (i.e. Rust).\n> \n> A C library based on libgit2 seems like a good idea; ideally the\n> bindings could interoperate with git2-rs.  (Alternatively, Rust can\n> *export* a C interface, so you could write directly with git2-rs. :) )\n\nCertainly a fair alternative, though it may arguably be safer to write\nthe C and export to other languages, as cool as Rust looks it's not\nestablished the way C is, so may be a slightly riskier foundation,\nin my view.\n\nAnd ofcourse in C we have native access to libgit2.\n\n> \n> One of the items on my long-term TODO list is a completely federated\n> GitHub; I've been looking at other aspects of that, but federated\n> reviews/comments/etc seem critical to that as well.\n> \n\nI agree.\n"},{"id":"292512","messageId":"20160729130054.GD4340@x","threadId":"42957","inReplyTo":"20160729124443.GA3686@salo","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-07-29T13:00:55Z","receivedAt":"2016-07-29T13:01:22Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Fri, Jul 29, 2016 at 01:44:44PM +0100, Richard Ipsum wrote:\n> On Fri, Jul 29, 2016 at 04:04:26AM -0700, Josh Triplett wrote:\n> > I hope to use git notes with git-series in the future, by putting\n> > another gitlink under the git-series for notes related to the series.\n> > I'd intended that for more persistent notes; putting them in the series\n> > solves some of the problems related to notes refs, pushing/pulling, and\n> > collaboration.  Using notes for review comments makes sense as well,\n> > whether in a series or in a separate ref.\n> \n> Sounds interesting, can you explain how this works in more detail?\n\nThe tree within a git-series commit includes a blob \"cover\" for the\ncover letter, a gitlink \"base\" for the base commit, and a gitlink\n\"series\" for the top of the series.  I could add a gitlink \"notes\",\nwhich acts like a notes ref; then, each version of the series would have\nits own notes ref.  As with the series, git-series would track the\n\"history of history\"; since git-notes themselves use git history to\nstore a set of notes, git-series would store the history of the notes.\nSo if you add, remove, or change a note, git-series would track that as\na change to the notes ref.  If you merge/rebase/etc the notes ref to\nmerge notes, git-series would track that too.  A different series would\nhave a different set of notes, so you wouldn't be limited to\none notes ref per repository.\n\nThis doesn't solve the problem of merging notes, but it *does* mean you\nhave a full history of the changes to notes, not just the notes\nthemselves.\n\nSomething similar might work for the Gerrit notesdb.\n\n> > > I've been considering taking the perl-notedb prototype and writing\n> > > a C library for it with bindings for other languages (i.e. Rust).\n> > \n> > A C library based on libgit2 seems like a good idea; ideally the\n> > bindings could interoperate with git2-rs.  (Alternatively, Rust can\n> > *export* a C interface, so you could write directly with git2-rs. :) )\n> \n> Certainly a fair alternative, though it may arguably be safer to write\n> the C and export to other languages, as cool as Rust looks it's not\n> established the way C is, so may be a slightly riskier foundation,\n> in my view.\n\nI was mostly joking there.  Rust makes that potentially reasonable,\nunlike most languages that can consume but not easily provide a C API,\nbut that doesn't make it the ideal solution quite yet. :)\n\n> And ofcourse in C we have native access to libgit2.\n\nRight.\n\n> > One of the items on my long-term TODO list is a completely federated\n> > GitHub; I've been looking at other aspects of that, but federated\n> > reviews/comments/etc seem critical to that as well.\n>\n> I agree.\n"},{"id":"292533","messageId":"CAGZ79kbTViNYLq0aouQ--5d7m=HYi3QxUYqaaH8sTCS_YTDquQ@mail.gmail.com","threadId":"42957","inReplyTo":"20160729124443.GA3686@salo","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-07-29T16:59:08Z","receivedAt":"2016-07-29T16:59:25Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, Jul 29, 2016 at 5:44 AM, Richard Ipsum\n<richard.ipsum@codethink.co.uk> wrote:\n>>\n>> These definitely seem like a family of related problems.  I'd like to\n>> use git-series as a format for storing iterations on things like GitHub\n>> pull-requests or Gerrit patch versions (in the latter case, overcoming\n>> Gerrit's limitations on only handling one patch at a time).  Integrating\n>> reviews with that seems helpful.\n>\n> Worth noting here that Gerrit's one patch per change format isn't\n> intrinsic to Notedb, since we just need to track the sha we want\n> to merge and optionally the branch we intend to merge into.\n\nNote that Gerrit started to lose the \"one patch at a time\" notion.\nIt is possible to at least submit multiple changes coupled together\n(even across project boundaries) via the topic. Some sort of cover\nletter is missing though, that could be used e.g. for the merge commit.\n"},{"id":"292684","messageId":"20160731140936.GA3959@salo","threadId":"42957","inReplyTo":"CAGZ79kbTViNYLq0aouQ--5d7m=HYi3QxUYqaaH8sTCS_YTDquQ@mail.gmail.com","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Richard Ipsum","fromEmail":"richard.ipsum@codethink.co.uk","sentAt":"2016-07-31T14:09:36Z","receivedAt":"2016-07-31T14:11:25Z","isPatch":false,"sender":{"key":"richard.ipsum@codethink.co.uk","avatar":null},"body":"On Fri, Jul 29, 2016 at 09:59:08AM -0700, Stefan Beller wrote:\n> On Fri, Jul 29, 2016 at 5:44 AM, Richard Ipsum\n> <richard.ipsum@codethink.co.uk> wrote:\n> >>\n> >> These definitely seem like a family of related problems.  I'd like to\n> >> use git-series as a format for storing iterations on things like GitHub\n> >> pull-requests or Gerrit patch versions (in the latter case, overcoming\n> >> Gerrit's limitations on only handling one patch at a time).  Integrating\n> >> reviews with that seems helpful.\n> >\n> > Worth noting here that Gerrit's one patch per change format isn't\n> > intrinsic to Notedb, since we just need to track the sha we want\n> > to merge and optionally the branch we intend to merge into.\n> \n> Note that Gerrit started to lose the \"one patch at a time\" notion.\n> It is possible to at least submit multiple changes coupled together\n> (even across project boundaries) via the topic. Some sort of cover\n> letter is missing though, that could be used e.g. for the merge commit.\n\nPotentially my misuse of the format but git-candidate puts the cover\nletter into the body of the commit message before the footers begin,\nfor each new patchset added to the change. This has the advantage\nthat you can track each version of the cover letter,\nsince there's one per patchset.\n"},{"id":"292687","messageId":"20160731143539.GA15477@salo","threadId":"42957","inReplyTo":"20160729130054.GD4340@x","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Richard Ipsum","fromEmail":"richard.ipsum@codethink.co.uk","sentAt":"2016-07-31T14:35:39Z","receivedAt":"2016-07-31T14:39:22Z","isPatch":false,"sender":{"key":"richard.ipsum@codethink.co.uk","avatar":null},"body":"On Fri, Jul 29, 2016 at 06:00:55AM -0700, Josh Triplett wrote:\n> On Fri, Jul 29, 2016 at 01:44:44PM +0100, Richard Ipsum wrote:\n> > On Fri, Jul 29, 2016 at 04:04:26AM -0700, Josh Triplett wrote:\n> > > I hope to use git notes with git-series in the future, by putting\n> > > another gitlink under the git-series for notes related to the series.\n> > > I'd intended that for more persistent notes; putting them in the series\n> > > solves some of the problems related to notes refs, pushing/pulling, and\n> > > collaboration.  Using notes for review comments makes sense as well,\n> > > whether in a series or in a separate ref.\n> > \n> > Sounds interesting, can you explain how this works in more detail?\n> \n> The tree within a git-series commit includes a blob \"cover\" for the\n> cover letter, a gitlink \"base\" for the base commit, and a gitlink\n> \"series\" for the top of the series.  I could add a gitlink \"notes\",\n> which acts like a notes ref; then, each version of the series would have\n> its own notes ref.  As with the series, git-series would track the\n> \"history of history\"; since git-notes themselves use git history to\n> store a set of notes, git-series would store the history of the notes.\n> So if you add, remove, or change a note, git-series would track that as\n> a change to the notes ref.  If you merge/rebase/etc the notes ref to\n> merge notes, git-series would track that too.  A different series would\n> have a different set of notes, so you wouldn't be limited to\n> one notes ref per repository.\n> \n> This doesn't solve the problem of merging notes, but it *does* mean you\n> have a full history of the changes to notes, not just the notes\n> themselves.\n> \n> Something similar might work for the Gerrit notesdb.\n> \n\nOkay I think there is a misunderstanding, Notedb is based on notes,\nbut they're not used in the same way as git-notes,\nan example will help explain what I mean,\n\nFor a candidate 'update_readme' we store the change/candidate/whatever\nmetadata at refs/candidates/heads/up/update_readme/meta which is analogous\nto Gerrit's notedb refs which uses something like refs/changes/34/1234/meta,\nthe prototype library I've written supports both forms and allows for some\nflexibility in the naming of the prefix of the former type of ref\n(so you may use refs/series/heads/up/update_readme/meta for example).\n\nSo the output of,\n    git log -p refs/candidates/heads/up/update_readme/meta\n\ngives\n\ncommit 38d0c182a46dc5a0f5d04ea0890e278b8e7a6eb6\nAuthor: Richard Ipsum <richardipsum@fastmail.co.uk>\nDate:   Sun Jul 24 16:59:16 2016 +0100\n\n    Metadata update\n    \n    Patch-set: 1\n    Status: merged\n\ncommit f45a396a156e121f923321e7530e74746e10bdb8\nAuthor: Richard Ipsum <richardipsum@fastmail.co.uk>\nDate:   Sun Jul 24 16:50:13 2016 +0100\n\n    Vote on patch set 1\n    \n    \n    \n    Label: CodeReview=+1\n    Patch-set: 1\n\ncommit b74eb15c1847d3bb28618c738c8ebc3412b6935a\nAuthor: Richard Ipsum <richardipsum@fastmail.co.uk>\nDate:   Sun Jul 24 16:48:11 2016 +0100\n\n    Update our README to reflect reality\n    BranchCommit; 59c46c9fa03725308779841f95ad71e7ccdb919c\n    \n    Branch: master\n    Commit: 761d8da03a10b63b0b1e3cf97ffd7ececb09e3d6\n    Patch-set: 1\n    Status: new\n    Subject: update_readme\n\nThis Notedb history is the result of the following git-candidate invocations\n\n    git candidate create update_readme -m \"Update our README to reflect reality\"\n    git candidate vote +1\n    (use whatever git commands you like to merge the change)\n    git candidate close update_readme\n\nBasically any change made to a change in Notedb is recorded in a git history.\n\nThe format is explained in some more detail here[1].\n\n[1]: https://storage.googleapis.com/gerrit-talks/summit/2015/NoteDB.pdf\n"},{"id":"292701","messageId":"CAP8UFD12Jk0s0HPPWS3CqFcB37gzhzZZi-V0PfqrRhZO4zhHOA@mail.gmail.com","threadId":"42957","inReplyTo":"20160729101011.GA3469@salo","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2016-08-01T05:04:15Z","receivedAt":"2016-08-01T05:04:48Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum\n<richard.ipsum@codethink.co.uk> wrote:\n> On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:\n> [snip]\n>>\n>> I'd welcome any feedback, whether on the interface and workflow, the\n>> internals and collaboration, ideas on presenting diffs of patch series,\n>> or anything else.\n>\n> This looks awesome!\n>\n> I've been working on some similar stuff for a while also.[1][2]\n>\n> I'm particularly interested in trying to establish a standard for\n> storing review data in git. I've got a prototype for doing that[3],\n> and an example tool that uses it[4]. The tool is still incomplete/buggy though.\n\nThere is also git-appraise (https://github.com/google/git-appraise)\nwritten in Go to store code review data in Git.\nIt looks like it stores its data in git notes and can be integrated\nwith Rust (https://github.com/Nemo157/git-appraise-rs).\n\n> There seem to be a number of us trying to solve this in our different ways,\n> it would be great to coordinate our efforts.\n\nYeah, I agree.\n"},{"id":"292703","messageId":"20160801075554.GA22222@starla","threadId":"42957","inReplyTo":"CAP8UFD12Jk0s0HPPWS3CqFcB37gzhzZZi-V0PfqrRhZO4zhHOA@mail.gmail.com","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-01T07:55:54Z","receivedAt":"2016-08-01T07:57:39Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Christian Couder <christian.couder@gmail.com> wrote:\n> On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum\n> <richard.ipsum@codethink.co.uk> wrote:\n> > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:\n> > [snip]\n> >>\n> >> I'd welcome any feedback, whether on the interface and workflow, the\n> >> internals and collaboration, ideas on presenting diffs of patch series,\n> >> or anything else.\n\n> > I'm particularly interested in trying to establish a standard for\n> > storing review data in git. I've got a prototype for doing that[3],\n> > and an example tool that uses it[4]. The tool is still incomplete/buggy though.\n> \n> There is also git-appraise (https://github.com/google/git-appraise)\n> written in Go to store code review data in Git.\n> It looks like it stores its data in git notes and can be integrated\n> with Rust (https://github.com/Nemo157/git-appraise-rs).\n\nI'm not convinced another format/standard is needed besides the\nemail workflow we already use for git and kernel development.\n\nRather, better ways to archive/search the emails is desirable.\nFortunately, commit titles are rather unique :)\n\nI started archiving the git ML with public-inbox (which uses git):\n\n  https://public-inbox.org/git/20160710004813.GA20210@dcvr.yhbt.net/T/\n\nIt can be easy to search by Subject (commit titles):\n\n  https://public-inbox.org/git/?q=s:%22more+archives+of+this+list%22\n\nSearch (currently Xapian) will be tuned to parse things like\nfilenames and diffs to allow searching within those.  It is\nalready somewhat email-aware, such as deprioritizing quoted\ntext; and having a code repository browser with mail archive\nintegration is in the works.\n\nI also see the reliance on an after-the-fact search engine\n(which can be tuned/replaced) as philosophically inline with\nwhat git does, too, such as not having rename tracking and\ndoing delayed deltafication.\n\nEmail also has the advantage of having existing tooling, and\nbeing (at least for now) federated without a single point of\nfailure.\n\nvger.kernel.org can still be a major point of failure, which is\nwhy the \"archives first\" approach of public-inbox favors readers\npulling messages over NNTP/HTTP/git (and maybe soon, POP3).\n"},{"id":"292707","messageId":"20160801085928.lw3ltdksyrjujutu@x","threadId":"42957","inReplyTo":"20160801075554.GA22222@starla","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-08-01T08:59:29Z","receivedAt":"2016-08-01T09:00:00Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Mon, Aug 01, 2016 at 07:55:54AM +0000, Eric Wong wrote:\n> Christian Couder <christian.couder@gmail.com> wrote:\n> > On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum\n> > <richard.ipsum@codethink.co.uk> wrote:\n> > > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:\n> > > [snip]\n> > >>\n> > >> I'd welcome any feedback, whether on the interface and workflow, the\n> > >> internals and collaboration, ideas on presenting diffs of patch series,\n> > >> or anything else.\n> \n> > > I'm particularly interested in trying to establish a standard for\n> > > storing review data in git. I've got a prototype for doing that[3],\n> > > and an example tool that uses it[4]. The tool is still incomplete/buggy though.\n> > \n> > There is also git-appraise (https://github.com/google/git-appraise)\n> > written in Go to store code review data in Git.\n> > It looks like it stores its data in git notes and can be integrated\n> > with Rust (https://github.com/Nemo157/git-appraise-rs).\n> \n> I'm not convinced another format/standard is needed besides the\n> email workflow we already use for git and kernel development.\n\nNot all projects use a patches-by-email workflow, or want to.  To the\nextent that tools and projects use some other workflow, standardizing\nthe format they use to store patch reviews (including per-line\nannotations, approvals, test results, etc) seems preferable to having\neach tool use its own custom format.\n\n> I also see the reliance on an after-the-fact search engine\n> (which can be tuned/replaced) as philosophically inline with\n> what git does, too, such as not having rename tracking and\n> doing delayed deltafication.\n\nStoring review data in git doesn't mean it needs to end up in the\nhistory of the project itself; it can use after-the-fact annotations on\na commit.\n\n> Email also has the advantage of having existing tooling, and\n> being (at least for now) federated without a single point of\n> failure.\n\nStoring review data in git makes it easy to push and pull it, which can\nprovide the basis for a federated system.\n\n- Josh Triplett\n"},{"id":"292717","messageId":"20160801095351.GA27496@salo","threadId":"42957","inReplyTo":"20160801085928.lw3ltdksyrjujutu@x","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Richard Ipsum","fromEmail":"richard.ipsum@codethink.co.uk","sentAt":"2016-08-01T09:53:51Z","receivedAt":"2016-08-01T09:57:22Z","isPatch":false,"sender":{"key":"richard.ipsum@codethink.co.uk","avatar":null},"body":"On Mon, Aug 01, 2016 at 01:59:29AM -0700, Josh Triplett wrote:\n> On Mon, Aug 01, 2016 at 07:55:54AM +0000, Eric Wong wrote:\n[snip]\n> > \n> > I'm not convinced another format/standard is needed besides the\n> > email workflow we already use for git and kernel development.\n> \n> Not all projects use a patches-by-email workflow, or want to.  To the\n> extent that tools and projects use some other workflow, standardizing\n> the format they use to store patch reviews (including per-line\n> annotations, approvals, test results, etc) seems preferable to having\n> each tool use its own custom format.\n\nI concur, for better or for worse many projects have abandoned\nmailing lists in favour of github, gerrit, gitlab and the like.\nThe problem being, with the exception of gerrit, most of these\ntools store review data in sql databases, which is bad for obvious reasons.\n\n> \n> > I also see the reliance on an after-the-fact search engine\n> > (which can be tuned/replaced) as philosophically inline with\n> > what git does, too, such as not having rename tracking and\n> > doing delayed deltafication.\n> \n> Storing review data in git doesn't mean it needs to end up in the\n> history of the project itself; it can use after-the-fact annotations on\n> a commit.\n\nExactly.\n"},{"id":"292744","messageId":"b7bd1464-1412-1feb-fe10-9ecb6018e122@wwwdotorg.org","threadId":"42957","inReplyTo":"20160729064055.GB25331@x","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Stephen Warren","fromEmail":"swarren@wwwdotorg.org","sentAt":"2016-08-01T15:14:54Z","receivedAt":"2016-08-01T15:25:02Z","isPatch":false,"sender":{"key":"swarren@wwwdotorg.org","avatar":null},"body":"On 07/29/2016 12:40 AM, Josh Triplett wrote:\n> I'd like to announce a project I've been working on for a while:\n>\n> git-series provides a tool for managing patch series with git, tracking\n> the \"history of history\". git series tracks changes to the patch series\n> over time, including rebases and other non-fast-forwarding changes. git\n> series also tracks a cover letter for the patch series, formats the\n> series for email, and prepares pull requests.\n\nJust as an FYI, I wouldn't be surprised if there's some overlap, or \npotential for merging of tools, between this tool and the \"patman\" tool \nthat's part of the U-Boot source tree:\n\nhttp://git.denx.de/?p=u-boot.git;a=blob;f=tools/patman/README;h=e36857dedea1d0dbafa41732aaf9bf0988d63f38;hb=HEAD\n\n"},{"id":"292780","messageId":"20160801183750.ivwue4mxm5ilgzqz@x","threadId":"42957","inReplyTo":"b7bd1464-1412-1feb-fe10-9ecb6018e122@wwwdotorg.org","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-08-01T18:37:50Z","receivedAt":"2016-08-01T19:47:19Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote:\n> On 07/29/2016 12:40 AM, Josh Triplett wrote:\n> > I'd like to announce a project I've been working on for a while:\n> > \n> > git-series provides a tool for managing patch series with git, tracking\n> > the \"history of history\". git series tracks changes to the patch series\n> > over time, including rebases and other non-fast-forwarding changes. git\n> > series also tracks a cover letter for the patch series, formats the\n> > series for email, and prepares pull requests.\n> \n> Just as an FYI, I wouldn't be surprised if there's some overlap, or\n> potential for merging of tools, between this tool and the \"patman\" tool\n> that's part of the U-Boot source tree:\n> \n> http://git.denx.de/?p=u-boot.git;a=blob;f=tools/patman/README;h=e36857dedea1d0dbafa41732aaf9bf0988d63f38;hb=HEAD\n\nInteresting tool; thanks for the link.\n\nAs far as I can tell from that documentation, patman doesn't track old\nversions of a patch series; you rebase to modify patches or change\npatman tags (embedded in commit messages), and nothing preserves the\nprevious version.  And it tracks the cover letter and similar in one of\nthe commit messages in the series, so previous versions of that don't\nget saved either.  If you wanted to track the history of your changes,\nyou'd have to use branch names or similar.\n\nIn addition, tracking metadata in commit messages only works with a\npatches-by-mail workflow where the messages get processed when\ngenerating patches; that doesn't work for please-pull workflows.\n\npatman does have quite a few interesting ideas, though.  git-series\nneeds some way of handling To/Cc addresses for patches and the cover\nletter (beyond just scripts/get_maintainer.pl), and more automatic\nhandling of series versioning (v2, v3, ...) and associated series\nchangelogs.  Suggestions welcome.\n\n- Josh Triplett\n"},{"id":"292797","messageId":"20160801211938.GA16348@dcvr","threadId":"42957","inReplyTo":"20160801085928.lw3ltdksyrjujutu@x","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-01T21:19:38Z","receivedAt":"2016-08-01T21:20:49Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Josh Triplett <josh@joshtriplett.org> wrote:\n> On Mon, Aug 01, 2016 at 07:55:54AM +0000, Eric Wong wrote:\n> > Christian Couder <christian.couder@gmail.com> wrote:\n> > > On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum\n> > > <richard.ipsum@codethink.co.uk> wrote:\n> > > > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:\n> > > > [snip]\n> > > >>\n> > > >> I'd welcome any feedback, whether on the interface and workflow, the\n> > > >> internals and collaboration, ideas on presenting diffs of patch series,\n> > > >> or anything else.\n> > \n> > > > I'm particularly interested in trying to establish a standard for\n> > > > storing review data in git. I've got a prototype for doing that[3],\n> > > > and an example tool that uses it[4]. The tool is still incomplete/buggy though.\n\n> > I'm not convinced another format/standard is needed besides the\n> > email workflow we already use for git and kernel development.\n> \n> Not all projects use a patches-by-email workflow, or want to.  To the\n> extent that tools and projects use some other workflow, standardizing\n> the format they use to store patch reviews (including per-line\n> annotations, approvals, test results, etc) seems preferable to having\n> each tool use its own custom format.\n\nI think standardizing on email conventions (such as what we\nalready do with format-patch, request-pull, S-o-b trailers) would\nbe a step in this direction and a good step to take.\n\nBut yeah, I also hope git adopters can somehow be convinced to\nalso adopt the workflow that built git itself.\n\n> > I also see the reliance on an after-the-fact search engine\n> > (which can be tuned/replaced) as philosophically inline with\n> > what git does, too, such as not having rename tracking and\n> > doing delayed deltafication.\n> \n> Storing review data in git doesn't mean it needs to end up in the\n> history of the project itself; it can use after-the-fact annotations on\n> a commit.\n\nRight.  So on public-inbox.org/git today, one could search for\nafter-the-fact annotations based on commit titles and maybe\nexact commit ID matches.\n\nA future goal might be to get search indexing working on commit\nID substrings.  So finding references to commit\ndeadbeefcafe01234567890123467890abcdef00 could be done by\nsearching for \"commit deadbeefcafe\" or even a shorter ID, and\nthe following results could still be returned:\n\n  1. commit deadbeefcafe broke my cat feeder\n  2. commit deadbeef killed my cow\n\n> > Email also has the advantage of having existing tooling, and\n> > being (at least for now) federated without a single point of\n> > failure.\n> \n> Storing review data in git makes it easy to push and pull it, which can\n> provide the basis for a federated system.\n\nEvery public-inbox exposed over HTTP(S) is git clonable[1], so\nit's possible to push/pull or have developers merge/combine\ninboxes with index-only operations.  There's no UI for that,\nyet, and having a working tree checked out is inefficient with\n300K uncompressed mails...\n\nBut there needs to be way to message others about the existence\nof new pushes/pull-requests/reviews/etc; including users\nunable to clone or host 800M git repos; so that messaging\nsystem might as well be email.\n\n\n\n[1] git clone --mirror https://public-inbox.org/git/\n    That's not efficient, yet, though, at around 800M when the\n    gzipped fast-export dump is around half that:\n    https://public-inbox.org/git/20160710034745.GA20270@dcvr.yhbt.net/T/#u\n"},{"id":"292968","messageId":"20160803191202.GA22881@salo","threadId":"42957","inReplyTo":"20160729064055.GB25331@x","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Richard Ipsum","fromEmail":"richard.ipsum@codethink.co.uk","sentAt":"2016-08-03T19:12:02Z","receivedAt":"2016-08-03T19:22:43Z","isPatch":false,"sender":{"key":"richard.ipsum@codethink.co.uk","avatar":null},"body":"On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:\n> \n> I'd welcome any feedback, whether on the interface and workflow, the\n> internals and collaboration, ideas on presenting diffs of patch series,\n> or anything else.\n> \n\nOne other nice thing I've noticed about this tool is the\nway series behave like regular git branches: I specify the name\nof the series and from then on all other commands act on that\nseries until told otherwise.\n\ngit-appraise looks as though it might also have this behaviour.\nI think it's a nice way to do it, since you don't generally\nperform more than one review simultaneously. So I may well\nuse this idea in git-candidate if it's okay. :)\n\nI haven't found time to use the tool to do any serious review\nyet, but I'll try and post some more feedback when I do.\n\nHope this helps,\nRichard\n"},{"id":"293149","messageId":"20160804224058.po43kl7w26ockfie@x","threadId":"42957","inReplyTo":"20160803191202.GA22881@salo","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-08-04T22:40:58Z","receivedAt":"2016-08-04T22:41:34Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote:\n> On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:\n> > I'd welcome any feedback, whether on the interface and workflow, the\n> > internals and collaboration, ideas on presenting diffs of patch series,\n> > or anything else.\n> \n> One other nice thing I've noticed about this tool is the\n> way series behave like regular git branches: I specify the name\n> of the series and from then on all other commands act on that\n> series until told otherwise.\n\nThanks; I spent a while thinking about that part of the workflow.  I\nsave the current series as a symbolic ref SHEAD, and everything operates\non SHEAD.  (I should probably add support for running things like \"git\nseries log\" or \"git series format\" on a different series, because right\nnow \"until told otherwise\" doesn't include a way to tell it otherwise.)\n\nOne fun detail that took a couple of iterations to get right: I keep\nseparate \"staged\" and \"working\" versions per-series, so even with\noutstanding changes to the cover letter, base, or series, you can always\ndetach or checkout another series without losing anything.  If you\nswitch back, all your staged and unstaged changes will remain staged and\nunstaged where you left them.  That solves the \"checkout a different\nseries with modifications to the current series\" case.\n\n> git-appraise looks as though it might also have this behaviour.\n> I think it's a nice way to do it, since you don't generally\n> perform more than one review simultaneously. So I may well\n> use this idea in git-candidate if it's okay. :)\n\nBy all means.  For a review tool like git-candidate, it seems like you'd\nwant even more contextual information, to make it easier to specify\nthings like \"comment on file F line L\".  For instance, what if you\nspawned the diff to review in an editor, with plenty of extra context\nand a file extension that'll cause most editors to recognize it as a\npatch (and specifically a git-candidate patch to allow specialized\neditor modes), and told people to add their comments after the line they\napplied to?  When the editor exits successfully, you can scan the file,\ndetect the added lines, and save those as comments.  You could figure\nout the appropriate line by looking for the diff hunk headers and\ncounting line numbers.\n\nIf you use a format-patch diff that includes the headers and commit\nmessage, you could also support commenting on those in the same way.\nDoes the notedb format support commenting on those?\n\n> I haven't found time to use the tool to do any serious review\n> yet, but I'll try and post some more feedback when I do.\n\nThanks!\n\n- Josh Triplett\n"},{"id":"293632","messageId":"20160810093731.GA3404@salo","threadId":"42957","inReplyTo":"20160804224058.po43kl7w26ockfie@x","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Richard Ipsum","fromEmail":"richard.ipsum@codethink.co.uk","sentAt":"2016-08-10T09:37:31Z","receivedAt":"2016-08-10T19:59:46Z","isPatch":false,"sender":{"key":"richard.ipsum@codethink.co.uk","avatar":null},"body":"On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote:\n> On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote:\n> > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:\n> > > I'd welcome any feedback, whether on the interface and workflow, the\n> > > internals and collaboration, ideas on presenting diffs of patch series,\n> > > or anything else.\n> > \n> > One other nice thing I've noticed about this tool is the\n> > way series behave like regular git branches: I specify the name\n> > of the series and from then on all other commands act on that\n> > series until told otherwise.\n> \n> Thanks; I spent a while thinking about that part of the workflow.  I\n> save the current series as a symbolic ref SHEAD, and everything operates\n> on SHEAD.  (I should probably add support for running things like \"git\n> series log\" or \"git series format\" on a different series, because right\n> now \"until told otherwise\" doesn't include a way to tell it otherwise.)\n\nApologies for this delayed response,\nI needed time to gather my thoughts,\nand also to fix the perl libgit2 binding to allow me to use\nyour symbolic ref suggestion. :p\n\nThough it turns out that libgit2 doesn't currently allow\nme to write arbitrary data to a symbolic ref as git-symbolic-ref(1) will,\nso this still needs to be fixed somehow.\n\n> \n> One fun detail that took a couple of iterations to get right: I keep\n> separate \"staged\" and \"working\" versions per-series, so even with\n> outstanding changes to the cover letter, base, or series, you can always\n> detach or checkout another series without losing anything.  If you\n> switch back, all your staged and unstaged changes will remain staged and\n> unstaged where you left them.  That solves the \"checkout a different\n> series with modifications to the current series\" case.\n\nCool\n\n> \n> > git-appraise looks as though it might also have this behaviour.\n> > I think it's a nice way to do it, since you don't generally\n> > perform more than one review simultaneously. So I may well\n> > use this idea in git-candidate if it's okay. :)\n> \n> By all means.  For a review tool like git-candidate, it seems like you'd\n> want even more contextual information, to make it easier to specify\n> things like \"comment on file F line L\".  For instance, what if you\n> spawned the diff to review in an editor, with plenty of extra context\n> and a file extension that'll cause most editors to recognize it as a\n> patch (and specifically a git-candidate patch to allow specialized\n> editor modes), and told people to add their comments after the line they\n> applied to?  When the editor exits successfully, you can scan the file,\n> detect the added lines, and save those as comments.  You could figure\n> out the appropriate line by looking for the diff hunk headers and\n> counting line numbers.\n\nI really like this idea, the current interface for commenting is a little\ntedious I find.\n\n> \n> If you use a format-patch diff that includes the headers and commit\n> message, you could also support commenting on those in the same way.\n> Does the notedb format support commenting on those?\n\nComments in notedb are just a git note keyed on the sha of the\ncommit being commented on, I'm not certain what advantage a format-patch\ndiff provides in this case?\n\nI've been closely following the 'patch submission process' thread,\nand given the discussion there I'm having doubts over the value\nof comments in git-candidate vs the mailing list. It seems to me that\ngit-candidate has many of the disadvantages of Github/Gitlab when it\ncomes to comments, for example, there is no threading.\n\nAlso the system would be less open than the mailing list, since,\nas it stands currently you would require push access to the repository\nto comment on anything.\n\nIt may be worth reflecting that one reason some organisations\nhave switched away from mailing list reviews to Github/Gitlab is that\nthey provide patch tracking, where the mailing list provides none,\nso patches there can be 'lost'. So instead of trying to reimplement\nan entire Gerrit/Github/Gitlab ui on the commandline, I wonder whether\nit would be sufficient to add the minimum functionality necessary\nto provide git with native patch tracking, and leave comments for the\nmailing list. Ofcourse this is exactly what git-series seems to do,\nso in some sense I may be advocating dropping my own work in favour of\nimproving git-series.\n\nOn the other hand, relying on the mailing list means that some of the\nhistory of a series is left outside of the repository which is\nanathema to the goal of git based/stored review, not least because\nmail archives are centralised.\n(which can obviously be problematic (as we've seen recently with gmane))\n\nMaybe there's a better solution to this problem than git-candidate then,\nmaybe we can just invent some wonderful new subcommand that fetches\na mailing list archive into a git repo, for those that want that,\nI don't know.\n\nOut of interest, did you have any thoughts on Notedb itself with respect\nto its suitability for git-series?\n\n> \n> > I haven't found time to use the tool to do any serious review\n> > yet, but I'll try and post some more feedback when I do.\n> \n> Thanks!\n> \n"},{"id":"293662","messageId":"13509A14-16CB-476C-B983-7001F3D0DA61@joshtriplett.org","threadId":"42957","inReplyTo":"20160810093731.GA3404@salo","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-08-10T22:07:26Z","receivedAt":"2016-08-10T22:09:42Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On August 9, 2016 11:37:31 PM HST, Richard Ipsum <richard.ipsum@codethink.co.uk> wrote:\n>On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote:\n>> On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote:\n>> > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:\n>> > > I'd welcome any feedback, whether on the interface and workflow,\n>the\n>> > > internals and collaboration, ideas on presenting diffs of patch\n>series,\n>> > > or anything else.\n>> > \n>> > One other nice thing I've noticed about this tool is the\n>> > way series behave like regular git branches: I specify the name\n>> > of the series and from then on all other commands act on that\n>> > series until told otherwise.\n>> \n>> Thanks; I spent a while thinking about that part of the workflow.  I\n>> save the current series as a symbolic ref SHEAD, and everything\n>operates\n>> on SHEAD.  (I should probably add support for running things like\n>\"git\n>> series log\" or \"git series format\" on a different series, because\n>right\n>> now \"until told otherwise\" doesn't include a way to tell it\n>otherwise.)\n>\n>Apologies for this delayed response,\n>I needed time to gather my thoughts,\n>and also to fix the perl libgit2 binding to allow me to use\n>your symbolic ref suggestion. :p\n\nYeah, during git-series development I ended up doing some work on both libgit2 and git2-rs. :)\n\n>Though it turns out that libgit2 doesn't currently allow\n>me to write arbitrary data to a symbolic ref as git-symbolic-ref(1)\n>will,\n>so this still needs to be fixed somehow.\n\nWhat arbitrary data do you need to write?\n\nAlso, note that you want to put your symbolic ref in refs/, not directly in .git, so that git takes it into account for object reachability.\n\n>> > git-appraise looks as though it might also have this behaviour.\n>> > I think it's a nice way to do it, since you don't generally\n>> > perform more than one review simultaneously. So I may well\n>> > use this idea in git-candidate if it's okay. :)\n>> \n>> By all means.  For a review tool like git-candidate, it seems like\n>you'd\n>> want even more contextual information, to make it easier to specify\n>> things like \"comment on file F line L\".  For instance, what if you\n>> spawned the diff to review in an editor, with plenty of extra context\n>> and a file extension that'll cause most editors to recognize it as a\n>> patch (and specifically a git-candidate patch to allow specialized\n>> editor modes), and told people to add their comments after the line\n>they\n>> applied to?  When the editor exits successfully, you can scan the\n>file,\n>> detect the added lines, and save those as comments.  You could figure\n>> out the appropriate line by looking for the diff hunk headers and\n>> counting line numbers.\n>\n>I really like this idea, the current interface for commenting is a\n>little\n>tedious I find.\n>\n>> \n>> If you use a format-patch diff that includes the headers and commit\n>> message, you could also support commenting on those in the same way.\n>> Does the notedb format support commenting on those?\n>\n>Comments in notedb are just a git note keyed on the sha of the\n>commit being commented on, I'm not certain what advantage a\n>format-patch\n>diff provides in this case?\n\nI meant for opening in an editor to write email-reply-style comments. The review tool and review storage format should allow commenting on commit messages, not just diffs.\n\n>I've been closely following the 'patch submission process' thread,\n>and given the discussion there I'm having doubts over the value\n>of comments in git-candidate vs the mailing list. It seems to me that\n>git-candidate has many of the disadvantages of Github/Gitlab when it\n>comes to comments, for example, there is no threading.\n\nThat's not inherent, though. You could allow commenting on a comment easily enough. (Of course, at some point you've recreated email-style in-reply-to headers...)\n\n>Also the system would be less open than the mailing list, since,\n>as it stands currently you would require push access to the repository\n>to comment on anything.\n\nYou'd need a federation mechanism.\n\n>It may be worth reflecting that one reason some organisations\n>have switched away from mailing list reviews to Github/Gitlab is that\n>they provide patch tracking, where the mailing list provides none,\n>so patches there can be 'lost'. So instead of trying to reimplement\n>an entire Gerrit/Github/Gitlab ui on the commandline, I wonder whether\n>it would be sufficient to add the minimum functionality necessary\n>to provide git with native patch tracking, and leave comments for the\n>mailing list. Ofcourse this is exactly what git-series seems to do,\n>so in some sense I may be advocating dropping my own work in favour of\n>improving git-series.\n\nI think the two serve different (though related) functions. I'd love to be able to use a text editor and command-line tool to produce and submit comments to systems like Gerrit or GitHub.\n\n>On the other hand, relying on the mailing list means that some of the\n>history of a series is left outside of the repository which is\n>anathema to the goal of git based/stored review, not least because\n>mail archives are centralised.\n>(which can obviously be problematic (as we've seen recently with\n>gmane))\n\nAgreed. You can always choose to *intentionally* discard history, or store it elsewhere, but having it in the repository allows you to make that decision with all the data really available (and easily backed up).\n\n>Maybe there's a better solution to this problem than git-candidate\n>then,\n>maybe we can just invent some wonderful new subcommand that fetches\n>a mailing list archive into a git repo, for those that want that,\n>I don't know.\n\npublic-inbox seems to address that use case. I'd love to see a public-inbox version of LKML, with full history. I don't think that fully solves the review storage and interchange problem, but it seems like an *excellent* solution for email archiving, and for distribution of archives.\n\n>Out of interest, did you have any thoughts on Notedb itself with\n>respect\n>to its suitability for git-series?\n\nSeems like a potentially reasonable format for storing reviews. I think the two could work well together, with git-series storing all the historical versions of a series, and then a notedb could reference those commits.\n\nI've given some thought to using git-series as a server-side storage format for something like a pull request. I think it might make sense for a tool like Gerrit or GitLab to allow pushing and pulling series branches (that must fast-forward) to a special ref (like Gerrit's refs/for/master).\n\n"},{"id":"293691","messageId":"20160811062344.GA20280@starla","threadId":"42957","inReplyTo":"13509A14-16CB-476C-B983-7001F3D0DA61@joshtriplett.org","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-11T06:23:44Z","receivedAt":"2016-08-11T06:23:55Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Josh Triplett <josh@joshtriplett.org> wrote:\n> On August 9, 2016 11:37:31 PM HST, Richard Ipsum <richard.ipsum@codethink.co.uk> wrote:\n> \n> >Maybe there's a better solution to this problem than git-candidate\n> >then,\n> >maybe we can just invent some wonderful new subcommand that fetches\n> >a mailing list archive into a git repo, for those that want that,\n> >I don't know.\n> \n> public-inbox seems to address that use case. I'd love to see a\n> public-inbox version of LKML, with full history. I don't think\n> that fully solves the review storage and interchange problem,\n> but it seems like an *excellent* solution for email archiving,\n> and for distribution of archives.\n\nThanks, I'd like to see an LKML version, too :)  First, I want\nto ensure public-inbox can handle large repos better, first.\npublic-inbox.org/git has been doing well so far, even on a\nlow-end VM with 2 cores and 2GB RAM.\n\nI don't have anything close to full history of LKML, and\ndownload.gmane.org is down, right now :<  I'd use NNTP, but\nnews.gmane.org gets overloaded from slrnpull and I even got\ntemporarily banned there before discovering download.gmane\n:x\n\nMaybe I'll do what was done with linux.git in 2005 and just\nignore old mail for a while...\n"},{"id":"299367","messageId":"CAPnjgZ2-sWuibLGK-AR2D=mM=MoOrQM9OVuJnCtVAE5GYqJXcQ@mail.gmail.com","threadId":"42957","inReplyTo":"20160801183750.ivwue4mxm5ilgzqz@x","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Simon Glass","fromEmail":"sjg@chromium.org","sentAt":"2016-08-15T18:17:11Z","receivedAt":"2016-08-15T18:17:49Z","isPatch":false,"sender":{"key":"sjg@chromium.org","avatar":null},"body":"Hi Josh,\n\nOn 1 August 2016 at 12:37, Josh Triplett <josh@joshtriplett.org> wrote:\n> On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote:\n>> On 07/29/2016 12:40 AM, Josh Triplett wrote:\n>> > I'd like to announce a project I've been working on for a while:\n>> >\n>> > git-series provides a tool for managing patch series with git, tracking\n>> > the \"history of history\". git series tracks changes to the patch series\n>> > over time, including rebases and other non-fast-forwarding changes. git\n>> > series also tracks a cover letter for the patch series, formats the\n>> > series for email, and prepares pull requests.\n>>\n>> Just as an FYI, I wouldn't be surprised if there's some overlap, or\n>> potential for merging of tools, between this tool and the \"patman\" tool\n>> that's part of the U-Boot source tree:\n>>\n>> http://git.denx.de/?p=u-boot.git;a=blob;f=tools/patman/README;h=e36857dedea1d0dbafa41732aaf9bf0988d63f38;hb=HEAD\n>\n> Interesting tool; thanks for the link.\n>\n> As far as I can tell from that documentation, patman doesn't track old\n> versions of a patch series; you rebase to modify patches or change\n> patman tags (embedded in commit messages), and nothing preserves the\n> previous version.  And it tracks the cover letter and similar in one of\n> the commit messages in the series, so previous versions of that don't\n> get saved either.  If you wanted to track the history of your changes,\n> you'd have to use branch names or similar.\n\nThat's right. Normally you would keep the old branch around, or tag\nit. Of course old branches are often based on older versions the\nupstream repo, so they are not that useful for diiff, etc. But the\nnormal procedure when updating a series to a new version is:\n\ngit checkout -b wibble-v2 wibble\ngit rebase upstream/master\ngit commit --amend\n# Edit commit to add 'Series-version: 2', update cover letter etc.\n\nOf course any change log is preserved when you move to v3, since you\njust add more 'Series-changes:' tags. The old version of the cover\nletter, and the old version of the commits can be preserved with 'git\ntag'.\n\n>\n> In addition, tracking metadata in commit messages only works with a\n> patches-by-mail workflow where the messages get processed when\n> generating patches; that doesn't work for please-pull workflows.\n\nCan you explain what a please-pull workflow looks like, and what tags\nare expected?\n\n>\n> patman does have quite a few interesting ideas, though.  git-series\n> needs some way of handling To/Cc addresses for patches and the cover\n> letter (beyond just scripts/get_maintainer.pl), and more automatic\n> handling of series versioning (v2, v3, ...) and associated series\n> changelogs.  Suggestions welcome.\n\nPatman builds the cover letter change lists from the commits. The main\npoint of patman is to automate the error-prone process of submitting a\nperfectly formed patch series.\n\nIn particular, patman requires no change to the normal workflow that\npeople use with git.\n\n>\n> - Josh Triplett\n\nRegards,\nSimon\n"},{"id":"299384","messageId":"20160815200553.ettprytevjjk7a6b@x","threadId":"42957","inReplyTo":"CAPnjgZ2-sWuibLGK-AR2D=mM=MoOrQM9OVuJnCtVAE5GYqJXcQ@mail.gmail.com","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-08-15T20:05:53Z","receivedAt":"2016-08-15T20:06:22Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Mon, Aug 15, 2016 at 12:17:11PM -0600, Simon Glass wrote:\n> On 1 August 2016 at 12:37, Josh Triplett <josh@joshtriplett.org> wrote:\n> > On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote:\n> >> On 07/29/2016 12:40 AM, Josh Triplett wrote:\n> >> > I'd like to announce a project I've been working on for a while:\n> >> >\n> >> > git-series provides a tool for managing patch series with git, tracking\n> >> > the \"history of history\". git series tracks changes to the patch series\n> >> > over time, including rebases and other non-fast-forwarding changes. git\n> >> > series also tracks a cover letter for the patch series, formats the\n> >> > series for email, and prepares pull requests.\n> >>\n> >> Just as an FYI, I wouldn't be surprised if there's some overlap, or\n> >> potential for merging of tools, between this tool and the \"patman\" tool\n> >> that's part of the U-Boot source tree:\n> >>\n> >> http://git.denx.de/?p=u-boot.git;a=blob;f=tools/patman/README;h=e36857dedea1d0dbafa41732aaf9bf0988d63f38;hb=HEAD\n> >\n> > Interesting tool; thanks for the link.\n> >\n> > As far as I can tell from that documentation, patman doesn't track old\n> > versions of a patch series; you rebase to modify patches or change\n> > patman tags (embedded in commit messages), and nothing preserves the\n> > previous version.  And it tracks the cover letter and similar in one of\n> > the commit messages in the series, so previous versions of that don't\n> > get saved either.  If you wanted to track the history of your changes,\n> > you'd have to use branch names or similar.\n> \n> That's right. Normally you would keep the old branch around, or tag\n> it. Of course old branches are often based on older versions the\n> upstream repo, so they are not that useful for diiff, etc. But the\n> normal procedure when updating a series to a new version is:\n> \n> git checkout -b wibble-v2 wibble\n> git rebase upstream/master\n\nThat's the workflow I used before git-series, as well.  Having to create\nversioned branch names motivated creating git-series; the branch names\nin the git-series documentation (\"feature-v8-rebased-4.6-alice-fix\") are\n*reduced* versions of actual branch names used for internal projects.\n\n> > In addition, tracking metadata in commit messages only works with a\n> > patches-by-mail workflow where the messages get processed when\n> > generating patches; that doesn't work for please-pull workflows.\n> \n> Can you explain what a please-pull workflow looks like, and what tags\n> are expected?\n\nYou push the branch somewhere, as a branch or tag, and then use git\nrequest-pull or otherwise tell someone \"please pull from here\".  They\npull the *exact* commit hashes you pushed, including whatever you based\nthem on.  That means they get the exact commit messages you pushed.  So,\nif you have any inline metadata in the commit message, that would end up\nin the project history.  The Linux kernel and other projects object to\ngetting those kinds of bits in commit messages; I've seen many patches\nrejected because they included a Gerrit Change-Id.\n\nTracking the history and cover letter in a separate string of \"series\ncommits\" allows the underlying patch series to contain the exact commits\nyou want upstream to pull, without any postprocessing required.\n\n- Josh Triplett\n"},{"id":"300038","messageId":"01106859-2e0b-326a-eca2-e8f935a90beb@gmail.com","threadId":"42957","inReplyTo":"13509A14-16CB-476C-B983-7001F3D0DA61@joshtriplett.org","subject":"Re: [ANNOUNCE] git-series: track changes to a patch series over time","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-08-24T10:56:03Z","receivedAt":"2016-08-24T10:58:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 11.08.2016 o 00:07, Josh Triplett pisze:\n> On August 9, 2016 11:37:31 PM HST, Richard Ipsum\n> <richard.ipsum@codethink.co.uk> wrote:\n>> On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote:\n[...]\n\n>>> If you use a format-patch diff that includes the headers and\n>>> commit message, you could also support commenting on those in the\n>>> same way. Does the notedb format support commenting on those?\n>> \n>> Comments in notedb are just a git note keyed on the sha of the \n>> commit being commented on, I'm not certain what advantage a \n>> format-patch diff provides in this case?\n> \n> I meant for opening in an editor to write email-reply-style comments.\n> The review tool and review storage format should allow commenting on\n> commit messages, not just diffs.\n\nThere is also cover letter and interdiff, and one would want to\nbe able to comment also on those.\n\nSo how notedb solve problem of in-diff comments, in-commit comments,\npost-commit comments, whole series cover letter and cover-letter\ncomments, interdiff and interdiff message / comments?\n\n\nNb. GitHub Pull Requests include only some of those, compared to\nthe mailing list / Usenet news interface.\n \n>> I've been closely following the 'patch submission process' thread, \n>> and given the discussion there I'm having doubts over the value of\n>> comments in git-candidate vs the mailing list. It seems to me that \n>> git-candidate has many of the disadvantages of Github/Gitlab when\n>> it comes to comments, for example, there is no threading.\n> \n> That's not inherent, though. You could allow commenting on a comment\n> easily enough. (Of course, at some point you've recreated email-style\n> in-reply-to headers...)\n\nI wonder if we could use 'parent' header of a commit message for this,\nor equivalent...\n \n>> Also the system would be less open than the mailing list, since, as\n>> it stands currently you would require push access to the\n>> repository to comment on anything.\n> \n> You'd need a federation mechanism.\n\n...which is as easy to set up and use as mailing list, for sending\npatches, applying patches, and patch review.  And/or provide \nbi-directional interface to the mailing list (I think Debian \ninfrastructure tries to be (inter)operable by email).\n\nThere are various federated technologies (like pump.io), the\nproblem might be their popularity.\n\n>> It may be worth reflecting that one reason some organizations have\n>> switched away from mailing list reviews to Github/Gitlab is that \n>> they provide patch tracking, where the mailing list provides none, \n>> so patches there can be 'lost'. So instead of trying to\n>> reimplement an entire Gerrit/Github/Gitlab UI on the commandline, I\n>> wonder whether it would be sufficient to add the minimum\n>> functionality necessary to provide git with native patch tracking,\n>> and leave comments for the mailing list. Of course this is exactly\n>> what git-series seems to do, so in some sense I may be advocating\n>> dropping my own work in favour of improving git-series.\n> \n> I think the two serve different (though related) functions. I'd love\n> to be able to use a text editor and command-line tool to produce and\n> submit comments to systems like Gerrit or GitHub.\n\nI think there are command-line tools that allow to submit comments\nto GitHub.\n\n-- \nJakub Narębski\n"}]}