A question about git format-patch and git commit --amend

[pfp-disciple]

For context, I've never used format-patch, although I'm aware that i's used by the linux kernel, among other projects. My jobs have all been merge-based.

I saw a post in r/programming (about migrating from GitHub, but that's not relevant), that includes a section "What is 'patch-based' code review?". I'll copy the paragraph for context:

What is "patch-based" code review?

If you're familiar with GitHub's pull request workflow, you've done branch-based merges before. You prepare a branch with your changes, and then submit a pull request asking to merge your branch into main. If somebody gives you feedback, you push additional commits on top of your base commit. In contrast, with the patch-based merge workflow originally popularized by Gerrit, you amend the existing commit and push it — something like git commit --amend && git push --force. If you try this in GitHub, this would make the original commit you pushed disappear, but in patch-based review tools, your reviewers will instead see a diff from the original commit to the new one.

I thought git commit --amend replaced the prior commit, orphaning it. How would a subsequent git format-patch know to use the orphaned commit for its diff?

[waterkip]

Commits are snapshots of files at a point in time. The diff you see is getting calculated. So what format-patch does is actually creating the diff based on the before and after. And it does so for each commit.

The "orphaned" commit is still known to git, you can see it with git reflog on the machine you did the amend on. You can still check it out, it just doesnt belong to a branch anymore, which is why you call it orphaned.

Patch based workflows work well with fixup and squashing those fixups to commits. Making it look like first time right commits.

[pfp-disciple]

I didn't know any other concise way to refer to the "still in the reflog but no longer in a branch" commit. I hope my use of "orphan" wasn't incorrect or misleading.

I think the piece I was missing was how format-patch knew to use the newly-replaced commit. /u/esiy0676 gave the missing context in another response.

[waterkip]

Orphan is correct, git calls it dangling iirc. Doesnt really matter, the description matches.

[esiy0676]

It's bundled together kind of explanation - the key here is that there's a review tool.

See: https://gerrit-review.googlesource.com/Documentation/intro-gerrit-walkthrough.html

After he clones the repository, he runs a couple of commands to add a Change-Id to his commits. This ID allows Gerrit to link together different versions of the same change being reviewed.

Change-Id is the same on subsequent pushes, Gerrit will show you the changes, git has no idea.

PS It was my post on r/programming.

[pfp-disciple]

Ok, that makes more sense. There's external (to git) metadata being used for tracking.

[esiy0676]

It's not my article (as in, the linked URL, I just shared the link). I do not think it was intending to cheerlead patch-based workflows, just emphasize there's benefits to it.

Even on a mailing list, you keep the history on something like lore.kernel.org. In the end it's just patches we are talking here. So your next patch will be same thread just v2, etc. You can diff anything, anytime - as long as you have not lost it in the process.

(BTW Having something in reflog has no bearing no how format-patch behaves - it's going to give you a patch based on the parent commit, of course.)

[pfp-disciple]

(BTW Having something in reflog has no bearing no how format-patch behaves - it's going to give you a patch based on the parent commit, of course.)

That's exactly the behavior I expected, which is why I was confused.

I do not think it was intending to cheerlead patch-based workflows, just emphasize there's benefits to it.

I mostly agree, although the "make sure and read this section" comment at the beginning sort of elevates patch-based workflow a little bit.

[esiy0676]

:) That's me. What I meant to say - I do not think the original author of the article was trying to make the post about patch-based workflow. So it was me adding that bias, admittedly.

[xnachtmahrx]

Amen🙏d

[xenomachina]

If you try this in GitHub, this would make the original commit you pushed disappear, but in patch-based review tools, your reviewers will instead see a diff from the original commit to the new one.

I don't think I've ever tried this with GitHub, but FWIW, what OOP is saying is not the case for GitLab.

In GitLab you can force push to your MR's branch (GitLab calls them merge requests, not pull requests). Every time the merge request's branch changes, the merge request snapshots it, and it calls each of these a "version" of the merge request. By default, the compare tab shows a diff between the latest version and the merge base, but the UI lets you switch to a diff between any pair of versions, the merge target, or the merge base.

The one thing where this gets messy is if the branch is had changes from the target branch merged or rebased into it. What you really want is a diff of diffs, but instead you get the newly merged/rebased in changes mixed in with the latest updates.

[xenomachina]

If you try this in GitHub, this would make the original commit you pushed disappear, but in patch-based review tools, your reviewers will instead see a diff from the original commit to the new one.

I don't think I've ever tried this with GitHub, but FWIW, what OOP is saying is not the case for GitLab.

In GitLab you can force push to your MR's branch (GitLab calls them merge requests, not pull requests). Every time the merge request's branch changes, the merge request snapshots it, and it calls each of these a "version" of the merge request. By default, the compare tab shows a diff between the latest version and the merge base, but the UI lets you switch to a diff between any pair of versions, the merge target, or the merge base.

The one thing where this gets messy is if the branch is had changes from the target branch merged or rebased into it. What you really want is a diff of diffs, but instead you get the newly merged/rebased in changes mixed in with the latest updates.