Hacker News Reader

Comment by sedatk | Hacker News Reader

I think that's for packaging PRs in a single diff file. Here's an example: https://diffx.org/spec/examples.html#diff-of-multiple-commit...

View on HN

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

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.

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.

This submission about some mysql fork ships that fork as a couple of 15MB .patch files in git https://news.ycombinator.com/item?id=44148039 -> https://github.com/enhancedformysql/enhancedformysql/blob/fb...

I am not the target audience for such a thing and thus didn't try to apply said patch but my experience has been that I'm not going to hold my breath

`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.

perhaps the solution is to stop using those SCMs?

If wishing made it so...

I have so many stories I could tell at this point.

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.

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.

Electricity and running water are great; alas, not all houses everywhere have them ...

Who cares?

The solution to SCMs not doing this and that is to implement ones which do. We have done that.

You can unlock the cage, and that is enough; if the apes want to stay, let them stay.

Reply on news.ycombinator.com