threads / discuss / 2122

Re: cg-merge should use git-merge

Subject: Re: cg-merge should use git-merge

## tl;dr

4 messages between Oct 17, 2005 and Oct 20, 2005.

replies: 3people: 2as markdown or json

Junio C Hamano· Oct 17, 2005, 08:31 UTC · lore

Martin Langhoff <martin.langhoff@gmail.com> writes:

> - Junio, would you tolerate a flag for git-merge that says "don't
> autocommit even on cleanly merged"?

I'd *welcome* not just tolerate.

Currently both git-am and git-applypatch call git-merge-resolve directly, but they should really be calling git-merge with user supplied strategy with '-s' parameter. By bypassing git-merge, they happen to get the "do not commit when you fall back on 3-way merge" semantics, but that is just by accident.

I have a plan to rewrite git-cherry-pick using git-format-patch piped into git-am (I have not scripted it, but that is the primary way I do cherry-picks these days), and being able to customize what happens after merge by git-merge would probably be useful there as well.

Junio C Hamano· Oct 17, 2005, 09:26 UTC · lore

Martin Langhoff <martin.langhoff@gmail.com> writes:

> Something like a manual merge that I could force to happen on command
>
>    git-doarbitrarymergeontree -r fromtree:totree  [ victimtree ]
>

That essentially is a simple one-liner:

     git-read-tree -m -u fromtree HEAD totree

which is more or less what git-cherry-pick and git-revert do, except fromtree always is totree^ in git-cherry-pick.

Martin Langhoff· Oct 19, 2005, 11:21 UTC · lore

Fwd: cg-merge should use git-merge

Resending a post that never made it to the list due to a bug at my end, and I think warrants some more discussion. Unfortunately, I'm bug-fixing at the moment, so implementing this has taken a backseat.

---------- Forwarded message ----------
From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Oct 17, 2005 12:44 PM
Subject: cg-merge should use git-merge
To: Petr Baudis <pasky@ucw.cz>, Git Mailing List <git@vger.kernel.org>

Petr,

After using git-merge a few times by hand to test-drive the new merge drivers, I'm sold on the idea, and I 'd like to have cg-merge use git-merge directly. I'll try and find the time one of these evenings to outline something, but I guess it's pretty core to Cogito, so I'm after some direction from you ;)

martin

Martin Langhoff· Oct 20, 2005, 07:04 UTC · re: Martin Langhoff · lore

On 10/20/05, Martin Langhoff <martin.langhoff@gmail.com> wrote:

> After using git-merge a few times by hand to test-drive the new merge
> drivers, I'm sold on the idea, and I 'd like to have cg-merge use
> git-merge directly.

I started drafting a 5-minute proof-of-concept, and then it struck me: cg users aren't aware of the index. This is really important when you are merging and have to resolve a conflict over a dirty tree. git users know that the "clean" part of the merge is in the index, and they have to resolve a couple of files in their checkout, and update the index for those only before calling git-write-tree & git-commit-tree.

Cogito users don't know about this magic at all, which is a bit of a problem. I can refuse to run cg-merge on a dirty tree to make things simpler, but that's cheating ;-)

tagging "for later"...

cheers,

martin