"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: histedit: How to fold M, D?
To:
Christian Weisgerber <naddy@mips.inka.de>
Cc:
gameoftrees@openbsd.org
Date:
Mon, 24 Jul 2023 15:58:24 +0200

Download raw body.

Thread
On Mon, Jul 24, 2023 at 03:40:48PM +0200, Christian Weisgerber wrote:
> Christian Weisgerber:
> 
> > Commit 1: Change some files.
> > Commit 2: Delete some of those files.
> > 
> > How do I fold those two commits into one?
> 
> I have found a solution:
> 
> Start histedit, "edit" commit 1.
> 
> When histedit interrupts, "got rv" the files in question, then "got rm"
> them.  Continue the histedit operation.
> 
> When histedit stops with "Files which had incoming changes but could
> not be found in the work tree", just continue again.
> 
> The histedit operation concludes successfully, and you now have
> revised commits 1a and 2a, where the deletion of the files has moved
> from old commit 2 to new commit 1a.
> 
> You can now perform another histedit run and fold commit 1a into 2a.
> 
> Phew.

The "different content" check for deletions is supposed to be a
safe-guard in cases where comnands such as rebase, merge, cherrypick,
and backout delete files. If file content is not 100% the same then
we cannot assume that the file being deleted is the "same". Maybe the
file was changed for some important reason and should now be preserved?
There is no way a program can know the answer with certainty.
(Ideally, Got would ask you what it should do and offer some reasonable
options. But that feature is not yet implemented.)

However, your histedit situation is a different use case. Maybe we
should relax the pre-deletion check in this specific context?