Re: [PATCH] describe: count the distance correctly when commit dates are skewed

From: SZEDER Gábor <szeder.dev@gmail.com>
Date: Nov 2, 2026, 06:17 UTC
Message-ID: <augrFe35Zci2mG+j@szeder.dev>
In-Reply-To: <xmqqa4nt2wch.fsf@gitster.g>

On Sat, Oct 31, 2026 at 06:07:10PM -0700, Junio C Hamano wrote:

Show 31 quoted lines

> Tuomas Ahola <taahol@utu.fi> writes:
> 
> > Linus Torvalds <torvalds@kernel.org> wrote:
> >
> >> +test_expect_success 'setup: describe a tag dated before its parent' '
> >> +	git init skew &&
> >> +	(
> >> +		cd skew &&
> >> +		git config core.commitGraph true &&
> >> +		test_commit --date "2020-01-01 18:00" base &&
> >> +		test_commit --date "2020-01-01 18:01" o &&
> >> +		test_commit --annotate --date "2020-01-01 17:01" T &&
> >> +		git checkout -b side o &&
> >> +		test_commit --date "2020-01-01 18:02" B &&
> >> +		git checkout main &&
> >> +		GIT_COMMITTER_DATE="2020-01-01 18:03" git merge --no-ff -m x side &&
> >> +		git commit-graph write --reachable
> >> +	)
> >> +'
> >
> > Just a clueless rewrite of the above.  I had quite fun writing it, so why not
> > to share... it works and might even offer some not-completely-bogus food for
> > thought.
> >
> > 	git init skew &&
> > 	(
> > 		cd skew &&
> > 		test_config core.commitGraph true &&
> 
> Doesn't this barf when it tries to register a clean-up action from
> inside a subshell?

In both cases this is a freshly initialized repository, and the commit graph has been enabled by default for a long time, so why do we need to set this config in the first place?