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