I think that dgit and git debrebase have the potential to support maintenance of the linux package in Debian, but I've run into a number of issues that I think are currently show-stoppers. I can turn them into bug reports if you like, but I'm not yet sure which of them are actually bugs in git debrebase.
For reference, my work can be found on the "use-dgit" branch of <https://salsa.debian.org/benh/linux.git>. 1. Safe rebasing linux is team-maintained, and it's normal for multiple developers to push changes multiple times between releases. It's therefore not acceptable to update branches in a non-fast-forward way. I believe that git debrebase is supposed to avoid doing that, but it seems quite easy to defeat the check: $ git checkout -b use-dgit-test Switched to a new branch 'use-dgit-test' $ git branch --set-upstream-to=benh/use-dgit-test Branch 'use-dgit-test' set up to track remote branch 'use-dgit-test' from 'benh'. $ git debrebase -i OK, you are ahead of refs/remotes/benh/use-dgit-test Waiting for Emacs... Successfully rebased and updated refs/heads/use-dgit-test. $ git rev-list ..benh/use-dgit-test | wc -l 109 $ git debrebase conclude git-debrebase: error: No ongoing git-debrebase session. $ git-debrebase status current branch contents, in git-debrebase terms: branch is laundered key git-debrebase commits: anchor 470915f1011c git-debrebase import: declare upstream breakwater 470915f1011c git-debrebase import: declare upstream branch and ref status, in git-debrebase terms: stitched? (no record of git-debrebase work) Why was there no pseudo-merge? Shouldn't the remote tracking branch have been recorded as ffq-prev? 2. Replacing commits Over the last 2 days I've prepared the patches and scripts in the package for conversion to a dgit patches-applied branch. There are three of these that import patches from elsewhere, all of which I have moved to debian/bin/genpatch-<something>. genpatch-rt can be ignored because it's updating optional patches that will have to remain as quilt-in-git. The other two will now need to effectively replace existing commits. When we discussed this at DebConf it was suggested that git rebase, and therefore git debrebase, could match up commits with corresponding reverts and delete both of them from the commit series. I therefore rewrote those scripts to revert the old imported patches (in reverse order) and then apply the new patches. However, I now find that "git debrebase -i --autosquash" leaves all the commits intact. So I don't know how I can automate this commit replacement now. 3. Speed of operation git debrebase (that is, the default operation) is very slow in the linux repository. I don't know whether the size of the tree, or the number of commits to upstream code, or both, is the problem. On stable branches we may have 1000 or more such commits, so if (as I suspect) the time is proportional to that number then I think we would need at least a factor of 10 improvement in the speed of operation. Ben. -- Ben Hutchings The Peter principle: In a hierarchy, every employee tends to rise to their level of incompetence.
signature.asc
Description: This is a digitally signed message part
