>>>>> On Tue, 30 Jul 2013, Rich Freeman wrote:
> On Tue, Jul 30, 2013 at 2:47 AM, Ciaran McCreesh
> <[email protected]> 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
