Jeff King writes:
> On Thu, Apr 04, 2013 at 10:49:44PM +0200, Uwe Kleine-König wrote:
>
>> On Thu, Apr 04, 2013 at 04:33:44PM -0400, Jeff King wrote:
>> > [...]
>> > So I do think zdiff3 is useful, and I plan to continue using it.
>> Thanks for your description. I'm using and liking zdiff3, too.
On Thu, Apr 04, 2013 at 10:49:44PM +0200, Uwe Kleine-König wrote:
> On Thu, Apr 04, 2013 at 04:33:44PM -0400, Jeff King wrote:
> > [...]
> > So I do think zdiff3 is useful, and I plan to continue using it.
> Thanks for your description. I'm using and liking zdiff3, too. So I'd
> really like seeing
Hi Jeff,
On Thu, Apr 04, 2013 at 04:33:44PM -0400, Jeff King wrote:
> [...]
> So I do think zdiff3 is useful, and I plan to continue using it.
Thanks for your description. I'm using and liking zdiff3, too. So I'd
really like seeing it in vanilla git.
Thanks
Uwe
--
Pengutronix e.K.
On Thu, Mar 07, 2013 at 01:50:46PM -0500, Jeff King wrote:
> On Thu, Mar 07, 2013 at 10:40:46AM -0800, Junio C Hamano wrote:
>
> > Where we differ is if such information loss is a good thing to have.
> >
> > We could say "both sides added, identically" is auto-resolved when
> > you use the zealou
On Thu, Mar 07, 2013 at 10:40:46AM -0800, Junio C Hamano wrote:
> Where we differ is if such information loss is a good thing to have.
>
> We could say "both sides added, identically" is auto-resolved when
> you use the zealous option, and do so regardless of how the merge
> conflicts are presente
Jeff King writes:
> I'm not sure I agree. In this output (which does the zealous
> simplification, the splitting, and arbitrarily assigns deleted preimage
> to the first of the split hunks):
>
> 1234ACE789
>
> I do not see the promotion of C to "already resolved, you cannot tell if
> it was rea
Junio C Hamano writes:
> You could make it "1234789", and that is
> technically correct (what there were in the shared original for the
> conflicted part is 5 and then 6), but the representation pretends
> that it knows more than there actually is information, which may be
> somewhat misleading.
On Thu, Mar 07, 2013 at 09:26:05AM -0800, Junio C Hamano wrote:
> Without thinking about it too deeply,...
>
> I think the "RCS merge" _could_ show it as "1234ACE789"
> without losing any information (as it is already discarding what was
> in the original in the part that is affected by the confl
Jeff King writes:
> I was also curious whether it would the diff3/zealous combination would
> trigger any weird corner cases. In particular, I wanted to know how the
> example you gave in that commit of:
>
> postimage#1: 1234ABCDE789
> |/
> | /
> prei
On Wed, Mar 06, 2013 at 01:32:28PM -0800, Junio C Hamano wrote:
> > We show "both sides added, either identically or differently" as
> > noteworthy events, but the patched code pushes "both sides added
> > identically" case outside the conflicting hunk, as if what was added
> > relative to the com
On Wed, Mar 06, 2013 at 01:50:46PM -0800, Junio C Hamano wrote:
> I think it is more like "I added bread and my wife added bread to
> our common shopping list" and our two-way "RCS merge" default is to
> collapse that case to "one loaf of bread on the shopping list". My
> impression has always be
Jeff King writes:
> I think Uwe's example shows that it _is_ useful. Yes, you no longer have
> the information about what happened through 1-14 (whether it was really
> there in the ancestor file, or whether it was simply added identically).
> But that information might or might not be relevant.
Junio C Hamano writes:
> Jeff King writes:
>
>> But it would apply to the content that is outside
>> of the hunk marker; we have changed the concept of what is in the base
>> and what is in the conflict by shrinking the conflict to its smallest
>> size.
>
> Hmm, unless you mean by "base" somethi
Hello Junio,
On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > But it would apply to the content that is outside
> > of the hunk marker; we have changed the concept of what is in the base
> > and what is in the conflict by shrinking the conflict to its sma
On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > But it would apply to the content that is outside
> > of the hunk marker; we have changed the concept of what is in the base
> > and what is in the conflict by shrinking the conflict to its smallest
> > siz
Jeff King writes:
> But it would apply to the content that is outside
> of the hunk marker; we have changed the concept of what is in the base
> and what is in the conflict by shrinking the conflict to its smallest
> size.
Hmm, unless you mean by "base" something entirely different from
"what wa
On Wed, Mar 06, 2013 at 12:40:48PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > then it will produce the output that Uwe expects. While it can be
> > misleading,...
>
> Misleading is one thing but in this case isn't it outright wrong?
>
> If you remove <<< ours ||| portion from the c
Jeff King writes:
> then it will produce the output that Uwe expects. While it can be
> misleading,...
Misleading is one thing but in this case isn't it outright wrong?
If you remove <<< ours ||| portion from the combined diff output,
I would expect that the hunk will apply to the base, but tha
On Wed, Mar 06, 2013 at 08:26:57PM +0100, Antoine Pelisse wrote:
> > however the difference isn't that easy to spot any more. I expected
> >
> > diff --cc file
> > index a07e697,5080129..000
> > --- a/file
> > +++ b/file
> > @@@ -12,7 -12,7 +12,12 @@@
>
> however the difference isn't that easy to spot any more. I expected
>
> diff --cc file
> index a07e697,5080129..000
> --- a/file
> +++ b/file
> @@@ -12,7 -12,7 +12,12 @@@
> 12
> 13
> 14
> ++<<< ours
> +
> git checkout --conflict=diff3 file
That's somehow unrelated, but shouldn't we have a "conflict" option to
git-merge as we have for git-checkout ?
With something like this (pasted into gmail):
diff --git a/builtin/merge.c b/builtin/merge.c
index 7c8922c..edad742 100644
--- a/builtin/mer
Hello,
Here comes another recipe for a different suggestion:
git init
echo 1 > file
git add file
git commit -m 'base'
git branch branch
seq 1 30 | grep -v 15 > file
git commit -m 'add 2-30 without 15' file
git checkout branch
22 matches
Mail list logo
