From: Harald Nordgren <haraldnordgren@gmail.com>
Date: Wed, 04 Mar 2026 10:30:29 GMT
Subject: Re: [PATCH v30 0/2] status: add status.compareBranches config for multiple branch comparisons
Message-ID: <20260304103029.8273-1-haraldnordgren@gmail.com>
In-Reply-To: <xmqq1pi1wzzh.fsf@gitster.g>

> The above two uses ( cd test && git $command ) to do what it can do
> with "git -C test $command", but the rest of the script seems to
> mostly stick to the latter.  Want to be a bit more consistent?

Good point, will fix!

> We see only one because... @{upstream} and @{push} are both
> origin/main and we can dedupe and there is no extra advice needed?
> If @{push} were missing and only @{upstream} existed, we would also
> see just one, so this test feels a bit under-explained.

Renaming this this now to clarify that it tests deduplicating. Also added
two new tests, for when reach of @{push} and @{upstream} are used alone.

> One thing the "advance" function does is to call "test_tick" to
> increment the mock timestamp, but the incremented mock timestamp
> would not survive beyond the end of a subshell.  Not that it matters
> too much to have commits with the same timestamp in these tests, as
> long as things are made more reproducible by use of the "advance"
> function.

Yeah, it's not great when used with subshells, I ended up differentiting
commits only by name like 'advance work2' because as you say, otherwise
they will get the same commit hash.

> I also am curious what should [jc: ditto] happen when @{upstream}
> and @{push} point at the same origin/main and our current branch is
> ahead by 1 commit.  The pull side would say "you are ahead of
> origin/main" and stop wile the push side would say the same thing
> with advice to push it out for publishing?  Or should they get
> deduped?

Jumping in altough the question was not directed to me:

When behind and ahead of the same branch we show the "diverged" message,
and since only one line is shown when deduped I think it works in a logical
way.

> So td;lr is that the tests in this step mostly look great.  It is
> just the semantics of "dedup" is a bit unclear, without a test that
> makes it clear (like the "@{push} @{upstream} @{push}" one), and
> perhaps a bit more documentation how having multiple tokens on the
> status.compareBranches variable affects the output.  A (n easier)
> half of that additional documentation could be as small as the
> following, but I didn't attempt to deal with the "dedup" part.

Will add documentation for the depuping and a new test case.


Harald