{"thread":{"id":"3096","subject":"\"tla missing -s\" equivalent with git/cogito","startedAt":"2006-01-18T14:53:26Z","lastAt":"2006-01-18T20:14:24Z","messageCount":10,"participants":["Belmar-Letelier","Andreas Ericsson","Junio C Hamano","Martin Langhoff","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"14818","messageId":"43CE5666.90502@itaapy.com","threadId":"3096","inReplyTo":null,"subject":"\"tla missing -s\" equivalent with git/cogito","fromName":"Belmar-Letelier","fromEmail":"luis@itaapy.com","sentAt":"2006-01-18T14:53:26Z","receivedAt":"2006-01-18T14:53:26Z","isPatch":false,"sender":{"key":"luis@itaapy.com","avatar":null},"body":"Hello,\n\nCould someone say me how we do in cogito or git the\n\narch-tla equivalent of\n\n$ cd project--luis--0.1\n$ tla missing -sD paul@mail.com--public/project--paul--0.1\n\nso I get the information like what are the interesting patch to get\n\nand then I take all of them with\n\n$ tla star-merge -t paul@mail.com--public/project--paul--0.1\n\nor I cherry pick only one of them (here patch-6) with\n\n$ tla replay  somefriend@mail.com--public/project--branchA--0.1--patch-6\n\ntks\n\n\n-- \nLuis\n"},{"id":"14827","messageId":"43CE75F0.4060009@op5.se","threadId":"3096","inReplyTo":"43CE5666.90502@itaapy.com","subject":"Re: \"tla missing -s\" equivalent with git/cogito","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-01-18T17:08:00Z","receivedAt":"2006-01-18T17:08:00Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Belmar-Letelier wrote:\n> Hello,\n> \n> Could someone say me how we do in cogito or git the\n> \n> arch-tla equivalent of\n> \n> $ cd project--luis--0.1\n> $ tla missing -sD paul@mail.com--public/project--paul--0.1\n> \n> so I get the information like what are the interesting patch to get\n> \n> and then I take all of them with\n> \n> $ tla star-merge -t paul@mail.com--public/project--paul--0.1\n> \n> or I cherry pick only one of them (here patch-6) with\n> \n> $ tla replay  somefriend@mail.com--public/project--branchA--0.1--patch-6\n> \n\nNot that I'm even half aware of how arch does this, but if the two repos \nare cloned from the same one (which they seem to be), you could just do\n\n\t$ git checkout -b paul\n\t$ git pull <path-to-pauls-repo> <branch-from-pauls-repo>\n\nThe \"pull\" above will do the merging nessecary. You can merge several \nbranches at once if you like (known as \"doing an octopus\" in gittish. I \nimagine that's a star-merge in arch).\n\nThen, if you want to cherry-pick commits from Paul's repo to your \nmaster-branch, you do\n\n\t$ git checkout master\n\t$ git cherry-pick -r paul~3\n\nto replay the commit 3 steps below the tip of Paul's latest commit in \nthe branch you just pulled from.\n\nIf you want to import all of them into your own master branch you can do\n\n\t$ git checkout master\n\t$ git pull . paul\n\n\nYou can also do\n\n\t$ cd pauls-repo\n\t$ git format-patch --mbox -k HEAD~10 -o /your/repo\n\t$ cd /your/repo\n\t$ git am -k 00*.txt\n\nbut that has the feel of doing things the wrong way around (exporting \nfrom a repo to import to another should be done by a fetch or, if you \nwant to merge them into whatever branch you're currently on, a pull).\n\n\nTwo things worth noting:\n* git repositories are damn near indestructible, so long as you don't \nrun \"git prune\" while mucking around doing very strange things or suffer \nhardware failure. Don't be afraid to experiment.\n\n* gitk is your friend for finding out where you are in the repo and what \nactually happens when you merge, reset, revert, rebase, commit, pull, \nfetch, branch, tag or does something else entirely. Use it. You'll be \nglad you did.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"14831","messageId":"7vlkxdwhs6.fsf@assigned-by-dhcp.cox.net","threadId":"3096","inReplyTo":"43CE75F0.4060009@op5.se","subject":"Re: \"tla missing -s\" equivalent with git/cogito","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-18T17:46:33Z","receivedAt":"2006-01-18T17:46:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> The \"pull\" above will do the merging nessecary. You can merge several\n> branches at once if you like (known as \"doing an octopus\" in\n> gittish. I imagine that's a star-merge in arch).\n\nArch star-merge is not an octopus.  They have different \"merge\nstrategy\" just like we have more than one.  No, I do not\nremember the details of how they do it.\n"},{"id":"14833","messageId":"46a038f90601180956r69ba5dffl2106f697a6be4750@mail.gmail.com","threadId":"3096","inReplyTo":"43CE5666.90502@itaapy.com","subject":"Re: \"tla missing -s\" equivalent with git/cogito","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-01-18T17:56:38Z","receivedAt":"2006-01-18T17:56:38Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Andreas' response is good is you're into pure git. Let me add some\ncogito tricks ;-)\n\nOn 1/19/06, Belmar-Letelier <luis@itaapy.com> wrote:\n> arch-tla equivalent of\n>\n> $ cd project--luis--0.1\n> $ tla missing -sD paul@mail.com--public/project--paul--0.1\n\n $ cd project-luis\n # only if have to do cg-branch-add the first time!\n $ cg-branch-add paul http://server/git/project.git\n $ cg-fetch paul\n # show what paul has that we don't\n $ cg-log -r master:paul\n $ cg-diff -r master:paul\n # show what we have that paul doesn't\n $ cg-log -r paul:master\n $ cg-diff -r master:paul\n\nYou can also do\n\n $ cg-diff -r master:paul\n\n> so I get the information like what are the interesting patch to get\n>\n> and then I take all of them with\n>\n> $ tla star-merge -t paul@mail.com--public/project--paul--0.1\n\n # if you've done cg-fetch paul and reviewed it what you're about to\nmerge, just do\n cg-merge paul\n\n # otherwise, for a shortcut of cg-fetch <branch> && cg-merge <branch> do\n $ cg-update paul\n\n> or I cherry pick only one of them (here patch-6) with\n>\n> $ tla replay  somefriend@mail.com--public/project--branchA--0.1--patch-6\n\n  # export the patches paul has that we don't\n  $ mkdir .patchesfrompaul\n  $ git-format-patch --mbox --signoff -o .patchesfrompaul master paul\n  # review the contents of .patchesfrompaul and decide what patches you want\n  $ git-am -3 .patchesfrompaul/0006-fix-frob-invocation.txt\n\nNote that git does not track patch application _explicitly_ like Arch\ndoes, it tracks them only indirectly. Merges (tla star-merge type of\nmerges) are recorded explicitly. This work surprisingly well. If you\ndo a cg-update, cg-merge or git-merge, git will keep a good record of\nwhat points of the history have been merged.\n\nWhen you cherry pick patches, if the patch applies cleanly, the next\ntime you do a merge from that branch it will be skipped automagically.\nIf the patch needs serious editing, there's a good chance that git\nwill try to apply it again.\n\ncheers.\n\n\nmartin\n"},{"id":"14835","messageId":"46a038f90601181006u40a1f8e1n47c27651a4cab3d@mail.gmail.com","threadId":"3096","inReplyTo":"7vlkxdwhs6.fsf@assigned-by-dhcp.cox.net","subject":"Re: \"tla missing -s\" equivalent with git/cogito","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-01-18T18:06:07Z","receivedAt":"2006-01-18T18:06:07Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/19/06, Junio C Hamano <junkio@cox.net> wrote:\n> Arch star-merge is not an octopus.  They have different \"merge\n> strategy\" just like we have more than one.  No, I do not\n> remember the details of how they do it.\n\nIn Arch, star-merge is roughly equivalent to git-merge. When I was an\nArch user, I could go out and take a walk under the stars while it\ntried to work its magic on my 10K file tree -- so the name was quite\nfitting ;-)\n\nThe main difference with git is that it has explicit rename tracking\nand explicit \"patches already applied\" tracking. We detect those\nthings at merge time, and in my projects it has so far worked better\nthan tla's explicit tracking of things -- but only when I merge with\ngit-merge. One of these days I'll convince Pasky to use git-merge for\ncg-merge's internals.\n\ncheers,\n\n\nmartin\n"},{"id":"14842","messageId":"20060118185542.GT28365@pasky.or.cz","threadId":"3096","inReplyTo":"46a038f90601180956r69ba5dffl2106f697a6be4750@mail.gmail.com","subject":"Re: \"tla missing -s\" equivalent with git/cogito","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-01-18T18:55:42Z","receivedAt":"2006-01-18T18:55:42Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Jan 18, 2006 at 06:56:38PM CET, I got a letter\nwhere Martin Langhoff <martin.langhoff@gmail.com> said that...\n> Andreas' response is good is you're into pure git. Let me add some\n> cogito tricks ;-)\n> \n> On 1/19/06, Belmar-Letelier <luis@itaapy.com> wrote:\n> > arch-tla equivalent of\n> >\n> > $ cd project--luis--0.1\n> > $ tla missing -sD paul@mail.com--public/project--paul--0.1\n> \n>  $ cd project-luis\n>  # only if have to do cg-branch-add the first time!\n>  $ cg-branch-add paul http://server/git/project.git\n>  $ cg-fetch paul\n>  # show what paul has that we don't\n>  $ cg-log -r master:paul\n>  $ cg-diff -r master:paul\n\nI usually do this as\n\n\t$ cg-log -m -r paul\n\nwhich is shorter (and in some situations more accurately describes which\ncommits are actually going to get merged).\n\nBut I believe that Belmar-Letelier might be happier with git-cherry,\nsince he wants to do cherrypicking (and wrapping that in cg-log might\nnot be bad idea).\n\n> > or I cherry pick only one of them (here patch-6) with\n> >\n> > $ tla replay  somefriend@mail.com--public/project--branchA--0.1--patch-6\n> \n>   # export the patches paul has that we don't\n>   $ mkdir .patchesfrompaul\n>   $ git-format-patch --mbox --signoff -o .patchesfrompaul master paul\n>   # review the contents of .patchesfrompaul and decide what patches you want\n>   $ git-am -3 .patchesfrompaul/0006-fix-frob-invocation.txt\n\nIf you just want to pick one commit, it shouldn't be more difficult than\n\n\t$ cg-diff -p -r commitid | cg-patch\n\t$ cg-commit -c commitid\n\nbut I was actually thinking about wrapping this up to something like\ncg-cherrypick or cg-pick. Perhaps I will just overload cg-patch, though\n- I want to add support for autocommitting the patches there anyway.\n\n> When you cherry pick patches, if the patch applies cleanly, the next\n> time you do a merge from that branch it will be skipped automagically.\n> If the patch needs serious editing, there's a good chance that git\n> will try to apply it again.\n\nNo, it will not be skipped automagically - GIT really does not properly\nsupport merging  of branch you've cherrypicked before. It might work,\nbut that's just luck - very similar to the luck you might have when\nre-merging branches in CVS using the original merge base.\n\nImagine having branch with two patches 1 and 2. There is a file X:\n\n\ta\n\nPpatch1:\n\n\t-a\n\t+b\n\t+c\n\nPatch2:\n\n\t-b\n\t+a\n\tc\n\nResulting file:\n\n\ta\n\tc\n\nNow, you've cherrypicked patch1, so your file is:\n\n\tb\n\tc\n\nNow you want to merge the branch as a whole. Cherrypicking-aware VCS\nwould just merge the patch2, but you are taking the whole diff:\n\n\ta\n\t+c\n\nAnd you get a conflict instead of b\\nc.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe.  -- Douglas Adams\n"},{"id":"14844","messageId":"46a038f90601181107h57e6fb73peb199689349aec41@mail.gmail.com","threadId":"3096","inReplyTo":"20060118185542.GT28365@pasky.or.cz","subject":"Re: \"tla missing -s\" equivalent with git/cogito","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-01-18T19:07:27Z","receivedAt":"2006-01-18T19:07:27Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/19/06, Petr Baudis <pasky@suse.cz> wrote:\n> Now you want to merge the branch as a whole. Cherrypicking-aware VCS\n> would just merge the patch2, but you are taking the whole diff:\n...\n> And you get a conflict instead of b\\nc.\n\nWhile I haven't tested your particular example, it looks to me like\ngit-cherry would identify it correctly. So far my experience has been\nthat git-cherry's strategy detects my cherry-picked patches pretty\nwell.\n\nWhy would it not work in your example? Patch 1 has clearly been\napplied in both branches, and git-cherry would normally detect that\nalright.\n\nbtw, when is cg-merge switching to use git-merge? :-p\n\n\n\nmartin\n"},{"id":"14846","messageId":"20060118192638.GU28365@pasky.or.cz","threadId":"3096","inReplyTo":"46a038f90601181107h57e6fb73peb199689349aec41@mail.gmail.com","subject":"Re: \"tla missing -s\" equivalent with git/cogito","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-01-18T19:26:38Z","receivedAt":"2006-01-18T19:26:38Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Jan 18, 2006 at 08:07:27PM CET, I got a letter\nwhere Martin Langhoff <martin.langhoff@gmail.com> said that...\n> On 1/19/06, Petr Baudis <pasky@suse.cz> wrote:\n> > Now you want to merge the branch as a whole. Cherrypicking-aware VCS\n> > would just merge the patch2, but you are taking the whole diff:\n> ...\n> > And you get a conflict instead of b\\nc.\n> \n> While I haven't tested your particular example, it looks to me like\n> git-cherry would identify it correctly. So far my experience has been\n> that git-cherry's strategy detects my cherry-picked patches pretty\n> well.\n> \n> Why would it not work in your example? Patch 1 has clearly been\n> applied in both branches, and git-cherry would normally detect that\n> alright.\n\n  It probably would. So? We are talking about git-merge and cg-merge\nhere. Now, it might be interesting to have a cherry-aware merge\nstrategy, but I suspect that the conflicts handling there would be quite\nnon-trivial.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe.  -- Douglas Adams\n"},{"id":"14848","messageId":"20060118193201.GV28365@pasky.or.cz","threadId":"3096","inReplyTo":"46a038f90601181006u40a1f8e1n47c27651a4cab3d@mail.gmail.com","subject":"Re: Cogito wishlist: ability to set merge strategy","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-01-18T19:32:01Z","receivedAt":"2006-01-18T19:32:01Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Jan 17, 2006 at 04:29:49AM CET, I got a letter\nwhere \"H. Peter Anvin\" <hpa@zytor.com> said that...\n> It would be nice if Cogito would let one override the default merge \n> strategy, i.e. to use the recursive merge strategy.  I've had some \n> moderate luck with using recursive merge for the klibc trees recently.\n\nDear diary, on Wed, Jan 18, 2006 at 07:06:07PM CET, I got a letter\nwhere Martin Langhoff <martin.langhoff@gmail.com> said that...\n> One of these days I'll convince Pasky to use git-merge for\n> cg-merge's internals.\n\nFor the record, I acknowledge that the merge strategies are useful and I\nplan to make cg-merge use them, but I'm unable to tell when that will\nhappen. I would still like to keep the current Cogito merging the\ndefault merge strategy at least for a while until the dust settles down,\nthough. From the Git merge strategies, I guess only recursive is\nuseful for Cogito...\n\nPatches welcome.  ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe.  -- Douglas Adams\n"},{"id":"14851","messageId":"46a038f90601181214m54318d89we505c130e4f397e2@mail.gmail.com","threadId":"3096","inReplyTo":"20060118193201.GV28365@pasky.or.cz","subject":"Re: Cogito wishlist: ability to set merge strategy","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-01-18T20:14:24Z","receivedAt":"2006-01-18T20:14:24Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/19/06, Petr Baudis <pasky@suse.cz> wrote:\n> though. From the Git merge strategies, I guess only recursive is\n> useful for Cogito...\n\nI haven't had time to figure out where the problem is, I do have some\ncases where git-merge does the right thing, and cg-merge gets it\nwrong. And without renames.\n\nAn example from yesterday:\nhttp://locke.catalyst.net.nz/gitweb?p=moodle.git;a=commit;h=b69d60a5141dfe22a073dd9931e6c8ff5dded0b9\n\n(the repo is accessble via http://locke.catalyst.net.nz/git/moodle.org\nif anyone is interested)\n\n> Patches welcome.  ;-)\n\nI know I promised patches in that direction, but I haven't had the\ntime to look into it. Sorry! (and, as a user, I just cheat and fall\nback to git-merge)\n\ncheers,\n\n\nmartin\n"}]}