stg repair can throw away commits

[smoofra]

To Reproduce:

$ git co -b xxx origin/main
$ stg init
$ stg new xxx
$ vi README
$ stg refresh
$ git commit --amend
$ stg repair

Results.

The amended commit has not been turned into a patch, and instead has been silently left behind.

Expected results.

Ideally stg repair would recognize that only the patch message has changed and update that. In any case though it should't abandon the commit, it should patchily the amended commit resulting in two, now conflicting identical unapplied patches in the
series.

Why would I do that anyway?

I use stgit to maintain my queue of ongoing patches while contributing to llvm-project, which uses Phabricator as a code review platform. Phabricators client wants to amend the commit messages to add its own information to them, which makes the workflow with stgit awkward.

[NonLogicalDev]

Hey @smoofra, yes unfortunately this is one of the shortcomings of stg at the moment. I too use Phab at work and I can definitely feel your pain. I have been thinking about how to make the repair process better. And if not detect the amends automatically then at least give the user a way to fixup stack state by hand. But alas that is the current limitation.

Working with Phab I have come up with a workaround for the trivial case of "oops I (or **cough** arc diff **cough** made an amend of the topmost commit":

• https://gist.github.com/NonLogicalDev/bd110dc0a9c1519f6d79a4138b3c80de

This will get you out of the pickle, but only if the amend touched the topmost commit. That will not save you from interactive rebase.

$ git co -b xxx origin/main
$ stg init
$ stg new xxx
$ vi README
$ stg refresh
$ git commit --amend

$ stg-repair-top
# your stack should be fixed and changes to your topmost commit should be preserved

@jpgrayson Do you have any workarounds if the user accidentally done git rebase -i and made some changes? I am happy we have stg repair but most of the time I am too scared to use it.

[jpgrayson]

A thing I'm noticing about the above amend scenario is that it only seems to be a problem when operating on the first applied patch. Consider the following scenario:

$ stg branch --create test-branch
$ stg new -m p0
$ vi README
$ stg refresh
$ stg new -m p1
$ vi README
$ stg refresh
$ git commit --amend -m "p1 amended"
$ stg repair
Creating 1 new patch ... 
  Creating patch p1-amended from commit a4cba3c316942cb99267baa9f83e85bd6d27a1aa
done
Checking patch appliedness ... 
  p1-amended is now applied
  p1 is now unapplied
done
Now at patch "p1-amended"
$ stg series
+ p0
> p1-amended
- p1

In this scenario, I think we get satisfactory behavior from stg repair. The amended commit is identified and patchified and the former patch remains in the series, but unapplied.

So it seems like stg repair could be repaired to recognize the amended commit's relationship to the stack's base and do its normal thing from there. I'll try to look at this in more detail in the near future.

[jpgrayson]

I've modified stg repair in 879b5c2 to handle the reported scenario. It was just a matter of having repair comprehend the stack base and proceed from there.

I have not attempted to resolve any repair scenarios involving git rebase -i (@NonLogicalDev), but if there is a use case there that stg repair doesn't handle well, I'd love to have a new issue opened for it.