{"thread":{"id":"11999","subject":"git/hg discussion from the memcached mailing list","startedAt":"2008-02-10T01:43:15Z","lastAt":"2008-02-10T22:05:48Z","messageCount":2,"participants":["Steven Grimm","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"68145","messageId":"196C7ED3-67BC-4BF9-8E5B-4E2187D8A93B@midwinter.com","threadId":"11999","inReplyTo":"D6147D3B-2E67-4D33-8EEC-BFCD641A6D52@spy.net","subject":"git/hg discussion from the memcached mailing list","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2008-02-10T01:43:15Z","receivedAt":"2008-02-10T01:43:15Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"The folks managing the memcached project are looking at switching from  \nsvn, and there's a discussion going on about whether to switch to git  \nor hg. One of the prominent list members is an hg fan, but he's open  \nto giving git a try. Here's his latest message from that thread; the  \nstart of the thread is at\n\nhttp://lists.danga.com/pipermail/memcached/2008-February/006335.html\n\nI'd say hg is winning the ease-of-use side of things at the moment, by  \nvirtue of its commands doing what people want by default rather than  \nrequiring additional arguments. Examples of that in the quoted message.\n\nUnfortunately I'm in semi-crunch mode at work right now and don't have  \ntime to really dive into this discussion, but maybe someone else would  \nbe interested in doing so. If nothing else the thread points out some  \nthings that could be discussed the next time there's talk about git's  \nuser interface.\n\n-Steve\n\n\nBegin forwarded message:\n\n> From: Dustin Sallings <dustin@spy.net>\n> Date: February 9, 2008 5:30:48 PM PST\n> To: dormando <dormando@rydia.net>\n> Cc: memcached list <memcached@lists.danga.com>\n> Subject: Re: Upcoming memcached releases + rambling.\n>\n>\n> On Feb 9, 2008, at 0:28, dormando wrote:\n>\n>> incoming/outgoing:\n>>\n>> If I _think_ I understand these right, you can actually sometimes git\n>> diff with the second repo as an argument. That'll show the  \n>> differences\n>> since the target repo/branch (git diff . /path/to/other/repo#branch),\n>> which will be incoming or outgoing.\n>\n> \tHmm...  Trying that, but it doesn't take ``origin'' nor the URL of  \n> origin as an argument.  Not quite what I'm looking for anyway...\n>\n>> That'll show the raw changes... for showing the difference in  \n>> changeset,\n>> you can do a: git log --since HEAD origin\n>> ... if origin were the remote repo. If you don't have the latest\n>> changes, fetch more, rebase your repo on top of that, then git log\n>> --since will show you what you have to upload.\n>\n> \tMy log (1.5.3.7) doesn't have --since (fatal: unrecognized  \n> argument:  --since)\n>\n>> Otherwise you can use git fetch to \"pull\" the remote changes into a\n>> branch but not apply anywhere, then use git log with relative  \n>> commit ids\n>> to show the changesets (with -p to show the full changes!)\n>\n> \tIs that the old..new stuff it printed when I fetched?  I guess  \n> that's close enough to what I want to accomplish, but it only seems  \n> to work once I've got the changes.\n>\n>> Unless I'm getting my wires crossed and this is a patch management\n>> thinger, in that case it's 'git format-patch' and 'git am' (although\n>> there's an alternative to am).\n>\n> \tOK, I don't think this is doing what what I want.  I did a ``git  \n> format-patch origin..'' and it didn't do anything.  I rebased my  \n> changes and did it and it included a bunch of changes I didn't  \n> make.  I did a ``git checkout HEAD'' to try to go back to sanity and  \n> format-patch now includes just the things I changed.\n>\n> \tI think ``git log origin..'' does what I want here (except in the  \n> case of git svn in which case origin is called something else and  \n> doesn't show up under git remote).\n>\n>> export:\n>>\n>> Appears to be git log --pretty=[format] [-p] ?\n>\n> \tI think it's probably ``git log --pretty=raw -n 1 -p [id]''\n>\n> \tI haven't tried git-am to see if it would apply this properly.  git- \n> apply does not (it modifies the tree, I want the change committed by  \n> the original author with the original date, etc...).\n>\n>> bundle:\n>>\n>> git bundle, same feature. push/pull accept bundles too, it seems.\n>\n> \tRight.  The equiv seems to be:\n>\n> \tgit bundle create /some/file origin..\n>\n>> serve:\n>>\n>> You got me here. I've been doing the \"scp a bare repo up to my  \n>> webhost,\n>> run a script to prep it for http pull's\" thing. Usually takes a few\n>> minutes if I don't forget what to do, and the basic tutorials show  \n>> how\n>> to do this.\n>\n> \tYou can do the above with mercurial, but they don't advertise it  \n> much because it's slow on the consumer side.  You don't need a  \n> script or anything to prep it, though.  Just dump your working tree  \n> on a web server.\n>\n>> No built in webbrick a-like though. I guess that's twistd?\n>> Or something? Dunno, that's pretty swanky, but my laptop doesn't  \n>> usually\n>> have direct internet access so I upload it to my webhost anyway.\n>\n> \tNo, python has a built-in web server.  It's just using that.\n>\n>> Mercurial does appear to work better with pushing things around,  \n>> while\n>> git is primarily pull oriented. I don't mind the loss there, pushing\n>> between distributed repos is kinda crazy. Or maybe I just haven't  \n>> used\n>> hg enough.\n>\n> \tpull is definitely better than push in general.  Except in the case  \n> I ran into yesterday where the only option I had other than pushing  \n> was emailing a bundle.  :)\n>\n>> I've spread git within a company of 15+ developers (now way more? I\n>> hope) to replace SVN. Slow adoption at first but they love it, and  \n>> were\n>> having very severe performance problems.\n>\n> \tThat's good.  I'm sure I just haven't learned it enough yet.  You  \n> may provide me with an opportunity to do so.  :)\n>\n>> I think a bunch of the ruby folk use git? We should have someone  \n>> who can\n>> say a word or two about it?\n>\n> \tAll the ruby stuff I can find uses svn, it's like...built into the  \n> tools.  They may be using git-svn, but that's really a different  \n> tool from what I can tell.  For example, cloning a git-svn clone  \n> doesn't give you a git-svn clone.\n>\n>>>   Should memcached choose git, it may be as simple as putting up a\n>>> page that says, ``this is how you clone, this is how you work,  \n>>> this is\n>>> how you submit your changes back.''\n>>>\n>>\n>> I've been stuck in the stone-age with git apparently! Every time I go\n>> read the tutorials I find four other commands I don't need to run\n>> anymore. It looks like with 1.4 or 1.5+ all you need to do is  \n>> clone, do\n>> some git remote's, and 'git pull' until you're bored. Then rebase  \n>> your\n>> branch on top of origin, and git-format-patch a patch series. Or  \n>> shove\n>> your repo up with http accessability and tell someone to pull.\n>>\n>> In which case I'd add a remote for their repo and pull into a branch.\n>>\n>> Anyway, I'm totally glad you asked because it finally gave me  \n>> something\n>> to look up. Brian once asked about bundle, but I had yet to find a\n>> difference :)\n>\n>\n> \tWell here's a summary of the differences in commands so far.  Let's  \n> assume I've done a clone of the hypothetical git repo and hg repo.   \n> The following commands would be equivalent based on what I found up  \n> here:\n>\n> Look for incoming changes:\n>\n> \thg in\n> \tgit fetch && git log [copy and paste in the stuff from the old..new  \n> line]\n>\n> Look for outgoing changes:\n>\n> \thg out\n> \tgit fetch && git log origin..\n>\n> Export a single changeset to be moved elsewhere:\n>\n> \thg export [change]\n> \tgit log --pretty=raw -n 1 -p [change]\n>\n> Import an exported changeset:\n>\n> \thg import /some/file\n> \tgit ??? /some/file\n>\n> Send changes as individual email patches:\n>\n> \t# note: hg requires patchbomb to be enabled in your .hgrc for this\n>\n> \thg email -o\n> \tgit format-patch origin.. && ??email script?? [0-9]*.patch\n>\n> Send changes as a single portable patch series:\n>\n> \thg out -p\n> \tgit fetch origin && git log -p origin..\n>\n> Send changes as a single bundle:\n>\n> \thg bundle /some/file\n> \tgit bundle create /some/file origin..\n>\n> \t[then send /some/file as an attachment]\n>\n> Share changes via plain http:\n>\n> \t[hg]#  rsync -va tree/ server:public_html/tree/\n> \t[git]# rsync -va tree/ server:public_html/tree/ && ssh server \"?? \n> setup-tree??\"\n>\n> Share changes on a LAN party:\n>\n> \thg serve\n> \tgit daemon --base-path=$PWD --export-all\n>\n>\n> \tThis is actually good progress (although perhaps a bad forum).   \n> I've been wanting a git cheat sheet, and this is helping me get it  \n> together.\n>\n> \tOf course, when it comes to contributing, I think there will have  \n> to some published recommendations on how to contribute changes.\n>\n> -- \n> Dustin Sallings\n>\n>\n>\n"},{"id":"68279","messageId":"alpine.LFD.1.00.0802101332060.2896@woody.linux-foundation.org","threadId":"11999","inReplyTo":"196C7ED3-67BC-4BF9-8E5B-4E2187D8A93B@midwinter.com","subject":"Re: git/hg discussion from the memcached mailing list","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-02-10T22:05:48Z","receivedAt":"2008-02-10T22:05:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 9 Feb 2008, Steven Grimm wrote:\n> > \n> > > export:\n> > > \n> > > Appears to be git log --pretty=[format] [-p] ?\n> > \n> > \tI think it's probably ``git log --pretty=raw -n 1 -p [id]''\n\nNo, for a single commit, that would be \"git show\".\n\nThe format, of course, can then be anything, the default is the readable \nand often most useful one, but depending on circumstances people might use \nanything from \"--pretty=email\" to \"--pretty=raw\".\n\n> > \tWell here's a summary of the differences in commands so far.  Let's\n> > assume I've done a clone of the hypothetical git repo and hg repo.  The\n> > following commands would be equivalent based on what I found up here:\n> > \n> > Look for incoming changes:\n> > \n> > \thg in\n> > \tgit fetch && git log [copy and paste in the stuff from the old..new line]\n\nThat would be\n\n\tgit fetch && git log ..origin\n\nNo copy-paste required.\n\nAnd the git approach may look \"bigger\", but it's actually a hell of a lot \nmore flexible, because it now means that in addition to (or in place of) \nthat \"git log ..origin\", you can now use the graphical viewers (ie doing \n\"gitk ..origin\" or anything else), along with all the cherry-picking \nor rebasing action you want.\n\nIf you really want a \"git in\", you can trivially do so with a simple \nalias.\n\n> > Look for outgoing changes:\n> > \n> > \thg out\n> > \tgit fetch && git log origin..\n\nSame commentary, except more forceful. You can do a single \"git fetch\", \nand now you can use\n\n\tgitk origin..\n\tgitk ..origin\n\ndepending on whether you want to see the new thing *they* have, or the new \nthing *you* have, or both. In fact, you can do the \"symmetric difference\" \n(with three dots)\n\n\tgitk ...origin\n\nto see both visually at the same time (and since that's a symmetric \ndifference, it doesn't matter whether it's '...origin' or 'origin...')\n\nAnd again, more interestingly, all of this works *exactly*the*same* even \nif you track multiple branches from multiple different remotes, and \neverything works really naturally, ie you can say\n\n\tgitk one-developer...other-developer\n\nto see what the difference (symmetric) between two different upstream \nthings are.\n\nThe \"hg in/out\" thing is just a very weak special case, and a trivial \nalias if you really feel it is such a _common_ weak special case.\n\n> > Export a single changeset to be moved elsewhere:\n> > \n> > \thg export [change]\n> > \tgit log --pretty=raw -n 1 -p [change]\n\n\"git show\" again, but more commonly it would be \"git cherry-pick\" between \nbranches if what you actually want to  move one patch from one place to \nanother (which will do things like the proper three-way merging etc, it's \nnot just a \"move patch around\").\n\n> > Import an exported changeset:\n> > \n> > \thg import /some/file\n> > \tgit ??? /some/file\n\nGit is designed for not just doing a single one, so the normal one would \nbe\n\n\t\"git am [mbox]\"\n\nto apply a series of patches from one mailbox. You'd create one of those \nthings with \"git format-patch\" (which can either generate lots of \nindividual files, or one mbox to stdout).\n\n> > Send changes as individual email patches:\n> > \n> > \t# note: hg requires patchbomb to be enabled in your .hgrc for this\n> > \n> > \thg email -o\n> > \tgit format-patch origin.. && ??email script?? [0-9]*.patch\n\nThe email script would be \"git send-email\", although I personally would \nsuggest not telling people to mailbomb things as a pipeline like that.\n\nWhat I do personally is that \"git format-patch -o dir -n origin..\" is a \nseparate phase, which allows you to check things out, and perhaps add \ncommentary after the \"---\" line (things that show up in the email, but not \nin the commit message after it's applied), and then do the sending as a \ntotally separate phase when you've verified that what you're doing to send \nis ok.\n\n(In fact, I end up actually emailing things individually, so I don't even \nuse \"git send-email\" at all, but that's just because I live in my mail \nreader anyway).\n\n> > Send changes as a single portable patch series:\n> > \n> > \thg out -p\n> > \tgit fetch origin && git log -p origin..\n\nThis is another example of git just handling branches in a more general \nmanner. See above.  You can view the differences any which  way you like, \nwhether with \"git log\" or with \"git log -p\" or with graphical viewers or \nwhatever.\n\n> > Share changes via plain http:\n> > \n> > \t[hg]#  rsync -va tree/ server:public_html/tree/\n> > \t[git]# rsync -va tree/ server:public_html/tree/ && ssh server\n> > \"??setup-tree??\"\n\nOuch. Hell no. That's crazy talk. And I assume it's crazy talk even for \nhg. You'd use \"git push\" to export changes.\n\n\t\t\tLinus\n"}]}