Path: csiph.com!weretis.net!feeder4.news.weretis.net!newsfeed.CARNet.hr!news.spin.it!bofh.it!news.nic.it!robomod From: Ben Hutchings Newsgroups: linux.debian.kernel Subject: Issues with using git debrebase for linux Date: Sun, 12 Aug 2018 05:00:01 +0200 Message-ID: X-Original-To: dgit@packages.debian.org X-Mailbox-Line: From debian-kernel-request@lists.debian.org Sun Aug 12 02:56:25 2018 Old-Return-Path: X-Amavis-Spam-Status: No, score=-11.543 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, LDO_WHITELIST=-5, MONEY=0.5, MURPHY_DRUGS_REL8=0.02, PGPSIGNATURE=-5, RCVD_IN_DNSWL_LOW=-0.7, SARE_MSGID_LONG40=0.637] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -6.1 Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-jgZYcmCNu5NMHBN9+z5H" X-Mailer: Evolution 3.28.2-1 MIME-Version: 1.0 X-Sa-Exim-Connect-IP: 86.18.191.213 X-Sa-Exim-Mail-From: ben@decadent.org.uk X-Sa-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false X-Mailing-List: archive/latest/117653 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/66ab847a0858d69b2fe6368a02136f081a144ca4.camel@decadent.org.uk Approved: robomod@news.nic.it Lines: 106 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: Debian kernel maintainers X-Original-Date: Sun, 12 Aug 2018 03:55:57 +0100 X-Original-Message-ID: <66ab847a0858d69b2fe6368a02136f081a144ca4.camel@decadent.org.uk> Xref: csiph.com linux.debian.kernel:61785 --=-jgZYcmCNu5NMHBN9+z5H Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 . 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=3Dbenh/use-dgit-test Branch 'use-dgit-test' set up to track remote branch 'use-dgit-test' from '= benh'. $ git debrebase -i=20 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-. 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. --=20 Ben Hutchings The Peter principle: In a hierarchy, every employee tends to rise to their level of incompetence. --=-jgZYcmCNu5NMHBN9+z5H Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAltvob0ACgkQ57/I7JWG EQmGxg/9HnEldsxj1KcMuW4gnbHpFaDDEOhldUwwTx8M5LFAMfb8TMIRzR+DUv+Z OFm+BpTXSVVU5HAFKisdhmwdI2hPf08l3iLQEfMvGBkjyZVp6Mc4Z2RlZ7zTTcik VS8H9V4sVG8OrbTYBfVCvxjshzkVtqxeSViL5RmDVJfN5mc7BxE/XWr+1SXLB1/4 cymQM+zmeZvcYD7KR7zWNkpX0vVR+n835jkbW0FVoJbad1oM8TxVa7wrOeLaPKxg ZgXkgHVQ6Cd7QKEPPOV5ZRc2/bgizhrKi5ykbc/mmB2mQwTdNVYiU8QNWlXyA8Zl zpUd6oNgUlvhnkjm+nRumbS94Sk1VD5/uSa6RG0sMO/+FRfv+Ee4+wplOjXh/0O5 Ip7tOMgOdfYD8rnraH8JIywTf7nOHTlv7BtEQeALGFGrPUWeTOO7j8cwcpo4tXDq z3wXAB9YoENapx7/QcOOaetIYx3O7xqH0podxdv2l1J7sKeH5rrBthPhb72PCJvL dOxQaCCbJqjlIYdHHfDwf1JjzoDzVtMOIUwEfmpDlYmrhKJVrBZPsFAuyljUxilo tYYJbdrlFNeQ1ptAUWnQ9u39M2E40pDCbKEALPQjKyTWe3HCgm7bq4Mp49dQycYB J6XBE6rHSqm7gVQ4ZQvVnPktgbP3dfBltU0q8TZyDSIrwQ52QvU= =OEdB -----END PGP SIGNATURE----- --=-jgZYcmCNu5NMHBN9+z5H--