Re: [ANNOUNCE] git-series: track changes to a patch series over time
Josh Triplett writes ("Re: [ANNOUNCE] git-series: track changes to a patch series over time"):
> On Thu, Aug 11, 2016 at 01:16:04PM +0100, Ian Jackson wrote:
> > My biggest question therefore is: how does your tool compare to
> > stgit ? Why should we use your tool rather than stgit ?
>
> While stgit does track the history of changes made to the stack, as far
> as I can tell, it doesn't do so in a manner meant for interchange
> between users. stgit works locally for one user, but doesn't seem to
> support multiple users. And the history of the patch stack doesn't
> include commit messages, nor does it group changes into logical commits.
> It seems more like the reflog (a tool to rescue old bits) than a
> historical record.
I don't understand what distinction there is between multiple users
and multiple development efforts by the same user. Or maybe I don't
understand what you mean by `support multiple users'. stg publish
seems to be the tool you use for sharing stg branches. NB I'm not
much of an stg user.
> > My next question is: how do you handle merging of changes made in
> > parallel in different meta-branches of the same series ? I don't mean
> > just aggregating patches, but other common operations such as:
> > reordering of patches; editing patch commit messages (or the cover
> > letter); splitting and merging patches; git rebase --autosquash; etc.
> >
> > I didn't see anything in the docs about this. And I confess I didn't
> > run your code to do any experiments.
>
> git-series does support merge commits within the series branch; see the
> section "git-series commits" in INTERNALS. Right now, git-series
> doesn't create those merge commits for you, but I plan to add a
> mechanism to support that. That'll probably start out as "here's two
> patch series, tell me when you've finished creating the merged version
> and I'll commit it", though I could imagine handling many simple cases
> more automatically. I hope that building a simple tool and
> incrementally improving it will work.
I think this is the key area of difficulty which stops people sharing
patch series as much as they like, at least as much as the lack of a
fast-forwarding view.
> > I did read the INTERNALS document about the data structures. I wonder
> > why you rejected other possibilities. In particular, your top level
> > `git series' branch data structure is not directly useable by any
> > other tool; it needs to be dereferenced/converted, to produce a
> > useable commit. Did you consider recording the metadata as dotfiles
> > in tree objects, or some such ?
>
> I started with a few fundamental constraints:
> - The commits tracked by the series *must* remain directly usable as
> commits in the underlying project, whether by sending patches or by
> pushing/pulling.
> - git must find every object in the history of a series reachable from a
> ref, so that fsck/repack/prune/etc cannot discard series history.
> - Similarly, `git push` and `git fetch` must work on series commits, and
> must transmit/receive the full series history with a series branch,
> without requiring any additional commands or special "series" versions
> of push/fetch.
>
> These constraints limit where metadata can live. Adding any dotfiles to
> the commits in the patch series would mean the resulting patches would
> include those dotfiles. Any metadata added to commit messages would end
> up in patches; note that several projects, including the Linux kernel,
> have complained about patches that include Gerrit "Change-Id" tags. Any
> format that stored patches within a series commit, rather than full
> links to commits for the patches, would not leave the commits themselves
> usable by git.
The usual approach taken by other patch stack tools is to treat picky
upstreams, like people who object to Change-Id, as an output format.
Those picky upstreams are likely to rewrite (or reapply) a series, so
what ends up in the upstream tree won't be the same commit objects
(and perhaps not the same tree objects) anyway.
> Do you see another possible storage format that meets all the
> constraints above?
Well, there is the obvious "pseudo-merge" convention: each patch
series tip is, when published, merged with -s ours with the previous
published version.
You do have to strip the pseudo-merge before starting work with
git-rebase, and then reapply it afterwards, but that is not
particularly difficult (and some tooling would help).
I intend to provide some tooling support this workflow, because I
think this workflow would work well with dgit. It produces a
fast-forwarding branch containing the intended output tree objects.
Series cover letters are less important for Debian so I haven't
thought about that much but the obvious answer is to have an "empty"
commit at the base of the stack.
> For repositories, you can push the series branch directly if you want to
> provide the history of your series, or you can push the current version
> (or an older version) of the patch series if you just want to publish
> that version.
Neither of these is compatible with dgit, of course.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: