Daniel Barkalow [EMAIL PROTECTED] writes:
I've started this, and have gotten as far as having read-tree accept 3
trees and ignore everything but the last 3. Am I correct in assuming that
if I break read-tree in any way, some test will fail?
If some test fails you would know you broke it, but
Hi, Daniel Barkalow wrote:
My proposal is actually to detect when a merge is ambiguous. In order to
determine that, however, you have to evaluate multiple potential outcomes
and see if they are actually different. I'm working on an efficient way to
do that.
Good.
There's also a related
On Wed, 24 Aug 2005, Daniel Barkalow wrote:
Of course, this is going to take a bit of work, because read-tree
currently puts all of its arguments into the cache and then works on
merging, and taking multiple ancestors requires putting them somewhere
else, because they won't fit in the cache.
Daniel Barkalow wrote:
I'm starting to work on letting the merging process see multiple
ancestors, and I think it's messy enough that I should actually discuss
it.
Review of the issue:
It is possible to lost reverts in cases when merging two commits with
multiple ancestors, in the
On Wed, 24 Aug 2005, A Large Angry SCM wrote:
Daniel Barkalow wrote:
I'm starting to work on letting the merging process see multiple
ancestors, and I think it's messy enough that I should actually discuss
it.
Review of the issue:
It is possible to lost reverts in cases when
5 matches
Mail list logo
