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.
Attachment:
signature.asc
Description: This is a digitally signed message part