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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 21/09/2021 14:36, Philip Oakley wrote:
> 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;-)



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux