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 <ijack...@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.