On Mon, Jul 29, 2013 at 10:07 PM, Ulrich Mueller <[email protected]> wrote: > Is the history from the v0.26.0 tag to the tip of the branch linear? > If it contains merge commits, then git format-patch / git am isn't > guaranteed to work.
There are branches. There is obviously /A/ linear path from the tag to the head (it is in the log), but there probably isn't a single such path. I'm not sure that all of the commits that ended up being output are in any such path, however. I still find it odd that some are able to apply that patch. I just tried again with git 1.8.3.2 and got the same behavior. If others are getting a patch that applies then there is something bizarre going on. I get a patch file that refers to three files that are obviously not anywhere near the root of the tree - they're buried 4 levels down. If git format-patch has undefined behavior when there are merges then that would be sufficient to explain it. I have no idea why the behavior varies, but that's certainly a possible consequence of it being undefined. Interestingly enough a similar problem comes up on the topic of validating a signed git tree (something I've been pondering for the eventual gentoo git migration). When you have merges there really is no way to know which branch is the "new" branch vs the "original" branch - git just doesn't have that concept. Figuring out what happened in a merge usually isn't difficult for a human, but it is pretty hard to build a script that can follow a tree back through merges the "right" way. Rich
