Re: Issues with using git debrebase for linux
Ben Hutchings writes ("Issues with using git debrebase for linux"):
> 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.
Thanks for investigating. As you know, it's a very new tool so there
will be rough edges etc.
> 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?
I think this is probably a bug. I will try to reproduce it. (I'm
still cloning the giant repo.)
> 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.
I think the discussion at DC involved some misunderstanding.
I'm not sure exactly what this script of yours is supposed to do. To
"replace" a commit in your delta queue, I would do something with
git-[deb]rebase -i and a stunt $EDITOR. It should be fairly
straightforward. Does that make sense ?
> 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.
You have a 1000-commit delta queue ? Wow.
The time taken is roughly proportiona to the number of commits since
your last anchor, so (roughly) the length of the delta queue plus the
number of packaging commits since the last new-upstream.
There is probably a lot of scope for performance improvement. I
hadn't given performance much thought yet. If need be some parts
might be rewritten in C, although I have little experience of
doing git stuff in C.
Anyway, please file a bug about this.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: