{"thread":{"id":"296","subject":"A darcs that can pull from git","startedAt":"2005-04-24T22:32:18Z","lastAt":"2005-04-26T12:47:09Z","messageCount":7,"participants":["Juliusz Chroboczek","David Roundy","Linus Torvalds","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"1556","messageId":"7ipswjbybx.fsf@lanthane.pps.jussieu.fr","threadId":"296","inReplyTo":null,"subject":"A darcs that can pull from git","fromName":"Juliusz Chroboczek","fromEmail":"juliusz.chroboczek@pps.jussieu.fr","sentAt":"2005-04-24T22:32:18Z","receivedAt":"2005-04-24T22:32:18Z","isPatch":false,"sender":{"key":"juliusz.chroboczek@pps.jussieu.fr","avatar":null},"body":"I've just finished putting together a hack for darcs to allow it to\npull from Git repositories.  You'll find the patch (Darcs patch, not\ndiff patch) on\n\n  http://www.pps.jussieu.fr/~jch/software/files/darcs-git-20050424.darcs\n\nYou should get yourself a copy of darcs-unstable, then apply this\npatch:\n\n  $ darcs get http://www.abridgegame.org/repos/darcs-unstable darcs-git\n  $ cd darcs-git\n  $ darcs apply darcs-git-20050424.darcs\n  $ make darcs\n\nIf you get merge conflicts, try using a version of the darcs-unstable\ntree from 18.04.2005, which is what I started with.\n\nA minor problem: there's something broken with the build procedure;\nyou'll probably need to manually do a ``make Context.hs'' followed\nwith ``make darcs'' when the build breaks.\n\nAfter you build darcs-git, you should be able to do something like\n\n  $ cd ..\n  $ mkdir a\n  $ cd a\n  $ darcs initialize\n  $ ../darcs-git/darcs pull /usr/local/src/git-pasky-0.4\n  $ darcs changes\n\nThis version can *pull* from git, but it cannot push; in other words,\nthe only way to export your data from Darcs back to git is to use diff\nand patch.\n\nPlease be aware that this is just a proof-of-concept prototype.  David\nand the rest of the Central Committee haven't looked at this code yet;\nit is quite likely that future versions of Darcs will generate\ncompletely different patches from git repositories.  It is also likely\nthat THIS CODE WILL EAT YOUR DATA.\n\nThe major issue is that we generate no patch dependencies.  If you try\nto cherry-pick from repositories generated with this version, you'd\nbetter know what you're doing.\n\nDavid, could you please have a look at the patches\n\n  Sun Apr 24 16:50:02 CEST 2005  Juliusz Chroboczek <jch@pps.jussieu.fr>\n    * First cut at remodularising repo access.\n\n  Sun Apr 24 16:01:32 CEST 2005  Juliusz Chroboczek <jch@pps.jussieu.fr>\n    * Change Repository to DarcsRepo.\n\nand tell me whether this sort of restructuring is okay with you.\n\n(David, I'm not claiming that this scheme is better than the ``tagging\nlike crazy'' scheme that you outlined; I'm only trying to prove that\nmy scheme is workable.)\n\nRight now, I'm taking a Git commit and manually generating a Darcs\npatch id from that, which is a bad idea.  A better way would be to get\nDarcs to deal with arbitrarily shaped patch ids; a patch that\noriginates with git would get the git patch id, while a patch that\ncomes from Darcs would retain its patch id even when pushed to git.\nDavid, you had some objections to that; any chance we could discuss\nthe issue?\n\nThis is slow.  There are a few obvious improvements to make to the\nperformance, but I'd rather first implement whatsnew, diff and apply,\nand fix the problem with patch dependencies.  (Whatsnew is where git's\nperformance is actually likely to be better than Darcs, but it will\nrequire some abstracting of ``Slurpy'' in order to make that\neffective.)  Unfortunately, I don't expect to have hacking time before\nnext week-end.\n\n\nEnjoy,\n\n                                        Juliusz Chroboczek\n"},{"id":"1612","messageId":"20050425133116.GG11667@abridgegame.org","threadId":"296","inReplyTo":"7ipswjbybx.fsf@lanthane.pps.jussieu.fr","subject":"Re: A darcs that can pull from git","fromName":"David Roundy","fromEmail":"droundy@abridgegame.org","sentAt":"2005-04-25T13:31:20Z","receivedAt":"2005-04-25T13:31:20Z","isPatch":false,"sender":{"key":"droundy@abridgegame.org","avatar":"https://gravatar.com/avatar/e8bcfd76f63303732bdfcdba6fc8ac6ccdff8f5a224a25ffaca24bd8a4c4571f?d=mp&s=160"},"body":"On Mon, Apr 25, 2005 at 12:32:18AM +0200, Juliusz Chroboczek wrote:\n> I've just finished putting together a hack for darcs to allow it to\n> pull from Git repositories.  You'll find the patch (Darcs patch, not\n> diff patch) on\n\nVery cool! :)\n\n>   http://www.pps.jussieu.fr/~jch/software/files/darcs-git-20050424.darcs\n\nFirst off, you need to include a license header in the git files indicating\nthat unlike the rest of darcs, they may only be distributed under GPL v2.\nSomething like the following would probably be fine (but it's Linus'\ncopyright that's involved, not mine)\n\n/*\n * GIT - The information manager from hell\n *\n * Copyright (C) Linus Torvalds, 2005\n\n  This program is free software; you can redistribute it and/or modify\n  it under the terms of version 2 of the GNU General Public License as\n  published by the Free Software Foundation.\n\n  This program is distributed in the hope that it will be useful,\n  but WITHOUT ANY WARRANTY; without even the implied warranty of\n  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\n  GNU General Public License for more details.\n\n  You should have received a copy of the GNU General Public License\n  along with this program; if not, write to the Free Software Foundation,\n  Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.\n */\n\nWithout this header, it's either illegal to distribute these files, or\nthey're assumed to be under GPLv2 or later along with the rest of darcs,\nwhich also isn't legal...\n\n> I've just finished putting together a hack for darcs to allow it to\n> pull from Git repositories.  You'll find the patch (Darcs patch, not\n> diff patch) on\n>   http://www.pps.jussieu.fr/~jch/software/files/darcs-git-20050424.darcs\n\nAny chance you can host a gettable repository? If not, I'd be happy to give\nyou an account on darcs.net on which you could host darcs-git.\n\n> If you get merge conflicts, try using a version of the darcs-unstable\n> tree from 18.04.2005, which is what I started with.\n\nThere is a conflict in GNUMakefile, which is moderately easy to resolve.\nIt would be nice to keep files in alphabetical order (as is mostly\ncurrently the case, which has some small chance of reducing the likelihood\nof conflicts.\n\n> A minor problem: there's something broken with the build procedure;\n> you'll probably need to manually do a ``make Context.hs'' followed\n> with ``make darcs'' when the build breaks.\n\nOr alternatively run \"autoconf; ./configure; make\"\n\n> After you build darcs-git, you should be able to do something like\n> \n>   $ cd ..\n>   $ mkdir a\n>   $ cd a\n>   $ darcs initialize\n>   $ ../darcs-git/darcs pull /usr/local/src/git-pasky-0.4\n>   $ darcs changes\n\nDo you have any plans/ideas for allowing pulls directly from a remote git\nrepository? Obviously it'll be less efficient, since you'll have to\ndownload at least one file in its entirety.  Perhaps we could store a git\nmirror in _darcs and use rsync?  :(\n\n> David, could you please have a look at the patches\n> \n>   Sun Apr 24 16:50:02 CEST 2005  Juliusz Chroboczek <jch@pps.jussieu.fr>\n>     * First cut at remodularising repo access.\n> \n>   Sun Apr 24 16:01:32 CEST 2005  Juliusz Chroboczek <jch@pps.jussieu.fr>\n>     * Change Repository to DarcsRepo.\n> \n> and tell me whether this sort of restructuring is okay with you.\n\nThose two look fine to me.  I'm increasingly liking (as I get to understand\nit better) your ideas regarding modularizing repository access.\n\n> (David, I'm not claiming that this scheme is better than the ``tagging\n> like crazy'' scheme that you outlined; I'm only trying to prove that\n> my scheme is workable.)\n\nOkay, it does look like most of your code will be equally useful for the\n\"tagging like crazy\" scheme.\n\n> Right now, I'm taking a Git commit and manually generating a Darcs\n> patch id from that, which is a bad idea.  A better way would be to get\n> Darcs to deal with arbitrarily shaped patch ids; a patch that\n> originates with git would get the git patch id, while a patch that\n> comes from Darcs would retain its patch id even when pushed to git.\n> David, you had some objections to that; any chance we could discuss\n> the issue?\n\nWe certainly can discuss it, and I still object.  I think it'd be much\nbetter to map from git commits to darcs patch ids.  Your scheme and mine\nboth have uglinesses.\n\nMy \"tag like crazy\" scheme gives a unique mapping of a git commit to one\ndarcs patch and one darcs tag, but has the ugliness that a darcs patch\ncan't be mapped to a git commit without adding an additional darcs tag.  I\ntend to see this as a plus.  It reflects the fact semantic difference\nbetween a darcs patch and a git commit--the git commit is actually\nequivalent not to a darcs patch but rather a darcs tag.\n\nYour idea has the niceness that it could provide a one-to-one (as opposed\nto two-to-one) mapping between darcs patches and git commits, but the catch\nis that we don't know the git commit ID until after the patch has been\nmoved into git-land.  This is directly analagous to the wart in my scheme\nthat darcs patches would acquire a tag when moved into git-land.  I prefer\nmy scheme, since extra tags are relatively harmless, and reflect the\ndependencies in the git repository.\n\n> This is slow.  There are a few obvious improvements to make to the\n> performance, but I'd rather first implement whatsnew, diff and apply,\n> and fix the problem with patch dependencies.  (Whatsnew is where git's\n> performance is actually likely to be better than Darcs, but it will\n> require some abstracting of ``Slurpy'' in order to make that\n> effective.)  Unfortunately, I don't expect to have hacking time before\n> next week-end.\n\nAll right.  I'll look forward to another installment after next weekend\nthen!  :)\n\nI had a few minor comments on your code, which I've forgotten.  One was\nthat either you're compiling with ghc 6.2, or you've disabled\n-Werror... It'd be nice to be sure that your code is -Werror-clean with ghc\n6.4 as well.\n-- \nDavid Roundy\nhttp://www.darcs.net\n"},{"id":"1614","messageId":"7i4qdusxdw.fsf@lanthane.pps.jussieu.fr","threadId":"296","inReplyTo":"20050425133116.GG11667@abridgegame.org","subject":"Re: A darcs that can pull from git","fromName":"Juliusz Chroboczek","fromEmail":"juliusz.chroboczek@pps.jussieu.fr","sentAt":"2005-04-25T15:12:59Z","receivedAt":"2005-04-25T15:12:59Z","isPatch":false,"sender":{"key":"juliusz.chroboczek@pps.jussieu.fr","avatar":null},"body":">>   http://www.pps.jussieu.fr/~jch/software/files/darcs-git-20050424.darcs\n\n> First off, you need to include a license header in the git files indicating\n> that unlike the rest of darcs, they may only be distributed under GPL v2.\n\nLinus, could you please suggest a suitable license statement to\ninclude in whichever files of yours we choose to include in Darcs?  Is\nDavid's suggestion (stock GPL boilerplate with ``or any later\nversion'' removed) okay with you?\n\n> Any chance you can host a gettable repository?\n\nThe last tag in darcs-unstable is 1.0.0rc2, which prevents me from\npublishing a partial repository in my web space.  Perhaps you could\npull a recent tag into darcs-unstable?\n\n> If not, I'd be happy to give you an account on darcs.net on which\n> you could host darcs-git.\n\nThat would be great (let me know if you need an ssh public key).\n\n> Do you have any plans/ideas for allowing pulls directly from a\n> remote git repository?\n\nI haven't thought about it yet.  Does anyone have any ideas about how\nto efficiently pull from git without a complete local copy?\n\nI'll reply to the more technical points below on darcs-devel -- no\npoint in spamming the kind folks on git@ any further, especially as\nthey probably know about\n\n  http://www.abridgegame.org/pipermail/darcs-devel/\n\n                                        Juliusz\n\n"},{"id":"1684","messageId":"Pine.LNX.4.58.0504251752570.18901@ppc970.osdl.org","threadId":"296","inReplyTo":"7i4qdusxdw.fsf@lanthane.pps.jussieu.fr","subject":"Re: A darcs that can pull from git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-26T00:55:22Z","receivedAt":"2005-04-26T00:55:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n[ Side note: I tend to read the mailing lists much less often, and more \n  likely to skip stuff, so if you have a question that is literally for me \n  personally, it's probably best to Cc my private address rather than \n  depending on me reading every single mailing list email ]\n\nOn Mon, 25 Apr 2005, Juliusz Chroboczek wrote:\n> \n> Linus, could you please suggest a suitable license statement to\n> include in whichever files of yours we choose to include in Darcs?  Is\n> David's suggestion (stock GPL boilerplate with ``or any later\n> version'' removed) okay with you?\n\nStock GNU boilerplate without the \"or any later version\" works fine. \n\nAs does a simple one-liner \"Licensed under GPLv2\", for that matter. It's \nnot like there can be any real confusion.\n\n\t\tLinus\n"},{"id":"1728","messageId":"20050426110613.GB20723@abridgegame.org","threadId":"296","inReplyTo":"7i4qdusxdw.fsf@lanthane.pps.jussieu.fr","subject":"Re: Re: A darcs that can pull from git","fromName":"David Roundy","fromEmail":"droundy@abridgegame.org","sentAt":"2005-04-26T11:06:17Z","receivedAt":"2005-04-26T11:06:17Z","isPatch":false,"sender":{"key":"droundy@abridgegame.org","avatar":"https://gravatar.com/avatar/e8bcfd76f63303732bdfcdba6fc8ac6ccdff8f5a224a25ffaca24bd8a4c4571f?d=mp&s=160"},"body":"On Mon, Apr 25, 2005 at 05:12:59PM +0200, Juliusz Chroboczek wrote:\n> > Do you have any plans/ideas for allowing pulls directly from a\n> > remote git repository?\n> \n> I haven't thought about it yet.  Does anyone have any ideas about how\n> to efficiently pull from git without a complete local copy?\n\nI don't think so.  My best thought so far would be to have something like a\n~/.gitcache/, which would store the sha1 objects themselves, so at least\nwe'd only end up with *one* local copy.  I'm actually curious what the true\ngit people do about this--it would be nice to share a cache.  For darcs'\npurposes, we could prune the cache from time to time.  If we're running\nwith a darcs backend, we really only need the recent versions of files and\ntrees.\n\nDo the git have any suggestions about how to avoid excess downloads or\nexcess copies of a git repository? It seems to me like it would make sense\nto always download sha1s to ~/.gitcache/, and then hardlink them to the\ncurrent git repository, so you wouldn't end up ever downloading the same\nsha1 twice.  Or we should use $GITCACHE/, to give the user some\nflexibility.  But perhaps this is an already-solved problem, and I've just\nnot noticed...\n\nAs far as other details, currently we can just walk the tree to find out\nwhat files are needed, right?\n-- \nDavid Roundy\nhttp://www.darcs.net\n"},{"id":"1731","messageId":"20050426123445.GE18971@pasky.ji.cz","threadId":"296","inReplyTo":"20050426110613.GB20723@abridgegame.org","subject":"Re: Re: A darcs that can pull from git","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-26T12:34:45Z","receivedAt":"2005-04-26T12:34:45Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Apr 26, 2005 at 01:06:17PM CEST, I got a letter\nwhere David Roundy <droundy@abridgegame.org> told me that...\n> On Mon, Apr 25, 2005 at 05:12:59PM +0200, Juliusz Chroboczek wrote:\n> > > Do you have any plans/ideas for allowing pulls directly from a\n> > > remote git repository?\n> > \n> > I haven't thought about it yet.  Does anyone have any ideas about how\n> > to efficiently pull from git without a complete local copy?\n> \n> I don't think so.  My best thought so far would be to have something like a\n> ~/.gitcache/, which would store the sha1 objects themselves, so at least\n> we'd only end up with *one* local copy.  I'm actually curious what the true\n> git people do about this--it would be nice to share a cache.  For darcs'\n> purposes, we could prune the cache from time to time.  If we're running\n> with a darcs backend, we really only need the recent versions of files and\n> trees.\n> \n> Do the git have any suggestions about how to avoid excess downloads or\n> excess copies of a git repository? It seems to me like it would make sense\n> to always download sha1s to ~/.gitcache/, and then hardlink them to the\n> current git repository, so you wouldn't end up ever downloading the same\n> sha1 twice.  Or we should use $GITCACHE/, to give the user some\n> flexibility.  But perhaps this is an already-solved problem, and I've just\n> not noticed...\n\nI'm not sure about the problem you are actually trying to solve, and I\ndidn't manage to guess it quickly just from the mails themselves;\ncg-init /local/path now hardlinks the sha1 objects to the local\n.git/objects directory, so you get no space waste. If you are talking\nabout downloading stuff from remote repositories, http-pull might help.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"1733","messageId":"20050426124704.GB28120@abridgegame.org","threadId":"296","inReplyTo":"20050426123445.GE18971@pasky.ji.cz","subject":"Re: [darcs-devel] Re: A darcs that can pull from git","fromName":"David Roundy","fromEmail":"droundy@abridgegame.org","sentAt":"2005-04-26T12:47:09Z","receivedAt":"2005-04-26T12:47:09Z","isPatch":false,"sender":{"key":"droundy@abridgegame.org","avatar":"https://gravatar.com/avatar/e8bcfd76f63303732bdfcdba6fc8ac6ccdff8f5a224a25ffaca24bd8a4c4571f?d=mp&s=160"},"body":"On Tue, Apr 26, 2005 at 02:34:45PM +0200, Petr Baudis wrote:\n> Dear diary, on Tue, Apr 26, 2005 at 01:06:17PM CEST, I got a letter\n> where David Roundy <droundy@abridgegame.org> told me that...\n> > Do the git have any suggestions about how to avoid excess downloads or\n> > excess copies of a git repository? It seems to me like it would make sense\n> > to always download sha1s to ~/.gitcache/, and then hardlink them to the\n> > current git repository, so you wouldn't end up ever downloading the same\n> > sha1 twice.  Or we should use $GITCACHE/, to give the user some\n> > flexibility.  But perhaps this is an already-solved problem, and I've just\n> > not noticed...\n> \n> I'm not sure about the problem you are actually trying to solve, and I\n> didn't manage to guess it quickly just from the mails themselves;\n> cg-init /local/path now hardlinks the sha1 objects to the local\n> .git/objects directory, so you get no space waste. If you are talking\n> about downloading stuff from remote repositories, http-pull might help.\n\nYeah, what I was wondering about was the scenario where a user does (and\npardon any errors, I haven't actually used cogito) something like\n\ncd foo\ncg-init http://remote_repository\ncd ../bar\ncg-init ../foo\n\n(so far we've only got hard links and everything is great)\n\nhttp-pull http://remote_repository (downloads a few more commits to bar)\ncd ../foo\nhttp-pull http://remote_repository\n\nDoes this last pull download the same commits as the previous one? Ideally\nit wouldn't.  The whole point of the sha1-named files is that you don't\nhave to worry about where you got it from.  Ideally the second pull would\nget the actual files from ../bar, where they've already been downloaded.\n\nOr perhaps (and this was what I was *really* hoping) all the cogito remote\noperations would store a hardlink of their results in a common cache\ndirectory, so that one could actually do\n\ncd foo\ncg-init http://remote_repository\ncd ../bar\ncg-init http://remote_repository\n\nwithout either downloading anything twice, or wasting any disk space.  In\npractice what's more likely in practice is that you'll want to\n\ncd foo\ncg-init http://linus_remote_repository\ncd ../bar\ncg-init http://gregkh_remote_repository\n\nand would like to avoid downloading redundant info.\n-- \nDavid Roundy\nhttp://www.darcs.net\n"}]}