{"thread":{"id":"1008","subject":"Updated git HOWTO for kernel hackers","startedAt":"2005-06-22T22:24:54Z","lastAt":"2005-07-11T08:56:58Z","messageCount":94,"participants":["Jeff Garzik","Dave Jones","Greg KH","Linus Torvalds","Daniel Barkalow","Adam Kropelin","Miles Bader","Petr Baudis","Anton Altaparmakov","Vojtech Pavlik","Martin Langhoff","Dave Airlie","Matt Mackall","Andrea Arcangeli","Matthias Urlichs","Theodore Ts'o","Paolo Ciarrocchi","Kevin Smith","Christopher Li","John W. Linville","Junio C Hamano","Joel Becker","Kyle Moffett","Pavel Machek","Benjamin LaHaise","Ed Tomlinson","Andrew Thompson","Sven Verdoolaege","Sean","Thomas Arendsen Hein","Amin Azez"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"5127","messageId":"42B9E536.60704@pobox.com","threadId":"1008","inReplyTo":null,"subject":"Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-22T22:24:54Z","receivedAt":"2005-06-22T22:24:54Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"\nThings in git-land are moving at lightning speed, and usability has \nimproved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11\n\n\n\n1) installing git\n\ngit requires bootstrapping, since you must have git installed in order \nto check out git.git (git repo), and linux-2.6.git (kernel repo). I \nhave put together a bootstrap tarball of today's git repository.\n\nDownload tarball from:\nhttp://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2\n\ntarball build-deps: zlib, libcurl, libcrypto (openssl)\n\ninstall tarball: unpack && make && sudo make prefix=/usr/local install\n\njgarzik helper scripts, not in official git distribution:\nhttp://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch\nhttp://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script\n\nAfter reading the rest of this document, come back and update your copy \nof git to the latest:\nrsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git\n\n\n2) download a linux kernel tree for the very first time\n\n$ mkdir -p linux-2.6/.git\n$ cd linux-2.6\n$ rsync -a --delete --verbose --stats --progress \\\nrsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \n\\ <- word-wrapped backslash; sigh\n .git/\n\n\n3) update local kernel tree to latest 2.6.x upstream (\"fast-forward merge\")\n\n$ cd linux-2.6\n$ git-pull-script \\\nrsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n\n\n4) check out files from the git repository into the working directory\n\n$ git checkout -f\n\n\n5) check in your own modifications (e.g. do some hacking, or apply a patch)\n\n# go to repo\n$ cd linux-2.6\n\n# make some modifications\n$ patch -sp1 < /tmp/my.patch\n$ diffstat -p1 < /tmp/my.patch\n\n# NOTE: add '--add' and/or '--remove' if files were added or removed\n$ git-update-cache \n\n# check in changes\n$ git commit\n\n\n6) List all changes in working dir, in diff format.\n\n$ git-diff-cache -p HEAD\n\n\n7) List all changesets (i.e. show each cset's description text) in local \nbranch of local tree, that are not present in remote tree.\n\n$ cd my-kernel-tree-2.6\n$ git-changes-script -L ../linux-2.6 | less\n\n\n8) List all changesets:\n\n$ git-whatchanged\n\n\n9) apply all patches in a Berkeley mbox-format file\n\nFirst, download and add to your PATH Linus's git tools:\nrsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git\n\n$ cd my-kernel-tree-2.6\n$ dotest /path/to/mbox # yes, Linus has no taste in naming scripts\n\n\n10) don't forget to download tags from time to time.\n\ngit-pull-script only downloads sha1-indexed object data, and the \nrequested remote head. This misses updates to the .git/refs/tags/ and \n.git/refs/heads directories. It is advisable to update your kernel .git \ndirectories periodically with a full rsync command, to make sure you got \neverything:\n\n$ cd linux-2.6\n$ rsync -a --delete --verbose --stats --progress \\\nrsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/\n\\ <- word-wrapped backslash; sigh\n .git/\n\n\n11) list all branches, such as those found in my netdev-2.6 or \nlibata-dev trees.\n\nDownload\nrsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git\n\tor\nrsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git\n\n\n$ cd netdev-2.6\n$ ls .git/refs/heads/\n\n{ these are the current netdev-2.6 branches }\n> 8139cp forcedeth master qeth smc91x we18\n> 8139too-iomap for-linus natsemi r8169 smc91x-eeprom wifi\n> airo hdlc ns83820 register-netdev starfire\n> atmel ieee80211 orinoco remove-drivers tlan\n> chelsio iff-running orinoco-hch sis900 veth\n> dm9000 janitor ppp skge viro\n\n\n12) make desired branch current in working directory\n\n$ git checkout -f $branch\n\n\n13) create a new branch, and make it current\n\n$ cp .git/refs/heads/master .git/refs/heads/my-new-branch-name\n$ git checkout -f my-new-branch-name\n\n\n14) examine which branch is current\n\n$ ls -l .git/HEAD\n\n\n15) undo all local modifications (same as checkout):\n\n$ git checkout -f\n\n\n16) obtain a diff between current branch, and master branch\n\nIn most trees WITH BRANCHES, .git/refs/heads/master contains the current \n'vanilla' upstream tree, for easy diffing and merging. (in trees \nwithout branches, 'master' simply contains your latest changes)\n\n$ git-diff-tree -p master HEAD\n\n\n"},{"id":"5128","messageId":"20050622224003.GA21298@redhat.com","threadId":"1008","inReplyTo":"42B9E536.60704@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Dave Jones","fromEmail":"davej@redhat.com","sentAt":"2005-06-22T22:40:03Z","receivedAt":"2005-06-22T22:40:03Z","isPatch":false,"sender":{"key":"davej@redhat.com","avatar":null},"body":"On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:\n > \n > Things in git-land are moving at lightning speed, and usability has \n > improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11\n > \n > \n > \n > 1) installing git\n > \n > git requires bootstrapping, since you must have git installed in order \n > to check out git.git (git repo), and linux-2.6.git (kernel repo). I \n > have put together a bootstrap tarball of today's git repository.\n > \n > Download tarball from:\n > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2\n\n\ndaily snapshots (refreshed once an hour) are available at:\nhttp://www.codemonkey.org.uk/projects/git-snapshots/git/\n\n\n > tarball build-deps: zlib, libcurl, libcrypto (openssl)\n > \n > install tarball: unpack && make && sudo make prefix=/usr/local install\n\nthe sudo thing isn't necessary. make install by itself installs it\nin ~/bin/ just fine.\n\n > After reading the rest of this document, come back and update your copy \n > of git to the latest:\n > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git\n\nSee above, which allows you to skip this step ;)\n\n\t\tDave\n\n"},{"id":"5129","messageId":"42B9EA67.1040407@pobox.com","threadId":"1008","inReplyTo":"20050622224003.GA21298@redhat.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-22T22:47:03Z","receivedAt":"2005-06-22T22:47:03Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Dave Jones wrote:\n> On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:\n> > \n> > Things in git-land are moving at lightning speed, and usability has \n> > improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11\n> > \n> > \n> > \n> > 1) installing git\n> > \n> > git requires bootstrapping, since you must have git installed in order \n> > to check out git.git (git repo), and linux-2.6.git (kernel repo). I \n> > have put together a bootstrap tarball of today's git repository.\n> > \n> > Download tarball from:\n> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2\n> \n> \n> daily snapshots (refreshed once an hour) are available at:\n> http://www.codemonkey.org.uk/projects/git-snapshots/git/\n> \n> \n> > tarball build-deps: zlib, libcurl, libcrypto (openssl)\n> > \n> > install tarball: unpack && make && sudo make prefix=/usr/local install\n> \n> the sudo thing isn't necessary. make install by itself installs it\n> in ~/bin/ just fine.\n\nClearly this does not work if installing in /usr/local, as I and others \ndo (and as the example shows).\n\n\n> > After reading the rest of this document, come back and update your copy \n> > of git to the latest:\n> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git\n> \n> See above, which allows you to skip this step ;)\n\nhuh? Nothing allows you to skip that step. Regardless of when you suck \nthe tarball, even from your snapshots, the users should not skip this step.\n\n\tJeff\n\n\n"},{"id":"5130","messageId":"20050622225255.GB21298@redhat.com","threadId":"1008","inReplyTo":"42B9EA67.1040407@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Dave Jones","fromEmail":"davej@redhat.com","sentAt":"2005-06-22T22:52:55Z","receivedAt":"2005-06-22T22:52:55Z","isPatch":false,"sender":{"key":"davej@redhat.com","avatar":null},"body":"On Wed, Jun 22, 2005 at 06:47:03PM -0400, Jeff Garzik wrote:\n\n > > > install tarball: unpack && make && sudo make prefix=/usr/local install\n > >\n > >the sudo thing isn't necessary. make install by itself installs it\n > >in ~/bin/ just fine.\n > \n > Clearly this does not work if installing in /usr/local, as I and others \n > do (and as the example shows).\n\nSure, it just seemed to imply that it doesn't work with a non-root install,\nwhich isn't true.\n\n > > > After reading the rest of this document, come back and update your copy \n > > > of git to the latest:\n > > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git\n > >\n > >See above, which allows you to skip this step ;)\n > \n > huh? Nothing allows you to skip that step. Regardless of when you suck \n > the tarball, even from your snapshots, the users should not skip this step.\n\nAt worse, users will have tools 59 minutes old. If a situation arises\nwhere git from an hour ago isn't new enough to pull from the repository,\nwe have bigger problems.\n\nYou seem to be proposing that everyone needs the shiniest newest things,\nwhich clearly isn't true, and suggesting so just complicates things\nfurther imo.\n\n\t\tDave\n\n"},{"id":"5131","messageId":"20050622230905.GA7873@kroah.com","threadId":"1008","inReplyTo":"42B9E536.60704@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2005-06-22T23:09:05Z","receivedAt":"2005-06-22T23:09:05Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:\n> 10) don't forget to download tags from time to time.\n> \n> git-pull-script only downloads sha1-indexed object data, and the \n> requested remote head. This misses updates to the .git/refs/tags/ and \n> .git/refs/heads directories. It is advisable to update your kernel .git \n> directories periodically with a full rsync command, to make sure you got \n> everything:\n> \n> $ cd linux-2.6\n> $ rsync -a --delete --verbose --stats --progress \\\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/\n> \\ <- word-wrapped backslash; sigh\n> .git/\n\nOk, this is annoying. Is there some reason why git doesn't pull the\ntags in properly when doing a merge? Chris and I just hit this when I\npulled his 2.6.12.1 tree and and was wondering where the tag went.\n\nthanks,\n\ngreg k-h\n"},{"id":"5132","messageId":"Pine.LNX.4.58.0506221603120.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"42B9E536.60704@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-22T23:16:00Z","receivedAt":"2005-06-22T23:16:00Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Jeff Garzik wrote:\n>\n> 2) download a linux kernel tree for the very first time\n> \n> $ mkdir -p linux-2.6/.git\n> $ cd linux-2.6\n> $ rsync -a --delete --verbose --stats --progress \\\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \n> \\ <- word-wrapped backslash; sigh\n> .git/\n\nGaah. I should do a \"git-clone-script\" or something that does this, and \nthen you could just do\n\n\tgit clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6\n\t\nAnybody?\n\n> # make some modifications\n> $ patch -sp1 < /tmp/my.patch\n> $ diffstat -p1 < /tmp/my.patch\n> \n> # NOTE: add '--add' and/or '--remove' if files were added or removed\n> $ git-update-cache \n> \n> # check in changes\n> $ git commit\n\nA few notes on these things:\n\n\tgit-apply --index /tmp/my.patch\n\nwill not only apply the patch (unified patches only!), but will do the\nindex updates for you while it's at it, so if the patch contains new files\n(or it deletes files), you don't need to worry about it.\n\nAlso, you can do\n\n\tgit commit \n\nas a shorthand for\n\n\tgit-update-cache \n\tgit commit\n\nwhich some people will probably find more natural.\n\n> 6) List all changes in working dir, in diff format.\n> \n> $ git-diff-cache -p HEAD\n\nOr, perhaps preferably:\n\n\tgit diff HEAD\n\nsince that is shorter ad will also show renames.\n\n> 8) List all changesets:\n> \n> $ git-whatchanged\n\nNo, if you just want the changesets listed, then\n\n\tgit log\n\nis a lot better, since it shows merges.\n\n\"git-whatchanged\" is useful if you actually want to see what the commits \n_changed_, and then you often want to use the \"-p\" flag to see it as \npatches. Also, it's worth pointing out the fact that you can limit it to \ncertain subdirectories (or individual files) etc, ie:\n\n\tgit-whatchanged -p drivers/net\n\nsince that is often what people want.\n\nBut if you just want the log, \"git log\" is faster and simpler and more \ncorrect.\n\n> 16) obtain a diff between current branch, and master branch\n> \n> In most trees WITH BRANCHES, .git/refs/heads/master contains the current \n> 'vanilla' upstream tree, for easy diffing and merging. (in trees \n> without branches, 'master' simply contains your latest changes)\n> \n> $ git-diff-tree -p master HEAD\n\nAgain, I think is possibly more naturally expressed with \"git diff\":\n\n\tgit diff master..HEAD\n\nwhich just says \"show the differences from 'master' to 'HEAD'\" and will\nalso show renames etc.\n\n(A plain \"git diff\" will show just the difference to the index file, in \ncase you care).\n\n\t\tLinus\n"},{"id":"5133","messageId":"Pine.LNX.4.58.0506221623210.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"20050622230905.GA7873@kroah.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-22T23:25:08Z","receivedAt":"2005-06-22T23:25:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Greg KH wrote:\n> \n> Ok, this is annoying. Is there some reason why git doesn't pull the\n> tags in properly when doing a merge? Chris and I just hit this when I\n> pulled his 2.6.12.1 tree and and was wondering where the tag went.\n\nTags are private in git (the same way branches are), which means that you\ncan have a million of your own tags and never disturb anybody else.\n\nBut, like branches, it means that if you want a tag, you need to know the \ntag you want, and download it the same way you download a branch.\n\n\t\tLinus\n"},{"id":"5134","messageId":"42B9FCAE.1000607@pobox.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506221623210.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-23T00:05:02Z","receivedAt":"2005-06-23T00:05:02Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Wed, 22 Jun 2005, Greg KH wrote:\n> \n>>Ok, this is annoying. Is there some reason why git doesn't pull the\n>>tags in properly when doing a merge? Chris and I just hit this when I\n>>pulled his 2.6.12.1 tree and and was wondering where the tag went.\n> \n> \n> Tags are private in git (the same way branches are), which means that you\n> can have a million of your own tags and never disturb anybody else.\n> \n> But, like branches, it means that if you want a tag, you need to know the \n> tag you want, and download it the same way you download a branch.\n\nStill -- that's interesting data that no script currently tracks. You \ngotta fall back to rsync.\n\n\tJeff\n\n\n"},{"id":"5135","messageId":"42B9FEE5.1090305@pobox.com","threadId":"1008","inReplyTo":"20050622225255.GB21298@redhat.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-23T00:14:29Z","receivedAt":"2005-06-23T00:14:29Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Dave Jones wrote:\n> At worse, users will have tools 59 minutes old. If a situation arises\n> where git from an hour ago isn't new enough to pull from the repository,\n> we have bigger problems.\n> \n> You seem to be proposing that everyone needs the shiniest newest things,\n> which clearly isn't true, and suggesting so just complicates things\n> further imo.\n\nFor the purposes of the these instructions, it is highly recommended.\n\nHowever, I was unaware that your snapshots were updated hourly. Yeah, \nthat's quite fine.\n\n\tJeff\n\n\n"},{"id":"5137","messageId":"42B9FF3A.4010700@pobox.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506221603120.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-23T00:15:54Z","receivedAt":"2005-06-23T00:15:54Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n[snip]\n\nThanks, this is all good stuff. I'll update it and post another, in a \nfew days or so.\n\ngit-clone-script would indeed be nice, even if its only a 2-line script.\n\n\tJeff\n"},{"id":"5139","messageId":"Pine.LNX.4.58.0506221724140.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"42B9FCAE.1000607@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T00:29:17Z","receivedAt":"2005-06-23T00:29:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Jeff Garzik wrote:\n>\n> > But, like branches, it means that if you want a tag, you need to know the \n> > tag you want, and download it the same way you download a branch.\n> \n> Still -- that's interesting data that no script currently tracks. You \n> gotta fall back to rsync.\n\nSomething like\n\n\tgit-ssh/http-pull -w tags/ tags/ \n\n_should_ hopefully work now (and the \"-a\" flag should mean that you also \nget all the objects needed for the tag).\n\nI've not tested it, as usual, but it should work as of today thanks to \nDaniel Barkalow fixing the pulling of arbitrary objects.\n\n\t\tLinus\n"},{"id":"5140","messageId":"Pine.LNX.4.58.0506221729520.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506221603120.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T00:33:14Z","receivedAt":"2005-06-23T00:33:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Linus Torvalds wrote:\n> \n> A few notes on these things:\n> \n> \tgit-apply --index /tmp/my.patch\n> \n> will not only apply the patch (unified patches only!), but will do the\n> index updates for you while it's at it, so if the patch contains new files\n> (or it deletes files), you don't need to worry about it.\n\nBtw, if the patch contains rename/copy-patches or mode updates, you _need_\nto use git-apply, since regular \"patch\" doesn't know about file modes and\ncan't handle file renames or copies.\n\nNow, the rename/copy patches are easy to avoid by just not asking git to\ngenerate them (so they'll show up as just straight file creates, with a\ndelete of the old file for a rename), but the file mode part in particular\nis useful as more than just a way to create smaller (and more\nhuman-readable) patches.\n\n\t\tLinus\n"},{"id":"5143","messageId":"42BA14B8.2020609@pobox.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506221724140.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-23T01:47:36Z","receivedAt":"2005-06-23T01:47:36Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Wed, 22 Jun 2005, Jeff Garzik wrote:\n> \n>>>But, like branches, it means that if you want a tag, you need to know the \n>>>tag you want, and download it the same way you download a branch.\n>>\n>>Still -- that's interesting data that no script currently tracks. You \n>>gotta fall back to rsync.\n> \n> \n> Something like\n> \n> \tgit-ssh/http-pull -w tags/ tags/ \n> \n> _should_ hopefully work now (and the \"-a\" flag should mean that you also \n> get all the objects needed for the tag).\n\nThe problem isn't pulling tags, the problem is that nothing \nautomatically downloads the 41-byte tag files themselves. Pulling \nlinux-2.6.git after the 2.6.12 release did not cause refs/tags/v2.6.12 \nto be downloaded.\n\nWith BK, tags came with each pull. With git, you have to go \"outside \nthe system\" (rsync) just get the new tags.\n\n\tJeff\n"},{"id":"5144","messageId":"Pine.LNX.4.58.0506221850030.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"42B9FF3A.4010700@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T01:53:06Z","receivedAt":"2005-06-23T01:53:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Jeff Garzik wrote:\n> \n> git-clone-script would indeed be nice, even if its only a 2-line script.\n\nOk, added. You can update your tutorial to make the initial setup of a \nkernel archive slightly less scary, ie it's now\n\n\tgit clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6\n\tcd linux-2.6\n\tgit checkout\n\nwhich looks almost user-friendly.\n\n(Of course, since the rsync protocol doesn't know anything about git\nconsistency, if the mirroring is half-way, you'll end up with something\nless than wonderful, and confusing. Details, details)\n\n\t\tLinus\n"},{"id":"5145","messageId":"Pine.LNX.4.58.0506221853280.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"42BA14B8.2020609@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T01:56:16Z","receivedAt":"2005-06-23T01:56:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Jeff Garzik wrote:\n>\n> With BK, tags came with each pull. With git, you have to go \"outside \n> the system\" (rsync) just get the new tags.\n\nYou don't have to use rsync, and you don't have to go outside the system. \nThat was my point: you can use \"git-ssh-pull\" to pull the tags.\n\nBut yes, you have to explicitly ask for them by name, ie the other side \nhas to let you know: \"Oh, btw, I created a 'xyz' tag for you\". And having \nanother helper script to hide the details of how git-*-pull handles tags \nis obviously also a good idea, although it's pretty low on my list of \nthings to worry about.\n\n\t\tLinus\n"},{"id":"5147","messageId":"42BA18AF.2070406@pobox.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506221603120.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-23T02:04:31Z","receivedAt":"2005-06-23T02:04:31Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n> A few notes on these things:\n> \n> \tgit-apply --index /tmp/my.patch\n> \n> will not only apply the patch (unified patches only!), but will do the\n> index updates for you while it's at it, so if the patch contains new files\n> (or it deletes files), you don't need to worry about it.\n\nThe output isn't terribly helpful:\n\n[jgarzik@pretzel netdev-2.6]$ git apply --index \\\n\t~/tmp/linux-2.6.12-rc4-cxgb2.1.1.patch\nFragment applied at offset 11\n\nThat is worse than no message at all... fragment? offset 11? did it \nwork? Did it apply only a \"fragment\" of my patch, not the whole thing? \n I'm worried! \n\nOutputting the following (stolen from 'git commit') would be far more \nuseful:\n\n modified: Documentation/networking/cxgb.txt\n modified: drivers/net/chelsio/Makefile\n deleted: drivers/net/chelsio/ch_ethtool.h\n modified: drivers/net/chelsio/common.h\n modified: drivers/net/chelsio/cphy.h\n modified: drivers/net/chelsio/cpl5_cmd.h\n modified: drivers/net/chelsio/cxgb2.c\n deleted: drivers/net/chelsio/cxgb2.h\n modified: drivers/net/chelsio/elmer0.h\n modified: drivers/net/chelsio/espi.c\n modified: drivers/net/chelsio/espi.h\n modified: drivers/net/chelsio/gmac.h\n modified: drivers/net/chelsio/mv88x201x.c\n deleted: drivers/net/chelsio/osdep.h\n modified: drivers/net/chelsio/pm3393.c\n modified: drivers/net/chelsio/regs.h\n modified: drivers/net/chelsio/sge.c\n modified: drivers/net/chelsio/sge.h\n modified: drivers/net/chelsio/subr.c\n modified: drivers/net/chelsio/suni1x10gexp_regs.h\n deleted: drivers/net/chelsio/tp.c\n deleted: drivers/net/chelsio/tp.h\n modified: include/linux/pci_ids.h\n\n\n> Also, you can do\n> \n> \tgit commit \n> \n> as a shorthand for\n> \n> \tgit-update-cache \n> \tgit commit\n> \n> which some people will probably find more natural.\n\nIt would be natural if it functioned like 'bk citool' ;-)\n\n\tgit commit --figure-out-for-me-what-files-changed\n\n'git diff' can do this, so it's certainly feasible.\n\nObviously added/removed files would still require git-update-cache or \ngit-commit.\n\n\n> \"git-whatchanged\" is useful if you actually want to see what the commits \n> _changed_, and then you often want to use the \"-p\" flag to see it as \n> patches. Also, it's worth pointing out the fact that you can limit it to \n> certain subdirectories (or individual files) etc, ie:\n> \n> \tgit-whatchanged -p drivers/net\n> \n> since that is often what people want.\n> \n> But if you just want the log, \"git log\" is faster and simpler and more \n> correct.\n\nI usually want just two things:\n\n1) browse the log\n\n2) list changes in local tree that are not in $remote_tree, a la\n\tbk changes -L ../linux-2.6\n\nI agree that seeing the merge csets is useful, that is why [being \nignorant of 'git log'] I used git-changes-script.\n\n\tJeff\n\n\n"},{"id":"5150","messageId":"42BA1B68.9040505@pobox.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506221853280.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-23T02:16:08Z","receivedAt":"2005-06-23T02:16:08Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Wed, 22 Jun 2005, Jeff Garzik wrote:\n> \n>>With BK, tags came with each pull. With git, you have to go \"outside \n>>the system\" (rsync) just get the new tags.\n> \n> \n> You don't have to use rsync, and you don't have to go outside the system. \n> That was my point: you can use \"git-ssh-pull\" to pull the tags.\n\nOK, understood.\n\n\n> But yes, you have to explicitly ask for them by name, ie the other side \n> has to let you know: \"Oh, btw, I created a 'xyz' tag for you\". And having \n> another helper script to hide the details of how git-*-pull handles tags \n> is obviously also a good idea, although it's pretty low on my list of \n> things to worry about.\n\nThe problem is still that nothing says \"oh, btw, I created 'xyz' tag for \nyou\" AFAICS?\n\nIMO the user (GregKH and me, at least) just wants to know their set of \ntags and heads is up-to-date on local disk. Wants to know what tags are \nout there. It's quite annoying when two data sets are out of sync \n(.git/objects and .git/refs/tags).\n\nAsking for the tag by name isn't useful at all, in that regard, because \nthat requires that the user already know what tags are available. To \nget that info, one must use rsync, gitweb, or a subscription to Psychic \nFriends Network.\n\n\tJeff\n\n\n"},{"id":"5151","messageId":"Pine.LNX.4.58.0506221915280.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"42BA18AF.2070406@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T02:28:45Z","receivedAt":"2005-06-23T02:28:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Jeff Garzik wrote:\n> \n> The output isn't terribly helpful:\n\nYeah. The good news is that if something bad happens, it surely lets you \nknow, and it's very verbose about that.\n\nI should probably remove the \"Fragment applied at offset xx\" thing, it was \nbasically a debugging message to make sure that I applied patch fragments \ncorrectly even if the line offset given in the patch was sligthly off..\n\n> Outputting the following (stolen from 'git commit') would be far more \n> useful:\n> \n> modified: Documentation/networking/cxgb.txt\n> modified: drivers/net/chelsio/Makefile\n> deleted: drivers/net/chelsio/ch_ethtool.h\n> modified: drivers/net/chelsio/common.h\n> modified: drivers/net/chelsio/cphy.h\n> modified: drivers/net/chelsio/cpl5_cmd.h\n> modified: drivers/net/chelsio/cxgb2.c\n> deleted: drivers/net/chelsio/cxgb2.h\n> modified: drivers/net/chelsio/elmer0.h\n> modified: drivers/net/chelsio/espi.c\n> modified: drivers/net/chelsio/espi.h\n> modified: drivers/net/chelsio/gmac.h\n> modified: drivers/net/chelsio/mv88x201x.c\n> deleted: drivers/net/chelsio/osdep.h\n> modified: drivers/net/chelsio/pm3393.c\n> modified: drivers/net/chelsio/regs.h\n> modified: drivers/net/chelsio/sge.c\n> modified: drivers/net/chelsio/sge.h\n> modified: drivers/net/chelsio/subr.c\n> modified: drivers/net/chelsio/suni1x10gexp_regs.h\n> deleted: drivers/net/chelsio/tp.c\n> deleted: drivers/net/chelsio/tp.h\n> modified: include/linux/pci_ids.h\n\nHow about this patch? Then you can say\n\n\tgit-apply --stat --summary --apply --index /tmp/my.patch\n\nand it will not only apply the patch, but also give a diffstat and a\nsummary or renames etc..\n\nThis also removes the \"Fragment..\" debugging message.\n\nBtw, \"--stat\" and \"--summary\" normally turn off the \"apply\" flag, so \n\"--apply\" has to come _after_ the stat/summary thing, fwiw:\n\ndiff --git a/apply.c b/apply.c\n--- a/apply.c\n+++ b/apply.c\n@@ -860,7 +860,6 @@ static int find_offset(const char *buf, \n \t\tn = (i >> 1)+1;\n \t\tif (i & 1)\n \t\t\tn = -n;\n-\t\tfprintf(stderr, \"Fragment applied at offset %d\\n\", n);\n \t\treturn try;\n \t}\n \n@@ -1434,6 +1433,10 @@ int main(int argc, char **argv)\n \t\t\tcheck_index = 1;\n \t\t\tcontinue;\n \t\t}\n+\t\tif (!strcmp(arg, \"--apply\")) {\n+\t\t\tapply = 1;\n+\t\t\tcontinue;\n+\t\t}\n \t\tif (!strcmp(arg, \"--show-files\")) {\n \t\t\tshow_files = 1;\n \t\t\tcontinue;\n\n> > Also, you can do\n> > \n> > \tgit commit \n> > \n> > as a shorthand for\n> > \n> > \tgit-update-cache \n> > \tgit commit\n> > \n> > which some people will probably find more natural.\n> \n> It would be natural if it functioned like 'bk citool' ;-)\n> \n> \tgit commit --figure-out-for-me-what-files-changed\n> \n> 'git diff' can do this, so it's certainly feasible.\n\nWell, it _does_ do that. That's what the \"git status\" thing does, and look \nat the initial commit message comments that it prepares for you: it tells \nyou which files are modified but haven't been marked for check-in etc.\n\nBut the thing is, you need to have a graphical tool for that. I don't want\nto have some silly command line that asks for each modified file whether\nyou want to include that file in the commit or not.\n\nSo this is where \"git\" ends, and a nice user interface (written by \nsomebody else than me) begins. Ie this is a cogito-like thing.\n\n> > \"git-whatchanged\" is useful if you actually want to see what the commits \n> > _changed_, and then you often want to use the \"-p\" flag to see it as \n> > patches. Also, it's worth pointing out the fact that you can limit it to \n> > certain subdirectories (or individual files) etc, ie:\n> > \n> > \tgit-whatchanged -p drivers/net\n> > \n> > since that is often what people want.\n> > \n> > But if you just want the log, \"git log\" is faster and simpler and more \n> > correct.\n> \n> I usually want just two things:\n> \n> 1) browse the log\n> \n> 2) list changes in local tree that are not in $remote_tree, a la\n> \tbk changes -L ../linux-2.6\n> \n> I agree that seeing the merge csets is useful, that is why [being \n> ignorant of 'git log'] I used git-changes-script.\n\nFor (1) \"bk log\" is good. For (2) you'll have to use your own script, or\njust have the remote tree as a branch in the same tree, in which case you\ncan do\n\n\tgit log remotebranch..mybranch\n\nand it will do what you expect. In fact, since \"HEAD\" is the default \nbranch for the final one, you can do\n\n\tgit log remotebranch..\n\nand you'll get the log of everything that is in your HEAD but it _not_ in \nthe \"remotebranch\" branch.\n\nBtw, if you have the remote as a branch in your own tree, you can also do\n\n\tgitk remotebranch..mybranch\n\nwhich is a really nice way of graphically seeing \"what is in 'mybranch' \nthat is not in 'remotebranch'\".\n\n\t\t\tLinus\n"},{"id":"5152","messageId":"Pine.LNX.4.58.0506221929430.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"42BA1B68.9040505@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T02:39:24Z","receivedAt":"2005-06-23T02:39:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Jeff Garzik wrote:\n> \n> The problem is still that nothing says \"oh, btw, I created 'xyz' tag for \n> you\" AFAICS?\n> \n> IMO the user (GregKH and me, at least) just wants to know their set of \n> tags and heads is up-to-date on local disk. Wants to know what tags are \n> out there. It's quite annoying when two data sets are out of sync \n> (.git/objects and .git/refs/tags).\n\nWell, I really think this is the exact same issue as when you write any \nannoucement, and say \"please pull from branch xyz of repo abc\".\n\nWhat I'm saying is that for a tagged release, that really translates to\n\"please pull tag xyz from repo abc\" and the tools like git-ssh-pull will \njust do the right thing: they'll pull the tag itself _and_ they'll pull \nthe objects it points to.\n\nOf course, right now \"git fetch\" is hardcoded to always write FETCH_HEAD \n(not the tag name), but I'm saying ythat _literally_ you can do this \nalready:\n\n\tgit fetch repo-name tags/xyz &&\n\t\t( cat .git/FETCH_HEAD > .git/tags/xyz )\n\nand it should do exactly what you want. Hmm?\n\nSo if we script this (maybe teach \"git-fetch-script\" to take \"tag\" as its \nfirst argument and do this on its own), and people learn to just do\n\n\tgit fetch tag v2.6.18.5\n\nwhen Chris or Greg make an announcement about \"v2.6.18.5\", then you're all\ndone, no?\n\nThe change to \"git-fetch-script\" would look something like the appended.. \nTotally untested, of course. Give it a try,\n\n\t\t\tLinus\n\n---\ndiff --git a/git-fetch-script b/git-fetch-script\n--- a/git-fetch-script\n+++ b/git-fetch-script\n@@ -1,5 +1,12 @@\n #!/bin/sh\n #\n+destination=FETCH_HEAD\n+\n+if [ \"$1\" = \"tag\" ]; then\n+\tshift\n+\tdestination=\"refs/tags/$2\"\n+fi\n+\n merge_repo=$1\n merge_name=${2:-HEAD}\n \n@@ -35,7 +42,7 @@ download_objects () {\n }\n \n echo \"Getting remote $merge_name\"\n-download_one \"$merge_repo/$merge_name\" \"$GIT_DIR\"/FETCH_HEAD || exit 1\n+download_one \"$merge_repo/$merge_name\" \"$GIT_DIR/$dest\" || exit 1\n \n echo \"Getting object database\"\n-download_objects \"$merge_repo\" \"$(cat \"$GIT_DIR\"/FETCH_HEAD)\" || exit 1\n+download_objects \"$merge_repo\" \"$(cat \"$GIT_DIR/$dest\")\" || exit 1\n"},{"id":"5153","messageId":"42BA271F.6080505@pobox.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506221929430.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-23T03:06:07Z","receivedAt":"2005-06-23T03:06:07Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n> What I'm saying is that for a tagged release, that really translates to\n> \"please pull tag xyz from repo abc\" and the tools like git-ssh-pull will \n> just do the right thing: they'll pull the tag itself _and_ they'll pull \n> the objects it points to.\n\nYes, everything does the right there here.\n\n\n> Of course, right now \"git fetch\" is hardcoded to always write FETCH_HEAD \n> (not the tag name), but I'm saying ythat _literally_ you can do this \n> already:\n> \n> \tgit fetch repo-name tags/xyz &&\n> \t\t( cat .git/FETCH_HEAD > .git/tags/xyz )\n> \n> and it should do exactly what you want. Hmm?\n\nNo, not at all. This sub-thread is all about tags/ dir updates. Users \nshould be able to do\n\n\tgit pull-more rsync://...\n\nand get ALL of .git/refs/tags/* that have appeared since their last update.\n\nConcrete example: I have a git tree on local disk. I need to find out \nwhere, between 2.6.12-rc1 and 2.6.12, a driver broke. This requires \nthat I have -ALL- linux-2.6.git/refs/tags on disk already, so that I can \nbounce quickly and easily between tags.\n\nIt is valuable to have a local copy of -all- tags, -before- you need \nthem. That is why people like me and GregKH use rsync directly. We \nwant EVERYTHING in the kernel.org linux-2.6.git tree, not just what we \nknow we need right now.\n\n\tJeff\n\n\n"},{"id":"5154","messageId":"Pine.LNX.4.58.0506222014000.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"42BA271F.6080505@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T03:24:22Z","receivedAt":"2005-06-23T03:24:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Jeff Garzik wrote:\n> \n> Concrete example: I have a git tree on local disk. I need to find out \n> where, between 2.6.12-rc1 and 2.6.12, a driver broke. This requires \n> that I have -ALL- linux-2.6.git/refs/tags on disk already, so that I can \n> bounce quickly and easily between tags.\n\nAbsolutely not.\n\nI might have my private tags in my kernel, and you might have your private \ntags (\"tested\") in your kernel, so there is no such thing as \"ALL\".\n\nThe fact that BK had it was a BK deficiency, and just meant that you \nbasically couldn't use tags at all with BK, the \"official ones\" excepted. \nIt basically meant that nobody else than me could ever tag a tree. Do you \nnot see how that violates the very notion of \"distributed\"?\n\nThis is _exactly_ the same thing as if you said \"I want to merge with ALL\nBRANCHES\". That notion doesn't exist. You can rsync the whole repository,\nand you'll get all branches from that repository, that's really by virtue\nof doing a filesystem operation, not because you asked git to get you all\nbranches.\n\nA tag is even _implemented_ exactly like a branch, except it allows (but\ndoes not require) that extra step of signing an object. The only\ndifference is literally whether it is in refs/branches or refs/tags.\n\n> It is valuable to have a local copy of -all- tags, -before- you need \n> them.\n\nYou seem to not realize that \"all tags\" is a nonsensical statement in a \ndistributed system.\n\nIf you want to have a list of official tags, why not just do exactly that? \nWhat's so hard with saying \"ok, that place has a list of 'official' tags, \nlet's fetch them\".\n\nHow would you fetch them? You might use rsync, for example. Or maybe wget. \nOr whatever. The point is that this works already. You're asking for \nsomething nonsensical, outside of just a script that does\n\n\trsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/\n\nSee? What's your complaint with just doing that?\n\n\t\t\tLinus\n"},{"id":"5158","messageId":"07be01c577a7$05108660$03c8a8c0@kroptech.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506221915280.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Adam Kropelin","fromEmail":"akropel1@rochester.rr.com","sentAt":"2005-06-23T03:52:47Z","receivedAt":"2005-06-23T03:52:47Z","isPatch":false,"sender":{"key":"akropel1@rochester.rr.com","avatar":null},"body":"Linus Torvalds wrote:\n> On Wed, 22 Jun 2005, Jeff Garzik wrote:\n>> git commit --figure-out-for-me-what-files-changed\n>\n> Well, it _does_ do that. That's what the \"git status\" thing does, and\n> look at the initial commit message comments that it prepares for you: \n> it\n> tells you which files are modified but haven't been marked for \n> check-in\n> etc.\n>\n> But the thing is, you need to have a graphical tool for that. I don't\n> want to have some silly command line that asks for each modified file\n> whether you want to include that file in the commit or not.\n\nI know I shouldn't invoke this particular acronym, but I rather like \nCVS's approach. If the user does not specify any files on the command \nline, assume he wants to check in everything that has changed (added and \nremoved files excluded). When you see the initial commit message you can \nreview the list of affected files and you can always abort and specify \nfiles explictly if you realize you want to exclude some.\n\nI like that method because it gives you a kick in the pants for having \nmixed multiple unrelated changes in your working directory. \"Oh, you \nwere lazy and changed six unrelated things without comitting, eh? You \nwill now pay for your lack of rigor by typing filenames...\" On the flip \nside, you get rewarded with less typing if you keep your working \ndirectory clean.\n\n--Adam\n\n"},{"id":"5157","messageId":"Pine.LNX.4.21.0506230019440.30848-100000@iabervon.org","threadId":"1008","inReplyTo":"42B9E536.60704@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-23T04:23:10Z","receivedAt":"2005-06-23T04:23:10Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 22 Jun 2005, Jeff Garzik wrote:\n\n> 5) check in your own modifications (e.g. do some hacking, or apply a patch)\n> \n> # go to repo\n> $ cd linux-2.6\n> \n> # make some modifications\n> $ patch -sp1 < /tmp/my.patch\n> $ diffstat -p1 < /tmp/my.patch\n> \n> # NOTE: add '--add' and/or '--remove' if files were added or removed\n> $ git-update-cache \n\nThere's actually \"git add\" for when you add a file (if you're actually\ndeveloping with git, rather than just applying patching with it). No\nscript, so far as I can tell, for removing a file, though.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"5159","messageId":"Pine.LNX.4.58.0506222146460.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"07be01c577a7$05108660$03c8a8c0@kroptech.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T04:54:23Z","receivedAt":"2005-06-23T04:54:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Adam Kropelin wrote:\n> \n> I know I shouldn't invoke this particular acronym, but I rather like \n> CVS's approach.\n\nThe problem I have with \"git commit\" committing everything dirty by\ndefault is that it encourages exactly the wrong kind of behaviour, ie the \n\"commit it all in one go without thinking about it\".\n\nAlso, CVS really doesn't have much choice, since CVS doesn't _have_ the \nnotion of marking files for commits. In contrast, in git the index file \nreally does end up beign a good way to say which files are ready to be \ncommitted.\n\nAnd \"git status\" really isn't that hard to type, and it will tell you \nexactly what you've already marked for commit, and what you have dirty in \nthe tree but isn't marked for commit yet.\n\nSo I think the \"git commit \" thing is very convenient, but it's\nconvenient exactly because it's concise yet still precise and doesn't \nencourage the \"just commit whatever random dirty state I have right now\" \nmentality.\n\nAnd if you have more than a few files dirty in your tree, I really think\nit's much better to do \"git status\" and think about it a bit and select\nthe files you do want to commit than it is to just do \"git commit\" and let\nit rip.\n\nNow, I could well imagine adding an \"--all\" flag (and not even allow the \nshorthane version) to both git-update-cache and \"git commit\". So that you \ncould say \"commit all the dirty state\", but you'd at least have to think \nabout it before you did so.\n\n\t\tLinus\n"},{"id":"5160","messageId":"42BA45B1.7060207@pobox.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506222014000.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-23T05:16:33Z","receivedAt":"2005-06-23T05:16:33Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"\nLinus Torvalds wrote:\n> \trsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/\n> \n> See? What's your complaint with just doing that?\n\nNo complaint with that operation. The complaint is that it's an \nadditional operation. Re-read what Greg said:\n\n> Is there some reason why git doesn't pull the\n> tags in properly when doing a merge? Chris and I just hit this when I\n> pulled his 2.6.12.1 tree and and was wondering where the tag went.\n\nMultiple users -- not just me -- would prefer that git-pull-script \npulled the tags, too.\n\nSuggested solution: add '--tags' to git-pull-script \n(git-fetch-script?), which calls\n\trsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/\n\n\n> You seem to not realize that \"all tags\" is a nonsensical statement in a \n> distributed system.\n> \n> If you want to have a list of official tags, why not just do exactly that? \n> What's so hard with saying \"ok, that place has a list of 'official' tags, \n> let's fetch them\".\n\nI know how tags work, and I like the new flexibility above and beyond BK.\n\nKernel hackers are surprised when the tags aren't pulled, along with the \nobjects. BK and CVS trained us that tags came with the repo, no \nadditional steps needed. Why not give us the OPTION of working like \nwe've always worked?\n\nLet the kernel hacker say \"yes, I really do want to download the tags \nLinus publicly posted in linux-2.6.git/refs/tags\" because this was a \ncommon operation in the previous workflow, a common operation that we \n-made use of-.\n\n\tJeff\n\n\n"},{"id":"5163","messageId":"42BA4A29.7030601@pobox.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506222146460.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-23T05:35:37Z","receivedAt":"2005-06-23T05:35:37Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n> The problem I have with \"git commit\" committing everything dirty by\n> default is that it encourages exactly the wrong kind of behaviour, ie the \n> \"commit it all in one go without thinking about it\".\n\n100% agreed\n\n\n> And \"git status\" really isn't that hard to type, and it will tell you \n> exactly what you've already marked for commit, and what you have dirty in \n> the tree but isn't marked for commit yet.\n\nHaving found about it recently, 'git status' is quite useful.\n\n\n> So I think the \"git commit \" thing is very convenient, but it's\n> convenient exactly because it's concise yet still precise and doesn't \n> encourage the \"just commit whatever random dirty state I have right now\" \n> mentality.\n> \n> And if you have more than a few files dirty in your tree, I really think\n> it's much better to do \"git status\" and think about it a bit and select\n> the files you do want to commit than it is to just do \"git commit\" and let\n> it rip.\n\nFor me at least, providing a file list is a pain, because I am so \nprecise [read: obsessive] about keeping an otherwise clean working dir \n:) Except in rare occasions, I know precisely that the changes in the \nworking dir comprise 100% of what I plan to commit.\n\nLocally I have scripted\n\n git-diff-cache -p HEAD | diffstat -p1 | awk '{print $1}' > /tmp/lst\n git-update-cache `cat /tmp/lst`\n\nbecause of this.\n\n[again, clearly doesn't work with remove/add/mode change]\n\n\n> Now, I could well imagine adding an \"--all\" flag (and not even allow the \n> shorthane version) to both git-update-cache and \"git commit\". So that you \n> could say \"commit all the dirty state\", but you'd at least have to think \n> about it before you did so.\n\nThat's pretty much what I suggested when I said\n\n\tgit commit --figure-out-for-me-what-files-changed\n\n:)\n\nSo I certainly agree there.\n\n\tJeff\n\n\n\n"},{"id":"5164","messageId":"Pine.LNX.4.58.0506222225010.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"42BA45B1.7060207@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T05:58:13Z","receivedAt":"2005-06-23T05:58:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Jun 2005, Jeff Garzik wrote:\n>\n> No complaint with that operation. The complaint is that it's an \n> additional operation. Re-read what Greg said:\n\nPlease re-read what I said.\n\nPulling a regular head _cannot_ and _must_not_ update tags. Tags are not \nassociated with the tree, and they _cannot_ and _must_not_ be so, exactly \nbecause that would make them global instead of private, and it would \nfundamentally make them not be distributed, and would mean that they'd be \npointless as anything but \"Linus' official tags\".\n\nThat's what we had in BK _AND IT DOES NOT WORK_!\n\nDoes it help when I scream?\n\n> > Is there some reason why git doesn't pull the\n> > tags in properly when doing a merge? Chris and I just hit this when I\n> > pulled his 2.6.12.1 tree and and was wondering where the tag went.\n\nAnd I suggested that if you want that, then you pull on the TAG. You take \nmy modification, you test it, and you see if\n\n\tgit fetch tag ..repo.. tagname\n\nworks.\n\nThat solves exactly the case that Greg is complaining about, and it solves\nit in a _sane_ manner: you tell git that you want a tag, and git fetches\nit for you. It's that simple, and it does not introduce the _BROKEN_\nnotion that tags are associated directly with the commit itself and\nsomehow visible to all.\n\n> Multiple users -- not just me -- would prefer that git-pull-script \n> pulled the tags, too.\n\nAnd multiple users -- clearly including you -- aren't listening to me. \nTags are separate from the source they tag, and they HAVE TO BE. There is \nno \"you automatically get the tags when you get the tree\", because the two \ndon't have a 1:1 relationship.\n\nAnd not making them separate breaks a lot of things. As mentioned, it\nfundamentally breaks the distributed nature, but that also means that it\nbreaks whenever two people use the same name for a tag, for example. You\ncan't \"merge\" tags. BK had a very strange form of merging, which was (I\nthink) to pick the one last in the BK ChangeSet file, but that didn't make\nit \"right\". You just never noticed, because Linux could never use tags at\nall due to the lack of privacy, except for big releases..\n\n> Suggested solution: add '--tags' to git-pull-script \n> (git-fetch-script?), which calls\n> \trsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/\n\nHow is this AT ALL different from just having a separate script that does\nthis? You've introduced nothing but syntactic fluff, and you've made it\nless flexible at the same time. First off, you might want to get new tags\n_without_ fetching anything else, and you might indeed want to get the \ntags _first_ in order to decide what you want to fetch. In fact, in many \ncases that's exactly what you want, namely you want to fetch the data \nbased on the tag.\n\nSecondly, if your worry is that you forget, then hell, write a small shell \nfunction, and be done with it.\n\nBUT DO NOT MESS UP THINGS FOR OTHER PEOPLE.\n\nWhen I fetch somebody elses head, I had better not fetch his tags. His\ntags may not even make _sense_ in what I have - he may tag things in other\nbranches that I'm not fetching at all. In fact, his tag-namespace might be\n_different_ from mine, ie he might have tagged something \"broken\" in his\ntree, and I tagged something _else_ \"broken\" in mine, just because it\nhappens to be a very useful tag for when you want to mark \"ok, that was a\nbroken tree\".\n\nIt is wrong, wrong, _wrong_ to think that fetching somebody elses tree\nmeans that you should fetch his tags. The _only_ reason you think it's\nright is because you've only ever seen centralized tags: tags were the one\nthing that BK kept centralized.\n\nBut once people realize that they can use tags in their own trees, and \nnobody else will ever notice, they'll slowly start using them. Maybe it \ntakes a few months or even longer. But it will happen. And I refuse to \nmake stupid decisions that makes it not work.\n\nAnd thinking that \"fetching a tree fetches all the tags from that tree\" \nreally _is_ a stupid decision. It's missing the big picture. It's missing\nthe fact that tags _should_ be normal every-day things that you just use\nas \"book-marks\", and that the kind of big \"synchronization point for many\npeople\" tag should actually be the _rare_ case.\n\nThe fact that global tags make that private \"bookmark\" usage impossible\nshould be a big red blinking sign saying \"don't do global tags\".\n\n> Let the kernel hacker say \"yes, I really do want to download the tags \n> Linus publicly posted in linux-2.6.git/refs/tags\" because this was a \n> common operation in the previous workflow, a common operation that we \n> -made use of-.\n\nAnd I already suggested a trivial script. Send me the script patch,\ninstead of arguing for stupid things.\n\n\t\t\tLinus\n"},{"id":"5166","messageId":"buofyv9wqpw.fsf@mctpc71.ucom.lsi.nec.co.jp","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506222146460.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Miles Bader","fromEmail":"miles@lsi.nec.co.jp","sentAt":"2005-06-23T06:07:55Z","receivedAt":"2005-06-23T06:07:55Z","isPatch":false,"sender":{"key":"miles@lsi.nec.co.jp","avatar":null},"body":"Linus Torvalds writes:\n> And if you have more than a few files dirty in your tree, I really think\n> it's much better to do \"git status\" and think about it a bit and select\n> the files you do want to commit than it is to just do \"git commit\" and let\n> it rip.\n>\n> Now, I could well imagine adding an \"--all\" flag (and not even allow the \n> shorthane version) to both git-update-cache and \"git commit\". So that you \n> could say \"commit all the dirty state\", but you'd at least have to think \n> about it before you did so.\n\nI think both modes of operation are useful -- sometimes I want to hack\nin the tree and later decide what to commit, and sometimes I know\nexactly what sequence of commits I want to make and do a series of\n\"change-some-files then commit everything\" steps.\n\nIn the latter case, it's very convenient to have commit just grab\neverything and clear the slate for my next step. Morever, I use the\nlatter style enough that I think even the requirement of a long option\nseems annoying and artificial; a short option would be fine though...\n\n-Miles\n-- \nAny man who is a triangle, has thee right, when in Cartesian Space, to\nhave angles, which when summed, come to know more, nor no less, than\nnine score degrees, should he so wish. [TEMPLE OV THEE LEMUR]\n"},{"id":"5167","messageId":"20050623062045.GA11638@kroah.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506222225010.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2005-06-23T06:20:45Z","receivedAt":"2005-06-23T06:20:45Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Wed, Jun 22, 2005 at 10:58:13PM -0700, Linus Torvalds wrote:\n> And I suggested that if you want that, then you pull on the TAG. You take \n> my modification, you test it, and you see if\n> \n> \tgit fetch tag ..repo.. tagname\n> \n> works.\n\nHm, that doesn't work right now. Both:\n git fetch rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git tag v2.6.12.1\nor\n git fetch tag rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git v2.6.12.1\n\ndie. Or am I just trying to take a point you were making about not\npulling all tags (which I can live with, just was not aware it was this\nway, and I agree that it does offer up a lot of possiblities of me using\nlocal tags in the future), and taking it literally?\n\nthanks,\n\ngreg k-h\n"},{"id":"5170","messageId":"Pine.LNX.4.58.0506222325080.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"42BA4A29.7030601@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T06:37:57Z","receivedAt":"2005-06-23T06:37:57Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Jun 2005, Jeff Garzik wrote:\n> \n> Locally I have scripted\n> \n> git-diff-cache -p HEAD | diffstat -p1 | awk '{print $1}' > /tmp/lst\n> git-update-cache `cat /tmp/lst`\n> \n> because of this.\n\nBtw, that's some extremely convoluted computation.\n\nThis is exactly when you do _not_ want the diff in \"patch\" form, and you\nreally want the native git format (which is just a strange \"this file\nchanged from this mode/sha1 to that mode/sha1\" format).\n\nSo instead, try to do just\n\n\tgit-diff-cache HEAD | cut -f2\n\nand now it's going to be a whole lot simpler and faster - it won't turn \nthings into a diff only to do a \"diffstat\" on it to turn it into a name \nagain. I bet it's more reliable too.\n\n> [again, clearly doesn't work with remove/add/mode change]\n\nWell, it actually can work with removes, and rewriting it to be a bit \nmore clean (and handle files that start with \"-\") gives you:\n\n\tgit-update-cache --remove -- $(git-diff-cache HEAD | cut -f2)\n\nwhich should actually work fine for files that you have removed. But yes,\nit fundamentally _cannot_ work for new files, of course, since git will\nnever even try to look for files you haven't told it about. So you always \nhave to add files by hand some way.\n\nNote how the \"--remove\" parameter to git-update-cache really only means\n\"it's ok if some of the files mentioned don't exist any more, and that\nmeans you should remove them from the cache\".\n\nWithout the \"--remove\" flag, a filename that is listed but that doesn't\nexist in the working tree is either considered an error, or is ignored\n(depending on the \"--ignore-missing\" flag).\n\nThat's actually what \"--add\" means too: it means \"it's ok if some of the\nfilenames on the command line don't currently exist in the index: if they\nexist in the working directory, you should add them\".\n\nSo even if it looks a bit strange, in a script it actually makes perfect\nsense to write something that seems as _apparently_ senseless as:\n\n\tgit-update-cache --add --remove --refresh -- \"$@\"\n\nand it will refresh all existing files, and add or remove any files \nexplicitly mentioned that either exist or have been removed in the working \ndirectory.\n\n\t\t\tLinus\n"},{"id":"5168","messageId":"Pine.LNX.4.58.0506222338290.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"20050623062045.GA11638@kroah.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T06:51:40Z","receivedAt":"2005-06-23T06:51:40Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Greg KH wrote:\n> \n> Hm, that doesn't work right now.\n\nYeah, my suggested mod sucks.\n\nTry the following slightly modified version instead, with\n\n\tgit fetch rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git tag v2.6.12.1\n\nand now it should work.\n\n\t\tLinus\n\n---\ndiff --git a/git-fetch-script b/git-fetch-script\n--- a/git-fetch-script\n+++ b/git-fetch-script\n@@ -1,7 +1,13 @@\n #!/bin/sh\n #\n+destination=FETCH_HEAD\n+\n merge_repo=$1\n merge_name=${2:-HEAD}\n+if [ \"$2\" = \"tag\" ]; then\n+\tmerge_name=\"refs/tags/$3\"\n+\tdestination=\"$merge_name\"\n+fi\n \n : ${GIT_DIR=.git}\n : ${GIT_OBJECT_DIRECTORY=\"${SHA1_FILE_DIRECTORY-\"$GIT_DIR/objects\"}\"}\n@@ -35,7 +41,7 @@ download_objects () {\n }\n \n echo \"Getting remote $merge_name\"\n-download_one \"$merge_repo/$merge_name\" \"$GIT_DIR\"/FETCH_HEAD || exit 1\n+download_one \"$merge_repo/$merge_name\" \"$GIT_DIR/$destination\" || exit 1\n \n echo \"Getting object database\"\n-download_objects \"$merge_repo\" \"$(cat \"$GIT_DIR\"/FETCH_HEAD)\" || exit 1\n+download_objects \"$merge_repo\" \"$(cat \"$GIT_DIR/$destination\")\" || exit 1\n"},{"id":"5171","messageId":"42BA5EDF.3020804@pobox.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506222225010.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-23T07:03:59Z","receivedAt":"2005-06-23T07:03:59Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n> Pulling a regular head _cannot_ and _must_not_ update tags. Tags are not \n> associated with the tree, and they _cannot_ and _must_not_ be so, exactly \n\nFor general git implementation, strongly agreed.\n\n\n> And not making them separate breaks a lot of things. As mentioned, it\n> fundamentally breaks the distributed nature, but that also means that it\n> breaks whenever two people use the same name for a tag, for example. You\n> can't \"merge\" tags. BK had a very strange form of merging, which was (I\n> think) to pick the one last in the BK ChangeSet file, but that didn't make\n> it \"right\". You just never noticed, because Linux could never use tags at\n> all due to the lack of privacy, except for big releases..\n\nAgreed.\n\n\n> How is this AT ALL different from just having a separate script that does\n> this? You've introduced nothing but syntactic fluff, and you've made it\n> less flexible at the same time. First off, you might want to get new tags\n> _without_ fetching anything else, and you might indeed want to get the \n> tags _first_ in order to decide what you want to fetch.\n\nThat's a fair point. A separate script would be better.\n\n\n> because that would make them global instead of private, and it would \n> fundamentally make them not be distributed, and would mean that they'd be \n> pointless as anything but \"Linus' official tags\".\n[...]\n> the fact that tags _should_ be normal every-day things that you just use\n> as \"book-marks\", and that the kind of big \"synchronization point for many\n> people\" tag should actually be the _rare_ case.\n\nFor my use, I require all \"Linus official tags\" to be present in all my \nkernel trees, precisely because it is a big sync point for many people.\n\nUser A sends me a patch against 2.6.12-rc2, user B sends me a patch \nagainst 2.6.12-rc3, user C sends me a patch against 2.6.12... I create \na branch with\n\tcp .git/refs/tags/$kversion .git/refs/heads/foo-net-drvr\n\tgit checkout -f foo-net-drvr\napply the patch, then pull linux-2.6.git to merge up to the latest version.\n\nSo in my case, the rare case is the 99% common case :)\n\nI suppose this usage is just highly specific to me.\n\n\tJeff\n\n\n"},{"id":"5169","messageId":"42BA5F6F.9090406@pobox.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506221850030.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-23T07:06:23Z","receivedAt":"2005-06-23T07:06:23Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n> (Of course, since the rsync protocol doesn't know anything about git\n> consistency, if the mirroring is half-way, you'll end up with something\n> less than wonderful, and confusing. Details, details)\n\nWould it make sense to add an fsck step to git-clone-script?\n\n\tJeff\n\n\n"},{"id":"5173","messageId":"20050623071133.GA12304@kroah.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506222338290.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2005-06-23T07:11:33Z","receivedAt":"2005-06-23T07:11:33Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Wed, Jun 22, 2005 at 11:51:40PM -0700, Linus Torvalds wrote:\n> \n> \n> On Wed, 22 Jun 2005, Greg KH wrote:\n> > \n> > Hm, that doesn't work right now.\n> \n> Yeah, my suggested mod sucks.\n> \n> Try the following slightly modified version instead, with\n> \n> \tgit fetch rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git tag v2.6.12.1\n> \n> and now it should work.\n\nYes, that patch works for me.\n\nthanks,\n\ngreg k-h\n"},{"id":"5172","messageId":"42BA6177.8060202@pobox.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506221915280.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-23T07:15:03Z","receivedAt":"2005-06-23T07:15:03Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n> How about this patch? Then you can say\n> \n> \tgit-apply --stat --summary --apply --index /tmp/my.patch\n> \n> and it will not only apply the patch, but also give a diffstat and a\n> summary or renames etc..\n\nQuite nice.\n\n\n\n>>I usually want just two things:\n>>\n>>1) browse the log\n>>\n>>2) list changes in local tree that are not in $remote_tree, a la\n>>\tbk changes -L ../linux-2.6\n>>\n>>I agree that seeing the merge csets is useful, that is why [being \n>>ignorant of 'git log'] I used git-changes-script.\n> \n> \n> For (1) \"bk log\" is good.\n\nChuckle. What does one call a Freudian slip, in computer-land?\n\n\n> For (2) you'll have to use your own script, or\n> just have the remote tree as a branch in the same tree, in which case you\n> can do\n> \n> \tgit log remotebranch..mybranch\n\nVery neat. That makes some things a bit easier, since I usually carry a \n'vanilla' branch as .git/refs/heads/master, and do all my modifications \non other branches.\n\nFWIW, git-changes-script (attached) facilitates #2 for me right now. I \nuse it just like BK's '-L' feature:\n\n\tcd netdev-2.6\n\tgit checkout -f ieee80211\n\tgit-changes-script -L ../linux-2.6 | less\n\nThat will produce the same output as the feature you just taught me,\n\n\tgit log master..ieee80211\n\nWARNING: You have previously called git-changes-script quite ugly (not \nsurprising), and this 'git log x..y' will probably replace it in my \nusage, long term.\n\n\tJeff\n\n\n\n\n#!/bin/bash\n#\n# Make a log of changes in a GIT branch.\n#\n# This script was originally written by (c) Ross Vandegrift.\n# Adapted to his scripts set by (c) Petr Baudis, 2005.\n# Major optimizations by (c) Phillip Lougher.\n# Rendered trivial by Linus Torvalds.\n# Added -L|-R option by James Bottomley\n#\n# options:\n# script [-L | -R |-r [ -r ]\n#\n# With no options shows all the revisions from HEAD to the root\n# -L shows all the changes in the local tree compared to the tree at \n# -R shows all the changes in the remote tree at compared to the local\n# -r shows all the changes in one commit or between two\n\ntmpfile=/tmp/git_changes.$$\nr1=\nr2=\n\nshowcommit() {\n\tcommit=\"$1\"\n\techo commit ${commit%:*};\n\tgit-cat-file commit $commit | \\\n\t\twhile read key rest; do\n\t\t\tcase \"$key\" in\n\t\t\t\"author\"|\"committer\")\n\t\t\t\tdate=(${rest#*> })\n\t\t\t\tsec=${date[0]}; tz=${date[1]}\n\t\t\t\tdtz=${tz/+/+ }; dtz=${dtz/-/- }\n\t\t\t\tpdate=\"$(date -Rud \"1970-01-01 UTC + $sec sec $dtz\" 2>/dev/null)\"\n\t\t\t\tif [ \"$pdate\" ]; then\n\t\t\t\t\techo $key $rest | sed \"s/>.*/> ${pdate/+0000/$tz}/\"\n\t\t\t\telse\n\t\t\t\t\techo $key $rest\n\t\t\t\tfi\n\t\t\t\t;;\n\t\t\t\"\")\n\t\t\t\techo; cat\n\t\t\t\t;;\n\t\t\t*)\n\t\t\t\techo $key $rest\n\t\t\t\t;;\n\t\t\tesac\n\n\t\tdone\n}\n\nwhile true; do\n\tcase \"$1\" in\n\t\t-R)\tshift;\n\t\t\tdiffsearch=+\n\t\t\tremote=\"$1\"\n\t\t\tshift;;\n\t\t-L)\tshift;\n\t\t\tdiffsearch=-\n\t\t\tremote=\"$1\"\n\t\t\tshift;;\n\t\t-r)\tshift;\n\t\t\tif [ -z \"$r1\" ]; then\n\t\t\t\tr1=\"$1\"\n\t\t\telse\n\t\t\t\tr2=\"$1\"\n\t\t\tfi\n\t\t\tshift;;\n\t\t*)\tbase=\"$1\"\n\t\t\tbreak;;\n\tesac\ndone\n\nif [ -n \"$r1\" ]; then\n\tif [ -z \"$r2\" ]; then\n\t\tshowcommit $r1\n\t\texit 0\n\tfi\n\tdiffsearch=+\n\tremote=`pwd`;\n\ttobase=\"$r2\";\n\tbase=\"$r1\"\nfi\n\t\nif [ -z \"$base\" ]; then\n\tbase=$(cat .git/HEAD) || exit 1\nfi\n\ngit-rev-tree $base | sort -rn > ${tmpfile}.base\nif [ -n \"$remote\" ]; then\n\t[ -d $remote/.git ] || exit 1\n\tif [ -z \"$tobase\" ]; then\n\t\ttobase=$(cat $remote/.git/HEAD) || exit 1\n\tfi\n\tpushd $remote > /dev/null\n\tgit-rev-tree $tobase | sort -rn > ${tmpfile}.remote\n\tdiff -u ${tmpfile}.base ${tmpfile}.remote | grep \"^${diffsearch}[^${diffsearch}]\" | cut -c 1- > ${tmpfile}.diff\n\trm -f ${tmpfile}.base ${tmpfile}.remote\n\tmv ${tmpfile}.diff ${tmpfile}.base\n\tif [ $diffsearch = \"-\" ]; then\n\t\tpopd > /dev/null\n\tfi\nfi\n\n[ -s \"${tmpfile}.base\" ] || exit 0\n\ncat ${tmpfile}.base | while read time commit parents; do\n\tshowcommit $commit\n\techo -e \"\\n--------------------------\"\n\ndone\nrm -f ${tmpfile}.base\n"},{"id":"5175","messageId":"20050623073845.GA5204@pasky.ji.cz","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506222225010.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-06-23T07:38:45Z","receivedAt":"2005-06-23T07:38:45Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Jun 23, 2005 at 07:58:13AM CEST, I got a letter\nwhere Linus Torvalds told me that...\n> Does it help when I scream?\n\nNope. I still think you are wrong. :-) (BTW, Cogito always fetches all\nthe tags now - but it's not that I would have a huge problem with\nchanging that to some better behaviour.)\n\n> > Multiple users -- not just me -- would prefer that git-pull-script \n> > pulled the tags, too.\n> \n> And multiple users -- clearly including you -- aren't listening to me. \n> Tags are separate from the source they tag, and they HAVE TO BE. There is \n> no \"you automatically get the tags when you get the tree\", because the two \n> don't have a 1:1 relationship.\n> \n> And not making them separate breaks a lot of things. As mentioned, it\n> fundamentally breaks the distributed nature, but that also means that it\n> breaks whenever two people use the same name for a tag, for example. You\n> can't \"merge\" tags. BK had a very strange form of merging, which was (I\n> think) to pick the one last in the BK ChangeSet file, but that didn't make\n> it \"right\". You just never noticed, because Linux could never use tags at\n> all due to the lack of privacy, except for big releases..\n\nI think there should simply be two namespaces - public tags and private\ntags. Private tags for stuff like \"broken\", \"merged\", or \"funnychange\".\nOther people don't care about those, and they certainly shouldn't get\nthem by default (but they should have a way to get them explicitly, if\nyou tell them). But then there are the official tags, like \"v2.6.13\" or\neven \"v2.6.12-ck2\" - if you merge with those branches, you should always\nget those precisely for what Jeff says - they are big syncing points for\na lot of people and you should be always able to refer to v2.6.13 if you\nhave the commit in your tree.\n\nSince there should be _few_ of those tags, you might even want to get\ntags only from branches marked \"tagtrusted\" (Cogito's origin branch\nwould be by default), or want to interactively confirm new tag additions\nduring a pull. Also, ideally there would be no or only extremely rare\ntag conflicts.\n\nI think it would be simplest to use a special prefix for the private\ntags. ~ and ! might get touched by shell, so what about %?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5176","messageId":"Pine.LNX.4.60.0506230900140.7099@hermes-1.csi.cam.ac.uk","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506221603120.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Anton Altaparmakov","fromEmail":"aia21@cam.ac.uk","sentAt":"2005-06-23T08:01:41Z","receivedAt":"2005-06-23T08:01:41Z","isPatch":false,"sender":{"key":"aia21@cam.ac.uk","avatar":null},"body":"On Wed, 22 Jun 2005, Linus Torvalds wrote:\n> On Wed, 22 Jun 2005, Jeff Garzik wrote:\n> > 2) download a linux kernel tree for the very first time\n> > \n> > $ mkdir -p linux-2.6/.git\n> > $ cd linux-2.6\n> > $ rsync -a --delete --verbose --stats --progress \\\n> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \n> > \\ <- word-wrapped backslash; sigh\n> > .git/\n> \n> Gaah. I should do a \"git-clone-script\" or something that does this, and \n> then you could just do\n> \n> \tgit clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6\n> \t\n> Anybody?\n\nWhat's wrong with Pasky's cogito scripts? There is a cg-pull as well as a \ncg-clone in there already. If nothing else you could just copy the \nrelevant scripts and rename them to git-blah...\n\nBest regards,\n\n\tAnton\n-- \nAnton Altaparmakov (replace at with @)\nUnix Support, Computing Service, University of Cambridge, CB2 3QH, UK\nLinux NTFS maintainer / IRC: #ntfs on irc.freenode.net\nWWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/\n"},{"id":"5180","messageId":"46a038f9050623011838d6b85f@mail.gmail.com","threadId":"1008","inReplyTo":"20050623073845.GA5204@pasky.ji.cz","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-06-23T08:18:22Z","receivedAt":"2005-06-23T08:18:22Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/23/05, Petr Baudis wrote:\n> I think there should simply be two namespaces - public tags and private\n> tags. Private tags for stuff like \"broken\", \"merged\", or \"funnychange\".\n\nI guess that public tags would also probably be in a different\nlocation from the actual tree. With the split Linus advocates, several\npeople could be publishing sets of \"public\" tags, as well as having\nthe official tags hosted separately from the .git repo.\n\ncheers,\n\n\nmartin\n"},{"id":"5178","messageId":"20050623083025.GA5066@ucw.cz","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506222225010.11175@ppc970.osdl.org","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Vojtech Pavlik","fromEmail":"vojtech@suse.cz","sentAt":"2005-06-23T08:30:25Z","receivedAt":"2005-06-23T08:30:25Z","isPatch":false,"sender":{"key":"vojtech@suse.cz","avatar":null},"body":"On Wed, Jun 22, 2005 at 10:58:13PM -0700, Linus Torvalds wrote:\n\n> And thinking that \"fetching a tree fetches all the tags from that tree\" \n> really _is_ a stupid decision. It's missing the big picture. It's missing\n> the fact that tags _should_ be normal every-day things that you just use\n> as \"book-marks\", and that the kind of big \"synchronization point for many\n> people\" tag should actually be the _rare_ case.\n> \n> The fact that global tags make that private \"bookmark\" usage impossible\n> should be a big red blinking sign saying \"don't do global tags\".\n\nMaybe it'd make sense to differentiate between the two types of tags?\nTo have local tags which don't propagate, and global (version) tags\nwhich do? They could live in different namespaces and thus wouldn't\ninterfere.\n\n-- \nVojtech Pavlik\nSuSE Labs, SuSE CR\n"},{"id":"5183","messageId":"21d7e99705062305255b1ec58e@mail.gmail.com","threadId":"1008","inReplyTo":"42B9E536.60704@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Dave Airlie","fromEmail":"airlied@gmail.com","sentAt":"2005-06-23T12:25:43Z","receivedAt":"2005-06-23T12:25:43Z","isPatch":false,"sender":{"key":"airlied@gmail.com","avatar":"https://gravatar.com/avatar/8ed1990dd745eed102534e9b1629e8f7adb5ae47b01640093ca24a9b2174bb02?d=mp&s=160"},"body":"> jgarzik helper scripts, not in official git distribution:\n> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch\n> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script\n> \n\nDo you have some sort of magic bk-make-sum type util at all... \n\nFor sending trees to Linus I used to run bk-make-sum and gcapatch and\nthen just throw my own stuff in the top of the mail ....\n\nI'm being lazy I probably could write it myself, but bk-make-sum was a\nvery useful script for me...\n\nDave.\n"},{"id":"5185","messageId":"Pine.LNX.4.58.0506230822370.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"42BA5F6F.9090406@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T15:29:07Z","receivedAt":"2005-06-23T15:29:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Jun 2005, Jeff Garzik wrote:\n>\n> Linus Torvalds wrote:\n> > (Of course, since the rsync protocol doesn't know anything about git\n> > consistency, if the mirroring is half-way, you'll end up with something\n> > less than wonderful, and confusing. Details, details)\n> \n> Would it make sense to add an fsck step to git-clone-script?\n\nWell, it's going to be slow. Of course, it's not as slow as pulling the \nstuff over a DSL line or whatever, but still..\n\nI think I need to make something that just verifies the top commits or\nwhatever - I need that for \"pull\" anyway, so that you can do a \n\n\tgit fsck ORIG_HEAD..\n\nand it will fsck only the new stuff that arrived as a result of the pull.\n\nAnd we need to improve the git-ssh-pull/git-http-pull scripts so that they\ndo pipelined requests: right now it's usually a lot faster to do \"rsync\" \nthan it is to do git-ssh-pull (unless you do a small pull), because even\nthough the rsync ends up needing to compare the full directory contents,\nit then transfers the data much faster.\n\n\t\tLinus\n"},{"id":"5186","messageId":"Pine.LNX.4.58.0506230833170.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"42BA6177.8060202@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T16:06:21Z","receivedAt":"2005-06-23T16:06:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Jun 2005, Jeff Garzik wrote:\n> \n> Chuckle. What does one call a Freudian slip, in computer-land?\n\nA \"Knuthian slip\"?\n\n> WARNING: You have previously called git-changes-script quite ugly (not \n> surprising), and this 'git log x..y' will probably replace it in my \n> usage, long term.\n\nEven short-term, you could actually make it prettier. \n\nYou can actually use git across multiple directories by setting the\nGIT_ALTERNATE_OBJECT_DIRECTORIES environment variable to point to the\nalternate ones, so you should be able to do a \"compare with remote\" with \nsomething like this:\n\n\texport GIT_ALTERNATE_OBJECT_DIRECTORIES=$remote/.git/objects\n\tremote_head=$(cat $remote/.git/HEAD)\n\tgit log $remote_head..\n\nwhich should literally give a nice log of what is in your HEAD but not in \n$remote_head. And if you want to see it the other way? Just change the \nlast line to\n\n\tgit log HEAD..$remote_head\n\nand voila, you're done.\n\nThe nice thing about this approach is that this works with other git\nprograms too, ie you can replace \"git log\" with \"gitk\", and suddenly you\nsee graphically the commits that are in your tree but not in the remote\nHEAD or vice versa.\n\nYeah, yeah, totally untested and maybe I'm talking through by *ss, but it \nshould work in theory.\n\n\t\tLinus\n"},{"id":"5203","messageId":"20050623235634.GC14426@waste.org","threadId":"1008","inReplyTo":"42B9E536.60704@pobox.com","subject":"Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Matt Mackall","fromEmail":"mpm@selenic.com","sentAt":"2005-06-23T23:56:34Z","receivedAt":"2005-06-23T23:56:34Z","isPatch":false,"sender":{"key":"mpm@selenic.com","avatar":null},"body":"On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:\n> \n> Things in git-land are moving at lightning speed, and usability has \n> improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11\n\nAnd here's a quick comparison with the current state of Mercurial..\n\n> 1) installing git\n> \n> git requires bootstrapping, since you must have git installed in order \n> to check out git.git (git repo), and linux-2.6.git (kernel repo). I \n> have put together a bootstrap tarball of today's git repository.\n> \n> Download tarball from:\n> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2\n> \n> tarball build-deps: zlib, libcurl, libcrypto (openssl)\n> \n> install tarball: unpack && make && sudo make prefix=/usr/local install\n> \n> jgarzik helper scripts, not in official git distribution:\n> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch\n> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script\n> \n> After reading the rest of this document, come back and update your copy \n> of git to the latest:\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git\n\nDownload from: http://selenic.com/mercurial/mercurial-snapshot.tar.gz\nBuild-deps: Python 2.3\nInstall: unpack && python setup.py install [--home=/usr/local]\n\n> 2) download a linux kernel tree for the very first time\n> \n> $ mkdir -p linux-2.6/.git\n> $ cd linux-2.6\n> $ rsync -a --delete --verbose --stats --progress \\\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \n> \\ <- word-wrapped backslash; sigh\n> .git/\n\n$ mkdir linux-2.6\n$ cd linux-2.6\n$ hg init http://www.kernel.org/hg/ # obviously you can also browse this\n\nThis downloads about 125M of data, which include the whole kernel history\nback to 2.4.0 and everything in Linus' git repo as well.\n\n> 3) update local kernel tree to latest 2.6.x upstream (\"fast-forward merge\")\n> \n> $ cd linux-2.6\n> $ git-pull-script \\\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n\n$ hg pull # defaults to where you originally pulled from\n\nIt takes about 4M of transfer and well under a minute to pull the\nentire git history, starting from a base of 2.6.12-rc2.\n\n> 4) check out files from the git repository into the working directory\n> \n> $ git checkout -f\n\n$ hg update # or up or checkout or co, depending on your SCM habits\n\n> 5) check in your own modifications (e.g. do some hacking, or apply a patch)\n> \n> # go to repo\n> $ cd linux-2.6\n> \n> # make some modifications\n> $ patch -sp1 < /tmp/my.patch\n> $ diffstat -p1 < /tmp/my.patch\n> \n> # NOTE: add '--add' and/or '--remove' if files were added or removed\n> $ git-update-cache \n> \n> # check in changes\n> $ git commit\n\n$ hg commit [files] # check in everything changed or just the named files\n\n5.1) undo the last commit or pull\n\n$ hg undo\n\n> 6) List all changes in working dir, in diff format.\n> \n> $ git-diff-cache -p HEAD\n\n$ hg status # show changed files\n\n> 7) List all changesets (i.e. show each cset's description text) in local \n> branch of local tree, that are not present in remote tree.\n> \n> $ cd my-kernel-tree-2.6\n> $ git-changes-script -L ../linux-2.6 | less\n\n$ hg history | less # How does git know what's not in the\n # remote tree? Psychic?\n\n> 8) List all changesets:\n> \n> $ git-whatchanged\n\n$ hg history | less\n\n> 9) apply all patches in a Berkeley mbox-format file\n> \n> First, download and add to your PATH Linus's git tools:\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git\n> \n> $ cd my-kernel-tree-2.6\n> $ dotest /path/to/mbox # yes, Linus has no taste in naming scripts\n\nhg doesn't do mboxes directly, but you can do:\n\n$ cat patch-list | xargs hg import\n\n> 10) don't forget to download tags from time to time.\n> \n> git-pull-script only downloads sha1-indexed object data, and the \n> requested remote head. This misses updates to the .git/refs/tags/ and \n> .git/refs/heads directories. It is advisable to update your kernel .git \n> directories periodically with a full rsync command, to make sure you got \n> everything:\n>\n> $ cd linux-2.6\n> $ rsync -a --delete --verbose --stats --progress \\\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/\n> \\ <- word-wrapped backslash; sigh\n> .git/\n\nTags in mercurial are properly version controlled and come along for\nthe ride with pulls. Also, the right thing happens with merges.\n \n> 11) list all branches, such as those found in my netdev-2.6 or \n> libata-dev trees.\n> \n> Download\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git\n> \tor\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git\n> \n> \n> $ cd netdev-2.6\n> $ ls .git/refs/heads/\n> \n> { these are the current netdev-2.6 branches }\n> >8139cp forcedeth master qeth smc91x we18\n> >8139too-iomap for-linus natsemi r8169 smc91x-eeprom wifi\n> >airo hdlc ns83820 register-netdev starfire\n> >atmel ieee80211 orinoco remove-drivers tlan\n> >chelsio iff-running orinoco-hch sis900 veth\n> >dm9000 janitor ppp skge viro\n\n$ hg heads # Has Andrew mentioned your git forest gives him a headache?\n\n> 12) make desired branch current in working directory\n> \n> $ git checkout -f $branch\n\n$ hg update -C \n\n> 13) create a new branch, and make it current\n> \n> $ cp .git/refs/heads/master .git/refs/heads/my-new-branch-name\n> $ git checkout -f my-new-branch-name\n\nSince the hg repo is lightweight, this is usually done by just having\ndifferent directories. Thus we don't explicitly name branches.\n\n$ mkdir new-branch\n$ cd new-branch\n$ hg init -u ../linux # makes hardlinks and does a checkout\n\n> 14) examine which branch is current\n> \n> $ ls -l .git/HEAD\n\n$ echo $PWD\n\n> 15) undo all local modifications (same as checkout):\n> \n> $ git checkout -f\n\n$ hg update -C\n\n> 16) obtain a diff between current branch, and master branch\n> \n> In most trees WITH BRANCHES, .git/refs/heads/master contains the current \n> 'vanilla' upstream tree, for easy diffing and merging. (in trees \n> without branches, 'master' simply contains your latest changes)\n> \n> $ git-diff-tree -p master HEAD\n\n$ hg diff -r -r \n\n17) run a browsable, pullable repo server of the current repo on your\nlocal machine\n\n$ hg serve\n\n18) push your changes to a remote server\n\n$ hg push ssh://user@host/path/ # aliases and defaults in .hgrc\n\n19) get per-file history\n\n$ hg log | less\n\n20) get annotated file contents\n\n$ hg annotate [file]\n\n21) record that a file has been copied or renamed for the next commit\n\n$ hg copy \n\n22) get online help\n\n$ hg help [command]\n\n\nMore info at http://selenic.com/mercurial/\n\n-- \nMathematics is the supreme nostalgia of our time.\n"},{"id":"5206","messageId":"20050624064101.GB14292@pasky.ji.cz","threadId":"1008","inReplyTo":"20050623235634.GC14426@waste.org","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-06-24T06:41:01Z","receivedAt":"2005-06-24T06:41:01Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jun 24, 2005 at 01:56:34AM CEST, I got a letter\nwhere Matt Mackall told me that...\n> On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:\n> > \n> > Things in git-land are moving at lightning speed, and usability has \n> > improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11\n> \n> And here's a quick comparison with the current state of Mercurial..\n\nAnd here's a quick back-comparison with Cogito. ;-)\n\n> > 1) installing git\n> > \n> > git requires bootstrapping, since you must have git installed in order \n> > to check out git.git (git repo), and linux-2.6.git (kernel repo). I \n> > have put together a bootstrap tarball of today's git repository.\n> > \n> > Download tarball from:\n> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2\n> > \n> > tarball build-deps: zlib, libcurl, libcrypto (openssl)\n> > \n> > install tarball: unpack && make && sudo make prefix=/usr/local install\n> > \n> > jgarzik helper scripts, not in official git distribution:\n> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch\n> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script\n> > \n> > After reading the rest of this document, come back and update your copy \n> > of git to the latest:\n> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git\n> \n> Download from: http://selenic.com/mercurial/mercurial-snapshot.tar.gz\n> Build-deps: Python 2.3\n> Install: unpack && python setup.py install [--home=/usr/local]\n\nDownload from: http://www.kernel.org/pub/software/scm/cogito/\nDeps: git's + bash + reasonable shell environment\nInstall: edit Makefile, make + make install\n\n> > 2) download a linux kernel tree for the very first time\n> > \n> > $ mkdir -p linux-2.6/.git\n> > $ cd linux-2.6\n> > $ rsync -a --delete --verbose --stats --progress \\\n> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \n> > \\ <- word-wrapped backslash; sigh\n> > .git/\n> \n> $ mkdir linux-2.6\n> $ cd linux-2.6\n> $ hg init http://www.kernel.org/hg/ # obviously you can also browse this\n\n$ cg-clone \\\nrsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/\n\n(that will checkout to linux-2.6/ directory; you can specify the target\ndirectory as the optional second parameter)\n\n> > 3) update local kernel tree to latest 2.6.x upstream (\"fast-forward merge\")\n> > \n> > $ cd linux-2.6\n> > $ git-pull-script \\\n> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n> \n> $ hg pull # defaults to where you originally pulled from\n\n$ cg-update\t# defaults to where you originally pulled from\n\n(cg-pull just gets the changes to your repository, but won't merge them\ninto your branch)\n\n> > 4) check out files from the git repository into the working directory\n> > \n> > $ git checkout -f\n> \n> $ hg update # or up or checkout or co, depending on your SCM habits\n\nIn Cogito, all files are always checked out.\n\n> > 5) check in your own modifications (e.g. do some hacking, or apply a patch)\n> > \n> > # go to repo\n> > $ cd linux-2.6\n> > \n> > # make some modifications\n> > $ patch -sp1 < /tmp/my.patch\n> > $ diffstat -p1 < /tmp/my.patch\n> > \n> > # NOTE: add '--add' and/or '--remove' if files were added or removed\n> > $ git-update-cache \n> > \n> > # check in changes\n> > $ git commit\n> \n> $ hg commit [files] # check in everything changed or just the named files\n\n$ cg-commit [-m\"Message\"...] [files] # check in everything changed or just\n # the named files\n\nIf you pass multiple -m arguments, they get formatted as separate\nparagraphs in the log message. It is customary for the first -m argument\nto contain a short one-line summary.\n\nNote that you must add/remove files by\n\n$ cg-add files...\n\nand\n\n$ cg-rm files...\n\n> 5.1) undo the last commit or pull\n> \n> $ hg undo\n\n$ cg-admin-uncommit\n\nNote that you should never do this if you already pushed the changes\nout, or someone might get them. (That holds for regular Git too.) See\n\n$ cg-help cg-admin-uncommit # (or cg-admin-uncommit --help)\n\nfor details. (That's another Cogito's cool feature. Handy docs! ;-)\n\n> > 6) List all changes in working dir, in diff format.\n> > \n> > $ git-diff-cache -p HEAD\n> \n> $ hg status # show changed files\n\n$ cg-status\t\t# show changed files\n$ cg-diff [-c] [files]\t# show the diffs, -c colourfully\n\n> > 7) List all changesets (i.e. show each cset's description text) in local \n> > branch of local tree, that are not present in remote tree.\n> > \n> > $ cd my-kernel-tree-2.6\n> > $ git-changes-script -L ../linux-2.6 | less\n> \n> $ hg history | less # How does git know what's not in the\n> # remote tree? Psychic?\n\n# -c colourfully, -s prints only summaries, one line per changeset\n$ cg-log [-c] [-s] -m -r linux-2.6 # List changes only in linux-2.6\n\nNote that | less is unnecessary (even undesirable with -c).\n\n> > 8) List all changesets:\n> > \n> > $ git-whatchanged\n> \n> $ hg history | less\n\n$ cg-log [-c] [-s]\n\n8.1) List all changesets in the origin branch:\n\n$ cg-log [-c] [-s] -r origin\n\n8.2) List all changesets concerning files CREDITS and fs/inode.c:\n\n$ cg-log [-c] [-s] CREDITS fs/inode.c\n\n> > 9) apply all patches in a Berkeley mbox-format file\n> > \n> > First, download and add to your PATH Linus's git tools:\n> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git\n> > \n> > $ cd my-kernel-tree-2.6\n> > $ dotest /path/to/mbox # yes, Linus has no taste in naming scripts\n> \n> hg doesn't do mboxes directly, but you can do:\n> \n> $ cat patch-list | xargs hg import\n\nTheoretically, dotest should work just fine even if you use Cogito.\nAnyone tested it?\n\n> > 10) don't forget to download tags from time to time.\n> > \n> > git-pull-script only downloads sha1-indexed object data, and the \n> > requested remote head. This misses updates to the .git/refs/tags/ and \n> > .git/refs/heads directories. It is advisable to update your kernel .git \n> > directories periodically with a full rsync command, to make sure you got \n> > everything:\n> >\n> > $ cd linux-2.6\n> > $ rsync -a --delete --verbose --stats --progress \\\n> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/\n> > \\ <- word-wrapped backslash; sigh\n> > .git/\n> \n> Tags in mercurial are properly version controlled and come along for\n> the ride with pulls. Also, the right thing happens with merges.\n\ncg-update and cg-pull takes fetches new tags during a pull.\n\n> > 11) list all branches, such as those found in my netdev-2.6 or \n> > libata-dev trees.\n> > \n> > Download\n> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git\n> > \tor\n> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git\n> > \n> > \n> > $ cd netdev-2.6\n> > $ ls .git/refs/heads/\n> > \n> > { these are the current netdev-2.6 branches }\n> > >8139cp forcedeth master qeth smc91x we18\n> > >8139too-iomap for-linus natsemi r8169 smc91x-eeprom wifi\n> > >airo hdlc ns83820 register-netdev starfire\n> > >atmel ieee80211 orinoco remove-drivers tlan\n> > >chelsio iff-running orinoco-hch sis900 veth\n> > >dm9000 janitor ppp skge viro\n> \n> $ hg heads # Has Andrew mentioned your git forest gives him a headache?\n\n$ cg-branch-ls\n\n# Note that Cogito supports only remote branches properly now; that\n# will yet evolve (in some backwards-compatible way).\n\n> > 12) make desired branch current in working directory\n> > \n> > $ git checkout -f $branch\n> \n> $ hg update -C \n\nYou can check the desired branch out into another directory:\n\n$ cg-clone path/to/linux-2.6/.git#branch anotherdir\n\nSwitching branches in place will be supported soon (although I have\ndoubts about its usefulness).\n\n> > 13) create a new branch, and make it current\n> > \n> > $ cp .git/refs/heads/master .git/refs/heads/my-new-branch-name\n> > $ git checkout -f my-new-branch-name\n> \n> Since the hg repo is lightweight, this is usually done by just having\n> different directories. Thus we don't explicitly name branches.\n> \n> $ mkdir new-branch\n> $ cd new-branch\n> $ hg init -u ../linux # makes hardlinks and does a checkout\n\n$ mkdir new-branch\n$ cd new-branch\n$ cg-clone -s ../linux-2.6\n\n(Note that cg-clone given local path will do hardlinks too.)\n\nWe don't explicitly name branches either. You can make the branch\nvisible from the other tree by\n\n$ cg-branch-add new-branch ../new-branch\n\nand then refer to it as new-branch.\n\n> > 14) examine which branch is current\n> > \n> > $ ls -l .git/HEAD\n> \n> $ echo $PWD\n\nAlways the \"master\" branch.\n\n> > 15) undo all local modifications (same as checkout):\n> > \n> > $ git checkout -f\n> \n> $ hg update -C\n\n$ cg-cancel\n\n> > 16) obtain a diff between current branch, and master branch\n> > \n> > In most trees WITH BRANCHES, .git/refs/heads/master contains the current \n> > 'vanilla' upstream tree, for easy diffing and merging. (in trees \n> > without branches, 'master' simply contains your latest changes)\n> > \n> > $ git-diff-tree -p master HEAD\n> \n> $ hg diff -r -r \n\n$ cg-diff -r -r \n\n> 17) run a browsable, pullable repo server of the current repo on your\n> local machine\n> \n> $ hg serve\n\nMake it accessible over HTTP, SSH, rsync, or for the local users if you\njust want them to access it.\n\n> 18) push your changes to a remote server\n> \n> $ hg push ssh://user@host/path/ # aliases and defaults in .hgrc\n\nWill be supported Real Soon (tm) (well, probably sometimes next week).\n\n> 19) get per-file history\n> \n> $ hg log | less\n\n$ cg-log [-c] [-s] \n\n> 20) get annotated file contents\n> \n> $ hg annotate [file]\n\nPlanned.\n\n> 22) get online help\n> \n> $ hg help [command]\n\n$ cg-help [command]\n\nCool. Except where the concepts are just different, Cogito mostly\nappears at least equally simple to use as Mercurial. Yes, some features\nare missing yet. I hope to fix that soon. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5224","messageId":"20050624121925.GB9519@64m.dyndns.org","threadId":"1008","inReplyTo":"4d8e3fd3050624064620a4945e@mail.gmail.com","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Christopher Li","fromEmail":"hg@chrisli.org","sentAt":"2005-06-24T12:19:25Z","receivedAt":"2005-06-24T12:19:25Z","isPatch":false,"sender":{"key":"hg@chrisli.org","avatar":null},"body":"\nOn Fri, Jun 24, 2005 at 03:46:21PM +0200, Paolo Ciarrocchi wrote:\n> > \n> > Which do you think is going to be faster to operate from a cold start\n> > using 4200 rpm laptop drives? :-)\n> > \n> > - Ted\n> \n> That's quite intersting, what the rational behind such a difference in\n> terms of disk occupation ?\n>\n\nLet me see. Mercurial using delta or full storage for the repository.\nIt insert a full node when it detect that delta it need to reach\ncertain node is too big. It just like MPEG movies, most of the frame\nis delta to the previous frame. Once a while you have full frame to\nallow you seek to.\n\nBut git has delta as well right? Another factor is that all file has\nsame path in mercurial using the same storage file. So in mercurial\nit has far less file to store in the repository. Each file has two repository\nfiles, the data storage file and the index file. Remember that file system\nlike ext3 is using blocks, if you store very small stuff on a file, it is\nstill going to take at least one block on disk. So that will defeat the delta\ncompression if the delta is always on a new file.\n\n\nChris\n\n"},{"id":"5225","messageId":"20050624123819.GD9519@64m.dyndns.org","threadId":"1008","inReplyTo":"20050624064101.GB14292@pasky.ji.cz","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Christopher Li","fromEmail":"hg@chrisli.org","sentAt":"2005-06-24T12:38:19Z","receivedAt":"2005-06-24T12:38:19Z","isPatch":false,"sender":{"key":"hg@chrisli.org","avatar":null},"body":"On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:\n> > 5.1) undo the last commit or pull\n> > \n> > $ hg undo\n> \n> $ cg-admin-uncommit\n> \n> Note that you should never do this if you already pushed the changes\n> out, or someone might get them. (That holds for regular Git too.) See\n> \n> $ cg-help cg-admin-uncommit # (or cg-admin-uncommit --help)\n> \n> for details. (That's another Cogito's cool feature. Handy docs! ;-)\n> \n\nDoes it still works if the last commit was interrupted or due to error for some\nreason? Undo pull is pretty cool because you might pull a lot of commit\nin one blow. Get rid of commit one by one is going to be painful. Some times\nthe object you pull has more than one chain of history it will be very nasty\nif you want to clean it up.\n\nMercurial's undo is taking a snapshot of all the changed file's repo file length\nat every commit or pull. It just truncate the file to original size and undo \nis done.\n\nChris\n\n"},{"id":"5218","messageId":"20050624130604.GK17715@g5.random","threadId":"1008","inReplyTo":"20050624064101.GB14292@pasky.ji.cz","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Andrea Arcangeli","fromEmail":"andrea@suse.de","sentAt":"2005-06-24T13:06:04Z","receivedAt":"2005-06-24T13:06:04Z","isPatch":false,"sender":{"key":"andrea@suse.de","avatar":null},"body":"On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:\n> Cool. Except where the concepts are just different, Cogito mostly\n> appears at least equally simple to use as Mercurial. Yes, some features\n> are missing yet. I hope to fix that soon. :-)\n\nThe user interface and network protocol isn't the big deal, the big deal\nis the more efficient on-disk storage format IMHO.\n"},{"id":"5219","messageId":"pan.2005.06.24.13.16.10.406827@smurf.noris.de","threadId":"1008","inReplyTo":"20050624064101.GB14292@pasky.ji.cz","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-06-24T13:16:13Z","receivedAt":"2005-06-24T13:16:13Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Petr Baudis wrote:\n\n> Switching branches in place will be supported soon (although I have\n> doubts about its usefulness).\n\nWell, I don't. Main reason: It's simply a lot faster to create+switch to a\nbranch locally for doing independent work, than to hardlink the whole\nLinux directory tree into a clone tree.\n\nHaving one tree also simpifies the \"what do I have that's not merged yet\"\nquestion -- just call \"gitk $(cat .git/refs/heads/*)\". ;-)\n\nThe only problem I have with it is that \"git-read-tree -m -u\"\ndoesn't delete files yet. To repeat my question from last week:\n>> Would it be safe to add all files for which\n>> read_tree.c:merge_cache:fn() returns zero to a \"delete me\" list?\n(files on which which then actually get deleted, of course, if g-r-t\ndoesn't find any problems.)\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nPolitics -- the gentle art of getting votes from the poor and campaign\nfunds from the rich by promising to protect each from the other.\n\t\t-- Oscar Ameringer\n\n\n"},{"id":"5220","messageId":"20050624133952.GB7445@thunk.org","threadId":"1008","inReplyTo":"20050624130604.GK17715@g5.random","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2005-06-24T13:39:52Z","receivedAt":"2005-06-24T13:39:52Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Jun 24, 2005 at 03:06:04PM +0200, Andrea Arcangeli wrote:\n> On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:\n> > Cool. Except where the concepts are just different, Cogito mostly\n> > appears at least equally simple to use as Mercurial. Yes, some features\n> > are missing yet. I hope to fix that soon. :-)\n> \n> The user interface and network protocol isn't the big deal, the big deal\n> is the more efficient on-disk storage format IMHO.\n\nE2fsprogs with the full revision history imported into git is 100\nmegs, and that's with deltas. E2fsprogs imported into Mercurial is 17\nmegs (and actually, the imported repository was just a tad bit smaller\nthan e2fsprogs' BK repository).\n\nWhich do you think is going to be faster to operate from a cold start\nusing 4200 rpm laptop drives? :-)\n\n\t\t\t\t\t\t- Ted\n"},{"id":"5222","messageId":"4d8e3fd3050624064620a4945e@mail.gmail.com","threadId":"1008","inReplyTo":"20050624133952.GB7445@thunk.org","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2005-06-24T13:46:21Z","receivedAt":"2005-06-24T13:46:21Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"2005/6/24, Theodore Ts'o :\n> On Fri, Jun 24, 2005 at 03:06:04PM +0200, Andrea Arcangeli wrote:\n> > On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:\n> > > Cool. Except where the concepts are just different, Cogito mostly\n> > > appears at least equally simple to use as Mercurial. Yes, some features\n> > > are missing yet. I hope to fix that soon. :-)\n> >\n> > The user interface and network protocol isn't the big deal, the big deal\n> > is the more efficient on-disk storage format IMHO.\n> \n> E2fsprogs with the full revision history imported into git is 100\n> megs, and that's with deltas. E2fsprogs imported into Mercurial is 17\n> megs (and actually, the imported repository was just a tad bit smaller\n> than e2fsprogs' BK repository).\n> \n> Which do you think is going to be faster to operate from a cold start\n> using 4200 rpm laptop drives? :-)\n> \n> - Ted\n\nThat's quite intersting, what the rational behind such a difference in\nterms of disk occupation ?\n\n-- \nPaolo\n"},{"id":"5223","messageId":"42BC112C.1040009@qualitycode.com","threadId":"1008","inReplyTo":"20050624130604.GK17715@g5.random","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Kevin Smith","fromEmail":"yarcs@qualitycode.com","sentAt":"2005-06-24T13:57:00Z","receivedAt":"2005-06-24T13:57:00Z","isPatch":false,"sender":{"key":"yarcs@qualitycode.com","avatar":null},"body":"Andrea Arcangeli wrote:\n > On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:\n >\n >>Cool. Except where the concepts are just different, Cogito mostly\n >>appears at least equally simple to use as Mercurial. Yes, some\n >>features are missing yet. I hope to fix that soon. :-)\n >\n >\n > The user interface and network protocol isn't the big deal, the\n > big deal is the more efficient on-disk storage format IMHO.\n\nFor me, efficient storage is not very important, because I mostly deal \nwith small projects. Likewise, speed isn't a factor for me, since both \ntools are plenty fast on small repos.\n\nFor me, the big advantage of mercurial is that it is written in python, \ninstead of shell scripts. I know for some people that's a DISadvantage, \nbut I see the following benefits as a result:\n\n- Can run on (native) MS Windows\n (necessary for me because I often work on cross-platform projects)\n- Python code can be more clear and expressive (IMHO)\n\nIn the long run, I think the python code base will be easier to maintain \nand enhance. A rewrite of cogito in python or ruby would be cool.\n\nOne advantage that cogito has is that git viewing/browsing tools can \noperate directly on cogito repos. But a psychological drawback is the \nongoing confusion between git and cogito. Questions: Would a git-based \ntool that writes to the repo (such as StGIT) mess up a cogito repo? Can \nyou switch a repo between git and cogito or back, at any time?\n\nMercurial's tags use a radical approach, whereas cogito's are more \nconventional. I haven't yet used mercurial's versioned-tags enough yet \nto judge whether they are better, worse, or just different.\n\nI am impressed with the vibrancy of the development communities of both \nprojects. Both are able to serve repos on a plain http server. Both are \neasy to use and have decent basic feature sets. Both projects are \ndeveloping test suites.\n\nMostly, I'm thrilled with this new wave of lightweight distributed SCM \nsystems. Most of the established tools tended to be too heavy on \nfeatures and complexity, and have taken a long time to develop. I love \nthat a single developer or small team can now create a simple but usable \ndistributed SCM in a couple months.\n\nKevin\n"},{"id":"5234","messageId":"20050624180307.GS27572@waste.org","threadId":"1008","inReplyTo":"42BC112C.1040009@qualitycode.com","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Matt Mackall","fromEmail":"mpm@selenic.com","sentAt":"2005-06-24T18:03:07Z","receivedAt":"2005-06-24T18:03:07Z","isPatch":false,"sender":{"key":"mpm@selenic.com","avatar":null},"body":"On Fri, Jun 24, 2005 at 09:57:00AM -0400, Kevin Smith wrote:\n> Mercurial's tags use a radical approach, whereas cogito's are more \n> conventional. I haven't yet used mercurial's versioned-tags enough yet \n> to judge whether they are better, worse, or just different.\n\nFYI, after reading Linus' rant about tags, I added a second kind of\ntags to Mercurial. So now it has both 'official' tags, which are\nproperly version controlled, and 'private' tags (like git's) as well.\n\nTo add a local tag, add a section like this to .hg/hgrc:\n\n[tags]\ntested = d6ac88a738c4b3afea56ff09e449b91d85abff68\n\n(This was a bit of a no-brainer, as it was two lines of code)\n-- \nMathematics is the supreme nostalgia of our time.\n"},{"id":"5235","messageId":"Pine.LNX.4.58.0506241153180.11175@ppc970.osdl.org","threadId":"1008","inReplyTo":"pan.2005.06.24.13.16.10.406827@smurf.noris.de","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-24T19:00:33Z","receivedAt":"2005-06-24T19:00:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 24 Jun 2005, Matthias Urlichs wrote:\n> \n> Well, I don't. Main reason: It's simply a lot faster to create+switch to a\n> branch locally for doing independent work, than to hardlink the whole\n> Linux directory tree into a clone tree.\n> \n> Having one tree also simpifies the \"what do I have that's not merged yet\"\n> question -- just call \"gitk $(cat .git/refs/heads/*)\". ;-)\n\nActually, I think that gets close to another real advantage of branches: \nthat is also what allows you to edit things that failed a merge.\n\nFor example, let's say that a merge fail. You've got the HEAD and the\nMERGE_HEAD, but a file type conflict (like a symlink that has turned into\na directory) or something like that means that you can't resolve them\nsanely at all.\n\nSo this is merge problem where you can't just do a three-way merge and fix \nup the result and commit: you have to fix things up before you can even \nreally do the merge. This is when switching to the MERGE_HEAD thing and \nfixing it up there, committing it, and then doing the merge with the \noriginal HEAD and the new MERGE_HEAD is really convenient.\n\n(No, the scripts don't help you in cases like this, and we don't do the\nMERGE_HEAD as a real branch right now, but the point is that we _can_, and\nthat this is more than an efficiency issue, it's a fundamental issue of\nworking with multiple end-points together. You _could_ clone the other \nhead into a totally new repository, fix it there, and then try the merge \nanew, but now you're working around a limitation, not just doing \nsomething slower).\n\nI still think you can go a bit too far on your branch usage (ie Jeff), but \nhey, what's the difference between three branches and fifty, really?\n\n(I'm kidding. The difference between three and fifty is how well you can \nkeep track of them in your head, but maybe Jeff just has a bigger head \nthan most people do. Jeff, do people go \"Boy, you've got a big head\" the \nfirst time they meet you?)\n\n\t\t\tLinus\n"},{"id":"5237","messageId":"20050624192547.GA6736@tuxdriver.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506241153180.11175@ppc970.osdl.org","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"John W. Linville","fromEmail":"linville@tuxdriver.com","sentAt":"2005-06-24T19:25:49Z","receivedAt":"2005-06-24T19:25:49Z","isPatch":false,"sender":{"key":"linville@tuxdriver.com","avatar":"https://gravatar.com/avatar/6d8306e6a14a7040d9197d96418fe97d4e6a76024ad7585f915c1170701aca01?d=mp&s=160"},"body":"On Fri, Jun 24, 2005 at 12:00:33PM -0700, Linus Torvalds wrote:\n\n> Jeff, do people go \"Boy, you've got a big head\" the \n> first time they meet you?)\n\nFWIW, Jeff _does_ have quite the melon riding around on his shoulders...\n-- \nJohn W. Linville\nlinville@tuxdriver.com\n"},{"id":"5238","messageId":"Pine.LNX.4.21.0506241659070.30848-100000@iabervon.org","threadId":"1008","inReplyTo":"pan.2005.06.24.13.16.10.406827@smurf.noris.de","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-24T21:11:02Z","receivedAt":"2005-06-24T21:11:02Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 24 Jun 2005, Matthias Urlichs wrote:\n\n> Hi, Petr Baudis wrote:\n> \n> > Switching branches in place will be supported soon (although I have\n> > doubts about its usefulness).\n> \n> Well, I don't. Main reason: It's simply a lot faster to create+switch to a\n> branch locally for doing independent work, than to hardlink the whole\n> Linux directory tree into a clone tree.\n\nThere's another option, which I may be the only person currently\nusing: have a repo (.git directory) not in a working directory, and have\nthe objects/ and refs/ subdirectories of the .git directories in your\nworking directories symlinked to those subdirectories of the repo. Then\nyou can have any number of functionally identical working directories,\neach of which is set to some branch. If you have a reasonably small number\nof branches at any time, they can each have a working directory switched\nto them. On the other hand, all of the branches are accessible from any of\nthem.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"5240","messageId":"7v1x6rbe6r.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1008","inReplyTo":"pan.2005.06.24.13.16.10.406827@smurf.noris.de","subject":"Should \"git-read-tree -m -u\" delete files?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-24T22:08:44Z","receivedAt":"2005-06-24T22:08:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"MU\" == Matthias Urlichs writes:\n\nMU> The only problem I have with it is that \"git-read-tree -m -u\"\nMU> doesn't delete files yet. To repeat my question from last week:\n>>> Would it be safe to add all files for which\n>>> read_tree.c:merge_cache:fn() returns zero to a \"delete me\" list?\nMU> (files on which which then actually get deleted, of course, if g-r-t\nMU> doesn't find any problems.)\n\nAs the guilty party for the \"read-tree two-way semantics table\"\nyou quoted in your \"question from last week\" message, I should\nhave replied sooner but could not. Sorry about that [*1*].\n\nAnyway, here are my answers.\n\n (1) No, merge_function[] returning zero just means \"I did not\n cause anything to change the number of already processed\n entries\". When it wants to delete an entry, it explicitly\n marks the entry to be deleted by calling deleted_entry(),\n and the deletion is processed at the very end by\n check_updates() function. Note that we do _not_ return\n zero in this case.\n\n (2) The part you quoted in your \"last week\" message is case 10;\n the current code does delete the path with -u [*2*].\n\n (3) There could be cases where twoway_merge() does not delete a\n clean path that _should_ be removed. If that is the case\n then you have spotted a bug --- I would appreciate it if\n you can show a reproduction recipe. I have looked at the\n function briefly again while writing this reply and did not\n find suspicious code that would just return 0 without\n calling deleted_entry(), though.\n\n (4) Using --emu23 (followed by git-merge-cache, of course),\n instead of doing \"git-read-tree -m -u H M\", should remove\n deleted paths as well.\n\n\n[Footnote]\n\n*1* I was on a crazy travel schedule, going just for 3 days last\nweek and then for another 2 days this week to Japan from US west\ncoast, two 10-hour roundtrip flights X-<. Now I am back and\nhopefully fully functional ;-).\n\n*2* The part you quoted in your previous message was this. I am\nre-quoting from the original to give it a bit more context:\n\n Two Tree Merge\n ~~~~~~~~~~~~~~\n ...\n In this case, the \"git-read-tree -m $H $M\" command makes sure\n that no local change is lost as the result of this \"merge\".\n Here are the \"carry forward\" rules:\n\n I (index) H M Result\n -------------------------------------------------------\n ...\n clean I==H I==M\n ------------------\n ...\n 10 yes yes N/A exists nothing remove path from cache\n\nThis case is covered by this test in t1002:\n\n test_expect_success \\\n '10 - path removed.' \\\n 'rm -f .git/index &&\n echo rezrov >rezrov &&\n git-update-cache --add rezrov &&\n git-read-tree -m -u $treeH $treeM &&\n git-ls-files --stage >10.out &&\n cmp M.out 10.out &&\n sha1sum -c M.sha1'\n\nWhere paths involved are:\n\n\tpath\t\ttreeH\t\ttreeM\n -----------------------------------------------------\n bozbar\t\texists\t\tmodified from treeH\n frotz\t\tdoes not exist\tadded in treeM\n nitfol\t\texists\t\tsame as in treeH\n rezrov\t\texists\t\tdeleted in treeM\n\nand after this test runs, you can see that the path \"rezrov\"\ngets removed from your work tree. Insert \"exit\" just before the\nnext test, run \"cd t && sh t1002-*.sh -i -v\", and inspect what\nis in the \"t/trash\" directory.\n\n\n"},{"id":"5242","messageId":"42BC8B72.8040203@pobox.com","threadId":"1008","inReplyTo":"Pine.LNX.4.58.0506241153180.11175@ppc970.osdl.org","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-24T22:38:42Z","receivedAt":"2005-06-24T22:38:42Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n> I still think you can go a bit too far on your branch usage (ie Jeff), but \n> hey, what's the difference between three branches and fifty, really?\n\nLOL ;-)\n\n\n> (I'm kidding. The difference between three and fifty is how well you can \n> keep track of them in your head, but maybe Jeff just has a bigger head \n> than most people do. Jeff, do people go \"Boy, you've got a big head\" the \n> first time they meet you?)\n\n50 branches is just easier than 50 different trees, for my usage :)\n\nPoor kernel.org would melt if I had 50 trees :)\n\n\tJeff\n\n\n"},{"id":"5243","messageId":"20050624224534.GF31165@ca-server1.us.oracle.com","threadId":"1008","inReplyTo":"20050624064101.GB14292@pasky.ji.cz","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Joel Becker","fromEmail":"joel.becker@oracle.com","sentAt":"2005-06-24T22:45:34Z","receivedAt":"2005-06-24T22:45:34Z","isPatch":false,"sender":{"key":"joel.becker@oracle.com","avatar":null},"body":"On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:\n> Theoretically, dotest should work just fine even if you use Cogito.\n> Anyone tested it?\n\n\tWhen I update the OCFS2 git tree, I clone with Cogito and patch\nwith dotest. Been doing it for a month or two, no problems.\n\nJoel\n\n-- \n\n\"I think it would be a good idea.\" \n - Mahatma Ghandi, when asked what he thought of Western\n civilization\n\nJoel Becker\nSenior Member of Technical Staff\nOracle\nE-mail: joel.becker@oracle.com\nPhone: (650) 506-8127\n"},{"id":"5244","messageId":"0C5DEAF8-11D3-4F12-9482-6DFEE099A392@mac.com","threadId":"1008","inReplyTo":"20050623235634.GC14426@waste.org","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2005-06-24T23:08:42Z","receivedAt":"2005-06-24T23:08:42Z","isPatch":false,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"On Jun 23, 2005, at 19:56:34, Matt Mackall wrote:\n> On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:\n>> Things in git-land are moving at lightning speed, and usability has\n>> improved a lot since my post a month ago: http://lkml.org/lkml/ \n>> 2005/5/26/11\n>\n> And here's a quick comparison with the current state of Mercurial..\n\nOooh!!! Nice!!! This is my new official source keeper for my next \nproject. I\nespecially like the fast operation and low disk storage \nrequirements. Many\nkudos to Matt Mackall for his awesome program! The efficient network \nprotocol\nis great too!\n\nCheers,\nKyle Moffett\n\n--\nThere are two ways of constructing a software design. One way is to \nmake it so simple that there are obviously no deficiencies. And the \nother way is to make it so complicated that there are no obvious \ndeficiencies.\n -- C.A.R. Hoare\n"},{"id":"5249","messageId":"42BCD092.6050201@pobox.com","threadId":"1008","inReplyTo":"20050622224003.GA21298@redhat.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-25T03:33:38Z","receivedAt":"2005-06-25T03:33:38Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Dave Jones wrote:\n> On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:\n> > \n> > Things in git-land are moving at lightning speed, and usability has \n> > improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11\n> > \n> > \n> > \n> > 1) installing git\n> > \n> > git requires bootstrapping, since you must have git installed in order \n> > to check out git.git (git repo), and linux-2.6.git (kernel repo). I \n> > have put together a bootstrap tarball of today's git repository.\n> > \n> > Download tarball from:\n> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2\n> \n> \n> daily snapshots (refreshed once an hour) are available at:\n> http://www.codemonkey.org.uk/projects/git-snapshots/git/\n> \n\nI was about to link to this, but a problem arose: your snapshots don't \ninclude the .git/objects directory.\n\nAlso, a git-latest.tar.gz symlink would be nice.\n\n\tJeff\n\n\n"},{"id":"5268","messageId":"20050625172902.GA2852@redhat.com","threadId":"1008","inReplyTo":"42BCD092.6050201@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Dave Jones","fromEmail":"davej@redhat.com","sentAt":"2005-06-25T17:29:02Z","receivedAt":"2005-06-25T17:29:02Z","isPatch":false,"sender":{"key":"davej@redhat.com","avatar":null},"body":"On Fri, Jun 24, 2005 at 11:33:38PM -0400, Jeff Garzik wrote:\n > Dave Jones wrote:\n > >On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:\n > > > \n > > > Things in git-land are moving at lightning speed, and usability has \n > > > improved a lot since my post a month ago: \n > > http://lkml.org/lkml/2005/5/26/11\n > > > \n > > > \n > > > \n > > > 1) installing git\n > > > \n > > > git requires bootstrapping, since you must have git installed in order \n > > > to check out git.git (git repo), and linux-2.6.git (kernel repo). I \n > > > have put together a bootstrap tarball of today's git repository.\n > > > \n > > > Download tarball from:\n > > > \n > > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2\n > >\n > >\n > >daily snapshots (refreshed once an hour) are available at:\n > >http://www.codemonkey.org.uk/projects/git-snapshots/git/\n > >\n > \n > I was about to link to this, but a problem arose: your snapshots don't \n > include the .git/objects directory.\n\nThis is intentional. Why is this a problem ?\nIn the same way, the bitkeeper snapshots I used to do never included\nBitkeeper/, and CVS snapshots don't include the CVS/ dirs.\n\n > Also, a git-latest.tar.gz symlink would be nice.\n\nThat's doable.\n\n\t\tDave\n\n"},{"id":"5300","messageId":"20050627183118.GB1415@elf.ucw.cz","threadId":"1008","inReplyTo":"20050623235634.GC14426@waste.org","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Pavel Machek","fromEmail":"pavel@ucw.cz","sentAt":"2005-06-27T18:31:18Z","receivedAt":"2005-06-27T18:31:18Z","isPatch":false,"sender":{"key":"pavel@ucw.cz","avatar":null},"body":"Hi!\n\n> > Things in git-land are moving at lightning speed, and usability has \n> > improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11\n> \n> And here's a quick comparison with the current state of Mercurial..\n> \n> > 1) installing git\n> > \n> > git requires bootstrapping, since you must have git installed in order \n> > to check out git.git (git repo), and linux-2.6.git (kernel repo). I \n> > have put together a bootstrap tarball of today's git repository.\n> > \n> > Download tarball from:\n> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2\n> > \n> > tarball build-deps: zlib, libcurl, libcrypto (openssl)\n> > \n> > install tarball: unpack && make && sudo make prefix=/usr/local install\n> > \n> > jgarzik helper scripts, not in official git distribution:\n> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch\n> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script\n> > \n> > After reading the rest of this document, come back and update your copy \n> > of git to the latest:\n> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git\n> \n> Download from: http://selenic.com/mercurial/mercurial-snapshot.tar.gz\n> Build-deps: Python 2.3\n> Install: unpack && python setup.py install [--home=/usr/local]\n\nDid that... (had to install python2.3-dev, first), but got...\n\n> $ mkdir linux-2.6\n> $ cd linux-2.6\n> $ hg init http://www.kernel.org/hg/ # obviously you can also browse this\n> \n> This downloads about 125M of data, which include the whole kernel history\n> back to 2.4.0 and everything in Linus' git repo as well.\n\nbyte-compiling /usr/local/lib/python/mercurial/fancyopts.py to\nfancyopts.pyc\nbyte-compiling /usr/local/lib/python/mercurial/hg.py to hg.pyc\nbyte-compiling /usr/local/lib/python/mercurial/hgweb.py to hgweb.pyc\nbyte-compiling /usr/local/lib/python/mercurial/httprangereader.py to\nhttprangereader.pyc\nbyte-compiling /usr/local/lib/python/mercurial/lock.py to lock.pyc\nbyte-compiling /usr/local/lib/python/mercurial/mdiff.py to mdiff.pyc\nbyte-compiling /usr/local/lib/python/mercurial/revlog.py to revlog.pyc\nbyte-compiling /usr/local/lib/python/mercurial/transaction.py to\ntransaction.pyc\nbyte-compiling /usr/local/lib/python/mercurial/ui.py to ui.pyc\nbyte-compiling /usr/local/lib/python/mercurial/util.py to util.pyc\nbyte-compiling /usr/local/lib/python/mercurial/version.py to\nversion.pyc\nrunning install_scripts\ncopying build/scripts-2.3/hg -> /usr/local/bin\ncopying build/scripts-2.3/hgmerge -> /usr/local/bin\nchanging mode of /usr/local/bin/hg to 755\nchanging mode of /usr/local/bin/hgmerge to 755\nrunning install_data\ncreating /usr/local/lib/python/mercurial/templates\ncopying templates/map -> /usr/local/lib/python/mercurial/templates\ncopying templates/map-raw -> /usr/local/lib/python/mercurial/templates\ncopying templates/changelog.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/changelogentry.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/changeset-raw.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/changeset.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/fileannotate.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/filediff-raw.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/filediff.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/filelog.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/filelogentry.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/filerevision-raw.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/filerevision.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/footer.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/header-raw.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/header.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/manifest.tmpl ->\n/usr/local/lib/python/mercurial/templates\ncopying templates/tags.tmpl ->\n/usr/local/lib/python/mercurial/templates\nroot@Elf:/data/tmp/hg/mercurial-snapshot# Use \"exit\" to leave the\nshell.\nroot@Elf:/data/tmp/hg/mercurial-snapshot# exit\npavel@Elf:/data/tmp/hg/mercurial-snapshot$ cd ../..\npavel@Elf:/data/tmp$ mkdir linux-hg\npavel@Elf:/data/tmp$ cd linux-hg/\npavel@Elf:/data/tmp/linux-hg$ hg init http://www.kernel.org/hg/\nTraceback (most recent call last):\n File \"/usr/local/bin/hg\", line 11, in ?\n from mercurial import commands\nImportError: No module named mercurial\npavel@Elf:/data/tmp/linux-hg$\n\t\t\t\t\t\t\tPavel\n-- \nteflon -- maybe it is a trademark, but it should not be.\n"},{"id":"5303","messageId":"4DB694DE-E3E8-4F72-8888-9529D2CC16B9@mac.com","threadId":"1008","inReplyTo":"20050627183118.GB1415@elf.ucw.cz","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2005-06-27T19:05:47Z","receivedAt":"2005-06-27T19:05:47Z","isPatch":false,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"On Jun 27, 2005, at 14:31:18, Pavel Machek wrote:\n> pavel@Elf:/data/tmp/linux-hg$ hg init http://www.kernel.org/hg/\n> Traceback (most recent call last):\n> File \"/usr/local/bin/hg\", line 11, in ?\n> from mercurial import commands\n> ImportError: No module named mercurial\n\nApparently your Python does not automatically look in /usr/local/lib/ \npython\nand you don't have PYTHONPATH=/usr/local/lib/python. Try adding the \nfollowing\nto your .bash_profile, then logging out and back in again:\n\nif [ -z \"$PYTHONPATH\" ]; then\n PYTHONPATH=/usr/local/lib/python\nelse\n PYTHONPATH=\"$PYTHONPATH:/usr/local/lib/python\"\nfi\nexport PYTHONPATH\n\nCheers,\nKyle Moffett\n\n--\nSomone asked me why I work on this free (http://www.fsf.org/philosophy/)\nsoftware stuff and not get a real job. Charles Shultz had the best \nanswer:\n\n\"Why do musicians compose symphonies and poets write poems? They do it\nbecause life wouldn't have any meaning for them if they didn't. \nThat's why\nI draw cartoons. It's my life.\"\n-- Charles Shultz\n"},{"id":"5304","messageId":"20050627194031.GK12006@waste.org","threadId":"1008","inReplyTo":"20050627183118.GB1415@elf.ucw.cz","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Matt Mackall","fromEmail":"mpm@selenic.com","sentAt":"2005-06-27T19:40:31Z","receivedAt":"2005-06-27T19:40:31Z","isPatch":false,"sender":{"key":"mpm@selenic.com","avatar":null},"body":"On Mon, Jun 27, 2005 at 08:31:18PM +0200, Pavel Machek wrote:\n> Hi!\n> \n> > > Things in git-land are moving at lightning speed, and usability has \n> > > improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11\n> > \n> > And here's a quick comparison with the current state of Mercurial..\n> > \n> > > 1) installing git\n> > > \n> > > git requires bootstrapping, since you must have git installed in order \n> > > to check out git.git (git repo), and linux-2.6.git (kernel repo). I \n> > > have put together a bootstrap tarball of today's git repository.\n> > > \n> > > Download tarball from:\n> > > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2\n> > > \n> > > tarball build-deps: zlib, libcurl, libcrypto (openssl)\n> > > \n> > > install tarball: unpack && make && sudo make prefix=/usr/local install\n> > > \n> > > jgarzik helper scripts, not in official git distribution:\n> > > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch\n> > > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script\n> > > \n> > > After reading the rest of this document, come back and update your copy \n> > > of git to the latest:\n> > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git\n> > \n> > Download from: http://selenic.com/mercurial/mercurial-snapshot.tar.gz\n> > Build-deps: Python 2.3\n> > Install: unpack && python setup.py install [--home=/usr/local]\n> \n> Did that... (had to install python2.3-dev, first), but got...\n> Traceback (most recent call last):\n> File \"/usr/local/bin/hg\", line 11, in ?\n> from mercurial import commands\n> ImportError: No module named mercurial\n\n>From the README:\n\n To install system-wide:\n\n $ python setup.py install # change python to python2.3 if 2.2 is default\n\n To install in your home directory (~/bin and ~/lib, actually), run:\n\n $ python2.3 setup.py install --home=~\n $ export PYTHONPATH=${HOME}/lib/python # add this to your .bashrc\n $ export PATH=${HOME}/bin:$PATH # \n\n And finally:\n\n $ hg # test installation, show help\n\n If you get complaints about missing modules, you probably haven't set\n PYTHONPATH correctly.\n\n-- \nMathematics is the supreme nostalgia of our time.\n"},{"id":"5305","messageId":"20050627195134.GA17107@kvack.org","threadId":"1008","inReplyTo":"20050627194031.GK12006@waste.org","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Benjamin LaHaise","fromEmail":"bcrl@kvack.org","sentAt":"2005-06-27T19:51:34Z","receivedAt":"2005-06-27T19:51:34Z","isPatch":false,"sender":{"key":"bcrl@kvack.org","avatar":null},"body":"On Mon, Jun 27, 2005 at 12:40:31PM -0700, Matt Mackall wrote:\n> $ export PYTHONPATH=${HOME}/lib/python # add this to your .bashrc\n\nThis needs to be ${HOME}/lib64/python on x86-64.\n\n\t\t-ben\n"},{"id":"5306","messageId":"20050627205112.GP12006@waste.org","threadId":"1008","inReplyTo":"20050627195134.GA17107@kvack.org","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Matt Mackall","fromEmail":"mpm@selenic.com","sentAt":"2005-06-27T20:51:12Z","receivedAt":"2005-06-27T20:51:12Z","isPatch":false,"sender":{"key":"mpm@selenic.com","avatar":null},"body":"On Mon, Jun 27, 2005 at 03:51:34PM -0400, Benjamin LaHaise wrote:\n> On Mon, Jun 27, 2005 at 12:40:31PM -0700, Matt Mackall wrote:\n> > $ export PYTHONPATH=${HOME}/lib/python # add this to your .bashrc\n> \n> This needs to be ${HOME}/lib64/python on x86-64.\n\nThanks, I'll add this to the README.\n\n-- \nMathematics is the supreme nostalgia of our time.\n"},{"id":"5307","messageId":"200506271753.13247.tomlins@cam.org","threadId":"1008","inReplyTo":"20050627195134.GA17107@kvack.org","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Ed Tomlinson","fromEmail":"tomlins@cam.org","sentAt":"2005-06-27T21:53:12Z","receivedAt":"2005-06-27T21:53:12Z","isPatch":false,"sender":{"key":"tomlins@cam.org","avatar":null},"body":"On Monday 27 June 2005 15:51, Benjamin LaHaise wrote:\n> On Mon, Jun 27, 2005 at 12:40:31PM -0700, Matt Mackall wrote:\n> > $ export PYTHONPATH=${HOME}/lib/python # add this to your .bashrc\n> \n> This needs to be ${HOME}/lib64/python on x86-64.\n\nBe careful. This is not true on debian.\n\nEd Tomlinson\n"},{"id":"5338","messageId":"20050628150027.GB1275@pasky.ji.cz","threadId":"1008","inReplyTo":"20050624123819.GD9519@64m.dyndns.org","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-06-28T15:00:27Z","receivedAt":"2005-06-28T15:00:27Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jun 24, 2005 at 02:38:19PM CEST, I got a letter\nwhere Christopher Li told me that...\n> On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:\n> > > 5.1) undo the last commit or pull\n> > > \n> > > $ hg undo\n> > \n> > $ cg-admin-uncommit\n> > \n> > Note that you should never do this if you already pushed the changes\n> > out, or someone might get them. (That holds for regular Git too.) See\n> > \n> > $ cg-help cg-admin-uncommit # (or cg-admin-uncommit --help)\n> > \n> > for details. (That's another Cogito's cool feature. Handy docs! ;-)\n> > \n> \n> Does it still works if the last commit was interrupted or due to error for some\n> reason?\n\nIf the last commit was interrupted, it didn't happen, so your tree stays\nin the same state as before doing the commit, as well as the repository.\nYou can just try again. If you want to get rid of dirty stuff,\ncg-cancel.\n\n> Undo pull is pretty cool because you might pull a lot of commit\n> in one blow. Get rid of commit one by one is going to be painful. Some times\n> the object you pull has more than one chain of history it will be very nasty\n> if you want to clean it up.\n\nIf it was a tree merge, cg-admin-uncommit will undo it. If it was\nfast-forward merge, there is no direct way to uncommit it, but you can\nfind the first fast-forwarded commit and pass it as argument to\ncg-admin-uncommit; it will then rewind all the commits up to (including)\nthe given commit.\n\n> Mercurial's undo is taking a snapshot of all the changed file's repo file length\n> at every commit or pull. It just truncate the file to original size and undo \n> is done.\n\n\"Trunactes\"? That sounds very wrong... you mean replace with old\nversion? Anyway, what if the file has same length? It just doesn't make\nmuch sense to me.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5339","messageId":"20050628150752.GC1275@pasky.ji.cz","threadId":"1008","inReplyTo":"42BC112C.1040009@qualitycode.com","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-06-28T15:07:52Z","receivedAt":"2005-06-28T15:07:52Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jun 24, 2005 at 03:57:00PM CEST, I got a letter\nwhere Kevin Smith told me that...\n> - Can run on (native) MS Windows\n> (necessary for me because I often work on cross-platform projects)\n\nI'd expect everything to work fine with Cygwin (or with only minor\nproblems easy to fix) or just any working bash + GNU coreutils\ninstallation. Any issue with that?\n\n> - Python code can be more clear and expressive (IMHO)\n> \n> In the long run, I think the python code base will be easier to maintain \n> and enhance. A rewrite of cogito in python or ruby would be cool.\n\nI've planned to rewrite Cogito in Perl, but it turned out the shell\nscripts really are far from the PITA they appeared to be - they work\njust fine and feel quite comfortable from the maintenance standpoint as\nwell. It surprised me too but I don't plan to rewrite Cogito in a\ndifferent language soon.\n\n> One advantage that cogito has is that git viewing/browsing tools can \n> operate directly on cogito repos. But a psychological drawback is the \n> ongoing confusion between git and cogito. Questions: Would a git-based \n> tool that writes to the repo (such as StGIT) mess up a cogito repo? Can \n> you switch a repo between git and cogito or back, at any time?\n\nCogito's only unusual requirement (well, expectation) is that HEAD is a\nsymlink to .git/refs/heads/master, and .git/refs/heads/master should\nreflect your current head. I will try to ease up this restriction so\nthat things will mostly work even if you just have HEAD. I think that\nmost auxiliary commands (e.g. cg-log - you just have to love it) should\nwork on any sensible git tree (but I didn't test it - yet).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5340","messageId":"42C16877.6000909@aktzero.com","threadId":"1008","inReplyTo":"20050628150027.GB1275@pasky.ji.cz","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Andrew Thompson","fromEmail":"andrewkt@aktzero.com","sentAt":"2005-06-28T15:10:47Z","receivedAt":"2005-06-28T15:10:47Z","isPatch":false,"sender":{"key":"andrewkt@aktzero.com","avatar":null},"body":"Petr Baudis wrote:\n>>Mercurial's undo is taking a snapshot of all the changed file's repo file length\n>>at every commit or pull. It just truncate the file to original size and undo \n>>is done.\n> \n> \"Trunactes\"? That sounds very wrong... you mean replace with old\n> version? Anyway, what if the file has same length? It just doesn't make\n> much sense to me.\n\nI believe this works because the files stored in a binary format that \nappends new changesets onto the end. Thus, truncating the new stuff from \nthe end effectively removes the commit.\n\n-- \nAndrew Thompson\nhttp://aktzero.com/\n\n\nbegin:vcard\nfn:Andrew Thompson\nn:Thompson;Andrew\nemail;internet:andrewkt@aktzero.com\nx-mozilla-html:FALSE\nurl:http://aktzero.com/\nversion:2.1\nend:vcard\n\n\n\n_______________________________________________\nMercurial mailing list\nMercurial@selenic.com\nhttp://selenic.com/mailman/listinfo/mercurial\n"},{"id":"5341","messageId":"20050628151522.GO5992MdfPADPa@garage.linux.student.kuleuven.ac.be","threadId":"1008","inReplyTo":"20050628150752.GC1275@pasky.ji.cz","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2005-06-28T15:15:22Z","receivedAt":"2005-06-28T15:15:22Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Tue, Jun 28, 2005 at 05:07:52PM +0200, Petr Baudis wrote:\n> Dear diary, on Fri, Jun 24, 2005 at 03:57:00PM CEST, I got a letter\n> where Kevin Smith told me that...\n> > - Can run on (native) MS Windows\n> > (necessary for me because I often work on cross-platform projects)\n> \n> I'd expect everything to work fine with Cygwin (or with only minor\n> problems easy to fix) or just any working bash + GNU coreutils\n> installation. Any issue with that?\n\nThe code is full of Unixisms. You'd almost think that the authors\nof git have some kind of affinity towards Unix.\n\ni386-mingw32-gcc -g -O2 -Wall '-DSHA1_HEADER=' -c -o read-cache.o read-cache.c\nIn file included from read-cache.c:6:\ncache.h:14:22: sys/mman.h: No such file or directory\ncache.h:16:24: netinet/in.h: No such file or directory\nIn file included from read-cache.c:6:\ncache.h: In function `create_ce_mode':\ncache.h:104: warning: implicit declaration of function `S_ISLNK'\ncache.h:105: warning: implicit declaration of function `htonl'\ncache.h:105: error: `S_IFLNK' undeclared (first use in this function)\ncache.h:105: error: (Each undeclared identifier is reported only once\ncache.h:105: error: for each function it appears in.)\n[..]\nread-cache.c:376: warning: implicit declaration of function `mmap'\nread-cache.c:376: error: `PROT_READ' undeclared (first use in this function)\nread-cache.c:376: error: `PROT_WRITE' undeclared (first use in this function)\nread-cache.c:376: error: `MAP_PRIVATE' undeclared (first use in this function)\nread-cache.c:376: warning: assignment makes pointer from integer without a cast\nread-cache.c:399: warning: implicit declaration of function `munmap'\n[..]\n\nskimo\n"},{"id":"5342","messageId":"20050628153450.GE1275@pasky.ji.cz","threadId":"1008","inReplyTo":"20050628151522.GO5992MdfPADPa@garage.linux.student.kuleuven.ac.be","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-06-28T15:34:50Z","receivedAt":"2005-06-28T15:34:50Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Jun 28, 2005 at 05:15:22PM CEST, I got a letter\nwhere Sven Verdoolaege told me that...\n> On Tue, Jun 28, 2005 at 05:07:52PM +0200, Petr Baudis wrote:\n> > Dear diary, on Fri, Jun 24, 2005 at 03:57:00PM CEST, I got a letter\n> > where Kevin Smith told me that...\n> > > - Can run on (native) MS Windows\n> > > (necessary for me because I often work on cross-platform projects)\n> > \n> > I'd expect everything to work fine with Cygwin (or with only minor\n> > problems easy to fix) or just any working bash + GNU coreutils\n> > installation. Any issue with that?\n> \n> The code is full of Unixisms. You'd almost think that the authors\n> of git have some kind of affinity towards Unix.\n\nAh. Well, I was speaking just of Cogito and didn't realize you might\nwant git too so that you can actually do anything with Cogito then. ;-)\n\n> read-cache.c:376: warning: implicit declaration of function `mmap'\n\nWell, I'm actually not very clueful about MS Windows environment, but\ndoesn't it provide any POSIX API? You might have more luck with that.\nOr I guess it should work on Cygwin.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5343","messageId":"20050628153545.GF1275@pasky.ji.cz","threadId":"1008","inReplyTo":"42C16877.6000909@aktzero.com","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-06-28T15:35:45Z","receivedAt":"2005-06-28T15:35:45Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Jun 28, 2005 at 05:10:47PM CEST, I got a letter\nwhere Andrew Thompson told me that...\n> Petr Baudis wrote:\n> >>Mercurial's undo is taking a snapshot of all the changed file's repo file \n> >>length\n> >>at every commit or pull. It just truncate the file to original size and \n> >>undo is done.\n> >\n> >\"Trunactes\"? That sounds very wrong... you mean replace with old\n> >version? Anyway, what if the file has same length? It just doesn't make\n> >much sense to me.\n> \n> I believe this works because the files stored in a binary format that \n> appends new changesets onto the end. Thus, truncating the new stuff from \n> the end effectively removes the commit.\n\nYes, I'm sorry - I missed the \"repo\" part and thought that was what it\nwas doing with the checked out files. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5349","messageId":"42C17FBC.7030509@qualitycode.com","threadId":"1008","inReplyTo":"20050628150752.GC1275@pasky.ji.cz","subject":"Cygwin and Native MS Windows (was: Mercurial vs Updated git HOWTO for kernel hackers)","fromName":"Kevin Smith","fromEmail":"yarcs@qualitycode.com","sentAt":"2005-06-28T16:50:04Z","receivedAt":"2005-06-28T16:50:04Z","isPatch":false,"sender":{"key":"yarcs@qualitycode.com","avatar":null},"body":"Petr Baudis wrote:\n > Dear diary, on Fri, Jun 24, 2005 at 03:57:00PM CEST, I got a letter\n > where Kevin Smith told me that...\n >\n >>- Can run on (native) MS Windows\n >> (necessary for me because I often work on cross-platform projects)\n >\n >\n > I'd expect everything to work fine with Cygwin (or with only minor\n > problems easy to fix) or just any working bash + GNU coreutils\n > installation. Any issue with that?\n\nI don't see cygwin as being a reasonable option for a core tool like \nSCM. Cygwin is too large and invasive to expect Windows users to install \nand use it. For my own projects, native Windows operation is a requirement.\n\nKevin\n"},{"id":"5350","messageId":"42C1800C.7040506@qualitycode.com","threadId":"1008","inReplyTo":"20050628150752.GC1275@pasky.ji.cz","subject":"Cogito vs. Git (was: Mercurial vs Updated git HOWTO for kernel hackers)","fromName":"Kevin Smith","fromEmail":"yarcs@qualitycode.com","sentAt":"2005-06-28T16:51:24Z","receivedAt":"2005-06-28T16:51:24Z","isPatch":false,"sender":{"key":"yarcs@qualitycode.com","avatar":null},"body":"Petr Baudis wrote:\n> Cogito's only unusual requirement (well, expectation) is that HEAD is a\n> symlink to .git/refs/heads/master, and .git/refs/heads/master should\n> reflect your current head. I will try to ease up this restriction so\n> that things will mostly work even if you just have HEAD. I think that\n> most auxiliary commands (e.g. cg-log - you just have to love it) should\n> work on any sensible git tree (but I didn't test it - yet).\n\nSo you're saying that aside from that one solveable issue, I could use \nlow-level git tools, third-party over-git tools, and cogito, \ninterchangebly on a single repo without the tools becoming confused? \nThat's cool, and should be made more clear in the cogito readme. I was \nunder the impression that cogito was tracking all kinds of extra meta \nmagic stuff that git tools wouldn't keep updated.\n\nIf I were using cogito, I probably wouldn't want to use the low-level \ngit stuff directly, but I might want to use (or maybe even write) some \nother over-git tools.\n\nYou might also consider removing the \"Core GIT\" section from the README, \nbecause I think it increases the confusion between the two.\n\nCheers,\n\nKevin\n"},{"id":"5353","messageId":"20050628180157.GI12006@waste.org","threadId":"1008","inReplyTo":"20050628150027.GB1275@pasky.ji.cz","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Matt Mackall","fromEmail":"mpm@selenic.com","sentAt":"2005-06-28T18:01:57Z","receivedAt":"2005-06-28T18:01:57Z","isPatch":false,"sender":{"key":"mpm@selenic.com","avatar":null},"body":"On Tue, Jun 28, 2005 at 05:00:27PM +0200, Petr Baudis wrote:\n> > Mercurial's undo is taking a snapshot of all the changed file's repo file length\n> > at every commit or pull. It just truncate the file to original size and undo \n> > is done.\n> \n> \"Trunactes\"? That sounds very wrong... you mean replace with old\n> version? Anyway, what if the file has same length? It just doesn't make\n> much sense to me.\n\nEverything in Mercurial is an append-only log. A transaction journal\nrecords the original length of each log so that it can be restored on\nfailure.\n\n-- \nMathematics is the supreme nostalgia of our time.\n"},{"id":"5364","messageId":"62CF578B-B9DF-4DEA-8BAD-041F357771FD@mac.com","threadId":"1008","inReplyTo":"20050628180157.GI12006@waste.org","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2005-06-28T20:27:53Z","receivedAt":"2005-06-28T20:27:53Z","isPatch":false,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"On Jun 28, 2005, at 14:01:57, Matt Mackall wrote:\n> Everything in Mercurial is an append-only log. A transaction journal\n> records the original length of each log so that it can be restored on\n> failure.\n\nDoes this mean that (excepting the \"undo\" feature) one could set the\next3 \"append-only\" attribute on the repository files to avoid losing\ndata due to user account compromise?\n\nCheers,\nKyle Moffett\n\n--\nI lost interest in \"blade servers\" when I found they didn't throw \nknives at people who weren't supposed to be in your machine room.\n -- Anthony de Boer\n"},{"id":"5366","messageId":"3886.10.10.10.24.1119991512.squirrel@linux1","threadId":"1008","inReplyTo":"62CF578B-B9DF-4DEA-8BAD-041F357771FD@mac.com","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-06-28T20:45:12Z","receivedAt":"2005-06-28T20:45:12Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, June 28, 2005 4:27 pm, Kyle Moffett said:\n> On Jun 28, 2005, at 14:01:57, Matt Mackall wrote:\n>> Everything in Mercurial is an append-only log. A transaction journal\n>> records the original length of each log so that it can be restored on\n>> failure.\n>\n> Does this mean that (excepting the \"undo\" feature) one could set the\n> ext3 \"append-only\" attribute on the repository files to avoid losing\n> data due to user account compromise?\n>\n\nProbably. In Git, which is a bit more flexible than Mecurial you can\nchmod your objects to read-only or use the ext3 immutable setting to\nprotect your existing objects. You can even have a setup where objects\nare archived onto write-once media like DVD and still participate in a\nlive repository, where new objects are written to hard disk, but older\nobject are (automatically) sourced from the DVD.\n\nSean\n"},{"id":"5367","messageId":"20050628205422.GI1275@pasky.ji.cz","threadId":"1008","inReplyTo":"42C1800C.7040506@qualitycode.com","subject":"Re: Cogito vs. Git (was: Mercurial vs Updated git HOWTO for kernel hackers)","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-06-28T20:54:22Z","receivedAt":"2005-06-28T20:54:22Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Jun 28, 2005 at 06:51:24PM CEST, I got a letter\nwhere Kevin Smith told me that...\n> Petr Baudis wrote:\n> >Cogito's only unusual requirement (well, expectation) is that HEAD is a\n> >symlink to .git/refs/heads/master, and .git/refs/heads/master should\n> >reflect your current head. I will try to ease up this restriction so\n> >that things will mostly work even if you just have HEAD. I think that\n> >most auxiliary commands (e.g. cg-log - you just have to love it) should\n> >work on any sensible git tree (but I didn't test it - yet).\n> \n> So you're saying that aside from that one solveable issue, I could use \n> low-level git tools, third-party over-git tools, and cogito, \n> interchangebly on a single repo without the tools becoming confused? \n\nYes, given that you use the toolset \"atomically\" - if you start doing\nsome large-scale operation using one tool, you should finish it using\nthe same tool. That is, if you start merging by Cogito and then try to\ncommit by Linus' git plumbing, it won't work (and vice versa). cg-seek\ncombined with third-party over-git tools might have unknown consequences\nas well.\n\n> That's cool, and should be made more clear in the cogito readme. I was \n> under the impression that cogito was tracking all kinds of extra meta \n> magic stuff that git tools wouldn't keep updated.\n\nIt is tracking only seeks and merges in way the git tools wouldn't keep\nupdated. I will try to actually make it use ~/.git/MERGE_HEAD instead of\n~/.git/merging as well, to make people's live even easier.\n\n> If I were using cogito, I probably wouldn't want to use the low-level \n> git stuff directly, but I might want to use (or maybe even write) some \n> other over-git tools.\n> \n> You might also consider removing the \"Core GIT\" section from the README, \n> because I think it increases the confusion between the two.\n\nI might consider throwing away Git from Cogito distribution altogether,\nbut that would require Git to have some actual release cycle. ;-)\n\nFYI, I will merge the pile of queued Cogito\npatches during the weekend and next week, preparing 0.11.4 or 0.12\n(depends on how I feel about it). I will also merge the Linus' stuff,\nbut only up to:\n\n7323aa11af1527d5a786d93ee34401c72c5df051\n\tJan Harkes 2005-06-25 13:41\n\t[PATCH] git-write-tree doesn't check alternate directories\n\nThe next patch is\n\nc323ac7d9c573c5ee8b45b9b9def92a4d4d8204d\n\tLinus Torvalds 2005-06-25 14:42\n\tgit-pack-objects: create a packed object representation\n\nand I'm not sure if I'm ready to already take the packed stuff; I will\nsee how tested it gets (and if fsck will get taught about it etc). If it\nwon't be ready by the time I'm ready for the release, I will merge the\nrest right after the release.\n\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5377","messageId":"20050628221422.GT12006@waste.org","threadId":"1008","inReplyTo":"3886.10.10.10.24.1119991512.squirrel@linux1","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Matt Mackall","fromEmail":"mpm@selenic.com","sentAt":"2005-06-28T22:14:22Z","receivedAt":"2005-06-28T22:14:22Z","isPatch":false,"sender":{"key":"mpm@selenic.com","avatar":null},"body":"On Tue, Jun 28, 2005 at 04:45:12PM -0400, Sean wrote:\n> On Tue, June 28, 2005 4:27 pm, Kyle Moffett said:\n> > On Jun 28, 2005, at 14:01:57, Matt Mackall wrote:\n> >> Everything in Mercurial is an append-only log. A transaction journal\n> >> records the original length of each log so that it can be restored on\n> >> failure.\n> >\n> > Does this mean that (excepting the \"undo\" feature) one could set the\n> > ext3 \"append-only\" attribute on the repository files to avoid losing\n> > data due to user account compromise?\n> >\n> \n> Probably. In Git, which is a bit more flexible than Mecurial you can\n> chmod your objects to read-only or use the ext3 immutable setting to\n> protect your existing objects.\n\nYou can do this in Mercurial as well.\n\n> You can even have a setup where objects\n> are archived onto write-once media like DVD and still participate in a\n> live repository, where new objects are written to hard disk, but older\n> object are (automatically) sourced from the DVD.\n\nHave fun with that. It's an excellent way to destroy your DVD drive.\n\nGit's completely structureless filename hashing pretty much guarantees\nthat disk layout will degrade to worst-case random access behavior\nover time. Just walking through the 2000 commit blobs in the current\ntree can take minutes cold cache on a fast hard disk. Walking the 1700\ntree blobs in a given version takes quite a while too.\n\nPut that on a DVD and that could easily turn into hours of continuous\nseeking for a simple operation like checking out tip of tree.\n\nAnd as far as I know, ISO9660 and UDF don't really handle huge\ndirectories well. So if you try and put the whole kernel history (200k\nfiles, some huge number of directory blobs, and 30k-60k commit blobs)\non a DVD, you'll be really hurting.\n\nMeanwhile the whole history (>30k changesets) with Mercurial fits on a\nregular CD, with reasonable directory sizes and I/O patterns.\n\nNot that it's really worth the trouble. It takes longer for me to burn\nan ISO image to disc than to download a complete kernel repo from\nkernel.org.\n\n-- \nMathematics is the supreme nostalgia of our time.\n"},{"id":"5378","messageId":"3993.10.10.10.24.1119997389.squirrel@linux1","threadId":"1008","inReplyTo":"20050628221422.GT12006@waste.org","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-06-28T22:23:09Z","receivedAt":"2005-06-28T22:23:09Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, June 28, 2005 6:14 pm, Matt Mackall said:\n>> You can even have a setup where objects\n>> are archived onto write-once media like DVD and still participate in a\n>> live repository, where new objects are written to hard disk, but older\n>> object are (automatically) sourced from the DVD.\n>\n> Have fun with that. It's an excellent way to destroy your DVD drive.\n\nOh come on, stop the FUD. You pack all the objects up into a single pack\nfile (see new feature in Git) and you burn it _once_ to dvd or cdrom.\n\n>\n> Git's completely structureless filename hashing pretty much guarantees\n> that disk layout will degrade to worst-case random access behavior\n> over time. Just walking through the 2000 commit blobs in the current\n> tree can take minutes cold cache on a fast hard disk. Walking the 1700\n> tree blobs in a given version takes quite a while too.\n>\n> Put that on a DVD and that could easily turn into hours of continuous\n> seeking for a simple operation like checking out tip of tree.\n>\n> And as far as I know, ISO9660 and UDF don't really handle huge\n> directories well. So if you try and put the whole kernel history (200k\n> files, some huge number of directory blobs, and 30k-60k commit blobs)\n> on a DVD, you'll be really hurting.\n>\n> Meanwhile the whole history (>30k changesets) with Mercurial fits on a\n> regular CD, with reasonable directory sizes and I/O patterns.\n>\n> Not that it's really worth the trouble. It takes longer for me to burn\n> an ISO image to disc than to download a complete kernel repo from\n> kernel.org.\n>\n\nGit is still developing, there will be new ways to seek and cache things\netc eventually that remove any performance issue. Git gets this right, it\nconcentrates on what is important, stays flexible and trusts that down the\nroad as things mature any performance problems can be dealt with.\n\nIt already has some tools that are better than BK ever had (gitk, gitweb,\netc..)\n\nCheers,\nSean\n"},{"id":"5379","messageId":"6CD96997-0454-40C0-89B3-AD2A2A7692B3@mac.com","threadId":"1008","inReplyTo":"3993.10.10.10.24.1119997389.squirrel@linux1","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2005-06-28T22:47:36Z","receivedAt":"2005-06-28T22:47:36Z","isPatch":false,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"On Jun 28, 2005, at 18:23:09, Sean wrote:\n> Git is still developing, there will be new ways to seek and cache \n> things\n> etc eventually that remove any performance issue. Git gets this \n> right, it\n> concentrates on what is important, stays flexible and trusts that \n> down the\n> road as things mature any performance problems can be dealt with.\n\nHave you tried (or even looked at) Mercurial? I'm now using it for four\ndifferent projects that used to be in CVS and I'm loving it.\n\n> It already has some tools that are better than BK ever had (gitk, \n> gitweb,\n> etc..)\n\nLikewise for Mercurial, except that IMHO, a from-scratch Mercurial \npull via\nHTTP + Mercurial checkout is faster than a BK or GIT checkout alone. \nAnd\nthen there's the fact that it stores the whole mess in a fraction of the\nspace used by git.\n\nPlease, just _try_ it first. You'll like it, I promise. (It's also a\nmuch smaller codebase too)\n\nCheers,\nKyle Moffett\n\n--\nI lost interest in \"blade servers\" when I found they didn't throw \nknives at people who weren't supposed to be in your machine room.\n -- Anthony de Boer\n"},{"id":"5380","messageId":"20050628224946.GU12006@waste.org","threadId":"1008","inReplyTo":"3993.10.10.10.24.1119997389.squirrel@linux1","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Matt Mackall","fromEmail":"mpm@selenic.com","sentAt":"2005-06-28T22:49:46Z","receivedAt":"2005-06-28T22:49:46Z","isPatch":false,"sender":{"key":"mpm@selenic.com","avatar":null},"body":"On Tue, Jun 28, 2005 at 06:23:09PM -0400, Sean wrote:\n> On Tue, June 28, 2005 6:14 pm, Matt Mackall said:\n> >> You can even have a setup where objects\n> >> are archived onto write-once media like DVD and still participate in a\n> >> live repository, where new objects are written to hard disk, but older\n> >> object are (automatically) sourced from the DVD.\n> >\n> > Have fun with that. It's an excellent way to destroy your DVD drive.\n> \n> Oh come on, stop the FUD. You pack all the objects up into a single pack\n> file (see new feature in Git) and you burn it _once_ to dvd or cdrom.\n\nAnd even as one big file, it will _still_ be layed out on disk in\npessimal order.\n\n> > Git's completely structureless filename hashing pretty much guarantees\n> > that disk layout will degrade to worst-case random access behavior\n> > over time. Just walking through the 2000 commit blobs in the current\n> > tree can take minutes cold cache on a fast hard disk. Walking the 1700\n> > tree blobs in a given version takes quite a while too.\n> >\n> > Put that on a DVD and that could easily turn into hours of continuous\n> > seeking for a simple operation like checking out tip of tree.\n> >\n> > And as far as I know, ISO9660 and UDF don't really handle huge\n> > directories well. So if you try and put the whole kernel history (200k\n> > files, some huge number of directory blobs, and 30k-60k commit blobs)\n> > on a DVD, you'll be really hurting.\n> >\n> > Meanwhile the whole history (>30k changesets) with Mercurial fits on a\n> > regular CD, with reasonable directory sizes and I/O patterns.\n> >\n> > Not that it's really worth the trouble. It takes longer for me to burn\n> > an ISO image to disc than to download a complete kernel repo from\n> > kernel.org.\n> >\n> \n> Git is still developing, there will be new ways to seek and cache things\n> etc eventually that remove any performance issue.\n\nAgain, have fun with that. Mercurial already went down this path a\nmonth ago, discovered it couldn't reasonably be fixed without\nabandoning the hashes as file name scheme, and changed repo layout.\n\nGit's going to have a much harder time as it's pretty solidly tied to\nlookup by contents hash. If you throw that out, you might as well use\nMercurial.\n\n-- \nMathematics is the supreme nostalgia of our time.\n"},{"id":"5381","messageId":"4846.10.10.10.24.1119999568.squirrel@linux1","threadId":"1008","inReplyTo":"20050628224946.GU12006@waste.org","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-06-28T22:59:28Z","receivedAt":"2005-06-28T22:59:28Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, June 28, 2005 6:49 pm, Matt Mackall said:\n\n> Again, have fun with that. Mercurial already went down this path a\n> month ago, discovered it couldn't reasonably be fixed without\n> abandoning the hashes as file name scheme, and changed repo layout.\n>\n> Git's going to have a much harder time as it's pretty solidly tied to\n> lookup by contents hash. If you throw that out, you might as well use\n> Mercurial.\n>\n\nBy the sounds of it, git could just use Mecurial or some variation thereof\nas a back end. Git is not tied to it's back end. Afterall, Mecurial\njust took the basic ideas from Linus' and adapted them to a different back\nend. But there are very few situation where Git performance is a\npractical problem, and where it is things are being addressed. Git is\nalready so much better for the things I do than BK ever was, I'll stick\nwith it.\n\nSean.\n"},{"id":"5382","messageId":"40A9C7C2-1AFE-45BC-90A5-571628304479@mac.com","threadId":"1008","inReplyTo":"4846.10.10.10.24.1119999568.squirrel@linux1","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2005-06-28T23:25:24Z","receivedAt":"2005-06-28T23:25:24Z","isPatch":false,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"On Jun 28, 2005, at 18:59:28, Sean wrote:\n> By the sounds of it, git could just use Mecurial or some variation \n> thereof\n> as a back end.\n\nUmm, you seem to miss the point, sir. If you use Mercurial, there is no\nreason you should layer any part of Git on top of it. It already does\neverything that git does anyways.\n\n> Git is already so much better for the things I do than BK ever was, \n> I'll\n> stick with it.\n\nThis is like saying \"Windows 3.1 is already so much better for the \nthings\nI do than DOS ever was, I'll stick with it.\" :-D\n\nCheers,\nKyle Moffett\n\n-----BEGIN GEEK CODE BLOCK-----\nVersion: 3.12\nGCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$\nL++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+\nPGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ \nr !y?(-)\n------END GEEK CODE BLOCK------\n"},{"id":"5383","messageId":"20050628232951.GW12006@waste.org","threadId":"1008","inReplyTo":"4846.10.10.10.24.1119999568.squirrel@linux1","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Matt Mackall","fromEmail":"mpm@selenic.com","sentAt":"2005-06-28T23:29:51Z","receivedAt":"2005-06-28T23:29:51Z","isPatch":false,"sender":{"key":"mpm@selenic.com","avatar":null},"body":"On Tue, Jun 28, 2005 at 06:59:28PM -0400, Sean wrote:\n> Afterall, Mecurial just took the basic ideas from Linus' and adapted\n> them to a different back end.\n\n??!\n\nJust for the record, Mercurial had working distributed merge before\nGit had any sort of merge at all. So it's hardly a case of me copying\ngit.\n\nLinus and I both freely borrowed ideas from Monotone and others and\nthus there is some rough similarity between the two.\n\n-- \nMathematics is the supreme nostalgia of our time.\n"},{"id":"5384","messageId":"1765.10.10.10.24.1120001856.squirrel@linux1","threadId":"1008","inReplyTo":"40A9C7C2-1AFE-45BC-90A5-571628304479@mac.com","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-06-28T23:37:36Z","receivedAt":"2005-06-28T23:37:36Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, June 28, 2005 7:25 pm, Kyle Moffett said:\n> On Jun 28, 2005, at 18:59:28, Sean wrote:\n>> By the sounds of it, git could just use Mecurial or some variation\n>> thereof\n>> as a back end.\n>\n> Umm, you seem to miss the point, sir. If you use Mercurial, there is no\n> reason you should layer any part of Git on top of it. It already does\n> everything that git does anyways.\n\nNo, you seem to miss the point. Git already does everything Mercurial\ndoes, and does it pretty well too. The _point_ was that if the big\n\"feature\" of Mercurial is it's on disk format, Git is perfectly capable of\ncopying it at any point. The on disk format just ISN'T CLOSE TO BEING\nTHE MOST IMPORTANT THING AT THE MOMENT.\n\n>\n>> Git is already so much better for the things I do than BK ever was,\n>> I'll\n>> stick with it.\n>\n> This is like saying \"Windows 3.1 is already so much better for the\n> things\n> I do than DOS ever was, I'll stick with it.\" :-D\n\nYes, so what's your point? Mercurial is trying to solve a problem that is\nalready perfectly well handled for me by Git. Therefore I have _zero_\nmotivation to direct my efforts elsewhere.\n\nCheers,\nSean\n"},{"id":"5385","messageId":"40A4071C-ED45-4280-928F-BCFC8761F47E@mac.com","threadId":"1008","inReplyTo":"1765.10.10.10.24.1120001856.squirrel@linux1","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2005-06-29T00:08:17Z","receivedAt":"2005-06-29T00:08:17Z","isPatch":false,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"On Jun 28, 2005, at 19:37:36, Sean wrote:\n> No, you seem to miss the point. Git already does everything Mercurial\n> does, and does it pretty well too. The _point_ was that if the big\n> \"feature\" of Mercurial is it's on disk format, Git is perfectly \n> capable of\n> copying it at any point. The on disk format just ISN'T CLOSE TO \n> BEING\n> THE MOST IMPORTANT THING AT THE MOMENT.\n\nFirstly, no need to shout, we can all hear you :-D.\n\nGit and Mercurial have all of the same core functionality. The only\nsignificant remaining difference is that Mercurial uses 1/20th the\nnetwork bandwidth and disk space. If you happen to be interested in\nthat advantage (as I am, due to my aging equipment and poor internet\nconnection), then there are two options: (1) fix git, or (2) just use\nMercurial. From my point of view, option 2 is much more productive.\nYou may (and probably do) have different priorities and requirements\nthan I do, but in my view, Mercurial is an excellent tool.\n\n> Yes, so what's your point? Mercurial is trying to solve a problem \n> that is\n> already perfectly well handled for me by Git. Therefore I have \n> _zero_\n> motivation to direct my efforts elsewhere.\n\nActually, Mercurial solved some of the problems first, before git did;\ndistributed merge is one example that comes to mind. In any case, I'm\nnot trying to tell you what to use, I'm just pointing out alternatives\nthat are available and explaining why I like them, in case you haven't\nseen them or tried them before.\n\nCheers,\nKyle Moffett\n\n-----BEGIN GEEK CODE BLOCK-----\nVersion: 3.12\nGCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$\nL++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+\nPGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ \nr !y?(-)\n------END GEEK CODE BLOCK------\n"},{"id":"5387","messageId":"2661.10.10.10.24.1120004702.squirrel@linux1","threadId":"1008","inReplyTo":"40A4071C-ED45-4280-928F-BCFC8761F47E@mac.com","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-06-29T00:25:02Z","receivedAt":"2005-06-29T00:25:02Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, June 28, 2005 8:08 pm, Kyle Moffett said:\n\n> Firstly, no need to shout, we can all hear you :-D.\n\nok\n\n>\n> Git and Mercurial have all of the same core functionality. The only\n> significant remaining difference is that Mercurial uses 1/20th the\n> network bandwidth and disk space. If you happen to be interested in\n> that advantage (as I am, due to my aging equipment and poor internet\n> connection), then there are two options: (1) fix git, or (2) just use\n> Mercurial. From my point of view, option 2 is much more productive.\n> You may (and probably do) have different priorities and requirements\n> than I do, but in my view, Mercurial is an excellent tool.\n\nwell the feature set for both are changing rapidly. i like the emphasis\nplaced on functionality over performance shown by the git developers (not\nthat git is slow, it's _way_ faster than bk ever was). also the web\ninterface that i looked at for mecurial (admittedly four or fivve weeks\nback) didn't come close to gitweb. and the work done by jon seymour and\nothers on the history lineralization is just great. it's something bk\nlacked and was always a thorn in my side.\n\n> Actually, Mercurial solved some of the problems first, before git did;\n> distributed merge is one example that comes to mind. In any case, I'm\n> not trying to tell you what to use, I'm just pointing out alternatives\n> that are available and explaining why I like them, in case you haven't\n> seen them or tried them before.\n\nthere will be a price to pay if the linux community fragments over choice\nof scm. the good news is that we're no longer locked into the whims of\nsome proprietary system. so it should be straight forward for those who\nchoose any tool to work with those who've chosen another. this is already\nevidenced by the fact that the git repository is pulled and re-exeported\nwith mecurial.\n\nanyway, all the best, just wish you guys would spend less time trying to\nconvert git users and more time advancing your own tool.\n\nsean\n"},{"id":"5392","messageId":"12B6F9A5-81F8-46BD-A05D-B9FA1A70A9FF@mac.com","threadId":"1008","inReplyTo":"2661.10.10.10.24.1120004702.squirrel@linux1","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2005-06-29T03:53:47Z","receivedAt":"2005-06-29T03:53:47Z","isPatch":false,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"On Jun 28, 2005, at 20:25:02, Sean wrote:\n> there will be a price to pay if the linux community fragments over \n> choice\n> of scm.\n\nI don't agree. With the current set of SCMs, I don't think it will \nbe long\nbefore somebody invents a gitweb/Mercurial/whatever gateway, such \nthat I can\n\"hg serve\" from my Mercurial repository and have Linus \"git pull\" from a\nmultiprotocol bridge.\n\n> the good news is that we're no longer locked into the whims of\n> some proprietary system. so it should be straight forward for \n> those who\n> choose any tool to work with those who've chosen another. this is \n> already\n> evidenced by the fact that the git repository is pulled and re- \n> exeported\n> with mecurial.\n\nI agree completely! Cheers to the end of proprietary revision storage!\n\n> anyway, all the best, just wish you guys would spend less time \n> trying to\n> convert git users and more time advancing your own tool.\n\nA project with no users isn't much of a project, now is it? In any \ncase,\nthis thread has long since passed its usefulness, so let's let it \ndie, ok?\n\nCheers,\nKyle Moffett\n\n--\nI lost interest in \"blade servers\" when I found they didn't throw \nknives at people who weren't supposed to be in your machine room.\n -- Anthony de Boer\n"},{"id":"5406","messageId":"20050629063233.GE16872@intevation.de","threadId":"1008","inReplyTo":"62CF578B-B9DF-4DEA-8BAD-041F357771FD@mac.com","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Thomas Arendsen Hein","fromEmail":"thomas@intevation.de","sentAt":"2005-06-29T06:32:33Z","receivedAt":"2005-06-29T06:32:33Z","isPatch":false,"sender":{"key":"thomas@intevation.de","avatar":null},"body":"(repost to all lists who received the original mail)\n\n* Kyle Moffett [20050628 22:28]:\n> On Jun 28, 2005, at 14:01:57, Matt Mackall wrote:\n> >Everything in Mercurial is an append-only log. A transaction journal\n> >records the original length of each log so that it can be restored on\n> >failure.\n> \n> Does this mean that (excepting the \"undo\" feature) one could set the\n> ext3 \"append-only\" attribute on the repository files to avoid losing\n> data due to user account compromise?\n\nThis will break Mercurial's journaling. If 'hg pull' fails it\ntruncates the already appended-to files to the last known state.\n\nThomas\n\n-- \nEmail: thomas@intevation.de\nhttp://intevation.de/~thomas/\n"},{"id":"5412","messageId":"20050629102746.GA2484@ucw.cz","threadId":"1008","inReplyTo":"12B6F9A5-81F8-46BD-A05D-B9FA1A70A9FF@mac.com","subject":"Re: Mercurial vs Updated git HOWTO for kernel hackers","fromName":"Vojtech Pavlik","fromEmail":"vojtech@suse.cz","sentAt":"2005-06-29T10:27:46Z","receivedAt":"2005-06-29T10:27:46Z","isPatch":false,"sender":{"key":"vojtech@suse.cz","avatar":null},"body":"On Tue, Jun 28, 2005 at 11:53:47PM -0400, Kyle Moffett wrote:\n\n> On Jun 28, 2005, at 20:25:02, Sean wrote:\n> >there will be a price to pay if the linux community fragments over\n> >choice of scm.\n> \n> I don't agree. With the current set of SCMs, I don't think it will\n> be long before somebody invents a gitweb/Mercurial/whatever gateway,\n> such that I can \"hg serve\" from my Mercurial repository and have\n> Linus \"git pull\" from a multiprotocol bridge.\n\nI hope this will happen sooner than later, since that way the\ncompetition between git and mercurial will give us the best tools while\nkeeping interoperability.\n\n-- \nVojtech Pavlik\nSuSE Labs, SuSE CR\n"},{"id":"5824","messageId":"42CE9961.3090708@ufomechanic.net","threadId":"1008","inReplyTo":"42B9E536.60704@pobox.com","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Amin Azez","fromEmail":"azez@ufomechanic.net","sentAt":"2005-07-08T15:18:57Z","receivedAt":"2005-07-08T15:18:57Z","isPatch":false,"sender":{"key":"azez@ufomechanic.net","avatar":null},"body":"Thanks for the HOWTO, Jeff, but it gives me problems in step 4.\nI checked out your latest git source today and \"make install\"ed it as \npart of your instructions and at step 4 I get:\n\n$ git checkout -f\nerror: cannot map sha1 file f8640c306db2d583b9a30f2e52f8fb0a4cf624e0\nfatal: failed to unpack tree object a92b7b80579fe68fe229892815c750f6652eb6a9\n\n$ cat .git/HEAD\na92b7b80579fe68fe229892815c750f6652eb6a9\n\nNaturally I have no idea what f8640c306db2d583b9a30f2e52f8fb0a4cf624e0 \nrefers to.\n\nStep 3:\n$ git-pull-script \\\nrsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n\nsaid I was already up to date.\n\nVariations on step 4:\n\n$ git-read-tree -m HEAD\nor\n$ git-read-tree a92b7b80579fe68fe229892815c750f6652eb6a9\nalso fail in the same way.\n\nMy linux-2.6 directory only has one entry, .git, containing about 75M of \nfiles.\n\nSam\n\nJeff Garzik wrote:\n> \n> Things in git-land are moving at lightning speed, and usability has \n> improved a lot since my post a month ago: \n> http://lkml.org/lkml/2005/5/26/11\n> \n> \n> \n> 1) installing git\n> \n> git requires bootstrapping, since you must have git installed in order \n> to check out git.git (git repo), and linux-2.6.git (kernel repo). I \n> have put together a bootstrap tarball of today's git repository.\n> \n> Download tarball from:\n> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2\n> \n> tarball build-deps: zlib, libcurl, libcrypto (openssl)\n> \n> install tarball: unpack && make && sudo make prefix=/usr/local install\n> \n> jgarzik helper scripts, not in official git distribution:\n> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch\n> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script\n> \n> After reading the rest of this document, come back and update your copy \n> of git to the latest:\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git\n> \n> \n> 2) download a linux kernel tree for the very first time\n> \n> $ mkdir -p linux-2.6/.git\n> $ cd linux-2.6\n> $ rsync -a --delete --verbose --stats --progress \\\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \n> \\ <- word-wrapped backslash; sigh\n> .git/\n> \n> \n> 3) update local kernel tree to latest 2.6.x upstream (\"fast-forward merge\")\n> \n> $ cd linux-2.6\n> $ git-pull-script \\\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n> \n> \n> 4) check out files from the git repository into the working directory\n> \n> $ git checkout -f\n> \n> \n> 5) check in your own modifications (e.g. do some hacking, or apply a patch)\n> \n> # go to repo\n> $ cd linux-2.6\n> \n> # make some modifications\n> $ patch -sp1 < /tmp/my.patch\n> $ diffstat -p1 < /tmp/my.patch\n> \n> # NOTE: add '--add' and/or '--remove' if files were added or removed\n> $ git-update-cache \n> \n> # check in changes\n> $ git commit\n> \n> \n> 6) List all changes in working dir, in diff format.\n> \n> $ git-diff-cache -p HEAD\n> \n> \n> 7) List all changesets (i.e. show each cset's description text) in local \n> branch of local tree, that are not present in remote tree.\n> \n> $ cd my-kernel-tree-2.6\n> $ git-changes-script -L ../linux-2.6 | less\n> \n> \n> 8) List all changesets:\n> \n> $ git-whatchanged\n> \n> \n> 9) apply all patches in a Berkeley mbox-format file\n> \n> First, download and add to your PATH Linus's git tools:\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git\n> \n> $ cd my-kernel-tree-2.6\n> $ dotest /path/to/mbox # yes, Linus has no taste in naming scripts\n> \n> \n> 10) don't forget to download tags from time to time.\n> \n> git-pull-script only downloads sha1-indexed object data, and the \n> requested remote head. This misses updates to the .git/refs/tags/ and \n> .git/refs/heads directories. It is advisable to update your kernel .git \n> directories periodically with a full rsync command, to make sure you got \n> everything:\n> \n> $ cd linux-2.6\n> $ rsync -a --delete --verbose --stats --progress \\\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/\n> \\ <- word-wrapped backslash; sigh\n> .git/\n> \n> \n> 11) list all branches, such as those found in my netdev-2.6 or \n> libata-dev trees.\n> \n> Download\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git\n> or\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git\n> \n> \n> $ cd netdev-2.6\n> $ ls .git/refs/heads/\n> \n> { these are the current netdev-2.6 branches }\n> \n>> 8139cp forcedeth master qeth smc91x we18\n>> 8139too-iomap for-linus natsemi r8169 smc91x-eeprom wifi\n>> airo hdlc ns83820 register-netdev starfire\n>> atmel ieee80211 orinoco remove-drivers tlan\n>> chelsio iff-running orinoco-hch sis900 veth\n>> dm9000 janitor ppp skge viro\n> \n> \n> \n> 12) make desired branch current in working directory\n> \n> $ git checkout -f $branch\n> \n> \n> 13) create a new branch, and make it current\n> \n> $ cp .git/refs/heads/master .git/refs/heads/my-new-branch-name\n> $ git checkout -f my-new-branch-name\n> \n> \n> 14) examine which branch is current\n> \n> $ ls -l .git/HEAD\n> \n> \n> 15) undo all local modifications (same as checkout):\n> \n> $ git checkout -f\n> \n> \n> 16) obtain a diff between current branch, and master branch\n> \n> In most trees WITH BRANCHES, .git/refs/heads/master contains the current \n> 'vanilla' upstream tree, for easy diffing and merging. (in trees \n> without branches, 'master' simply contains your latest changes)\n> \n> $ git-diff-tree -p master HEAD\n> \n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"5939","messageId":"42D2345A.8040307@ufomechanic.net","threadId":"1008","inReplyTo":"42CE9961.3090708@ufomechanic.net","subject":"Re: Updated git HOWTO for kernel hackers","fromName":"Amin Azez","fromEmail":"azez@ufomechanic.net","sentAt":"2005-07-11T08:56:58Z","receivedAt":"2005-07-11T08:56:58Z","isPatch":false,"sender":{"key":"azez@ufomechanic.net","avatar":null},"body":"Dave Jones daily snapshot of git solved the problem, available from:\nhttp://www.codemonkey.org.uk/projects/git-snapshots/git/\n\nI realise that Jeff's howto suggested updating git using git, but it\nsuggested doing this after following the intermediate steps. I also find\nit ironic that the version of git Jeff provides doesn't work with his\ninstructions; however, still many thanks to Jeff for his HOWTO and to\nDave for git.\n\nAzez\n\nAmin Azez wrote:\n> Thanks for the HOWTO, Jeff, but it gives me problems in step 4.\n> I checked out your latest git source today and \"make install\"ed it as\n> part of your instructions and at step 4 I get:\n> \n> $ git checkout -f\n> error: cannot map sha1 file f8640c306db2d583b9a30f2e52f8fb0a4cf624e0\n> fatal: failed to unpack tree object\n> a92b7b80579fe68fe229892815c750f6652eb6a9\n> \n> $ cat .git/HEAD\n> a92b7b80579fe68fe229892815c750f6652eb6a9\n> \n> Naturally I have no idea what f8640c306db2d583b9a30f2e52f8fb0a4cf624e0\n> refers to.\n> \n> Step 3:\n> $ git-pull-script \\\n> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n> \n> said I was already up to date.\n> \n> Variations on step 4:\n> \n> $ git-read-tree -m HEAD\n> or\n> $ git-read-tree a92b7b80579fe68fe229892815c750f6652eb6a9\n> also fail in the same way.\n> \n> My linux-2.6 directory only has one entry, .git, containing about 75M of\n> files.\n> \n> Sam\n> \n> Jeff Garzik wrote:\n> \n>>\n>> Things in git-land are moving at lightning speed, and usability has\n>> improved a lot since my post a month ago: \n>> http://lkml.org/lkml/2005/5/26/11\n>>\n>>\n>>\n>> 1) installing git\n>>\n>> git requires bootstrapping, since you must have git installed in order\n>> to check out git.git (git repo), and linux-2.6.git (kernel repo). I\n>> have put together a bootstrap tarball of today's git repository.\n>>\n>> Download tarball from:\n>> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2\n>>\n>>\n>> tarball build-deps: zlib, libcurl, libcrypto (openssl)\n>>\n>> install tarball: unpack && make && sudo make prefix=/usr/local install\n>>\n>> jgarzik helper scripts, not in official git distribution:\n>> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch\n>> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script\n>>\n>> After reading the rest of this document, come back and update your\n>> copy of git to the latest:\n>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git\n>>\n>>\n>> 2) download a linux kernel tree for the very first time\n>>\n>> $ mkdir -p linux-2.6/.git\n>> $ cd linux-2.6\n>> $ rsync -a --delete --verbose --stats --progress \\\n>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/\n>> \\ <- word-wrapped backslash; sigh\n>> .git/\n>>\n>>\n>> 3) update local kernel tree to latest 2.6.x upstream (\"fast-forward\n>> merge\")\n>>\n>> $ cd linux-2.6\n>> $ git-pull-script \\\n>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n>>\n>>\n>> 4) check out files from the git repository into the working directory\n>>\n>> $ git checkout -f\n>>\n>>\n>> 5) check in your own modifications (e.g. do some hacking, or apply a\n>> patch)\n>>\n>> # go to repo\n>> $ cd linux-2.6\n>>\n>> # make some modifications\n>> $ patch -sp1 < /tmp/my.patch\n>> $ diffstat -p1 < /tmp/my.patch\n>>\n>> # NOTE: add '--add' and/or '--remove' if files were added or removed\n>> $ git-update-cache \n>>\n>> # check in changes\n>> $ git commit\n>>\n>>\n>> 6) List all changes in working dir, in diff format.\n>>\n>> $ git-diff-cache -p HEAD\n>>\n>>\n>> 7) List all changesets (i.e. show each cset's description text) in\n>> local branch of local tree, that are not present in remote tree.\n>>\n>> $ cd my-kernel-tree-2.6\n>> $ git-changes-script -L ../linux-2.6 | less\n>>\n>>\n>> 8) List all changesets:\n>>\n>> $ git-whatchanged\n>>\n>>\n>> 9) apply all patches in a Berkeley mbox-format file\n>>\n>> First, download and add to your PATH Linus's git tools:\n>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git\n>>\n>> $ cd my-kernel-tree-2.6\n>> $ dotest /path/to/mbox # yes, Linus has no taste in naming scripts\n>>\n>>\n>> 10) don't forget to download tags from time to time.\n>>\n>> git-pull-script only downloads sha1-indexed object data, and the\n>> requested remote head. This misses updates to the .git/refs/tags/ and\n>> .git/refs/heads directories. It is advisable to update your kernel\n>> .git directories periodically with a full rsync command, to make sure\n>> you got everything:\n>>\n>> $ cd linux-2.6\n>> $ rsync -a --delete --verbose --stats --progress \\\n>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/\n>> \\ <- word-wrapped backslash; sigh\n>> .git/\n>>\n>>\n>> 11) list all branches, such as those found in my netdev-2.6 or\n>> libata-dev trees.\n>>\n>> Download\n>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git\n>> or\n>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git\n>>\n>>\n>> $ cd netdev-2.6\n>> $ ls .git/refs/heads/\n>>\n>> { these are the current netdev-2.6 branches }\n>>\n>>> 8139cp forcedeth master qeth smc91x we18\n>>> 8139too-iomap for-linus natsemi r8169 smc91x-eeprom wifi\n>>> airo hdlc ns83820 register-netdev starfire\n>>> atmel ieee80211 orinoco remove-drivers tlan\n>>> chelsio iff-running orinoco-hch sis900 veth\n>>> dm9000 janitor ppp skge viro\n>>\n>>\n>>\n>>\n>> 12) make desired branch current in working directory\n>>\n>> $ git checkout -f $branch\n>>\n>>\n>> 13) create a new branch, and make it current\n>>\n>> $ cp .git/refs/heads/master .git/refs/heads/my-new-branch-name\n>> $ git checkout -f my-new-branch-name\n>>\n>>\n>> 14) examine which branch is current\n>>\n>> $ ls -l .git/HEAD\n>>\n>>\n>> 15) undo all local modifications (same as checkout):\n>>\n>> $ git checkout -f\n>>\n>>\n>> 16) obtain a diff between current branch, and master branch\n>>\n>> In most trees WITH BRANCHES, .git/refs/heads/master contains the\n>> current 'vanilla' upstream tree, for easy diffing and merging. (in\n>> trees without branches, 'master' simply contains your latest changes)\n>>\n>> $ git-diff-tree -p master HEAD\n>>\n>>\n>> -\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>>\n> \n"}]}