Re: Trimming 'deadheads' (TREESAME 2nd parent) from revision walks?

From: Philip Oakley <philipoakley@iee.email>
Date: Sep 21, 2021, 18:24 UTC
Message-ID: <be7ec330-2b2c-a01f-c7ca-e5e752493ee0@iee.email>
In-Reply-To: <9b85811f-de5d-24b3-36f6-7e2f9be6cae0@iee.email>

On 21/09/2021 14:36, Philip Oakley wrote:

Show 12 quoted lines

> The `theirs` strategy is really only suitable for maintainers, rather
> than solo coders, as it need to be 'old releases` that are kept, rather
> 'old cruft` (I've generated too much of that in my time).
>
> Dscho's scripts (for anyone interested) for GfW are in
> https://github.com/git-for-windows/build-extra/blob/main/shears.sh#L16-L18
> and 
> https://github.com/git-for-windows/build-extra/blob/main/ever-green.sh,
> though from the script perspective it's an 'ours' strategy.
>
> Dscho has to locate the start commit via it's subject line, rather than
> it's topology.

It's taken me a while to realise why/how Dscho is using 'ours', for a 'theirs' merge.

He is inserting that merge into the start of the --merging-rebase's instruction sheet, which means that the rebase itself will reverse the meaning of 'ours' and 'theirs' as it checks out the 'theirs' branch first before performing the actions in the instruction sheet.

Thus the 'ours' strategy now works in our favour, to effectively deadhead the old hear as a 'theirs' merge and then begin the rebasing of the Git-for-Windows patch thicket on top of the latest Git.

Sneaky.

-- Philip (added dscho as cc, just in case I've got it wrong again;-)