Re: [gentoo-dev] Odd git format-patch behavior

[Ulrich Mueller]

>>>>> On Tue, 30 Jul 2013, Rich Freeman wrote:

> On Tue, Jul 30, 2013 at 2:47 AM, Ciaran McCreesh
> <ciaran.mccreesh@××××××××××.com> wrote:
>> The log doesn't give you a linear path. Use --decorate --graph to
>> avoid the illusion.

> Understood.  I think we're just quipping over the definition of
> "linear path" though.

> If having a linear path from A to B means that these nodes are
> connected and there is exactly one way to traverse the graph from A to
> B then there is not a linear path.  If having a linear path from A to
> B means that these nodes are connected, and thus there is at least one
> way to traverse the graph from A to B without revisiting any nodes,
> then there is a linear path.

> Using the latter definition, a linear path exists if one node shows up
> in a git log started from the other.  Using the former definition, you
> need to use --decorate --graph as you suggest.

You have a situation like the following here:

   A---B---C---D---E---F---G
        \             /
         H---I---J---K

D is the tagged commit, G is the branch tip. Now "git format-patch D"
will output all commits that are not D or its ancestors. So it will
give you commits E, F, and G. But it will also give you commits H, I,
J, and K because they are not ancestors of D.

The series of numbered patches (0001-* etc.) doesn't preserve the
information about the topology of the graph, so it's not surprising
that you get conflicts when you try to apply them on top of D.

Ulrich