"stg push" not indicating if the patch was modified

[shivaprasadbhat]

With recent update, if the patch is modified automatically when doing "stg push" Ex: Few hunks of the patch up on the stack are copied to the patches on the bottom of stack.

Earlier "stg push" used to mention "modified". Now, it doesnt! Is it expected?

[jpgrayson]

I think you are correct that there has been a regression w.r.t. stg push not reporting when pushed patches have been modified.

[jpgrayson]

Fixed in 2868ffe.

[shivaprasadbhat]

Excellent!! Thank you!

[jpgrayson]

I may have been too hasty with the fix for this that went into StGit 2.4.11. I think StGit may have gone from under-reporting modified patches to now over-reporting.

Specifically, the new behavior is for "(modified)" to be reported anytime the patch's commit changes. This is much more aggressive than StGit 1.x where "(modified)" would only be reported if the apparent diff of a patch changed. I.e. only reporting "(modified)" if hunks were added, removed, or moved.

StGit 1.x and 2.x have some differences in the exact git/gix operations performed when pushing patches. I need to look at this again, but IIRC the git commands StGit 1.x used provided a clear signal about whether a patch was "modified" in the limited "diff changed" sense whereas that signal is not as readily determined in StGit 2.x (but StGit 2.x does something faster).

Any feedback about new/old/ideal behavior(s) in this space would be appreciated.

[jpgrayson]

Okay, what's going on is that in StGit 2.0 we started using the --3way option to git apply when pushing patches which generally allows patch application to succeed first-try whereas in StGit 1.0 patches that required any sort of non-trivial patch application would first fail with git apply and then fallback to using git merge-recursive. Whenever the fallback to git merge-recursive was needed, that was when the "(modified)" status would be shown.

So in StGit 2.0, it is still conceivable that some patches might hit the git merge-recursive fallback and thus could show up as "(modified)", but in practice it doesn't happen.

The thing about the current patch application flow using git apply --3way is that it is fast and correct. So reverting back just so we can see "(modified)" doesn't feel like the right move to me.

The change I'm planning on making is to add a new "(updated)" status that indicates when a patch's commit is changed. I.e. replacing the overzealous and misleading "(modified)" status that went into 2.4.11.

[shivaprasadbhat]

Thanks for continuing. I havent had time to try your fix and give feedback.

I am confused.

• If on StGit 2.0, "git merge-recursive" fallback doesnt happen practically, then isn't the lost (modified) a lost functionality from StGit 1.0 ?
• Or We will have both (updated) and (modified) shown as and when necessary?(This would be best!)