[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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