[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 ("[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.


Reply to: