It's a solved problem. Commits can be represented as e-mails. (e.g. "git format-patch").
The mails can be catenated together into one file; this is called the mbox format.
Get three commits as three separate files:
$ git checkout
Your branch is up to date with 'origin/master'.
$ git format-patch HEAD~3
0001-Issue-successful-status-out-of-cdlog.recover.patch
0002-cdalias-take-zero-one-or-two-args.patch
0003-cdunalias-improve-test-for-undefined-alias.patch
Now checkout to before those commits, detaching HEAD:
$ git checkout HEAD~3
Note: checking out 'HEAD~3'.
You are in 'detached HEAD' state.
HEAD is now at b3c0288 New feature: auto recovery.
Now, catenate those files together to create one "patch.mbox" file:
$ cat 000* > patch.mbox
"git am" takes the whole file and applies it:
$ git am patch.mbox
Applying: Issue successful status out of cdlog.recover.
Applying: cdalias: take zero, one or two args.
Applying: cdunalias: improve test for undefined alias.
Clean up: return to master, delete the file:
$ git checkout master
Warning: you are leaving 3 commits behind, not connected to
any of your branches:
[ .... ]
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
$ rm patch.mbox
`git format-patch` and `git am` are great! Not all SCMs have something like that (many don't even have a diff format with enough information to reliably look up a file or apply all of its changes).
Having the whole state of a series of commits up-front can help with tools like ours that need that information ideally in one place and need to do analysis across multiple commits.
We also wanted to avoid issues where, due to a bug or network error or whatever, a missing patch in a sequence could result in a broken set of changes to apply. This is obvious when you're patching locally, but less so when you're sending to a tool to process later. Having it up-front reduces the chances of problems and simplifies a lot of edge cases.
If you're forced to use crappy STM, you can still make "stealth" uses of a better SCM in your private workflows.
I have stories also. In one company almost twenty years ago, some Java-spewing troglodytes went on a branch and did stupid things, like simultaneously rename A.java to B.java, B.java to C.java and C.java to A.java! While of course changing all their content too.
When it came time to merge, this was completely beyond the power of Subversion to sort out.
They came to me for help, and I whipped out my Meta-CVS, with excellent support not only for renaming but for doing snapshot imports which figure out renaming by file similarity. We imported all the baselines into it, and it did the merge flawlessly across the rotated renames.
We took the resulting merged baseline out of Meta-CVS and cleanly committed it to the Subversion trunk.
Don't discount other SCMs being useful as tools in SCM problems, even if they are not the main source-of-truth SCM used by the org.
I mean ok but you having a business reason to spend effort on supporting legacy systems doesn't really make for a convincing argument why others should care about your "standard" especially when the largest VCS (by far) already supports most of the things you are adding but in an incompatible way.
I worked somewhere that maintained their own branch of some software in this way, and they then committed the patches to git. A strange workflow for sure, but it seemed to mostly work
I maintained a long-lived branch once that involved major refactorings, with a lot of machine translation and a lot of manual translation. Periodic rerbasing involved a lot of diff diffing, and editing patch files was often a very practical approach.
Interesting. I wonder why they didn't mention this in their docs. They brush over "Git diff is close to the ideal..." but don't go into specifics like this.
