Re: [ANNOUNCE] git-series: track changes to a patch series over time
Josh Triplett writes ("[ANNOUNCE] git-series: track changes to a patch series over time"):
> I'd like to announce a project I've been working on for a while:
Thanks for the info. I have an interest in this kind of thing.
(At one point I tried to make a workable data model for something like
topgit, and even generated a few dozen of pages of algebra proving
that things would work, but the project was clearly too big for my
available effort.)
I don't mean to be discouraging, but I have some questions/concerns.
AFAICT from the available information, your tool is roughly speaking a
competitor to stgit. It seems to be intended to offer a different
(better) UI for patch stack management than raw git, and the ability
to push a series around in a fast-forwarding way.
My biggest question therefore is: how does your tool compare to
stgit ? Why should we use your tool rather than stgit ?
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.
I found the docs were unclear about the interaction between raw git
operations and git series operations. In particular, the interaction
between `git checkout' (and other branch-switching operations). I
think that some combinations of these operations could result in
... unexpected and undesirable results.
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 ?
One problem with the approach you have chosen (which, to be fair,
affects stgit too) is that supplying some system (a repository; an
auto builder; ...) with the appropriate tree in the form of a git
commit, does not provide anyone who retrieves that commit with the
series metadata - so all these other programs need to be provided with
what is essentially an output git branch which is the result of an
irreversible transformation from the git series information.
> I'm announcing this to debian-devel specifically because package
> maintenance tends to have this exact family of problems: maintaining a
> set of patches to upstream code, rebasing those patches on new upstream
> versions, reorganizing/refining/adding/dropping patches, having
> individual patches merged upstream, and backporting changes *from*
> upstream. I've seen git repositories for Debian packaging of software
> maintained many different ways, but in general, it seems non-trivial to
> simultaneously maintain a tree based on upstream git history while
> managing patches that don't go upstream right away. I hope that
> git-series can make Debian package maintenance easier.
That would be nice.
Ian.
Reply to: