From: Petr Baudis <pasky@suse.cz>
To: "Martin Langhoff \(CatalystIT\)" <martin@catalyst.net.nz>
Cc: Dmitry Torokhov <dtor_core@ameritech.net>, git@vger.kernel.org
Subject: Re: LCA2006 Git/Cogito tutorial
Date: Fri, 21 Oct 2005 11:15:51 +0200 [thread overview]
Message-ID: <20051021091551.GE30889@pasky.or.cz> (raw)
In-Reply-To: <4358597A.6000306@catalyst.net.nz>
Dear diary, on Fri, Oct 21, 2005 at 04:59:06AM CEST, I got a letter
where "Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> told me that...
> Almost. No, truly, I'm very impressed with git-merge.sh, which first
> does the simple git-read-tree -m, and it can then try several merger
> scripts to resolve the index. The "smartest" merge resolver we have
> follows renames, but we could have language-specific and
> project-specific resolvers, for instance.
Yes, following renames is nice. But as long as it is three-way, it
suffers of inherent and rather nasty problems. Well, I'm watching the
weave merge effort and plan to give it a try to port it to GIT when I
have some time.
> If you combine the coolness of git-merge.sh with the fact that cg-merge
> right now is buggy[*]... I'm starting to rely on doing cg-fetch and
> running git-merge.sh by hand.
>
> * I just merged your latest fixes, knowing that they'd conflict on
> cg-fetch, but the merge didn't say a thing a bout cg-fetch, and only
> complained like this:
>
> MERGE ERROR: : Not handling case -> ->
>
> But there were no conflicts at all in the tree! It seems to be that it's
> dropping the upstream changes it doesn't like.
There was a bug in argument parsing of cg-Xmergefile, already fixed now.
Well, it's true that cg-Xmergefile still does not handle all merge
cases, but it certainly will not be silent about it, at least. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
next prev parent reply other threads:[~2005-10-21 9:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-17 0:48 LCA2006 Git/Cogito tutorial Martin Langhoff (CatalystIT)
2005-10-21 0:51 ` Petr Baudis
2005-10-21 2:37 ` Dmitry Torokhov
2005-10-21 2:59 ` Martin Langhoff (CatalystIT)
2005-10-21 9:15 ` Petr Baudis [this message]
2005-10-23 15:35 ` Horst von Brand
2005-10-23 22:39 ` Petr Baudis
2005-10-24 8:32 ` Fredrik Kuivinen
2005-10-23 15:33 ` Horst von Brand
2005-10-23 22:40 ` Petr Baudis
2005-10-24 0:22 ` Horst von Brand
2005-10-24 6:25 ` Martin Langhoff
2005-10-24 0:58 ` Junio C Hamano
2005-10-24 1:35 ` Linus Torvalds
2005-10-24 1:48 ` Junio C Hamano
2005-10-24 3:32 ` Linus Torvalds
2005-10-24 7:54 ` Petr Baudis
2005-10-24 9:44 ` Junio C Hamano
2005-10-24 15:04 ` Linus Torvalds
2005-10-21 3:02 ` Martin Langhoff (CatalystIT)
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=20051021091551.GE30889@pasky.or.cz \
--to=pasky@suse.cz \
--cc=dtor_core@ameritech.net \
--cc=git@vger.kernel.org \
--cc=martin@catalyst.net.nz \
/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).