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 zealous option,
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, 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 it in
Jeff King p...@peff.net 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,
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 common
Jeff King p...@peff.net 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
|/
| /
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 1234AB=XCD=YE789
without losing any information (as it is already discarding what was
in the original in the part that is affected by the
Junio C Hamano gits...@pobox.com writes:
You could make it 1234AB|5=AXC|=CDE|6=YE789, 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
Jeff King p...@peff.net 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):
1234AB|56=XCD|YE789
I do not see the promotion of C to already resolved, you cannot tell
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 presented.
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
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
---
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
+15
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 @@@
12
Jeff King p...@peff.net 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
On Wed, Mar 06, 2013 at 12:40:48PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Hello Junio,
On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
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 been that
22 matches
Mail list logo
