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 Fri, Aug 12, 2016 at 12:31:49PM +0100, Ian Jackson wrote:
> > Josh Triplett writes ("Re: [ANNOUNCE] git-series: track changes to a patch series over time"):
> > > 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).
>
> Not just git-rebase; that approach requires using special tools around
> any git command that operates on the actual patch series.
It does require some additional tooling, but it's quite modest. The
task is simple enough to be done by hand on an ad-hoc basis.
> You can't
> just run "git cherry-pick", "git rebase", "git rebase -i", "git commit
> --amend", "git am", or even just "git commit" without first un-applying
> the merge commit. Analysis tools like "git bisect" or "git blame" will
> also find themselves unhappy.)
This is not true.
Firstly, read-only operations which depend only on the tree object do
not need any special handling. The interchange format is directly
useful (buildable) without special tooling.
Secondly, I think git blame will do something sensible. (If it
doesn't, it could be fixed: ISTM that if git blame is examining a
merge commit P with parents A B where tree(P)==tree(A)!=tree(B), it
should descend to A and ignore B.)
git operations which do not rewrite history and do not introduce
additional parents, in particular cherry-pick and commit, work
correctly and produce a new commit on top of the pseudo-merge. The
pseudo-merge stripper tool can spot that and work with it.
> In addition, a "pseudo-merge" encodes non-trivial metadata into the
> parent list of commits, making it more difficult to handle things like
> merges between meta-commits, or conversely the history of commits that
> themselves include merges. How can you follow the history of such a
> patch series, and tell the difference between meta-commits and commits?
In practice this does not seem to be a problem. git-dpm uses a
similar representation.
> Some of those problems seem fixable; you could define a precise format
> based on pseudo-merge commits, including all the same metadata, a
> precise definition for which parents refer to other pseudo-merges and
> which ones refer to versions of the series, and so on. I don't see the
> advantage of such a format, though.
The advantage is that the interchange format between users of the
pseudo-merge and patch stack management tool is directly useable by
naive consumers of git histories.
> > 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.
>
> "tree objects" alone don't suffice. They provide enough information to
> extract a source tree, but then, so do archived source tarballs. That
> doesn't suffice for collaborative development processes anymore; for
> that, you need commit objects.
I think you have misunderstood me. I meant: unlike your `git series',
my approach produces a fast forwarding branch whose commits contain
the intended actual tree objects for the program source code.
> > 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.
>
> Git really despises empty commits and does its best to destroy them at
> every turn. (This partly comes from trying to drop already-applied
> commits when rebasing on a newer upstream.) I would not recommend
> putting any data you value into an empty commit.
>
> In addition, this would make the patch series completely unusable with a
> "git pull" or "git push" workflow, since upstream would not want that
> empty commit in its history; you could *only* send such a patch series
> via email.
In my view, the `git pull' format is an output format.
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: