logoalt Hacker News

kazinator • last Wednesday at 3:47 AM • 3 replies • 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

Replies

chipx86 • last Wednesday at 6:26 AM

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

➕ show 2 replies
anitil • last Wednesday at 4:55 AM

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

➕ show 2 replies
sedatk • last Wednesday at 4:02 AM

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.