From: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Use diff3 instead of merge in merge-recursive.
Date: Fri, 20 Oct 2006 23:11:21 +0200 [thread overview]
Message-ID: <20061020211121.GB3024@cepheus.pub> (raw)
In-Reply-To: <Pine.LNX.4.63.0610181135120.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi Uwe,
>
> On Wed, 18 Oct 2006, Uwe Zeisberger wrote:
>
> > If no error occurs, merge (from rcs 5.7) is nothing but:
> >
> > diff3 -E -am -L label1 -L label2 -L label3 file1 file2 file3 > tmpfile
> > cat tmpfile > file1
>
> Interesting.
> I wonder if we could streamline the code such that index_fd
> is called directly on the output of diff3? Of course, the result has to be
> removed when the call to diff3 fails.
I thought about that, too. But my primary intention was to get rid of
'merge', because the Solaris boxes I use from time to time lack merge,
but have (GNU) diff3[1]. I already had a mental note to look into that.
If Linus is right that there are systems that have merge but lack diff3,
then a combined approach is maybe the best? That is, try diff3 and if
that is missing, try merge. (Or the other way round if you prefer.)
OK, I looked a bit deeper into rcs, and it seems to handle the BSD diff3
case. So Linus might be right.
BTW, merge -p sends the merged result to stdout instead of overwriting
the first file given. That is
merge -p -L label1 -L label2 -L label3 file1 file2 file3
and (GNU)
diff3 -E -am -L label1 -L label2 -L label3 file1 file2 file3
are exactly equivalent.
So if that option of merge is old enough, these are the candidates for
the "combined approach" (see above).
> > I didn't made any timing tests or further tests for correctness, but I
> > hope Johannes still has the framework from the time when he converted
> > the Python script to C?
> >
> > @Johannes: If so, could you test this patch?
>
> I have to dig a little where I have it, but I think I can give it a try in
> a few hours (imagine this lyrics to the melody of the day job blues).
Seems to be a long blues because you didn't sent any results. :-(
Best regards
Uwe
[1] They also have a version of diff3 (I guess from BSD) that is not
suited to be used for merging, at least rcs' merge cannot use it.
--
Uwe Zeisberger
If a lawyer and an IRS agent were both drowning, and you could only save
one of them, would you go to lunch or read the paper?
next prev parent reply other threads:[~2006-10-20 21:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-18 8:59 [PATCH] Use diff3 instead of merge in merge-recursive Uwe Zeisberger
2006-10-18 9:35 ` Jakub Narebski
2006-10-18 10:04 ` Johannes Schindelin
2006-10-18 15:53 ` Linus Torvalds
2006-10-19 6:31 ` Daniel Barkalow
2006-10-18 9:38 ` Johannes Schindelin
2006-10-20 21:11 ` Uwe Zeisberger [this message]
2006-10-21 0:06 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061020211121.GB3024@cepheus.pub \
--to=zeisberg@informatik.uni-freiburg.de \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).