{"thread":{"id":"2122","subject":"Re: cg-merge should use git-merge","startedAt":"2005-10-17T08:31:36Z","lastAt":"2005-10-20T07:04:52Z","messageCount":4,"participants":["Junio C Hamano","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10173","messageId":"7vzmp81r4n.fsf@assigned-by-dhcp.cox.net","threadId":"2122","inReplyTo":"46a038f90510161744m7e95303eu8a9942363ffc58a6@mail.gmail.com","subject":"Re: cg-merge should use git-merge","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-17T08:31:36Z","receivedAt":"2005-10-17T08:31:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff <martin.langhoff@gmail.com> writes:\n\n> - Junio, would you tolerate a flag for git-merge that says \"don't\n> autocommit even on cleanly merged\"?\n\nI'd *welcome* not just tolerate.\n\nCurrently both git-am and git-applypatch call git-merge-resolve\ndirectly, but they should really be calling git-merge with user\nsupplied strategy with '-s' parameter.  By bypassing git-merge,\nthey happen to get the \"do not commit when you fall back on\n3-way merge\" semantics, but that is just by accident.\n\nI have a plan to rewrite git-cherry-pick using git-format-patch\npiped into git-am (I have not scripted it, but that is the\nprimary way I do cherry-picks these days), and being able to\ncustomize what happens after merge by git-merge would probably\nbe useful there as well.\n"},{"id":"10175","messageId":"7vach81olt.fsf@assigned-by-dhcp.cox.net","threadId":"2122","inReplyTo":"46a038f90510170203ndee2b2bi913b62014614f68e@mail.gmail.com","subject":"Re: cg-merge should use git-merge","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-17T09:26:06Z","receivedAt":"2005-10-17T09:26:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff <martin.langhoff@gmail.com> writes:\n\n> Something like a manual merge that I could force to happen on command\n>\n>    git-doarbitrarymergeontree -r fromtree:totree  [ victimtree ]\n>\n\nThat essentially is a simple one-liner:\n\n     git-read-tree -m -u fromtree HEAD totree\n\nwhich is more or less what git-cherry-pick and git-revert do,\nexcept fromtree always is totree^ in git-cherry-pick.\n"},{"id":"10277","messageId":"46a038f90510190421l50b2c12k495db23b62015782@mail.gmail.com","threadId":"2122","inReplyTo":"46a038f90510161644l35119401rdc05c081506ae715@mail.gmail.com","subject":"Fwd: cg-merge should use git-merge","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-19T11:21:47Z","receivedAt":"2005-10-19T11:21:47Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Resending a post that never made it to the list due to a bug at my\nend, and I think warrants some more discussion. Unfortunately, I'm\nbug-fixing at the moment, so implementing this has taken a backseat.\n\n---------- Forwarded message ----------\nFrom: Martin Langhoff <martin.langhoff@gmail.com>\nDate: Oct 17, 2005 12:44 PM\nSubject: cg-merge should use git-merge\nTo: Petr Baudis <pasky@ucw.cz>, Git Mailing List <git@vger.kernel.org>\n\n\nPetr,\n\nAfter using git-merge a few times by hand to test-drive the new merge\ndrivers, I'm sold on the idea, and I 'd like to have cg-merge use\ngit-merge directly. I'll try and find the time one of these evenings\nto outline something, but I guess it's pretty core to Cogito, so I'm\nafter some direction from you ;)\n\n\n\nmartin\n"},{"id":"10344","messageId":"46a038f90510200004l67e2d19kf8e9a4c6190f44f@mail.gmail.com","threadId":"2122","inReplyTo":"46a038f90510190421l50b2c12k495db23b62015782@mail.gmail.com","subject":"Re: cg-merge should use git-merge","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-20T07:04:52Z","receivedAt":"2005-10-20T07:04:52Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/20/05, Martin Langhoff <martin.langhoff@gmail.com> wrote:\n> After using git-merge a few times by hand to test-drive the new merge\n> drivers, I'm sold on the idea, and I 'd like to have cg-merge use\n> git-merge directly.\n\nI started drafting a 5-minute proof-of-concept, and then it struck me:\ncg users aren't aware of the index. This is really important when you\nare merging and have to resolve a conflict over a dirty tree. git\nusers know that the \"clean\" part of the merge is in the index, and\nthey have to resolve a couple of files in their checkout, and update\nthe index for those only before calling git-write-tree &\ngit-commit-tree.\n\nCogito users don't know about this magic at all, which is a bit of a\nproblem. I can refuse to run cg-merge on a dirty tree to make things\nsimpler, but that's cheating ;-)\n\ntagging \"for later\"...\n\ncheers,\n\n\nmartin\n"}]}