Hello Jeff, I adapted the subject for the new evidences. On Wed, Mar 25, 2020 at 01:30:39AM -0400, Jeff King wrote: > On Tue, Mar 24, 2020 at 06:29:49PM +0100, Uwe Kleine-König wrote: > > > So v5.4.27 is an ancestor of HEAD: > > > > $ git merge-base --is-ancestor v5.4.27 @ && echo yes > > yes > > > > But!: > > > > $ git rev-list --count HEAD..v5.4.27 > > 3868 > > Yeah, this seems impossible. If v5.4.27 is an ancestor of HEAD, then > that rev-list result must be 0 commits. I'd trust merge-base over > rev-list's limiting, as the latter can be confused by clock skew. > > And indeed, doing: > > $ git log --graph --format='%h %cd' HEAD > > does point to some weirdness: > > [...] > * | | d1437a91a10e Tue Mar 24 17:53:00 2020 +0100 > * | | 803aad81ca69 Mon Feb 3 21:24:56 2020 +0100 > * | | 8a4579487b00 Thu Jan 30 11:58:13 2020 +0100 > * | | 25a9309d7ded Thu Jan 30 11:54:28 2020 +0100 > * | | e8f40385c55d Thu Jan 30 14:15:47 2020 +0100 > * | | b95a62694eae Wed Sep 30 11:19:29 2015 +0200 > * | | f5af38a6b7a1 Thu Sep 19 17:59:29 2019 +0200 > * | | 14075cd0ce1b Tue Nov 17 21:20:00 2015 +0100 > * | | 338647d2ab5c Wed Jul 13 10:41:40 2016 +0200 > * | | b31f3c6fbc18 Mon Sep 23 15:59:16 2019 +0200 > * | | 585e0cc08069 Sat Mar 21 08:12:00 2020 +0100 > The commit dates are very out-of-order: we go back to January (and even > to 2015!) for commits that are built on top of ones from last Saturday. That's done because the linearisation of the patch stack (that is created for consumption by quilt) uses the original committer dates for reproducibility. hmm ... > So while looking for a common ancestor with v5.4.27 (which is from only > a few days ago), I think we'd stop walking if we're left only with > UNINTERESTING commits (which these are, being ancestors of HEAD) that > seem to be from long before the last interesting one. > > There's a slop-counter which is supposed to skip over up to 5 > out-of-order commits, but that's clearly not enough here. Curiously, > bumping it to 100k commits isn't enough for this case! I had to bump it > to a million (effectively disabling the optimization entirely): > > diff --git a/revision.c b/revision.c > index 8136929e23..cf585f375e 100644 > --- a/revision.c > +++ b/revision.c > @@ -1085,7 +1085,7 @@ static void cherry_pick_list(struct commit_list *list, struct rev_info *revs) > } > > /* How many extra uninteresting commits we want to see.. */ > -#define SLOP 5 > +#define SLOP 1000000 > > static int still_interesting(struct commit_list *src, timestamp_t date, int slop, > struct commit **interesting_cache) > > I guess this depth might have to do with some weird topology between > linux-stable and linux.git (or maybe just something with your merge, I > didn't look too closely). > But my takeaways are: > > One, whatever is generating this history is wrong. Author dates can be > out of order (and it is perfectly reasonable to do so to represent > cherry-picked or rebased commits). But commit dates should generally be > monotonically increasing. If you're applying old patches, etc, you > should be using the old date for the author timestamp, but the current > time for the committer timestamp. Yeah, will take that to the team to discuss how to improve our tool. Thanks a lot for your analysis. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
