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.