{"thread":{"id":"16046","subject":"[VOTE] git versus mercurial","startedAt":"2008-10-26T04:28:24Z","lastAt":"2008-11-06T17:41:50Z","messageCount":65,"participants":["walt","Jakub Narebski","Maxim Vuets","Leo Razoumov","Felipe Contreras","Arne Babenhauserheide","dhruva","Benoit Boissinot","Leslie P. Polzer","David Soria Parra","0000 vk","Brandon Casey","Miklos Vajna","Nicolas Pitre","Johannes Schindelin","Peter Krefting","Matthieu Moy","Pieter de Bie","Andreas Ericsson","Randal L. Schwartz","SZEDER Gábor","Theodore Tso","Miles Bader","Shawn O. Pearce","Boyd Lynn Gerber","Florian Weimer","Santi Béjar","Linus Torvalds","Marcin Kasperski","Isaac Jurado"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"93955","messageId":"ge0rla$mce$1@ger.gmane.org","threadId":"16046","inReplyTo":null,"subject":"[VOTE] git versus mercurial","fromName":"walt","fromEmail":"w41ter@gmail.com","sentAt":"2008-10-26T04:28:24Z","receivedAt":"2008-10-26T04:28:24Z","isPatch":false,"sender":{"key":"w41ter@gmail.com","avatar":null},"body":"No, no, I'm not the one calling for a vote. You old-timers here\nwill know the name Matt Dillon, who is leading the dragonflybsd\nproject (www.dragonflybsd.org).\n\nMatt is the one who is calling for the vote in his thread \"Vote\nfor your source control system\" in the dragonfly.kernel group,\naccessible via nntp://nntp.dragonflybsd.org.\n\nI've already cast my vote for git, which I confess is not very\nhonest because I've never even tried mercurial. I would truly\nbe grateful to anyone here who knows both git and mercurial who\ncould contribute verifiable facts to that debate.\n\nThanks.\n"},{"id":"93979","messageId":"m3r663h276.fsf@localhost.localdomain","threadId":"16046","inReplyTo":"ge0rla$mce$1@ger.gmane.org","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-26T14:15:57Z","receivedAt":"2008-10-26T14:15:57Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: gmane.comp.version-control.git,\n gmane.comp.version-control.mercurial.general]\n\nwalt writes:\n\n> No, no, I'm not the one calling for a vote. You old-timers here\n> will know the name Matt Dillon, who is leading the dragonflybsd\n> project (www.dragonflybsd.org).\n> \n> Matt is the one who is calling for the vote in his thread \"Vote\n> for your source control system\" in the dragonfly.kernel group,\n> accessible via nntp://nntp.dragonflybsd.org.\n> \n> I've already cast my vote for git, which I confess is not very\n> honest because I've never even tried mercurial. I would truly\n> be grateful to anyone here who knows both git and mercurial who\n> could contribute verifiable facts to that debate.\n\nI also used only Git, but I have read a bit about Mercurial; however\nthe information I have on Mercurial might be out of date.\n\nBelow I have tried to compare Git with Mercurial, pointing the most\nimportant (to me) facts:\n\n1. Documentation and ease of use. \n\n Mercurial is supposedly better documented and easier to use; I\n think this descends from the early days of Git, where it was not\n very user friendly. IMHO Git has much improved since. Mercurial\n had 'hgbook' from the beginning; Git User's Manual is more recent.\n\n I also think that ease of use is just different learning curve.\n I am also biased and I think that Mercurial starts easy, but it has\n more difficult things (like e.g. merging, multiple branches in\n single repository etc.) harder than it Git.\n\n I'll admit that Mercurial UI is better designed; Git UI was not as\n much designed as it evolved from 'stupid content tracker' to\n full-featured SCM, therefore there are a few oddities (for example\n git-revert might do not what you expect, if you are accustomed to\n Subversion UI).\n\n2. Implementation, portability, bindings and extending\n\n Mercurial is implemented in Python, with core written in C for\n better performance. It has a plugin system, and additional extra\n features implemented through extensions. I don't know what is the\n status of bindings (or implementations) in other programming\n languages; but it has some API for use in extensions at least.\n\n Git is implemented as mixture of C, shell scripts, Perl and Tcl/Tk\n (for GUI). The main way of extending it is by scripting around\n powerfull set of low level tools, called 'plumbing', meant to be\n used in scripts. JGit is for example _reimplementation_ of Git in\n Java.\n\n3. Repository design and performance.\n\n Git is designed around idea of content adressed object database;\n objects are adressed by their content (by SHA-1 of their type and\n content). Commits for example have information about author and\n comitter, pointer to zero or more parent commits, and pointer to\n tree object (representing top directory in project). Branches\n and tags are just pointers to DAG (Direct Acyclic Graph) of\n commits; current branch is denoted by HEAD pointer to branch.\n There is explicit staging area called 'index', used for conflict\n resolution dureing merges, and which can be used to make commit in\n stages, allow uncomitted changes in tree (in working directory).\n Git design supports very well multiple branches in single\n repository, and tracking changes in multiple remote repositories\n each with multiple branches.\n\n Mercurial, from what I have read of its documentation, and from the\n few discussion on #revctrl IRC channel, and from what I understand\n is based on changes stored per file, with information about files\n and their versions stored in manifest (flat) file, and with changes\n described in changelog-like file (changerev). One of limitations\n of \"record\" database (as opposed to Git's object database) is that\n commits can have zero (root commit), one or two (merge commits)\n parents only. There is apparent in design that Mercurial was\n developed with single branch per repository paradigm in mind.\n Local branches from what I understand are marked in CVS-like\n fashion using tags. Tags are implemented as either local to\n repository and untransferable, or as .hgtags versioned file with\n special case treatment. (But I'm obviously biased here).\n\n Git and Mercurial have similar performance, although it is thought\n that due to design Mercurla has faster patch applying and is\n optimized for cold cache case, while Git has faster merging and is\n optimized for warm cache case.\n\n Mercurial may have (or had) problems with larger binary files, from\n what I have heard.\n\n3. Advanced features, interfaces and tools\n\n I don't know much about Mercurial beside basic usage, what I\n remember from 'hgbook', but I think that most if not all advanced\n Git features are available either in Mercurial core, or as\n Mercurial extensions (plugins).\n\n For example both Git and Mercurial have bisect command for finding\n bug by searching (possibly nonlinear) history for commit which\n introduced bug, ForestExtension is rough equivalent of git\n submodules (or third party git-externals), there is Transplain\n extension for git-rebase, etc.\n\n Mercurial has hgserve which can function as both web repository\n browser and as anonymous server; in Git they are split between\n git-daemon for anonymous repository access, and gitweb (or other\n web interfaces: cgit, git-php, ViewGit, Gitorious,..) for web\n interface.\n\n NOTE: In Git repacking and garbage collecting is explicit\n (although can be automated with \"git gc --auto\", and some of it\n happens automatically); Git use _rename detection_ rather than\n _rename tracking_, which has its advantages and disadvantages.\n\n\nThey are many articles comparing Mercurial and Git; if they are blog\nposts please read the comments too. Among them are:\n* \"Git vs. Mercurial: Please Relax\" (Git is MacGyver, Mercurial\n is James Bond)\n http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/\n* \"The Differences Between Mercurial and Git\"\n http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/\n* \"Git vs. Mercurial\"\n http://blog.experimentalworks.net/archives/38-Git-vs.-Mercurial.html\n* \"Git versus Mercurial...\"\n http://codeheadsystems.wordpress.com/2008/05/10/git-versus-mercurial/\n* \"Git vs Mercurial\"\n http://www.simplicidade.org/notes/archives/2007/12/git_vs_mercuria_1.html\n\nNote however that the comparison at \"Better SCM Initiative\" has some\nwrong information about Git: see\n* \"Git at Better SCM Initiative comparison of VCS (long)\"\n http://thread.gmane.org/gmane.comp.version-control.git/95809/focus=97253\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"93980","messageId":"e15351d00810260730t1552e04cqb057993581514f3b@mail.gmail.com","threadId":"16046","inReplyTo":"m3r663h276.fsf@localhost.localdomain","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Maxim Vuets","fromEmail":"maxim.vuets@gmail.com","sentAt":"2008-10-26T14:30:27Z","receivedAt":"2008-10-26T14:30:27Z","isPatch":false,"sender":{"key":"maxim.vuets@gmail.com","avatar":null},"body":"On 26 Oct 2008 15:15:57 +0100, Jakub Narebski wrote:\n> 1. Documentation and ease of use.\n>\n> Mercurial is supposedly better documented and easier to use; I\n> think this descends from the early days of Git, where it was not\n> very user friendly. IMHO Git has much improved since. Mercurial\n> had 'hgbook' from the beginning; Git User's Manual is more recent.\n\nAlso, there is http://book.git-scm.com/ that is similar to hgbook, I think.\n\nThanks for the comprarision!\n\n-- \n . Hoc est simplicissimum!\n..: maxim.vuets.name\n"},{"id":"93982","messageId":"ee2a733e0810260805n35c3a637v4739dda938a22518@mail.gmail.com","threadId":"16046","inReplyTo":"e15351d00810260730t1552e04cqb057993581514f3b@mail.gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2008-10-26T15:05:21Z","receivedAt":"2008-10-26T15:05:21Z","isPatch":false,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On 10/26/08, Maxim Vuets wrote:\n> On 26 Oct 2008 15:15:57 +0100, Jakub Narebski wrote:\n> > 1. Documentation and ease of use.\n> >\n> > Mercurial is supposedly better documented and easier to use; I\n> > think this descends from the early days of Git, where it was not\n> > very user friendly. IMHO Git has much improved since. Mercurial\n> > had 'hgbook' from the beginning; Git User's Manual is more recent.\n>\n>\n> Also, there is http://book.git-scm.com/ that is similar to hgbook, I think.\n>\n> Thanks for the comprarision!\n\nI have been using Mercurial for about two years and am very\ncomfortable with it. Here are some cons and pros\n\nMercurial PROS:\n* Easier and more consistent UI. Newbie friendly.\n* Better documentation. IMHO, hgbook is by far better than\nhttp://book.git-scm.com/\n* Windows support (personally, I do not care)\n\nMercurial CONS:\n* Less potential than git. Once Ted Tso even said that \"git has more\nlegs than mercurial\", see\nhttp://thunk.org/tytso/blog/2007/03/24/git-and-hg/\n* Hg is strictly an SCM system while GIT is a content addressable file\nsystem that can be used in other ways, hence the name Global\nInformation Tracker (GIT)\n* Recently, Hg development seems to have somewhat slowed down. To\nsimply put it, there is not enough room in the world for several\nsimilar SCM systems. With git's pace and momentum the other SCMs\nincluding Hg are fighting an uphill battle.\n\nJust my two cents.\n--Leo--\n"},{"id":"93984","messageId":"94a0d4530810260857u7c0cb122g8147b9484108f539@mail.gmail.com","threadId":"16046","inReplyTo":"m3r663h276.fsf@localhost.localdomain","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-10-26T15:57:21Z","receivedAt":"2008-10-26T15:57:21Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski wrote:\n> [Cc: gmane.comp.version-control.git,\n> gmane.comp.version-control.mercurial.general]\n>\n> walt writes:\n>\n>> No, no, I'm not the one calling for a vote. You old-timers here\n>> will know the name Matt Dillon, who is leading the dragonflybsd\n>> project (www.dragonflybsd.org).\n>>\n>> Matt is the one who is calling for the vote in his thread \"Vote\n>> for your source control system\" in the dragonfly.kernel group,\n>> accessible via nntp://nntp.dragonflybsd.org.\n>>\n>> I've already cast my vote for git, which I confess is not very\n>> honest because I've never even tried mercurial. I would truly\n>> be grateful to anyone here who knows both git and mercurial who\n>> could contribute verifiable facts to that debate.\n\n\n\n> 3. Repository design and performance.\n>\n> Git is designed around idea of content adressed object database;\n> objects are adressed by their content (by SHA-1 of their type and\n> content). Commits for example have information about author and\n> comitter, pointer to zero or more parent commits, and pointer to\n> tree object (representing top directory in project). Branches\n> and tags are just pointers to DAG (Direct Acyclic Graph) of\n> commits; current branch is denoted by HEAD pointer to branch.\n> There is explicit staging area called 'index', used for conflict\n> resolution dureing merges, and which can be used to make commit in\n> stages, allow uncomitted changes in tree (in working directory).\n> Git design supports very well multiple branches in single\n> repository, and tracking changes in multiple remote repositories\n> each with multiple branches.\n>\n> Mercurial, from what I have read of its documentation, and from the\n> few discussion on #revctrl IRC channel, and from what I understand\n> is based on changes stored per file, with information about files\n> and their versions stored in manifest (flat) file, and with changes\n> described in changelog-like file (changerev). One of limitations\n> of \"record\" database (as opposed to Git's object database) is that\n> commits can have zero (root commit), one or two (merge commits)\n> parents only. There is apparent in design that Mercurial was\n> developed with single branch per repository paradigm in mind.\n> Local branches from what I understand are marked in CVS-like\n> fashion using tags. Tags are implemented as either local to\n> repository and untransferable, or as .hgtags versioned file with\n> special case treatment. (But I'm obviously biased here).\n>\n> Git and Mercurial have similar performance, although it is thought\n> that due to design Mercurla has faster patch applying and is\n> optimized for cold cache case, while Git has faster merging and is\n> optimized for warm cache case.\n>\n> Mercurial may have (or had) problems with larger binary files, from\n> what I have heard.\n\nThe fact that hg is changeset based means that certain operations are\nslower, like checkout a specific commit. In hg my bet is you would\nneed to gather a bunch of changesets while in git the operation is\ndone in a single step.\n\nIt also means that bare clones are not possible in hg, or at least\nvery complicated.\n\nNote: I'm not sure if what I'm claiming is correct.\n\n-- \nFelipe Contreras\n"},{"id":"93994","messageId":"200810261955.10536.jnareb@gmail.com","threadId":"16046","inReplyTo":"ee2a733e0810260805n35c3a637v4739dda938a22518@mail.gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-26T18:55:09Z","receivedAt":"2008-10-26T18:55:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"I'm not sure if Mercurial mailing list is not subscribe only. Git isn't.\n\nOn Sun, 26 Oct 2008, Leo Razoumov wrote:\n> On 10/26/08, Maxim Vuets wrote:\n>> On 26 Oct 2008 15:15:57 +0100, Jakub Narebski wrote:\n>>>\n>>> 1. Documentation and ease of use.\n>>>\n>>> Mercurial is supposedly better documented and easier to use; I\n>>> think this descends from the early days of Git, where it was not\n>>> very user friendly. IMHO Git has much improved since. Mercurial\n>>> had 'hgbook' from the beginning; Git User's Manual is more recent.\n>>\n>> Also, there is http://book.git-scm.com/ that is similar to hgbook, I think.\n>>\n>> Thanks for the comprarision!\n> \n> I have been using Mercurial for about two years and am very\n> comfortable with it. Here are some cons and pros\n> \n> Mercurial PROS:\n> * Easier and more consistent UI. Newbie friendly.\n\nI think that _might_ be example of \"Worse is better\" scenario, with Git\nhaving UI which evolved rather than was designed, and therefore less\nconsistent.\n\nAlso if you are limiting to what is described in main chapters of\n'hgbook', namely one branch (one \"fork\") per repository paradigm\neverything is simpler.\n\n> * Better documentation. IMHO, hgbook is by far better than\n> http://book.git-scm.com/\n\nAnd probably better than \"Git User's Manual\". There are lot of various\ngit-related documentation: \"Git Magic\", \"Git for Computer Scientists\",\n\"Git from bottoms up\"...\n\n> * Windows support (personally, I do not care)\n\nAnd I think it is not important for DragonflyBSD.\n\nBesides git _has_ MS Windows support, in the form of Cygwin and in the\nform of msysGit project. It is still not as full as Linux support (for\nexample git-svn comes to mind), but it is not bad. Well, Mercurial\nhas TortiouseHg, while Git-Cheetah is in very early stages...\n\n> \n> Mercurial CONS:\n> * Less potential than git. Once Ted Tso even said that \"git has more\n> legs than mercurial\", see\n> http://thunk.org/tytso/blog/2007/03/24/git-and-hg/\n\nI agree, and I think it is at least partially because of Git having\ncleaner design, even if you have to understand more terms at first.\n\n> * Hg is strictly an SCM system while GIT is a content addressable file\n> system that can be used in other ways, hence the name Global\n> Information Tracker (GIT)\n\nErrr... I think you are mislead by tongue-in-cheek backronym, which was\ncreated in the beginning, when git had very weak porcelain (i.e. SCM UI).\n\n> * Recently, Hg development seems to have somewhat slowed down. To\n> simply put it, there is not enough room in the world for several\n> similar SCM systems. With git's pace and momentum the other SCMs\n> including Hg are fighting an uphill battle.\n\nThe competing _distributed_ version control systems left seems to be\nBazaar-NG (Ubuntu), Mercurial (OpenSolaris, Mozilla), Git (Linux kernel,\nFreedesktop.org, Ruby on Rails people). There are many IDEs, many\neditors, many web browsers; there is Linux and there are *BSD; I hope\nthat Mercurial would continue to be developed, and not vanish in\nobscurity like Arch and clones...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"93995","messageId":"200810262007.30148.jnareb@gmail.com","threadId":"16046","inReplyTo":"94a0d4530810260857u7c0cb122g8147b9484108f539@mail.gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-26T19:07:29Z","receivedAt":"2008-10-26T19:07:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"I'm not sure if Mercurial mailing list is not subscribe only. Git isn't.\n\nOn Sun, 26 Sep 2008, Felipe Contreras wrote:\n> On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski wrote:\n> > [Cc: gmane.comp.version-control.git,\n> > gmane.comp.version-control.mercurial.general]\n\n> > 3. Repository design and performance.\n\n> > Git and Mercurial have similar performance, although it is thought\n> > that due to design Mercurial has faster patch applying and is\n> > optimized for cold cache case, while Git has faster merging and is\n> > optimized for warm cache case.\n> >\n> > Mercurial may have (or had) problems with larger binary files, from\n> > what I have heard.\n> \n> The fact that hg is changeset based means that certain operations are\n> slower, like checkout a specific commit. In hg my bet is you would\n> need to gather a bunch of changesets while in git the operation is\n> done in a single step.\n\nActually from what I have read Mercurial stores current version\n(snapshot) from time to time, so time to resolve specific commit is\nlimited. Also if you have packed your Git repository (good idea not\nonly to limit size, but also for performance (I/O performance)), then\nresolving specific commit also might require some delta resolution\n(by default delta chain length is limited to 50, see pack.depth).\n \n> It also means that bare clones are not possible in hg, or at least\n> very complicated.\n\nI think it is things like .hgtags which make bare clones (without\nworking directory) to be hard or even impossible in Mercurial.\n\n> Note: I'm not sure if what I'm claiming is correct.\n\nHmmm...\n-- \nJakub Narebski\nPoland\n"},{"id":"93998","messageId":"94a0d4530810261254m3668f02ek461fd220805f9b92@mail.gmail.com","threadId":"16046","inReplyTo":"200810262007.30148.jnareb@gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-10-26T19:54:53Z","receivedAt":"2008-10-26T19:54:53Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Oct 26, 2008 at 9:07 PM, Jakub Narebski wrote:\n> I'm not sure if Mercurial mailing list is not subscribe only. Git isn't.\n>\n> On Sun, 26 Sep 2008, Felipe Contreras wrote:\n>> On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski wrote:\n>> > [Cc: gmane.comp.version-control.git,\n>> > gmane.comp.version-control.mercurial.general]\n>\n>> > 3. Repository design and performance.\n>\n>> > Git and Mercurial have similar performance, although it is thought\n>> > that due to design Mercurial has faster patch applying and is\n>> > optimized for cold cache case, while Git has faster merging and is\n>> > optimized for warm cache case.\n>> >\n>> > Mercurial may have (or had) problems with larger binary files, from\n>> > what I have heard.\n>>\n>> The fact that hg is changeset based means that certain operations are\n>> slower, like checkout a specific commit. In hg my bet is you would\n>> need to gather a bunch of changesets while in git the operation is\n>> done in a single step.\n>\n> Actually from what I have read Mercurial stores current version\n> (snapshot) from time to time, so time to resolve specific commit is\n> limited. Also if you have packed your Git repository (good idea not\n> only to limit size, but also for performance (I/O performance)), then\n> resolving specific commit also might require some delta resolution\n> (by default delta chain length is limited to 50, see pack.depth).\n\nAh, ok, good to know.\n\n>> It also means that bare clones are not possible in hg, or at least\n>> very complicated.\n>\n> I think it is things like .hgtags which make bare clones (without\n> working directory) to be hard or even impossible in Mercurial.\n\nOops, I meant shallow clones (git clone --depth=1).\n\n-- \nFelipe Contreras\n"},{"id":"94009","messageId":"200810270120.55276.arne_bab@web.de","threadId":"16046","inReplyTo":"200810261955.10536.jnareb@gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Arne Babenhauserheide","fromEmail":"arne_bab@web.de","sentAt":"2008-10-27T00:20:49Z","receivedAt":"2008-10-27T00:20:49Z","isPatch":false,"sender":{"key":"arne_bab@web.de","avatar":"https://gravatar.com/avatar/4c060d566fc1b86d9ee5a5548bdc93436759676024e99f3e91191f32d38086d3?d=mp&s=160"},"body":"Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:\n> > * Recently, Hg development seems to have somewhat slowed down. To\n> > simply put it, there is not enough room in the world for several\n> > similar SCM systems. With git's pace and momentum the other SCMs\n> > including Hg are fighting an uphill battle.\n>\n> The competing _distributed_ version control systems left seems to be\n> Bazaar-NG (Ubuntu), Mercurial (OpenSolaris, Mozilla), Git (Linux kernel,\n> Freedesktop.org, Ruby on Rails people). There are many IDEs, many\n> editors, many web browsers; there is Linux and there are *BSD; I hope\n> that Mercurial would continue to be developed, and not vanish in\n> obscurity like Arch and clones...\n\nBefore we get tangled in this train of thought: \n\nI created a head-to-head code_swarm of Mercurial and Git and it clearly shows \nthat Mercurial development didn't slow down. \n\nThe code_swarm isn't a fancy one with music and annotations, but I think \nyou'll directly see for yourself what I mean: \n\n- http://www.rakjar.de/shared_codeswarm/hg-vs-git-short.avi\n\nred is git, \nblue is Mercurial. \n\nIt is a result of my shared_codeswarm project with which you can create \ncode_swarms from more than one repository automatically - and update them \nincrementally, creating new code_swarms of only the new commits in the \nrepositories: \n\n- http://www.rakjar.de/shared_codeswarm/project_activity_battle_swarm.html\n\nBest wishes, \nArne\n\n-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)\n-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the \nhistory of free software.\n-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.\n\n-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt\n"},{"id":"94011","messageId":"200810270147.52490.arne_bab@web.de","threadId":"16046","inReplyTo":"200810261955.10536.jnareb@gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Arne Babenhauserheide","fromEmail":"arne_bab@web.de","sentAt":"2008-10-27T00:47:46Z","receivedAt":"2008-10-27T00:47:46Z","isPatch":false,"sender":{"key":"arne_bab@web.de","avatar":"https://gravatar.com/avatar/4c060d566fc1b86d9ee5a5548bdc93436759676024e99f3e91191f32d38086d3?d=mp&s=160"},"body":"Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:\n> I agree, and I think it is at least partially because of Git having\n> cleaner design, even if you have to understand more terms at first.\n\nWhat do you mean by \"cleaner design\"? \n\nFrom what I see (and in my definition of \"design\"), Mercurial is designed as \nVCS with very clear and clean design, which even keeps things like streaming \ndisk access in mind. \n\nAlso, looking at git, git users still have to garbage collect regularly, which \nshows to me that the design wasn't really cleaner. \n\nAs an example: If I want some revision in hg, my repository just reads the \nfiles in the store, jumps to the latest snapshots, adds the changes after \nthese and has the data. \n\nIn git is has to check all changesets which affect the file. \n\nIf you read the hgbook, you'll find one especially nice comment: \n\n\"Unlike many revision control systems, the concepts upon which Mercurial is \nbuilt are simple enough that it’s easy to understand how the software really \nworks. Knowing this certainly isn’t necessary, but I find it useful to have a \n“mental model” of what’s going on.\"\n- http://hgbook.red-bean.com/hgbookch4.html\n\nI really like that, and in my opinion it is a great compliment to hg, for two \nreasons: \n\n1) Hg is easy to understand\n2) You don't have to understand it to use it\n\nAnd both are indications of a good design, the first of the core, the second \nof the UI. \n\nBest wishes, \nArne\n\n-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)\n-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the \nhistory of free software.\n-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.\n\n-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt\n"},{"id":"94012","messageId":"200810270252.23392.jnareb@gmail.com","threadId":"16046","inReplyTo":"200810270147.52490.arne_bab@web.de","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-27T01:52:22Z","receivedAt":"2008-10-27T01:52:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:\n> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:\n> >\n> > I agree, and I think it is at least partially because of Git having\n> > cleaner design, even if you have to understand more terms at first.\n> \n> What do you mean by \"cleaner design\"? \n\nClean _underlying_ design. Git has very nice underlying model of graph\n(DAG) of commits (revisions), and branches and tags as pointers to this\ngraph.\n\n> From what I see (and in my definition of \"design\"), Mercurial is designed as \n> VCS with very clear and clean design, which even keeps things like streaming \n> disk access in mind. \n\nI have read description of Mercurial's repository format, and it is not\nvery clear in my opinion. File changesets, bound using manifest, bound\nusing changerev / changelog.\n\nMercurial relies on transactions and O_TRUNC support, while Git relies\non atomic write and on updating data then updating reference to data.\n\nI don't quite understand comment about streaming disk access...\n\n> Also, looking at git, git users still have to garbage collect regularly, which \n> shows to me that the design wasn't really cleaner. \n\nWell, they have to a lot less than they used to, and there is \n\"git gc --auto\" that can be put in crontab safely.\n\nExplicit garbage collection was a design _decision_, not a sign of not\nclear design. We can argue if it was good or bad decision, but one\nshould consider the following issues:\n\n * Rolling back last commit to correct it, or equivalently amending\n last commit (for example because we forgot some last minute change,\n or forgot to signoff a commit), or backing out of changes to the\n last commit in Mercurial relies on transactions (and locking) and\n correct O_TRUNC, while in Git it leaves dangling objects to be\n garbage collected later.\n\n * Mercurial relies on transaction support. Git relies on atomic write\n support and on the fact that objects are immutable; those that are\n not needed are garbage collected later. Beside IIRC some of ways of\n implementing transaction in databases leads to garbage collecting.\n\n * Explicit packing and having two repository \"formats\": loose and\n packed is a bit of historical reason: at the beginning there was\n only loose format. Pack format was IIRC invented for network\n transport, and was used for on disk storage (the same format!) for\n better I/O patterns[1]. Having packs as 'rewrite to pack' instead\n of 'append to pack' allows to prefer recency order, which result in\n faster access as objects from newer commits are earlier in delta\n chain and reduction in size in usual case of size growing with time\n as recency order allows to use delete deltas. Also _choosing_ base\n object allows further reduce size, especially in presence of\n nonlinear history.\n\n * From what I understand Mercurial by default uses packed format for\n branches and tags; Git uses \"loose\" format for recent branches\n (meaning one file per branch), while packing older references.\n Using loose affects performance (and size) only for insane number of\n references, and only for some operations like listing all references,\n while using packed format is IMHO a bit error prone when updating.\n\n * Git has reflogs which are pruned (expired) during garbage collecting\n to not grow them without bounds; AFAIK Mercurial doesn't have\n equivalent of this feature.\n\n (Reflogs store _local_ history of branch tip, noting commits, \n fetches, merges, rewinding branch, switching branches, etc._\n\n[1] You wrote about \"streaming disk access\". Git relies (for reading)\non good mmap implementation.\n\n> As an example: If I want some revision in hg, my repository just reads the \n> files in the store, jumps to the latest snapshots, adds the changes after \n> these and has the data. \n\nIf you want to show some revision in Git, meaning commit message and\ndiff in patch format (result of \"git show\"), Git just reads the commit,\noutputs commit message, reads parent, reads trees and performs diff.\n\nIf you want to checkout to specific revision, Git just reads commit,\nreads tree, and writes this tree (via index) to working area.\n \n> In git is has to check all changesets which affect the file. \n\nI don't understand you here... if I understand correctly above,\nthen you are wrong about Git.\n\n> If you read the hgbook, you'll find one especially nice comment: \n> \n> \"Unlike many revision control systems, the concepts upon which Mercurial is \n> built are simple enough that it’s easy to understand how the software really \n> works. Knowing this certainly isn’t necessary, but I find it useful to have a \n> “mental model” of what’s going on.\"\n> - http://hgbook.red-bean.com/hgbookch4.html\n> \n> I really like that, and in my opinion it is a great compliment to hg, for two \n> reasons: \n> \n> 1) Hg is easy to understand\n\nBecause it is simple... and less feature rich, c.f. multiple local\nbranches in single repository.\n\n> 2) You don't have to understand it to use it\n\nYou don't have to understand details of Git design (pack format, index,\nstages, refs,...) to use it either.\n\n> \n> And both are indications of a good design, the first of the core, the second \n> of the UI. \n\nWell, Git is built around concept of DAG of commits and branches as\nreferences to it. Without it you can use Git, but it is hard. But\nif you understand it, you can understand easily most advanced Git\nfeatures.\n\nI agree that Mercurial UI is better; as usually in \"Worse is Better\"\ncase... :-)\n-- \nJakub Narebski\nPoland\n"},{"id":"94017","messageId":"ee2a733e0810262115h705356dfmbc2237f8e88f3985@mail.gmail.com","threadId":"16046","inReplyTo":"200810270120.55276.arne_bab@web.de","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2008-10-27T04:15:11Z","receivedAt":"2008-10-27T04:15:11Z","isPatch":false,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On 10/26/08, Arne Babenhauserheide wrote:\n> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:\n>\n> > > * Recently, Hg development seems to have somewhat slowed down. To\n> > > simply put it, there is not enough room in the world for several\n> > > similar SCM systems. With git's pace and momentum the other SCMs\n> > > including Hg are fighting an uphill battle.\n> >\n> > The competing _distributed_ version control systems left seems to be\n> > Bazaar-NG (Ubuntu), Mercurial (OpenSolaris, Mozilla), Git (Linux kernel,\n> > Freedesktop.org, Ruby on Rails people). There are many IDEs, many\n> > editors, many web browsers; there is Linux and there are *BSD; I hope\n> > that Mercurial would continue to be developed, and not vanish in\n> > obscurity like Arch and clones...\n>\n>\n> Before we get tangled in this train of thought:\n>\n> I created a head-to-head code_swarm of Mercurial and Git and it clearly shows\n> that Mercurial development didn't slow down.\n>\n\nI am not familiar with code swarms, sorry. My impressions are\nsubjective are thoroughly un-scientific:-)\n(1) Judging by the activity of mailing lists git community is several\ntimes larger and more active in terms of actual submitted patches.\n(2) Hg forest extension is still not in the tree with outdated and\nincorrect documentation in the wiki. For me it was biggest reason to\nmigrate from Hg to git.\n\n--Leo--\n"},{"id":"94027","messageId":"200810270816.06020.arne_bab@web.de","threadId":"16046","inReplyTo":"ee2a733e0810262115h705356dfmbc2237f8e88f3985@mail.gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Arne Babenhauserheide","fromEmail":"arne_bab@web.de","sentAt":"2008-10-27T07:16:02Z","receivedAt":"2008-10-27T07:16:02Z","isPatch":false,"sender":{"key":"arne_bab@web.de","avatar":"https://gravatar.com/avatar/4c060d566fc1b86d9ee5a5548bdc93436759676024e99f3e91191f32d38086d3?d=mp&s=160"},"body":"Am Montag 27 Oktober 2008 05:15:11 schrieb Leo Razoumov:\n> > I created a head-to-head code_swarm of Mercurial and Git and it clearly\n> > shows that Mercurial development didn't slow down.\n>\n> I am not familiar with code swarms, sorry. My impressions are\n> subjective are thoroughly un-scientific:-)\n\nThat's always the case with code_swarms. \n\nThey only show the commit activity: How often how many files where changed. \n\nThey aren't a fair comparision but a damn unfair battle relying strongly on \ndevelopment style, programming language (influences the style) and such. \n\nWhat you can see very clearly in them is how activity patterns _change_. \n\nAnd the Mercurial activity doesn't slow down. \n\nInstead in the beginning you can see them pacing each other, git always the \nbigger activity. \nThere was a moment in may this year when git activity had receded to the point \nwhere it was equal to Mercurials activity, but it recovered from that. \n\nAn artifact in Mercurial is that it took an almost two week break in July this \nyear, but apart from that development always rolled on, and in august the \ncommits where coming fast again. \n\nThe smaller activity can for example be a result of a development style where \nchanges are thouroughly discussed before they get implemented. \n\n> (1) Judging by the activity of mailing lists git community is several\n> times larger and more active in terms of actual submitted patches.\n\nThis is something which didn't change. Git had higher activity from the start, \nyet Mercurials actual code paced it well and was faster at some things. \n\nGit still has higher activity, but that can simply stem from Mercurial being \nalmost completely done in Python which need less code to do the same work. \n\n> (2) Hg forest extension is still not in the tree with outdated and\n> incorrect documentation in the wiki. For me it was biggest reason to\n> migrate from Hg to git.\n\nWhy didn't you instead update the documentation in the wiki? \n\nI don't use the forest extension, so I can't judge whether it is fit for \ninclusion in the tree. \n\nBut I wrote the group extension and learned that way that writing Mercurial \nextensions is far easier than I thought. And different from the shell, Python \ncode is platform independent. \n\nBest wishes, \nArne\n\n-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)\n-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the \nhistory of free software.\n-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.\n\n-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt\n"},{"id":"94028","messageId":"e3f230850810270016r53588f9duce6ede57a890ab89@mail.gmail.com","threadId":"16046","inReplyTo":"ee2a733e0810262115h705356dfmbc2237f8e88f3985@mail.gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"dhruva","fromEmail":"dhruvakm@gmail.com","sentAt":"2008-10-27T07:16:30Z","receivedAt":"2008-10-27T07:16:30Z","isPatch":false,"sender":{"key":"dhruvakm@gmail.com","avatar":"https://gravatar.com/avatar/96fe022a95b60fd0de7f9f521364d964cdc7c46be5cfef279f8d4379e49e19a6?d=mp&s=160"},"body":"Hello,\n\nOn Mon, Oct 27, 2008 at 9:45 AM, Leo Razoumov wrote:\n> (2) Hg forest extension is still not in the tree with outdated and\n> incorrect documentation in the wiki. For me it was biggest reason to\n> migrate from Hg to git.\n\nThere are a few extensions that ought to be part of main hg, I have\nproposed rdiff and am still waiting to hear. Since hg depends a lot on\nextensions to extend it (good design), commnly used or useful\nextensions must be made part of mainstream at a steady pace.\nOtherwise, new users who are not aware of existence of various\nextensions will start comparing main hg with git. Since git has most\nof the features in the core part, hence the comparisons will be not\napple to apple.\n\n-dhruva\n\n-- \nContents reflect my personal views only!\n"},{"id":"94029","messageId":"200810270850.09696.arne_bab@web.de","threadId":"16046","inReplyTo":"200810270252.23392.jnareb@gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Arne Babenhauserheide","fromEmail":"arne_bab@web.de","sentAt":"2008-10-27T07:50:08Z","receivedAt":"2008-10-27T07:50:08Z","isPatch":false,"sender":{"key":"arne_bab@web.de","avatar":"https://gravatar.com/avatar/4c060d566fc1b86d9ee5a5548bdc93436759676024e99f3e91191f32d38086d3?d=mp&s=160"},"body":"Am Montag 27 Oktober 2008 02:52:22 schrieb Jakub Narebski:\n> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:\n> > Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:\n> > > I agree, and I think it is at least partially because of Git having\n> > > cleaner design, even if you have to understand more terms at first.\n> >\n> > What do you mean by \"cleaner design\"?\n>\n> Clean _underlying_ design. Git has very nice underlying model of graph\n> (DAG) of commits (revisions), and branches and tags as pointers to this\n> graph.\n>\n> > From what I see (and in my definition of \"design\"), Mercurial is designed\n> > as VCS with very clear and clean design, which even keeps things like\n> > streaming disk access in mind.\n>\n> I have read description of Mercurial's repository format, and it is not\n> very clear in my opinion. File changesets, bound using manifest, bound\n> using changerev / changelog.\n\nThis grows very simple if you keep common filesystem layout in mind. \n\ninodes and datanodes (the files in the store), organized in directories which \nkeep many files (manifests) bound in changesets which keep additional data. \n\n> Mercurial relies on transactions and O_TRUNC support, while Git relies\n> on atomic write and on updating data then updating reference to data.\n\nFor most operations Mercurial just relies on appending support. \n\n> I don't quite understand comment about streaming disk access...\n\nIf you tell a disk \"give me files a, b, c, d, e, f (of the whole abc)\", it is \nfaster then if you tell it \"give me files a k p q s t\", because the filesystem \ncan easier optimize that call. \n\nThat's why for example Mercurial avoids hashing filenames. \n\n> Well, they have to a lot less than they used to, and there is\n> \"git gc --auto\" that can be put in crontab safely.\n\nrelying on crontab which might not be available in all systems (I only use \nGNU/Linux, but what about friends of mine who have to use Windows?)\n\n> Explicit garbage collection was a design _decision_, not a sign of not\n> clear design. We can argue if it was good or bad decision, but one\n> should consider the following issues:\n>\n> * Rolling back last commit to correct it, or equivalently amending\n> last commit (for example because we forgot some last minute change,\n> or forgot to signoff a commit), or backing out of changes to the\n> last commit in Mercurial relies on transactions (and locking) and\n> correct O_TRUNC, while in Git it leaves dangling objects to be\n> garbage collected later.\n\nAs far as I know the only problem woth O_TRUNC was that it sadly had bugs in \nLinux.\n\n> * Mercurial relies on transaction support. Git relies on atomic write\n> support and on the fact that objects are immutable; those that are\n> not needed are garbage collected later. Beside IIRC some of ways of\n> implementing transaction in databases leads to garbage collecting.\n\nBut Mercurial normally works on standard filesystems, so this isn't the case \nfor normal operations. \n\nYou culd say, though, that git implements a very simple transaction model: \nKeep all old data until it gets purged explicitely. \n\n> * Explicit packing and having two repository \"formats\": loose and\n> packed is a bit of historical reason: at the beginning there was\n> only loose format. Pack format was IIRC invented for network\n> transport, and was used for on disk storage (the same format!) for\n> better I/O patterns[1]. Having packs as 'rewrite to pack' instead\n> of 'append to pack' allows to prefer recency order, which result in\n> faster access as objects from newer commits are earlier in delta\n> chain and reduction in size in usual case of size growing with time\n> as recency order allows to use delete deltas. Also _choosing_ base\n> object allows further reduce size, especially in presence of\n> nonlinear history.\n\nSo having multiple packs is equivalent to the automatic snapshot system in \nMercurial which doesn't need user interaction. \n\n> * From what I understand Mercurial by default uses packed format for\n> branches and tags; Git uses \"loose\" format for recent branches\n> (meaning one file per branch), while packing older references.\n> Using loose affects performance (and size) only for insane number of\n> references, and only for some operations like listing all references,\n> while using packed format is IMHO a bit error prone when updating.\n\nAs far as I know, Mercurial got that \"using packed format\" right from the \nbeginning. \n\n> * Git has reflogs which are pruned (expired) during garbage collecting\n> to not grow them without bounds; AFAIK Mercurial doesn't have\n> equivalent of this feature.\n>\n> (Reflogs store _local_ history of branch tip, noting commits,\n> fetches, merges, rewinding branch, switching branches, etc._\n\nAs far as I know Mercurial only tracks the state of the working directory, so \nit doesn't track your whole local history. \n\nBut others can better tell you more about that in greater detail. \n\n> [1] You wrote about \"streaming disk access\". Git relies (for reading)\n> on good mmap implementation.\n>\n> > In git is has to check all changesets which affect the file.\n>\n> I don't understand you here... if I understand correctly above,\n> then you are wrong about Git.\n\nMight be that I remember incorrectly about what git does. \n\nAre its commits \"the whole changed file\" or \"the diff of the changes\"? \n\nIf the latter, it needs to walk back all commits to the snapshot revision to \nget the file data. \n\nOne story I experienced with that: \n\nMy amd64 GNU/Linux box suffers from performance problems when it gets high \nlevels of disk activity (something about the filesystem layer doesn't play \nwell with amd64 - reported by others, too). \n\nWhen I pulled a the Linux kernel repository with git half a year ago, my disk \nstarted klicking and the whole computer slowed down to a crawl. \n\nWhen I pulled the same repository data from a Mercurial repository, the \ncomputer kept running smooth, the disk stayed silent and happily wrote the \ndata. \n\nMercurial felt smooth, while git felt damn clumsy (though not slow). \n\n> > 1) Hg is easy to understand\n>\n> Because it is simple... and less feature rich, c.f. multiple local\n> branches in single repository.\n\nThat works quite well. People just don't use it very often, because the \nworkflow of having multiple repositories is easier with hg. \n\n> > 2) You don't have to understand it to use it\n>\n> You don't have to understand details of Git design (pack format, index,\n> stages, refs,...) to use it either.\n\nI remember that to have been incorrect about half a year ago, when I stumbled \nover many problems in git whenever I tried to do something a bit nonstandard. \n\nIt took me hours (and in the end asking a friend) to find out about \n\n\"git checkout .\"\n\njust to get back my deleted files. \n\nThe answer I got when I asked why it's done that way was \"this is because of \nthe inner workings of git. You should know them if you use it\". \n\n> > And both are indications of a good design, the first of the core, the\n> > second of the UI.\n>\n> Well, Git is built around concept of DAG of commits and branches as\n> references to it. Without it you can use Git, but it is hard. But\n> if you understand it, you can understand easily most advanced Git\n> features.\n>\n> I agree that Mercurial UI is better; as usually in \"Worse is Better\"\n> case... :-)\n\nWhat do you mean with that? \n\nBest wishes, \nArne\n\n-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)\n-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the \nhistory of free software.\n-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.\n\n-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt\n"},{"id":"94034","messageId":"40f323d00810270229w7dfecabcm86e5e611fb4250ef@mail.gmail.com","threadId":"16046","inReplyTo":"200810270252.23392.jnareb@gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Benoit Boissinot","fromEmail":"bboissin@gmail.com","sentAt":"2008-10-27T09:29:36Z","receivedAt":"2008-10-27T09:29:36Z","isPatch":false,"sender":{"key":"bboissin@gmail.com","avatar":null},"body":"On Mon, Oct 27, 2008 at 2:52 AM, Jakub Narebski wrote:\n> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:\n>> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:\n>> >\n>> > I agree, and I think it is at least partially because of Git having\n>> > cleaner design, even if you have to understand more terms at first.\n>>\n>> What do you mean by \"cleaner design\"?\n>\n> Clean _underlying_ design. Git has very nice underlying model of graph\n> (DAG) of commits (revisions), and branches and tags as pointers to this\n> graph.\n\nGit and Mercurial are very close from that point of view.\nMercurial explicitely disallow octopus merges (and we don't think there's\na good reason to allow them, although I agree with Linus, they look very nice\nin gitk ;) ).\nAnd we don't have \"branches as pointer\" in core, but the bookmark extension does\nthat.\nAppart from that I think the underlying format are interchangeable, someone\ncould use the git format with the hg ui, or use revlogs (the basic\nformat of mercurial)\nlike packs.\n\nThe only special thing about revlogs is the linkrev stuff, it's a\npointer to the first revision\nthat introduced an object, so we can easily find what to send in our\nnetwork protocol\n(we don't have to read the manifest, ie the \"tree\" of objects\").\nlinkrev can be useful\nto speedup \"hg log\" too.\n\n> I have read description of Mercurial's repository format, and it is not\n> very clear in my opinion. File changesets, bound using manifest, bound\n> using changerev / changelog.\n>\n\njust do a s/// with the git terminology:\nfilelog -> blob\nmanifest -> tree\nchangelog -> commit object\n\nregards,\n\nBenoit\n"},{"id":"94035","messageId":"200810271041.54511.jnareb@gmail.com","threadId":"16046","inReplyTo":"200810270850.09696.arne_bab@web.de","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-27T09:41:53Z","receivedAt":"2008-10-27T09:41:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:\n> Am Montag 27 Oktober 2008 02:52:22 schrieb Jakub Narebski:\n>> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:\n>>> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:\n>>>>\n>>>> I agree, and I think it is at least partially because of Git having\n>>>> cleaner design, even if you have to understand more terms at first.\n>>>\n>>> What do you mean by \"cleaner design\"?\n\n>>> From what I see (and in my definition of \"design\"), Mercurial is designed\n>>> as VCS with very clear and clean design, which even keeps things like\n>>> streaming disk access in mind.\n>>\n>> I have read description of Mercurial's repository format, and it is not\n>> very clear in my opinion. File changesets, bound using manifest, bound\n>> using changerev / changelog.\n> \n> This grows very simple if you keep common filesystem layout in mind. \n> \n> inodes and datanodes (the files in the store), organized in directories which \n> keep many files (manifests) bound in changesets which keep additional data. \n\nWell, for you it might be simple, for others it is binding things\ntogether with duct tape and spit. (I am exaggerating here).\n\nWhat Mercurial repository design did not get correctly, in my opinion\nis its handling of tags and [named] branches.\n \n>> I don't quite understand comment about streaming disk access...\n> \n> If you tell a disk \"give me files a, b, c, d, e, f (of the whole abc)\", it is \n> faster then if you tell it \"give me files a k p q s t\", because the filesystem \n> can easier optimize that call. \n\nI would expect _good_ filesystem to be able to optimize this call as\nwell. As I said it looks like Mercurial and Git are optimized for\ndifferent cases: Git relies on filesystem for caching, and optimizes\nfor warm cache performance.\n\n> \n> That's why for example Mercurial avoids hashing filenames. \n\nFirst, git does not hash filenames. The hash is contents, not of name.\nYou can say it stores objects (in loose format) in hash-based filenames.\n \nSecond, in packed repository you don't have to ask filesystem to \"give\nme files a, k, p, q, s, t (of the whole abc)\"; you ask filesystem to\nmmap a _single_ pack file (well, almost, there is also pack index to\nmmap).\n\nYes, that means that you should periodically repack for better\nperformance... but currently git tries to use packed format as much\nas possible, keeping packs from network if they are not too small,\nrepacking if creating large number of objects, etc.\n\n>> Well, they have to a lot less than they used to, and there is\n>> \"git gc --auto\" that can be put in crontab safely.\n> \n> relying on crontab which might not be available in all systems (I only use \n> GNU/Linux, but what about friends of mine who have to use Windows?)\n\nSo they would have to either periodically repack by hand, or use some\ncrontab equivalent on MS Windows.\n\nBut that doesn't matter in the context of this discussion, which is\nDragonflyBSD; worse or better support for MS Windows doesn't matter\nhere, does it?\n\n> \n>> Explicit garbage collection was a design _decision_, not a sign of not\n>> clear design. We can argue if it was good or bad decision, but one\n>> should consider the following issues:\n>>\n>> * Rolling back last commit to correct it, or equivalently amending\n>> last commit (for example because we forgot some last minute change,\n>> or forgot to signoff a commit), or backing out of changes to the\n>> last commit in Mercurial relies on transactions (and locking) and\n>> correct O_TRUNC, while in Git it leaves dangling objects to be\n>> garbage collected later.\n> \n> As far as I know the only problem with O_TRUNC was that it sadly had bugs in \n> Linux.\n> \n>> * Mercurial relies on transaction support. Git relies on atomic write\n>> support and on the fact that objects are immutable; those that are\n>> not needed are garbage collected later. Beside IIRC some of ways of\n>> implementing transaction in databases leads to garbage collecting.\n> \n> But Mercurial normally works on standard filesystems, so this isn't the case \n> for normal operations.\n\nMercurial implements transactions as a way to keeping operations atomic.\nSo I don't know what you mean by \"normally works on standard filesystem\"\nhere.\n\n> \n> You could say, though, that git implements a very simple transaction model: \n> Keep all old data until it gets purged explicitely.\n\nGit just uses different way to keep operations atomic, different way\nof implementing transactions.\n\nI'm not sure if I should have mentioned transactions in databases here.\nOh, well... Note however that there are advanced way of doing\ntransactions in relational databases which lead to dangling things\nto be purged when transaction is interrupted. But this is not to the\npoint...\n\n> \n>> * Explicit packing and having two repository \"formats\": loose and\n>> packed is a bit of historical reason: at the beginning there was\n>> only loose format. Pack format was IIRC invented for network\n>> transport, and was used for on disk storage (the same format!) for\n>> better I/O patterns[1]. Having packs as 'rewrite to pack' instead\n>> of 'append to pack' allows to prefer recency order, which result in\n>> faster access as objects from newer commits are earlier in delta\n>> chain and reduction in size in usual case of size growing with time\n>> as recency order allows to use delete deltas. Also _choosing_ base\n>> object allows further reduce size, especially in presence of\n>> nonlinear history.\n> \n> So having multiple packs is equivalent to the automatic snapshot system in \n> Mercurial which doesn't need user interaction. \n\nSnapshot system doesn't change the fact that Mercurial (from what I\nunderstand) implements forward deltas, from older version to never\nversion, and not from newer version to older.\n\nAlso from what I remember Mercurial didn't implement deltification\nright from the start; it had problems with nonlinear history (it used\ndelta from last version appended, not from the parent version).\n\n>> * From what I understand Mercurial by default uses packed format for\n>> branches and tags; Git uses \"loose\" format for recent branches\n>> (meaning one file per branch), while packing older references.\n>> Using loose affects performance (and size) only for insane number of\n>> references, and only for some operations like listing all references,\n>> while using packed format is IMHO a bit error prone when updating.\n> \n> As far as I know, Mercurial got that \"using packed format\" right from the \n> beginning. \n\nAnd probably requires transactions and locks for that. Git simply uses\natomic write solution for atomic update of references.\n\n> \n>> * Git has reflogs which are pruned (expired) during garbage collecting\n>> to not grow them without bounds; AFAIK Mercurial doesn't have\n>> equivalent of this feature.\n>>\n>> (Reflogs store _local_ history of branch tip, noting commits,\n>> fetches, merges, rewinding branch, switching branches, etc._\n> \n> As far as I know Mercurial only tracks the state of the working directory, so \n> it doesn't track your whole local history. \n> \n> But others can better tell you more about that in greater detail. \n\nReflogs are very useful, and are natural extension of simple rollback\nlast transaction Mercurial has (which Git had equivalent from the very\nbeginning in the form of ORIG_HEAD). They allow for example for you\ngo back to the state before incorrect rewinding a branch, or before\napplying series of patches from email, etc.\n\n>> [1] You wrote about \"streaming disk access\". Git relies (for reading)\n>> on good mmap implementation.\n>>\n>>> In git is has to check all changesets which affect the file.\n>>\n>> I don't understand you here... if I understand correctly above,\n>> then you are wrong about Git.\n> \n> Might be that I remember incorrectly about what git does. \n> \n> Are its commits \"the whole changed file\" or \"the diff of the changes\"? \n> \n> If the latter, it needs to walk back all commits to the snapshot revision to \n> get the file data. \n\nGit is snapshot based SCM, although 'behind the scenes' it uses deltas\nin the pack format. So to get file data at given revision (i.e. to do\nsomething like \"git show :\") it needs to access\n, access its tree, and access contents of a file (blob).\n\nBehind the scenes, at a lower level, Git does necessary delta resolving.\nDelta chains in packs have limited length (as they have in Mercurial).\n\n> One story I experienced with that: \n> \n> My amd64 GNU/Linux box suffers from performance problems when it gets high \n> levels of disk activity (something about the filesystem layer doesn't play \n> well with amd64 - reported by others, too). \n> \n> When I pulled a the Linux kernel repository with git half a year ago, my disk \n> started klicking and the whole computer slowed down to a crawl. \n> \n> When I pulled the same repository data from a Mercurial repository, the \n> computer kept running smooth, the disk stayed silent and happily wrote the \n> data. \n> \n> Mercurial felt smooth, while git felt damn clumsy (though not slow). \n\nThe answer usually is: did you have this repository packed? I admit\nthat it might be considered one of disadvantages of git, this having\nto do garbage collection from time to time... just like in C ;-)\n\n>>> 1) Hg is easy to understand\n>>\n>> Because it is simple... and less feature rich, c.f. multiple local\n>> branches in single repository.\n> \n> That works quite well. People just don't use it very often, because the \n> workflow of having multiple repositories is easier with hg. \n\nWorkflow of having multiple repositories, or one branch per repository,\nis IMHO as simple in Git as in Mercurial, and as in Bazaar-NG.\n\n>>> 2) You don't have to understand it to use it\n>>\n>> You don't have to understand details of Git design (pack format, index,\n>> stages, refs,...) to use it either.\n> \n> I remember that to have been incorrect about half a year ago, when I stumbled \n> over many problems in git whenever I tried to do something a bit nonstandard. \n> \n> It took me hours (and in the end asking a friend) to find out about \n> \n> \"git checkout .\"\n> \n> just to get back my deleted files. \n> \n> The answer I got when I asked why it's done that way was \"this is because of \n> the inner workings of git. You should know them if you use it\". \n\nWell, understanding \"git checkout .\" doesn't require understanding\ninner workings of git. Your friend was incorrect here. I'll agree\nthough that it is a bit of quirk in UI[1] (but I use usually \n\"git reset --hard\" to reset to last committed state).\n\n[1] Having git-checkout behave very differently with and without\npathname parameter, and overloading of git-checkout.\n\n>>> And both are indications of a good design, the first of the core, the\n>>> second of the UI.\n>>\n>> Well, Git is built around concept of DAG of commits and branches as\n>> references to it. Without it you can use Git, but it is hard. But\n>> if you understand it, you can understand easily most advanced Git\n>> features.\n>>\n>> I agree that Mercurial UI is better; as usually in \"Worse is Better\"\n>> case... :-)\n> \n> What do you mean with that? \n\nJust Google for \"Worse is Better\". But what I actually mean that Git\nfeature set and UI has evolved from very bare-bones plumbing, adding\nfeatures and UI _as needed_, instead of being designed according to\nwhat designer thought it was needed.\n\nFor example in http://gitster.livejournal.com/9970.html Junio C Hamano\n(git maintainer) writes:\n\n By the time the basic structure as we currently know has stabilized,\n we had help from literally dozens of contributors to add many things\n on top of the very original version:\n [...]\n \n * We did not envision that multiple branches in a single repository\n would turn out to be such a useful way to work, and did not have\n support for switching branches.\n [...]\n \n It still is amazing that all of these were done without having to go\n back to the drawing board. It shows how sound the initial conceptual\n design was.\n\nP.S. See \"Innovations in git\", http://gitster.livejournal.com/16077.html\n-- \nJakub Narebski\nPoland\n"},{"id":"94040","messageId":"62339.88.73.238.241.1225102347.squirrel@mail.stardawn.org","threadId":"16046","inReplyTo":"200810271041.54511.jnareb@gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Leslie P. Polzer","fromEmail":"sky@viridian-project.de","sentAt":"2008-10-27T10:12:27Z","receivedAt":"2008-10-27T10:12:27Z","isPatch":false,"sender":{"key":"sky@viridian-project.de","avatar":null},"body":"\n> I'm not sure if I should have mentioned transactions in databases here.\n> Oh, well... Note however that there are advanced way of doing\n> transactions in relational databases which lead to dangling things\n> to be purged when transaction is interrupted.\n\nFor the record: transactions are applicable to all kinds of databases,\nnot only relational ones.\n\n Leslie\n"},{"id":"94037","messageId":"200810271114.03406.arne_bab@web.de","threadId":"16046","inReplyTo":"200810271041.54511.jnareb@gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Arne Babenhauserheide","fromEmail":"arne_bab@web.de","sentAt":"2008-10-27T10:14:00Z","receivedAt":"2008-10-27T10:14:00Z","isPatch":false,"sender":{"key":"arne_bab@web.de","avatar":"https://gravatar.com/avatar/4c060d566fc1b86d9ee5a5548bdc93436759676024e99f3e91191f32d38086d3?d=mp&s=160"},"body":"Am Montag 27 Oktober 2008 10:41:53 schrieb Jakub Narebski:\n> > If you tell a disk \"give me files a, b, c, d, e, f (of the whole abc)\",\n> > it is faster then if you tell it \"give me files a k p q s t\", because the\n> > filesystem can easier optimize that call.\n>\n> I would expect _good_ filesystem to be able to optimize this call as\n> well. As I said it looks like Mercurial and Git are optimized for\n> different cases: Git relies on filesystem for caching, and optimizes\n> for warm cache performance.\n\nThe problem is by which knowledge the filesystem should optimize this call \nwhen it is storing the files in the first place. \n\n> > relying on crontab which might not be available in all systems (I only\n> > use GNU/Linux, but what about friends of mine who have to use Windows?)\n>\n> But that doesn't matter in the context of this discussion, which is\n> DragonflyBSD; worse or better support for MS Windows doesn't matter\n> here, does it?\n\nIt only matters, if some developers are forced to work on WIndows machines at \ntimes. \n\n> > But Mercurial normally works on standard filesystems, so this isn't the\n> > case for normal operations.\n>\n> Mercurial implements transactions as a way to keeping operations atomic.\n> So I don't know what you mean by \"normally works on standard filesystem\"\n> here.\n\nI just meant \"databases are a bit off topic\" :) \n\n> > You could say, though, that git implements a very simple transaction\n> > model: Keep all old data until it gets purged explicitely.\n>\n> Git just uses different way to keep operations atomic, different way\n> of implementing transactions.\n\nThat's what I wanted to express. \n\n> And probably requires transactions and locks for that. Git simply uses\n> atomic write solution for atomic update of references.\n\nDoesn't atomic write also need locks, though on a lower level (to ensure \natomicity)? \n\n> Behind the scenes, at a lower level, Git does necessary delta resolving.\n> Delta chains in packs have limited length (as they have in Mercurial).\n\nSo both do snapshots - they seem more and more similar to me :) \n\n> The answer usually is: did you have this repository packed? I admit\n> that it might be considered one of disadvantages of git, this having\n> to do garbage collection from time to time... just like in C ;-)\n\nI cloned from the official repositories. \n\nI hope Linus had his repository packed :) \n\n> Well, understanding \"git checkout .\" doesn't require understanding\n> inner workings of git. Your friend was incorrect here. I'll agree\n> though that it is a bit of quirk in UI[1] (but I use usually\n> \"git reset --hard\" to reset to last committed state).\n\nDamn - one more way how I could have archieved what I wanted... one more way I \ndidn't find. \n\n> Just Google for \"Worse is Better\". But what I actually mean that Git\n> feature set and UI has evolved from very bare-bones plumbing, adding\n> features and UI _as needed_, instead of being designed according to\n> what designer thought it was needed.\n\nAnd that's how it feels to me. \n\nA great testing ground, but it developed too many stumbling blocks which keep \nme from trying things. \n\nWhen I now use git, I only do the most basic operations: clone, pull, push, \nadd, commit, checkout. When anything else arises, I check if it is worth the \nrisk of having to read up for hours - and since that wasn't the case for the \nlast few months, I then just ignore the problem or ask someone else if he can \nfix it. \n\nAs a contrast, when I encounter a problem with Mercurial, I simply check the \ncommands for a moment and then try to solve it, and normally I have what I \nwanted within seconds to minutes. \n\nGit instead bit me once too often. \n\nI know that this isn't something which hits everyone and that it is \nsubjective, but since it hit me, I'm wary of git, because in my view it isn't \nsomething for the majority of people - and you almost always have someone from \nthat \"majority\" in your project. \n\nI don't want people getting afraid of solving their own problems, so I avoid \nsystems which bite so often, that they create fear (for example of losing much \ntime on something which should be a side issue). \n\n\nAll in all it's a UI issue - while the git UI bit me quite often, the \nMercurial UI just works. \n\nBest wishes, \nArne\n\n-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)\n-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the \nhistory of free software.\n-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.\n\n-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt\n"},{"id":"94041","messageId":"200810271157.20313.jnareb@gmail.com","threadId":"16046","inReplyTo":"40f323d00810270229w7dfecabcm86e5e611fb4250ef@mail.gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-27T10:57:18Z","receivedAt":"2008-10-27T10:57:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia poniedziałek 27. października 2008 10:29, Benoit Boissinot napisał:\n> On Mon, Oct 27, 2008 at 2:52 AM, Jakub Narebski wrote:\n>> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:\n>>> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:\n>>>>\n>>>> I agree, and I think it is at least partially because of Git having\n>>>> cleaner design, even if you have to understand more terms at first.\n>>>\n>>> What do you mean by \"cleaner design\"?\n>>\n>> Clean _underlying_ design. Git has very nice underlying model of graph\n>> (DAG) of commits (revisions), and branches and tags as pointers to this\n>> graph.\n> \n> Git and Mercurial are very close from that point of view.\n>\n> Mercurial explicitely disallow octopus merges (and we don't think there's\n> a good reason to allow them, although I agree with Linus, they look very nice\n> in gitk ;) ).\n\nFrom what I see Mercurial disallows octopus merges (merges with more\nthan two parents) because of its rigid-record database repository\ndesign, while Git is more like object database. Fixed width records\nof VMS vs delimited records of Unix... There is simply place on\nzero, one or two parents (two parent fields, which can be null) in\nMercurial changerev format.\n\nBy the way flexibility of Git design allowed to add 'encoding' header\nto commit message (if commits message is encoded not in utf-8) after\nthe fact, without affecting older repository data, and playing well\nwith old git installations which do not understand this header.\n\n> And we don't have \"branches as pointer\" in core, but the bookmark\n> extension does that.\n\nI disagree. Mercurial implementation of tags is strange, and from\nwhat I remember and from discussion on #revctrl implementation\nof local named branches is also strange (CVS-like). They are IMHO\nnot well designed.\n\nAlso the 'hidden' branches after fetching from remote repository\n(hg pull) but before merging (hg update) are IMHO worse design\nthan explicit remote-tracking branches in Git, especially in presence\nof multiple [named] branches in repositories.\n\n> Apart from that I think the underlying format are interchangeable,\n> someone could use the git format with the hg ui, or use revlogs\n> (the basic format of mercurial) like packs.\n\nI don't think so. The 'content addressed filesystem' idea of Git\nis quite pervasive along Git implementation and Git thoughtflows.\n\n> \n> The only special thing about revlogs is the linkrev stuff, it's a\n> pointer to the first revision that introduced an object, so we can\n> easily find what to send in our network protocol (we don't have to\n> read the manifest, ie the \"tree\" of objects\"). linkrev can be useful\n> to speedup \"hg log\" too.\n\nAt first I thought: what a nice idea... but then I realized that in\ndistributed environment there is no way to define \"first revision that\nintroduced an object\". Take for example the following history \n(independent introduction):\n\n .---.---.---.---x---.---.---.\n \\\n --x---.---.\n\nwhere both 'x' have the same version of an object. The top branch\nappeared first in current repository, but the bottom branch had 'x'\nwith earlier timestamp (earlier authordate).\n\n\nGit just relies on the fact that traversing revision is a part of it\nthat is heavily optimized and really fast. Git very much by design\ndoesn't store any backlinks in repository object database.\n\n>> I have read description of Mercurial's repository format, and it is not\n>> very clear in my opinion. File changesets, bound using manifest, bound\n>> using changerev / changelog.\n>>\n> \n> just do a s/// with the git terminology:\n> filelog -> blob\n> manifest -> tree\n> changelog -> commit object\n\nTrue. But as I see it they are bound in reverse order in Mercurial:\ndeltas are stored in filelog, filelogs are bound together in manifest,\nmanifest are bound using changelog, while in Git commit object\nreferences tree (and parents), trees references blobs, and blob store\ncontent of a file. But that might be just my impression.\n\n\n.......................................................................\n\nBy the way, going back to the matter of choosing version control system\nfor DragonflyBSD; some time ago I have written post\n * \"Mercurial's only true \"plugin\" extension: inotify... \n and can it be done in Git?\"\n http://thread.gmane.org/gmane.comp.version-control.git/76661\n (current answer: it is possible using 'assume unchanged' bit)\nabout how nearly every Mercurial extension has equivalent functionality\nin Git. \n\nBut what about the reverse, about the following features and\nissues in Mercurial:\n\n * Merging in presence of criss-cross merges[1], and in presence of\n file renames, i.e what merge-recursive does in Git.\n\n * git-rerere, reusing recorded resolution of conflicted merges.\n Resolving the same merge happens often if you use topic branches\n and trial merging.\n\n * git-grep that allows you to \"and\" the match criteria together,\n and also pick a file (not a line) that matches all the criteria;\n and of course allow searching given revision and not only working\n directory.\n\n * pickaxe search (git log -S) which contrary to blame/annotate\n allow to find commit which _deleted_ given fragment.\n\n * easy management of multiple repositories you fetch from with \n remote-tracking branches and git-remote command.\n\n * blame that follows block-of-line movement (it was invented by Linus\n as a vision long time ago, but it took very long time to materialize).\n\n * a way to review merge resolution, something that is done in git\n by using combined diff format\n\n * git-stash, allowing to stash away changes to go back to them later;\n it allows to stash away even partially resolved merge conflict\n (merge resolution in progress).\n\n * git-filter-branch (based on cg-admin-rewrite-hist), which allow\n to rewrite history for example to remove file which should never\n be added to version control (for example because of copyright\n or license).\n\nReferences:\n===========\n[1] http://revctrl.org/CrissCrossMerge\n BTW I wonder why reverting spam is made so hard on revctrl.org wiki\n \n-- \nJakub Narebski\nPoland\n"},{"id":"94043","messageId":"4905A932.2030506@gmx.net","threadId":"16046","inReplyTo":"1225100597.31813.11.camel@abelardo.lan","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"David Soria Parra","fromEmail":"sn_@gmx.net","sentAt":"2008-10-27T11:42:42Z","receivedAt":"2008-10-27T11:42:42Z","isPatch":false,"sender":{"key":"sn_@gmx.net","avatar":"https://gravatar.com/avatar/b1075ecdd33ea094cbc23798fe8b95c73ec1ccf7bb213ac8260c719e2dd97b55?d=mp&s=160"},"body":"Emanuele Aina schrieb:\n> Jakub Narebski precisò:\n> \n>>> What do you mean by \"cleaner design\"? \n>> Clean _underlying_ design. Git has very nice underlying model of graph\n>> (DAG) of commits (revisions), and branches and tags as pointers to this\n>> graph.\n> \n> Just for reference, the abstract history model of Mercurial and GIT is\n> the same, a DAG of changesets identified by their cryptographic hash as\n> designed for Monotone, which can be considered the parent of both.\n> \n> GIT and Mercurial then differs in how this abstract model is written to\n> disk, with different tradeoffs in terms of performances and how easily a\n> specific feature can be implemented, but there is no reason something\n> can be done in GIT but not in Mercurial or viceversa.\n\nYes, it's the same: a DAG with hashes. But there are limitations due to \nthe implementation (and not the design). Just as a bad and completely \nuseless example (don't start to argue, I know it's nothing someone would \nlike to have): you cannot force mercurial to merge two revisions and \ncreate a merge commit if one is the others ancestor,which is possible in \ngit with git --no-ff. In addition they differ in some other ways: \nMercurial doesn't have an index to stage commits, which is something \nthat git has and allows very powerful features (such as git add -i, etc).\n"},{"id":"94045","messageId":"200810271348.39373.jnareb@gmail.com","threadId":"16046","inReplyTo":"200810271114.03406.arne_bab@web.de","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-27T12:48:38Z","receivedAt":"2008-10-27T12:48:38Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:\n> Am Montag 27 Oktober 2008 10:41:53 schrieb Jakub Narebski:\n>>>\n>>> If you tell a disk \"give me files a, b, c, d, e, f (of the whole abc)\",\n>>> it is faster then if you tell it \"give me files a k p q s t\", because the\n>>> filesystem can easier optimize that call.\n>>\n>> I would expect _good_ filesystem to be able to optimize this call as\n>> well. As I said it looks like Mercurial and Git are optimized for\n>> different cases: Git relies on filesystem for caching, and optimizes\n>> for warm cache performance.\n> \n> The problem is by which knowledge the filesystem should optimize this call \n> when it is storing the files in the first place. \n\nWell, that is a question for filesystem designer, and VFS designer...\n\nWhat I want to emphasize that perhaps Mercurial is optimized for \n\"streaming access\", but fully packed Git repository requires only\nsingle (well, up to details) mmap, which I think is even better.\n\n>>> relying on crontab which might not be available in all systems (I only\n>>> use GNU/Linux, but what about friends of mine who have to use Windows?)\n>>\n>> But that doesn't matter in the context of this discussion, which is\n>> DragonflyBSD; worse or better support for MS Windows doesn't matter\n>> here, does it?\n> \n> It only matters, if some developers are forced to work on Windows\n> machines at times. \n\nDragonFly BSD developers? I think they would work on DragonFly BSD\n(eating one's own dogfood and all that...).\n\nSidenote: I don't know if DragonFly BSD is more like Linux kernel, or\nas Linux distribution. It would be in my opinion good idea to ask\nsimilar projects about the impressions about SCM they use (Linux kernel,\nAndroid, ALT Linux distribution, Debian (build tools etc.), CRUX Linux\ndistribution, Exherbo, grml, Source Mage GNU/Linux for impressions\non their Git usage; OpenSolaris, Conary, Heretix, Linux HA, perhaps\nMozilla for impressions on their Mercurial usage; \n\nIIRC ALSA moved from Mercurial to Git, so they could be of help there.\n\n[...]\n>> Git just uses different way to keep operations atomic, different way\n>> of implementing transactions.\n\n>> And probably requires transactions and locks for that. Git simply uses\n>> atomic write solution for atomic update of references.\n> \n> Doesn't atomic write also need locks, though on a lower level (to ensure \n> atomicity)? \n\nNo, you can use create then rename to final place trick, making use\nof the fact (assumption) that renames are atomic. And Git first write\ndata, then write references which are used to access this data (this\nrelies on pruning dangling objects).\n \nI'm not saying that git does not use locks at all, because it does,\nfor example to edit config file, or update branch and its reflog as\natomic operation. But it needs locking in very few places.\n\n>> Behind the scenes, at a lower level, Git does necessary delta resolving.\n>> Delta chains in packs have limited length (as they have in Mercurial).\n> \n> So both do snapshots - they seem more and more similar to me :) \n\nThere are differences: Mercurial from what I understand uses forward\ndeltas (from older to never) while Git prefers recency order; delta\nchains in Git doesn't need to form single line, but can be forest of\ndelta chains; Git searches for good delta basis from large range of\nobjects (see pack.window); there is pack index which allow for random\naccess as if objects were in loose format (resolving deltas behind the\nscenes).\n\nI also don't know how Mercurial deals with binary files; in Git pack\nformat uses binary delta from LibXDiff by Davide Libenzi (File\nDifferential Library), heavy modified.\n\n>> The answer usually is: did you have this repository packed? I admit\n>> that it might be considered one of disadvantages of git, this having\n>> to do garbage collection from time to time... just like in C ;-)\n> \n> I cloned from the official repositories. \n> \n> I hope Linus had his repository packed :) \n\nWell, that also depends on _when_ did you try this. In older versions\nof Git pack file got from network (git:// and ssh:// protocols) was\nexploded into loose objects; now is kept if it is large enough, only\nexpanding it to make it thick, self contained pack file.\n\nUnless you used http:// protocol, which I think kept packs as they were,\nand as dumb protocol (along ftp:// and rsync://) depends on remote\nrepository being well packed.\n\n>> Well, understanding \"git checkout .\" doesn't require understanding\n>> inner workings of git. Your friend was incorrect here. I'll agree\n>> though that it is a bit of quirk in UI[1] (but I use usually\n>> \"git reset --hard\" to reset to last committed state).\n> \n> Damn - one more way how I could have archieved what I wanted...\n> one more way I didn't find. \n\nWell, there is a difference between \"git checkout .\" and\n\"git reset --hard\", but it does not matter here.\n\nBy the way, the design of Git allowed to add lately new feature:\n\"git checkout --merge ...\" to recreate conflicted merge in\nspecified paths. For example if you completely borked merge resolution,\nand want to start from scratch.\n\n>> Just Google for \"Worse is Better\". But what I actually mean that Git\n>> feature set and UI has evolved from very bare-bones plumbing, adding\n>> features and UI _as needed_, instead of being designed according to\n>> what designer thought it was needed.\n> \n> And that's how it feels to me. \n> \n> A great testing ground, but it developed too many stumbling blocks\n> which keep me from trying things. \n\nWell, as shown in \"Worse is better\", evolved design wins (Lisp machines\nversus Unix) :-)\n\n> When I now use git, I only do the most basic operations: clone, pull, push, \n> add, commit, checkout. When anything else arises, I check if it is worth the \n> risk of having to read up for hours - and since that wasn't the case for the \n> last few months, I then just ignore the problem or ask someone else if he can \n> fix it. \n\nUnderstanding Git \"mental model\" certainly helps.\n\n[...]\n> All in all it's a UI issue - while the git UI bit me quite often, the \n> Mercurial UI just works. \n\nBut _that_ might be because you are used to Mercurial UI, isn't it?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"94049","messageId":"fa27bd940810270729w488edd2clbd309093062558d6@mail.gmail.com","threadId":"16046","inReplyTo":"200810271157.20313.jnareb@gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"0000 vk","fromEmail":"0000.vk@gmail.com","sentAt":"2008-10-27T14:29:13Z","receivedAt":"2008-10-27T14:29:13Z","isPatch":false,"sender":{"key":"0000.vk@gmail.com","avatar":null},"body":"2008/10/27 Jakub Narebski \n\n> Dnia poniedziałek 27. października 2008 10:29, Benoit Boissinot napisał:\n> > On Mon, Oct 27, 2008 at 2:52 AM, Jakub Narebski \n> wrote:\n> >> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:\n> >>> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:\n> >>>>\n> >>>> I agree, and I think it is at least partially because of Git having\n> >>>> cleaner design, even if you have to understand more terms at first.\n> >>>\n> >>> What do you mean by \"cleaner design\"?\n> >>\n> >> Clean _underlying_ design. Git has very nice underlying model of graph\n> >> (DAG) of commits (revisions), and branches and tags as pointers to this\n> >> graph.\n> >\n> > Git and Mercurial are very close from that point of view.\n> >\n> > Mercurial explicitely disallow octopus merges (and we don't think there's\n> > a good reason to allow them, although I agree with Linus, they look very\n> nice\n> > in gitk ;) ).\n>\n> From what I see Mercurial disallows octopus merges (merges with more\n> than two parents) because of its rigid-record database repository\n> design, while Git is more like object database. Fixed width records\n> of VMS vs delimited records of Unix... There is simply place on\n> zero, one or two parents (two parent fields, which can be null) in\n> Mercurial changerev format.\n>\n> By the way flexibility of Git design allowed to add 'encoding' header\n> to commit message (if commits message is encoded not in utf-8) after\n> the fact, without affecting older repository data, and playing well\n> with old git installations which do not understand this header.\n>\n> > And we don't have \"branches as pointer\" in core, but the bookmark\n> > extension does that.\n>\n> I disagree. Mercurial implementation of tags is strange, and from\n> what I remember and from discussion on #revctrl implementation\n> of local named branches is also strange (CVS-like). They are IMHO\n> not well designed.\n>\n> Also the 'hidden' branches after fetching from remote repository\n> (hg pull) but before merging (hg update) are IMHO worse design\n> than explicit remote-tracking branches in Git, especially in presence\n> of multiple [named] branches in repositories.\n>\n> > Apart from that I think the underlying format are interchangeable,\n> > someone could use the git format with the hg ui, or use revlogs\n> > (the basic format of mercurial) like packs.\n>\n> I don't think so. The 'content addressed filesystem' idea of Git\n> is quite pervasive along Git implementation and Git thoughtflows.\n>\n> >\n> > The only special thing about revlogs is the linkrev stuff, it's a\n> > pointer to the first revision that introduced an object, so we can\n> > easily find what to send in our network protocol (we don't have to\n> > read the manifest, ie the \"tree\" of objects\"). linkrev can be useful\n> > to speedup \"hg log\" too.\n>\n> At first I thought: what a nice idea... but then I realized that in\n> distributed environment there is no way to define \"first revision that\n> introduced an object\". Take for example the following history\n> (independent introduction):\n>\n> .---.---.---.---x---.---.---.\n> \\\n> --x---.---.\n>\n> where both 'x' have the same version of an object. The top branch\n> appeared first in current repository, but the bottom branch had 'x'\n> with earlier timestamp (earlier authordate).\n>\n>\n> Git just relies on the fact that traversing revision is a part of it\n> that is heavily optimized and really fast. Git very much by design\n> doesn't store any backlinks in repository object database.\n>\n> >> I have read description of Mercurial's repository format, and it is not\n> >> very clear in my opinion. File changesets, bound using manifest, bound\n> >> using changerev / changelog.\n> >>\n> >\n> > just do a s/// with the git terminology:\n> > filelog -> blob\n> > manifest -> tree\n> > changelog -> commit object\n>\n> True. But as I see it they are bound in reverse order in Mercurial:\n> deltas are stored in filelog, filelogs are bound together in manifest,\n> manifest are bound using changelog, while in Git commit object\n> references tree (and parents), trees references blobs, and blob store\n> content of a file. But that might be just my impression.\n>\n>\n> .......................................................................\n>\n> By the way, going back to the matter of choosing version control system\n> for DragonflyBSD; some time ago I have written post\n> * \"Mercurial's only true \"plugin\" extension: inotify...\n> and can it be done in Git?\"\n> http://thread.gmane.org/gmane.comp.version-control.git/76661\n> (current answer: it is possible using 'assume unchanged' bit)\n> about how nearly every Mercurial extension has equivalent functionality\n> in Git.\n>\n> But what about the reverse, about the following features and\n> issues in Mercurial:\n>\n> * Merging in presence of criss-cross merges[1], and in presence of\n> file renames, i.e what merge-recursive does in Git.\n>\n> * git-rerere, reusing recorded resolution of conflicted merges.\n> Resolving the same merge happens often if you use topic branches\n> and trial merging.\n>\n> * git-grep that allows you to \"and\" the match criteria together,\n> and also pick a file (not a line) that matches all the criteria;\n> and of course allow searching given revision and not only working\n> directory.\n>\n> * pickaxe search (git log -S) which contrary to blame/annotate\n> allow to find commit which _deleted_ given fragment.\n>\n> * easy management of multiple repositories you fetch from with\n> remote-tracking branches and git-remote command.\n>\n> * blame that follows block-of-line movement (it was invented by Linus\n> as a vision long time ago, but it took very long time to materialize).\n>\n> * a way to review merge resolution, something that is done in git\n> by using combined diff format\n>\n> * git-stash, allowing to stash away changes to go back to them later;\n> it allows to stash away even partially resolved merge conflict\n> (merge resolution in progress).\n>\n> * git-filter-branch (based on cg-admin-rewrite-hist), which allow\n> to rewrite history for example to remove file which should never\n> be added to version control (for example because of copyright\n> or license).\n>\n> References:\n> ===========\n> [1] http://revctrl.org/CrissCrossMerge\n> BTW I wonder why reverting spam is made so hard on revctrl.org wiki\n>\n> --\n> Jakub Narebski\n> Poland\n>\n\nJakub,\n\nDo you know if git supports the equivalent of hg bundle?\nThanks.\n\nvk\n\n\n"},{"id":"94051","messageId":"200810271557.37196.jnareb@gmail.com","threadId":"16046","inReplyTo":"fa27bd940810270729w488edd2clbd309093062558d6@mail.gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-27T14:57:36Z","receivedAt":"2008-10-27T14:57:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 27 Oct 2008, 0000 vk wrote:\n> 2008/10/27 Jakub Narebski \n\n> > By the way, going back to the matter of choosing version control\n> > system for DragonflyBSD; some time ago I have written post\n> > * \"Mercurial's only true \"plugin\" extension: inotify...\n> > and can it be done in Git?\"\n> > http://thread.gmane.org/gmane.comp.version-control.git/76661\n> > (current answer: it is possible using 'assume unchanged' bit)\n> > about how nearly every Mercurial extension has equivalent functionality\n> > in Git.\n> >\n> > But what about the reverse, about the following features and\n> > issues in Mercurial:\n[...]\n\n> \n> Jakub,\n> \n> Do you know if git supports the equivalent of hg bundle?\n> Thanks.\n\nThe equivalent of \"hg bundle\" (http://www.selenic.com/mercurial/hg.1.html#bundle)\nwould be \"git bundle\" (http://git.or.cz/man/git-bundle). I think\ngit-bundle was inspired by Mercurial feature, just like fast-import\nformat and bisect went in other direction.\n\nP.S. Could you _please_ quote only relevant fragments of email you are\nreplying to, especially if it is so long?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"94063","messageId":"200810271901.48925.jnareb@gmail.com","threadId":"16046","inReplyTo":"200810271512.26352.arne_bab@web.de","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-27T18:01:48Z","receivedAt":"2008-10-27T18:01:48Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:\n> Am Monday 27 October 2008 13:48:38 schrieben Sie:\n\n>>> All in all it's a UI issue - while the git UI bit me quite often, the\n>>> Mercurial UI just works.\n>>\n>> But _that_ might be because you are used to Mercurial UI, isn't it?\n> \n> I rather think it is because I was used the Subversion UI before I tried git \n> and Mercurial.\n\nI think Mercurial UI is more compatibile with Subversion UI than Git;\nadditionally Mercurial uses separate, different names to avoid\nambiguities: examples are 'hg rollback' and 'hg backout' for commands\nwhich various SCM name reset and revert, sometimes referring to one\nand sometimes to the other.\n\nAFAIK Git mostly follows BitKeeper UI; it is quite natural as it was\nmeant as replacement for BitKeeper for Linux kernel development.\n\n[...]\n> Also, Mercurial is Python based with quite readable code and it's very easy to \n> create extensions for new uses, when I need them. \n> \n> If you know Python, creating a new Mercurial extension isn't harder than \n> creating a shell chain command for git, but it feels much cleaner and is \n> nicely integrated once it's done. You can even change the operation of basic \n> commands very easily without having to touch any existing code. \n\nThere are advantages and disadvantages to each method.\n\nGit was developed in true Unix tools style, as described in TAOUP i.e. \n\"The Art of UNIX Programming\" by ESR (http://catb.org/esr/writings/taoup/html/)\nIn \"Programming Pearls\" by Jon Bentley there is in one of chapters\ndescription of prototyping 'spell' using ready UNIX tools, pipelines,\nand a few of custom tools, to examine the needs of 'spell'.\n\nOne of the consequences of this type of design is that there isn't\n(yet?) something like git library; this is caused by the fact that\ntools (plumbing) that make up git are designed to run once, and let\noperating system take care of freeing resources.\n\nOn the other hand clean and clear design of git repository made it\npossible to create native Git (re)implementation in Java: the JGit\nproject. (Well, Git is GPLv2 and JGit/Egit is BSD 3-clause/EPL, so\nreimplementation might have been needed for licensing purposes anyway.\nWell, it is not _full_ implementation yet...\n\nBesides is writing plugin in Python for Mercurial that much easier\nthan writing new command or stuff in C for Git? Well, perhaps it is,\nas only recently there began to appear API documentation, and there\nwere created utility mini-libraries like strbuf, or string_list,\nor parseopt.\n\nAlso often third-party projects or stuff in contrib gets incorporated\ninto git proper; sometimes stuff is moved from git core to contrib,\nif there is no maintainer however (git-svnimport, git-p4import).\nGit repository has many roots: one from git core, one with gitk \n(graphical history viewer), one from what was git mail tools, one\nwith gitweb (web interface), and one with git-gui (graphical commit\ntool).\n\n\nThe extending via plugins idea used by Mercurial, so succesfull IMHO\nfor Firefox, and I think quite successfull for ikiwiki for example, is\nnot without drawbacks, especially that there is no plugins clearinghouse,\nand plugins are required for what is considered pretty required \nfunctionality, like bisect before hg 1.0.\n\nSee also blog post on vcscompare: \"Plugins In Version Control\"\nhttp://vcscompare.blogspot.com/2008/06/plugins-in-version-cotnrol.html\n\n-- \nJakub Narebski\nPoland\n"},{"id":"94078","messageId":"b6jwksWkldU6N726dbI3k3yYE6WL1aXJERb9Oh1lNd8g5zdTavgRew@cipher.nrlssc.navy.mil","threadId":"16046","inReplyTo":"200810270252.23392.jnareb@gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-10-27T20:07:32Z","receivedAt":"2008-10-27T20:07:32Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Jakub Narebski wrote:\n> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:\n>> Also, looking at git, git users still have to garbage collect regularly, which \n>> shows to me that the design wasn't really cleaner. \n> \n> Well, they have to a lot less than they used to, and there is \n> \"git gc --auto\" that can be put in crontab safely.\n\nI think you missed the most convincing argument _for_ explicit garbage collection.\n\nBy allowing explicit repository packing, git allows you to delay a cpu intensive\noperation til later, when time doesn't matter, like at the end of the day right\nbefore I go home. It also allows more cpu intensive delta/compression algorithms\nto be used.\n\nBy contrast, mercurial performs deltafication and compression on each commit.\nSo, acceptable commit speed must be weighed against the complexity of the\ndeltafication/compression algorithm and file format.\n\n-brandon\n"},{"id":"94079","messageId":"200810272137.07309.jnareb@gmail.com","threadId":"16046","inReplyTo":"b6jwksWkldU6N726dbI3k3yYE6WL1aXJERb9Oh1lNd8g5zdTavgRew@cipher.nrlssc.navy.mil","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-27T20:37:05Z","receivedAt":"2008-10-27T20:37:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 27 Oct 2008, Brandon Casey wrote:\n> Jakub Narebski wrote:\n> > On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:\n> > >\n> > > Also, looking at git, git users still have to garbage collect regularly, which \n> > > shows to me that the design wasn't really cleaner. \n> > \n> > Well, they have to a lot less than they used to, and there is \n> > \"git gc --auto\" that can be put in crontab safely.\n> \n> I think you missed the most convincing argument _for_ explicit garbage collection.\n> \n> By allowing explicit repository packing, git allows you to delay a cpu intensive\n> operation til later, when time doesn't matter, like at the end of the day right\n> before I go home. It also allows more cpu intensive delta/compression algorithms\n> to be used.\n> \n> By contrast, mercurial performs deltafication and compression on each commit.\n> So, acceptable commit speed must be weighed against the complexity of the\n> deltafication/compression algorithm and file format.\n\nOn the one hand one can use different compression for loose (immediate)\nand packed (in a free time) objects.\n\nOn the other access from \"smart\" client (git://, ssh://, future \"smart\"\nHTTP server) results in creating a pack, so we cannot allow for too\ntight pack compression, or to be more exact too much CPU load taken.\n\nThe ability to vary 'quality' of pack compression is very useful to\ndistinguish between very loosely packed fast-import pack, and tightly\nrepacked in free time.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"94081","messageId":"200810272149.13542.arne_bab@web.de","threadId":"16046","inReplyTo":"200810271901.48925.jnareb@gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Arne Babenhauserheide","fromEmail":"arne_bab@web.de","sentAt":"2008-10-27T20:48:50Z","receivedAt":"2008-10-27T20:48:50Z","isPatch":false,"sender":{"key":"arne_bab@web.de","avatar":"https://gravatar.com/avatar/4c060d566fc1b86d9ee5a5548bdc93436759676024e99f3e91191f32d38086d3?d=mp&s=160"},"body":"Am Montag 27 Oktober 2008 19:01:48 schrieb Jakub Narebski:\n> AFAIK Git mostly follows BitKeeper UI; it is quite natural as it was\n> meant as replacement for BitKeeper for Linux kernel development.\n\nIt is a great choice for an SCM intended for kernel development where everyone \nknows bitkeeper, but might not be optimal for other tasks. \n\n> Besides is writing plugin in Python for Mercurial that much easier\n> than writing new command or stuff in C for Git? Well, perhaps it is,\n> as only recently there began to appear API documentation, and there\n> were created utility mini-libraries like strbuf, or string_list,\n> or parseopt.\n\nYes, for two main reasons: \n\n1) Writing Python is much easier and quicker than writing C, especially when \nyou can just experiment with the Python interpreter (or better still: with \nipython). No memory management hassle, no strange compiler bugs, no stray \npointers. Just plain writing what you want to do. But if you need C speed, you \ncan still include parts written in C - where you really need it. For all other \ncases you have more readable and far more compact code. \n\n2) You can easily access every core function, and you can replace every \ncommand. \nYou don't have to invent a \"git foolog\" command. Instead you can just adapt \nthe regular log to do a foolog which people can use via \"hg log\". \n\n> Also often third-party projects or stuff in contrib gets incorporated\n> into git proper; sometimes stuff is moved from git core to contrib,\n> if there is no maintainer however (git-svnimport, git-p4import).\n> Git repository has many roots: one from git core, one with gitk\n> (graphical history viewer), one from what was git mail tools, one\n> with gitweb (web interface), and one with git-gui (graphical commit\n> tool).\n\nMaybe I should include the extensions in the codeswarm to have matching \nrepositories. \n\n> The extending via plugins idea used by Mercurial, so succesfull IMHO\n> for Firefox, and I think quite successfull for ikiwiki for example, is\n> not without drawbacks, especially that there is no plugins clearinghouse,\n> and plugins are required for what is considered pretty required\n> functionality, like bisect before hg 1.0.\n\nBut they can just be included in the core distibution once they become central \nenough. \n\nIt's a way of allowing people to add functionality they miss without forcing \nthem to mess with core code instantly. \n\n> See also blog post on vcscompare: \"Plugins In Version Control\"\n> http://vcscompare.blogspot.com/2008/06/plugins-in-version-cotnrol.html\n\nI just read it, and it didn't convince me, because in my opinion a VCS has \ncertain core functions which it should provide to everyone, and other \nfunctionality which only certain people need. \n\nFor example I normally don't need rebasing, mercurial queues, transplanting \nand similar. Why should my tool include the commands by default? \n\nThe defaults should be the most common way to use the tool, so people can \neasily learn it. \n\nAdvanced stuff can be added with extensions. \n\nAnd because the most used plugins are distributed with Mercurial, I can also \nactivate them when I don't control the Mercurial installation - and should \nsomething be missing which I need, I can just download and activate a plugin \nwithout having to compile anything, since they are simply Python modules. \n\nJust set \n[extensions]\nfoo = /blah/foo.py\n\nin ~/.hgrc and the foo plugin is active. \n\nGits missing plugin system might just be a reason, why its usability still \nsuffers from many problems: They have to do everything for everyone all the \ntime, so the chances are high, that they won't do it really good for anyone \n(but the main git coders). \n\nBest wishes, \nArne\n\n-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)\n-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the \nhistory of free software.\n-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.\n\n-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt\n"},{"id":"94082","messageId":"20081027210716.GS2273@genesis.frugalware.org","threadId":"16046","inReplyTo":"200810272149.13542.arne_bab@web.de","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-10-27T21:07:16Z","receivedAt":"2008-10-27T21:07:16Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Mon, Oct 27, 2008 at 09:48:50PM +0100, Arne Babenhauserheide wrote:\n> 1) Writing Python is much easier and quicker than writing C, especially when \n> you can just experiment with the Python interpreter (or better still: with \n> ipython). No memory management hassle, no strange compiler bugs, no stray \n> pointers. Just plain writing what you want to do. But if you need C speed, you \n> can still include parts written in C - where you really need it. For all other \n> cases you have more readable and far more compact code. \n\nYou compare Python to C here, but did you realize that in git you can\nwrite your git command in any language you want? Of course it's\nrecommended to do it in C/shell/perl if you want to get it included in\ngit.git, but that's just a decision.\n\n> 2) You can easily access every core function, and you can replace every \n> command. \n> You don't have to invent a \"git foolog\" command. Instead you can just adapt \n> the regular log to do a foolog which people can use via \"hg log\". \n\nIIRC the main reason git aliases can't overwrite git commands is because\nthat would break scripts relying on the output of existing git commands.\nGiven that I install such an extension, won't my script break?\n\n> The defaults should be the most common way to use the tool, so people can \n> easily learn it. \n> \n> Advanced stuff can be added with extensions. \n\nFrom a user's point of view, I think external git commands and such hg\nplugins are equal. The user instally the \"foo\"\nextension/command/plugin/whatever and gets the \"git/hg foo\" command.\n\n> And because the most used plugins are distributed with Mercurial, I can also \n> activate them when I don't control the Mercurial installation - and should \n> something be missing which I need, I can just download and activate a plugin \n> without having to compile anything, since they are simply Python modules. \n> \n> Just set \n> [extensions]\n> foo = /blah/foo.py\n> \n> in ~/.hgrc and the foo plugin is active. \n\nSame for git, as long as it's written in a scripting language; you\nshould include git-foo in PATH then you can use git foo.\n"},{"id":"94083","messageId":"200810272230.51683.arne_bab@web.de","threadId":"16046","inReplyTo":"20081027210716.GS2273@genesis.frugalware.org","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Arne Babenhauserheide","fromEmail":"arne_bab@web.de","sentAt":"2008-10-27T21:30:44Z","receivedAt":"2008-10-27T21:30:44Z","isPatch":false,"sender":{"key":"arne_bab@web.de","avatar":"https://gravatar.com/avatar/4c060d566fc1b86d9ee5a5548bdc93436759676024e99f3e91191f32d38086d3?d=mp&s=160"},"body":"Am Montag 27 Oktober 2008 22:07:16 schrieb Miklos Vajna:\n> You compare Python to C here, but did you realize that in git you can\n> write your git command in any language you want? Of course it's\n> recommended to do it in C/shell/perl if you want to get it included in\n> git.git, but that's just a decision.\n\nI was asked explicitely about the difference of writing a Mercurial extension \nand of writing some addition for git in C, so I answered that. \n\n> IIRC the main reason git aliases can't overwrite git commands is because\n> that would break scripts relying on the output of existing git commands.\n> Given that I install such an extension, won't my script break?\n\nSince that \"script\" will likely be an extension which will use the core \nfunction instead of the UI command, it won't break. \n\nStuff which does command line parsing can naturally break when I change the \noutput. But it can also directly use the advanced features. \n\n> From a user's point of view, I think external git commands and such hg\n> plugins are equal. The user instally the \"foo\"\n> extension/command/plugin/whatever and gets the \"git/hg foo\" command.\n[snip]\n> Same for git, as long as it's written in a scripting language; you\n> should include git-foo in PATH then you can use git foo.\n\nMeans git can provide additional commands and only has the limitation that I \ncan't overwrite the basic commands, right? \n\nBut we're slowly moving off topic, aside from \"OK, git also has extensions - \nthey are called external commands\". \n\nBest wishes, \nArne\n\n\n-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)\n-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the \nhistory of free software.\n-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.\n\n-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt\n"},{"id":"94084","messageId":"200810280025.18234.jnareb@gmail.com","threadId":"16046","inReplyTo":"200810272149.13542.arne_bab@web.de","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-27T23:25:17Z","receivedAt":"2008-10-27T23:25:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia poniedziałek 27. października 2008 21:48, Arne Babenhauserheide napisała:\n> Am Montag 27 Oktober 2008 19:01:48 schrieb Jakub Narebski:\n \n> > Besides is writing plugin in Python for Mercurial that much easier\n> > than writing new command or stuff in C for Git? Well, perhaps it is,\n> > as only recently there began to appear API documentation, and there\n> > were created utility mini-libraries like strbuf, or string_list,\n> > or parseopt.\n> \n> Yes, for two main reasons: \n> \n> 1) Writing Python is much easier and quicker than writing C, especially when \n> you can just experiment with the Python interpreter (or better still: with \n> ipython). No memory management hassle, no strange compiler bugs, no stray \n> pointers. Just plain writing what you want to do. But if you need C speed, you \n> can still include parts written in C - where you really need it. For all other \n> cases you have more readable and far more compact code. \n\nIn Git you can write in C, using (underdocumented) git API, or you can\nscript (in shell script, in Perl, in Python, in Ruby) using git plumbing\ncommands which are meant for scripting (or bindings in appropriate\nlanguage).\n \nMost new features, like git-remote tool to manage interaction with\nmultiple remote repositories, each of which can have multiple branches,\nstart as a shell or Perl script, and when they and their UI mature they\nget converted into C (made into builtin). Builtinification is done not\nonly for performance, but also for portability (think Perl support on\nMS Windows).\n\nSo in Mercurial you can write in Python, or you can write in C; in Git\nyou can write in any scripting language (e.g. shell script, Perl, Tcl/Tk),\nor you can write in C... yes, I know it is oversimplification...\n\n> 2) You can easily access every core function, and you can replace every \n> command. \n> You don't have to invent a \"git foolog\" command. Instead you can just adapt \n> the regular log to do a foolog which people can use via \"hg log\".\n\nWell, if I remember correctly if you drop git-foo in EXEC_PATH, then\nyou would be able to call it as \"git foo\". So adding commands is easy.\n\nGit provides a few entry points which can be used to extend\nfunctionality. They are: hooks system; gitattributes to define custom\nmerge, diff and clean/smudge (checkout) drivers per file (pathname);\ncustom merge strategies; EXTRENAL_DIFF and EXTERNAL_GREP.\n\nI'm not sure if other messing with core functions is a good idea to\nhave such ability accessible.\n\n> > The extending via plugins idea used by Mercurial, so succesfull IMHO\n> > for Firefox, and I think quite successfull for ikiwiki for example, is\n> > not without drawbacks, especially that there is no plugins clearinghouse,\n> > and plugins are required for what is considered pretty required\n> > functionality, like bisect before hg 1.0.\n> \n> But they can just be included in the core distibution once they become central \n> enough. \n\nHaving some extensions blessed to be included with core program (like\nikiwiki with goodstuff, and similar to Git with contrib/ section)\nsolves some problems of relying on extensions for basic functionality.\nI for example consider bisect and patch+mail workflow tools to be basic,\nwhile patch queue management (well, patch management in general) to be\nsomething that can be built on top of SCM, like StGit, Guilt, TopGit\nfor Git, or mq (Mercurial Queues) for Mercurial.\n \n>\n> It's a way of allowing people to add functionality they miss without forcing \n> them to mess with core code instantly. \n\nThe problem with extensions IMVVVHO is that they don't require to\nfollow strict \"inclusion in core\" standards, which means that there\nis no pressure to add them to core... which for example leads to\nincluding bisect in core only since hg v1.0, \"because it is available\nas extension\".\n\nRequiring to use large amount of extensions to having required\nfunctionality is also one of bad consequences of extension based\ndevelopment, although having default set of extensions that can be\nturned on via some metaextension / metapackage (like ikiwiki's\ngoodstuff) reduces impact of this.\n \nExtensions / modules / plugins are good in projects with high\nbarriers of development, like Mozilla / Firefox, GNU Emacs, etc.\nbut I am not sure if it doesn't make for slower core development...\n\n> Gits missing plugin system might just be a reason, why its usability still \n> suffers from many problems: They have to do everything for everyone all the \n> time, so the chances are high, that they won't do it really good for anyone \n> (but the main git coders). \n\nWell, Git doesn't have plugin system, but is easily scriptable...\n\nAnd, at least according to annual Git User's Survey results (on git wiki)\nmany people create their custom scripts and scriplets to make their work\nwith SCM easy...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"94085","messageId":"20081028001308.GA24201@genesis.frugalware.org","threadId":"16046","inReplyTo":"200810272230.51683.arne_bab@web.de","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-10-28T00:13:08Z","receivedAt":"2008-10-28T00:13:08Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Mon, Oct 27, 2008 at 10:30:44PM +0100, Arne Babenhauserheide wrote:\n> Means git can provide additional commands and only has the limitation that I \n> can't overwrite the basic commands, right? \n\nYes. And in general the API is the output of the plumbing commands, not\nthe API of libgit which is totally unstable.\n\n> But we're slowly moving off topic, aside from \"OK, git also has extensions - \n> they are called external commands\". \n\nI think we're offtopic since the dragonfly list is not in cc. :)\n"},{"id":"94086","messageId":"alpine.LFD.2.00.0810272041180.13034@xanadu.home","threadId":"16046","inReplyTo":"200810272137.07309.jnareb@gmail.com","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-10-28T01:28:37Z","receivedAt":"2008-10-28T01:28:37Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 27 Oct 2008, Jakub Narebski wrote:\n\n> On the other access from \"smart\" client (git://, ssh://, future \"smart\"\n> HTTP server) results in creating a pack, so we cannot allow for too\n> tight pack compression, or to be more exact too much CPU load taken.\n\nDon't forget that, in those cases, the created pack for streaming is \ncopying chunks of data from existing packs for most objects, effectively \nreusing for free the work that has previously been done to tightly \ncompress those packs.\n\n\nNicolas\n"},{"id":"94101","messageId":"ge70nl$l6t$1@ger.gmane.org","threadId":"16046","inReplyTo":"ge0rla$mce$1@ger.gmane.org","subject":"Re: [VOTE] git versus mercurial","fromName":"walt","fromEmail":"w41ter@gmail.com","sentAt":"2008-10-28T12:31:47Z","receivedAt":"2008-10-28T12:31:47Z","isPatch":false,"sender":{"key":"w41ter@gmail.com","avatar":null},"body":"walt wrote:\n> No, no, I'm not the one calling for a vote. You old-timers here\n> will know the name Matt Dillon, who is leading the dragonflybsd\n> project (www.dragonflybsd.org).\n>\n> Matt is the one who is calling for the vote in his thread \"Vote\n> for your source control system\" in the dragonfly.kernel group,\n> accessible via nntp://nntp.dragonflybsd.org...\n\nThe official vote was 19 to 19, plus one for perforce and one\nfor svn. Matt has proposed a primary git repository and a mirror\nin hg, and that's being debated now.\n\nI've already learned a lot from following this topic in both\nlists and it seems this is a topic of great interest to many,\nso I'll continue reading in both places.\n\nThanks!\n"},{"id":"94107","messageId":"alpine.DEB.1.00.0810281445190.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"16046","inReplyTo":"ge70nl$l6t$1@ger.gmane.org","subject":"Re: [VOTE] git versus mercurial","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-28T14:28:06Z","receivedAt":"2008-10-28T14:28:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 28 Oct 2008, walt wrote:\n\n> walt wrote:\n> > No, no, I'm not the one calling for a vote. You old-timers here will \n> > know the name Matt Dillon, who is leading the dragonflybsd project \n> > (www.dragonflybsd.org).\n> >\n> > Matt is the one who is calling for the vote in his thread \"Vote for \n> > your source control system\" in the dragonfly.kernel group, accessible \n> > via nntp://nntp.dragonflybsd.org...\n> \n> The official vote was 19 to 19, plus one for perforce and one for svn. \n> Matt has proposed a primary git repository and a mirror in hg, and \n> that's being debated now.\n\nWhile many may say that that is a half-baked solution, I actually like it. \nMercurial and Git are pretty similar in their concept (if not in how the \ndata is actually stored).\n\nNote that with git fast-export and hg fast-import, it should be relatively \nsimple to convert from one data format to the other, even incrementally.\n\nAnd for the other direction, you could use hg fast-export from the \nfast-export.git repository (I am working on a better one at the moment, \ntoo, so that incremental fast-export would be possible, too).\n\nCiao,\nDscho\n"},{"id":"94108","messageId":"Pine.LNX.4.64.0810281536360.27029@ds9.cixit.se","threadId":"16046","inReplyTo":"alpine.DEB.1.00.0810281445190.22125@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2008-10-28T14:41:29Z","receivedAt":"2008-10-28T14:41:29Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Johannes Schindelin:\n\n> While many may say that that is a half-baked solution, I actually\n> like it. Mercurial and Git are pretty similar in their concept (if\n> not in how the data is actually stored).\n\nThat touches on something that I have been thinking about for a while.\n\nHow difficult are the storage formats? Would it be possible, in a\nreasonable amount of work, to add support for the Mercurial protocol\nand format in \"git clone\", so that I could clone a Mercurial repository\nand work on it with Git, and then possibly use \"git push\" to possibly\npush the result back to Mercurial?\n\nIt seems to me that use of DVCS is polarising between Git, Mercurial\nand Bzr. It would be nice to have easy interoperability between the\nsystems, at least as far as can be covered by the lowest common\ndenominator of what they support. I would love to be able to use Git to\nclone a Bzr repository that I need to be able to access, since bzr is\njust different enough from Git to be annoying. Same goes for Mercurial.\nAnd I am sure that users of the other tools feel the same.\n\nWould it be possible to design a common transfer format that could be\nimplemented by all three (and that would be a little smarter than\nfast-export/fast-import)?\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"94109","messageId":"alpine.DEB.1.00.0810281551040.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"16046","inReplyTo":"Pine.LNX.4.64.0810281536360.27029@ds9.cixit.se","subject":"Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-28T14:59:04Z","receivedAt":"2008-10-28T14:59:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 28 Oct 2008, Peter Krefting wrote:\n\n> How difficult are the storage formats? Would it be possible, in a\n> reasonable amount of work, to add support for the Mercurial protocol\n> and format in \"git clone\", so that I could clone a Mercurial repository\n> and work on it with Git, and then possibly use \"git push\" to possibly\n> push the result back to Mercurial?\n\nThere was talk about imitating Mercurial's wire protocol in order to have \nan efficient HTTP server. Shawn is working on that front;\n\nWe discussed it briefly, and there might be some cute ways to copy it: \nsince we are not append-only, we have to download the pack index first \n(which is not downloaded ATM, as we generate it from the downloaded pack \nwhile verifying it). With that index, we can determine which parts we \nneed in order to regenerate the pack; it would still be pretty stupid when \nthere are a lot of branches and we are really only interested in one of \nthem.\n\nBut I doubt that it will be possible to use the wire protocol to pull/push \nbetween different DVCSes. I _strongly_ doubt that the SHA-1s in the \nMercurial repositories could _ever_ be reused in Git mirrors of them, as \nour data format (on which the hash depends) is different.\n\n> It would be nice to have easy interoperability between the systems, at \n> least as far as can be covered by the lowest common denominator of what \n> they support. I would love to be able to use Git to clone a Bzr \n> repository that I need to be able to access, since bzr is just different \n> enough from Git to be annoying. Same goes for Mercurial. And I am sure \n> that users of the other tools feel the same.\n\nWasn't bzr touting it as one of their major features that they could have \nforeign-scm remotes? If I remembered that correctly, that might be the \nroute you want to take.\n\nCiao,\nDscho\n"},{"id":"94110","messageId":"vpqr660g3tq.fsf@bauges.imag.fr","threadId":"16046","inReplyTo":"alpine.DEB.1.00.0810281551040.22125@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: Git/Mercurial interoperability (and what about bzr?)","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-10-28T15:02:57Z","receivedAt":"2008-10-28T15:02:57Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n> Wasn't bzr touting it as one of their major features that they could have \n> foreign-scm remotes? If I remembered that correctly, that might be the \n> route you want to take.\n\nYes, see http://bazaar-vcs.org/BzrForeignBranches . That can be\ncompared to git-svn for git, except that one uses the exact same\ncommand set to interact with the remotes (i.e. you \"bzr push\" to an\nsvn repository, while you would \"git svn dcommit\" with git).\n\nThere are read-only implementations of Git and Mercurial foreign\nbranches. AFAIK, unfortunately, they're more proof of concepts than\nreal \"production ready\" plugins.\n\n-- \nMatthieu\n"},{"id":"94118","messageId":"alpine.LFD.2.00.0810281052490.13034@xanadu.home","threadId":"16046","inReplyTo":"Pine.LNX.4.64.0810281536360.27029@ds9.cixit.se","subject":"Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-10-28T15:03:10Z","receivedAt":"2008-10-28T15:03:10Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 28 Oct 2008, Peter Krefting wrote:\n\n> Johannes Schindelin:\n> \n> > While many may say that that is a half-baked solution, I actually\n> > like it. Mercurial and Git are pretty similar in their concept (if\n> > not in how the data is actually stored).\n> \n> That touches on something that I have been thinking about for a while.\n> \n> How difficult are the storage formats? Would it be possible, in a\n> reasonable amount of work, to add support for the Mercurial protocol\n> and format in \"git clone\", so that I could clone a Mercurial repository\n> and work on it with Git, and then possibly use \"git push\" to possibly\n> push the result back to Mercurial?\n\nThe git protocol is intimately tied to its repository storage format, \nmaking any interoperability at the protocol level really hard. It is \nprobably easier to perform the clone/push operations with native tools \nand do the interoperability dance locally between repositories, possibly \nwith some wrappers hiding all the details. In the end you could still \nbe doing a \"git push\" but the native tool is best for handling transfer \nprotocols. Yes, there is git-cvsserver outperforming a real CVS server, \nbut that's another story.\n\n\nNicolas\n"},{"id":"94115","messageId":"E026EBDF-F402-49AB-A7A8-0A0EFB513907@ai.rug.nl","threadId":"16046","inReplyTo":"Pine.LNX.4.64.0810281536360.27029@ds9.cixit.se","subject":"Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-10-28T15:33:54Z","receivedAt":"2008-10-28T15:33:54Z","isPatch":false,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn 28 okt 2008, at 15:41, Peter Krefting wrote:\n\n> It seems to me that use of DVCS is polarising between Git, Mercurial\n> and Bzr. It would be nice to have easy interoperability between the\n> systems, at least as far as can be covered by the lowest common\n> denominator of what they support. I would love to be able to use Git \n> to\n> clone a Bzr repository that I need to be able to access, since bzr is\n> just different enough from Git to be annoying. Same goes for \n> Mercurial.\n> And I am sure that users of the other tools feel the same.\n>\n> Would it be possible to design a common transfer format that could be\n> implemented by all three (and that would be a little smarter than\n> fast-export/fast-import)?\n\nWhat would you want that the fast-export/imports are lacking? I think \nthey are excellent tools to build some integration on.\n\nYou might want to look at my git-bzr script (http://github.com/pieter/git-bzr/tree/master \n), which I created so I could use\nbazaar branches easily in git. It allows you to fetch a bzr branch, \nmerge it in with your local work, and then push it out again:\n\n\tgit bzr add bzr-branch ~/bazaar/something\n\tgit bzr fetch bzr-branch\n\tgit merge bzr/bzr-branch\n\tgit bzr push bzr-branch\n\nIt's quite crude, but it's also only 100 lines or so and does what I \nneed. It should also be simple enough to adapt it to also incorporate \nhg. When I needed the bzr integration, I looked into hg as well, but \nthere wasn't a hg fast-import yet. If I understand dscho correctly, \nthat exists now, so it should be easy enough to integrate that as well.\n\n- Pieter\n"},{"id":"94125","messageId":"4907506C.8090609@op5.se","threadId":"16046","inReplyTo":"200810272230.51683.arne_bab@web.de","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-28T17:48:28Z","receivedAt":"2008-10-28T17:48:28Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Arne Babenhauserheide wrote:\n> Am Montag 27 Oktober 2008 22:07:16 schrieb Miklos Vajna:\n>> IIRC the main reason git aliases can't overwrite git commands is because\n>> that would break scripts relying on the output of existing git commands.\n>> Given that I install such an extension, won't my script break?\n> \n> Since that \"script\" will likely be an extension which will use the core \n> function instead of the UI command, it won't break. \n> \n> Stuff which does command line parsing can naturally break when I change the \n> output. But it can also directly use the advanced features. \n> \n\nBut then you're back with a single language, taking valuable freedom\naway from the addon author. How many perl gurus have skipped writing\nstuff for hg because it's a \"python-or-bust\" thing?\n\nAnd please don't give me that rubbish of \"but Python is obviously better\nthan C\". Which one's true (if any) depends only on how you define \"better\".\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"94127","messageId":"200810282011.40647.arne_bab@web.de","threadId":"16046","inReplyTo":"4907506C.8090609@op5.se","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Arne Babenhauserheide","fromEmail":"arne_bab@web.de","sentAt":"2008-10-28T19:11:36Z","receivedAt":"2008-10-28T19:11:36Z","isPatch":false,"sender":{"key":"arne_bab@web.de","avatar":"https://gravatar.com/avatar/4c060d566fc1b86d9ee5a5548bdc93436759676024e99f3e91191f32d38086d3?d=mp&s=160"},"body":"Am Dienstag 28 Oktober 2008 18:48:28 schrieb Andreas Ericsson:\n> > Stuff which does command line parsing can naturally break when I change\n> > the output. But it can also directly use the advanced features.\n>\n> But then you're back with a single language, taking valuable freedom\n> away from the addon author. \n\nNot really. \n\nExtension authors just have to take care to keep their output compatible. \n\nYou can do command line parsing just like with git, but additionally you can \nchange the workings of the basic commands, but then you have to take care to \nkeep the output compatible. \n\nFor example when I wrote the group extension, I made sure that the log only \ngives grouped output, when it is explicitely asked to do so, either via \n--group or via the grouped_log=True setting in .hgrc. \n\n> How many perl gurus have skipped writing\n> stuff for hg because it's a \"python-or-bust\" thing?\n\nHow many Python people decided to write an extension for hg, because it can \nvery nicely be accessed via Python? \n\n(and which one of these has the higher effect? :) )\n\nBest wishes, \nArne\n\n\n-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)\n-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the \nhistory of free software.\n-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.\n\n-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt\n"},{"id":"94128","messageId":"20081028191234.GS24201@genesis.frugalware.org","threadId":"16046","inReplyTo":"E026EBDF-F402-49AB-A7A8-0A0EFB513907@ai.rug.nl","subject":"Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-10-28T19:12:34Z","receivedAt":"2008-10-28T19:12:34Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Tue, Oct 28, 2008 at 04:33:54PM +0100, Pieter de Bie wrote:\n> fast-import yet. If I understand dscho correctly, that exists now, so it \n> should be easy enough to integrate that as well.\n\nThat's new to me. Theodore Ts'o once mentioned on this list that there\nis a \"hg fast-export\" but actually he just referred to \"there is a\ngit2hg conversion tool in hg's contrib dir\" and it has nothing with\nfast-import.\n\nThere is an other reference to hg fast-import:\n\nhttp://www.nabble.com/cvs2git-2.1-causes-git-fast-import-to-exit-with-an-error-td16049922.html\n\nbut I found no code so far.\n\nTo sum up, I'm not so sure about a working hg fast-import is available\nat the moment.\n"},{"id":"94130","messageId":"86abcocyyy.fsf@blue.stonehenge.com","threadId":"16046","inReplyTo":"4907506C.8090609@op5.se","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2008-10-28T19:16:05Z","receivedAt":"2008-10-28T19:16:05Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Andreas\" == Andreas Ericsson writes:\n\nAndreas> And please don't give me that rubbish of \"but Python is obviously\nAndreas> better than C\". Which one's true (if any) depends only on how you\nAndreas> define \"better\".\n\nBut any way you define it, Perl is \"better\" than either of those!\n\n:-)\n\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion\n"},{"id":"94132","messageId":"20081028193841.GA23637@neumann","threadId":"16046","inReplyTo":"200810282011.40647.arne_bab@web.de","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2008-10-28T19:38:49Z","receivedAt":"2008-10-28T19:38:49Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Oct 28, 2008 at 08:11:36PM +0100, Arne Babenhauserheide wrote:\n> > How many perl gurus have skipped writing\n> > stuff for hg because it's a \"python-or-bust\" thing?\n> \n> How many Python people decided to write an extension for hg, because it can \n> very nicely be accessed via Python? \n\nAnd wouldn't they contribute at all, if there would be hg bindings for\nother programming languages, would they?\n\n\nBest,\nGábor\n"},{"id":"94139","messageId":"20081028211032.GU24201@genesis.frugalware.org","threadId":"16046","inReplyTo":"20081028191234.GS24201@genesis.frugalware.org","subject":"Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-10-28T21:10:32Z","receivedAt":"2008-10-28T21:10:32Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Tue, Oct 28, 2008 at 08:12:34PM +0100, Miklos Vajna wrote:\n> To sum up, I'm not so sure about a working hg fast-import is available\n> at the moment.\n\nI wrote too fast.\n\nThere is a minimal implementation here:\n\nhttp://hg.opensource.lshift.net/hg-fastimport/\n\n(I haven't tried it yet myself.)\n"},{"id":"94142","messageId":"20081028213144.GC10862@mit.edu","threadId":"16046","inReplyTo":"20081028191234.GS24201@genesis.frugalware.org","subject":"Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-10-28T21:31:44Z","receivedAt":"2008-10-28T21:31:44Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Oct 28, 2008 at 08:12:34PM +0100, Miklos Vajna wrote:\n> On Tue, Oct 28, 2008 at 04:33:54PM +0100, Pieter de Bie wrote:\n> > fast-import yet. If I understand dscho correctly, that exists now, so it \n> > should be easy enough to integrate that as well.\n> \n> That's new to me. Theodore Ts'o once mentioned on this list that there\n> is a \"hg fast-export\" but actually he just referred to \"there is a\n> git2hg conversion tool in hg's contrib dir\" and it has nothing with\n> fast-import.\n\nThe code I was referring to was called hg-fast-export, which is part\nof the \"fast export\" tools that front-end into git fast-import. The\ngit repository can be found here:\n\n\thttp://repo.or.cz/w/fast-export.git\n\tgit://repo.or.cz/fast-export.git\n\nI ended up using a very customized version of that script to convert\nthe hg e2fsprogs repository to git.\n\nIn the past I've looked at the possibility of creating a\nbi-directional, incremental gateway between hg and git repositories.\nThe main thing which makes this difficult is that hg stores tags\nin-band inside the change-controlled .hgtags file. This means that if\nyou cut a release, tag it, and then create a commit to further modify\nthe repository, the new commit is descended from the tag commit,\nwhereas in git, the tag is a \"bookmark\" --- perhaps signed via GPG,\nbut not part of the revision history.\n\nI think the git method is much more sane, but what it means is that\ntopologically, the commit tree for git and hg can never be identical.\nIt also means that if you add a tag to a git tree after making several\ncommits on that branch, how you reflect that in the hg repository is\nhighly problematic. Do you rewrite the branch? Do you add the tag\nlater on, disturbing the parent-child relationship of later commits?\nHow do you keep track of when a tag hg repository topology if you are\ntrying to maintain a bidirectional mapping between commits?\n\nIt's not impossible, but it makes it much more difficult, since in the\nhg world, tag commits can be inserted between arbitrary commits. This\nalso means that if you want to create a bidrectional gateway between\nhg and git, it has to be a single gateway so it can keep track of this\nstate information. If you try to have multiple gateways they would\nneed to synchronize on when a tag entered the hg universe, and with\nwhat commit ID (and what timestamp).\n\n\t\t\t\t\t\t- Ted\n"},{"id":"94147","messageId":"20081028232823.GX24201@genesis.frugalware.org","threadId":"16046","inReplyTo":"20081028213144.GC10862@mit.edu","subject":"Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-10-28T23:28:23Z","receivedAt":"2008-10-28T23:28:23Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Tue, Oct 28, 2008 at 05:31:44PM -0400, Theodore Tso wrote:\n> The code I was referring to was called hg-fast-export, which is part\n> of the \"fast export\" tools that front-end into git fast-import. The\n> git repository can be found here:\n> \n> \thttp://repo.or.cz/w/fast-export.git\n> \tgit://repo.or.cz/fast-export.git\n> \n> I ended up using a very customized version of that script to convert\n> the hg e2fsprogs repository to git.\n\nMy bad, I did not quote the article properly, so here is what I meant:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/42298\n\nand I just wanted to say that this one does not use fast-import, so it's\nnot really a \"hg-fast-import\" (it's not something that can parse the\noutput of git-fast-export).\n"},{"id":"94167","messageId":"buoy7074y1x.fsf@dhapc248.dev.necel.com","threadId":"16046","inReplyTo":"ge70nl$l6t$1@ger.gmane.org","subject":"Re: [VOTE] git versus mercurial","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2008-10-29T08:15:22Z","receivedAt":"2008-10-29T08:15:22Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"walt writes:\n> The official vote was 19 to 19, plus one for perforce and one\n> for svn. Matt has proposed a primary git repository and a mirror\n> in hg, and that's being debated now.\n\nBoy, whoever has the popcorn concession must be making a fortune!\n\n-Miles\n\n-- \nInfancy, n. The period of our lives when, according to Wordsworth, 'Heaven\nlies about us.' The world begins lying about us pretty soon afterward.\n"},{"id":"94206","messageId":"20081029191140.GB29357@spearce.org","threadId":"16046","inReplyTo":"alpine.DEB.1.00.0810281445190.22125@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: [VOTE] git versus mercurial","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-10-29T19:11:40Z","receivedAt":"2008-10-29T19:11:40Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Tue, 28 Oct 2008, walt wrote:\n> \n> > walt wrote:\n> > > No, no, I'm not the one calling for a vote. You old-timers here will \n> > > know the name Matt Dillon, who is leading the dragonflybsd project \n> > > (www.dragonflybsd.org).\n> > >\n> > > Matt is the one who is calling for the vote in his thread \"Vote for \n> > > your source control system\" in the dragonfly.kernel group, accessible \n> > > via nntp://nntp.dragonflybsd.org...\n> > \n> > The official vote was 19 to 19, plus one for perforce and one for svn. \n> > Matt has proposed a primary git repository and a mirror in hg, and \n> > that's being debated now.\n\nFWIW at the Google Summer of Code Mentor Summit this past weekend\nwe had a \"Git vs. Hg\" talk with both Git and Hg represented by\ncontributors to each project.\n\nSlides are online here:\n\n http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr\n\n-- \nShawn.\n"},{"id":"94212","messageId":"alpine.LNX.2.00.0810291335400.7553@suse104.zenez.com","threadId":"16046","inReplyTo":"20081029191140.GB29357@spearce.org","subject":"Re: [VOTE] git versus mercurial","fromName":"Boyd Lynn Gerber","fromEmail":"gerberb@zenez.com","sentAt":"2008-10-29T19:36:35Z","receivedAt":"2008-10-29T19:36:35Z","isPatch":false,"sender":{"key":"gerberb@zenez.com","avatar":null},"body":"On Wed, 29 Oct 2008, Shawn O. Pearce wrote:\n> Johannes Schindelin wrote:\n>> On Tue, 28 Oct 2008, walt wrote:\n>>> walt wrote:\n>>>> No, no, I'm not the one calling for a vote. You old-timers here will\n>>>> know the name Matt Dillon, who is leading the dragonflybsd project\n>>>> (www.dragonflybsd.org).\n>>>>\n>>>> Matt is the one who is calling for the vote in his thread \"Vote for\n>>>> your source control system\" in the dragonfly.kernel group, accessible\n>>>> via nntp://nntp.dragonflybsd.org...\n>>>\n>>> The official vote was 19 to 19, plus one for perforce and one for svn.\n>>> Matt has proposed a primary git repository and a mirror in hg, and\n>>> that's being debated now.\n>\n> FWIW at the Google Summer of Code Mentor Summit this past weekend\n> we had a \"Git vs. Hg\" talk with both Git and Hg represented by\n> contributors to each project.\n>\n> Slides are online here:\n>\n> http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr\n\nBut how do I save the presentation? I do not seem to be able to do it. I \nwould like to view it off-line.\n\nThanks,\n\n--\nBoyd Gerber \nZENEZ\t1042 East Fort Union #135, Midvale Utah 84047\n"},{"id":"94211","messageId":"alpine.DEB.1.00.0810292047530.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"16046","inReplyTo":"alpine.LNX.2.00.0810291335400.7553@suse104.zenez.com","subject":"Re: [VOTE] git versus mercurial","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-29T19:48:24Z","receivedAt":"2008-10-29T19:48:24Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 29 Oct 2008, Boyd Lynn Gerber wrote:\n\n> On Wed, 29 Oct 2008, Shawn O. Pearce wrote:\n> > Johannes Schindelin wrote:\n> > > On Tue, 28 Oct 2008, walt wrote:\n> > > > walt wrote:\n> > > > > No, no, I'm not the one calling for a vote. You old-timers here \n> > > > > will know the name Matt Dillon, who is leading the dragonflybsd \n> > > > > project (www.dragonflybsd.org).\n> > > > >\n> > > > > Matt is the one who is calling for the vote in his thread \"Vote \n> > > > > for your source control system\" in the dragonfly.kernel group, \n> > > > > accessible via nntp://nntp.dragonflybsd.org...\n> > > >\n> > > > The official vote was 19 to 19, plus one for perforce and one for \n> > > > svn. Matt has proposed a primary git repository and a mirror in \n> > > > hg, and that's being debated now.\n> >\n> > FWIW at the Google Summer of Code Mentor Summit this past weekend we \n> > had a \"Git vs. Hg\" talk with both Git and Hg represented by \n> > contributors to each project.\n> >\n> > Slides are online here:\n> >\n> > http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr\n> \n> But how do I save the presentation? I do not seem to be able to do it. \n> I would like to view it off-line.\n\nJust an idea: print to PDF? There is a link \"print slides\" on the lower \nright.\n\nCiao,\nDscho\n"},{"id":"94215","messageId":"alpine.LNX.2.00.0810291350440.7553@suse104.zenez.com","threadId":"16046","inReplyTo":"alpine.DEB.1.00.0810292047530.22125@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: [VOTE] git versus mercurial","fromName":"Boyd Lynn Gerber","fromEmail":"gerberb@zenez.com","sentAt":"2008-10-29T19:51:44Z","receivedAt":"2008-10-29T19:51:44Z","isPatch":false,"sender":{"key":"gerberb@zenez.com","avatar":null},"body":"On Wed, 29 Oct 2008, Johannes Schindelin wrote:\n> On Wed, 29 Oct 2008, Boyd Lynn Gerber wrote:\n>> On Wed, 29 Oct 2008, Shawn O. Pearce wrote:\n>>> Johannes Schindelin wrote:\n>>>> On Tue, 28 Oct 2008, walt wrote:\n>>>>> walt wrote:\n>>>>>> No, no, I'm not the one calling for a vote. You old-timers here\n>>>>>> will know the name Matt Dillon, who is leading the dragonflybsd\n>>>>>> project (www.dragonflybsd.org).\n>>>>>>\n>>>>>> Matt is the one who is calling for the vote in his thread \"Vote\n>>>>>> for your source control system\" in the dragonfly.kernel group,\n>>>>>> accessible via nntp://nntp.dragonflybsd.org...\n>>>>>\n>>>>> The official vote was 19 to 19, plus one for perforce and one for\n>>>>> svn. Matt has proposed a primary git repository and a mirror in\n>>>>> hg, and that's being debated now.\n>>>\n>>> FWIW at the Google Summer of Code Mentor Summit this past weekend we\n>>> had a \"Git vs. Hg\" talk with both Git and Hg represented by\n>>> contributors to each project.\n>>>\n>>> Slides are online here:\n>>>\n>>> http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr\n>>\n>> But how do I save the presentation? I do not seem to be able to do it.\n>> I would like to view it off-line.\n>\n> Just an idea: print to PDF? There is a link \"print slides\" on the lower\n> right.\n\nThat worked. I had to make my window full screen to see the option. It \ndid not show-up in my normal window.\n\n\nThanks,\n\n--\nBoyd Gerber \nZENEZ\t1042 East Fort Union #135, Midvale Utah 84047\n"},{"id":"94538","messageId":"87ljw3zx8i.fsf@mid.deneb.enyo.de","threadId":"16046","inReplyTo":"20081028213144.GC10862@mit.edu","subject":"Re: Git/Mercurial interoperability (and what about bzr?)","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2008-11-01T08:06:21Z","receivedAt":"2008-11-01T08:06:21Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Theodore Tso:\n\n> In the past I've looked at the possibility of creating a\n> bi-directional, incremental gateway between hg and git repositories.\n> The main thing which makes this difficult is that hg stores tags\n> in-band inside the change-controlled .hgtags file. This means that if\n> you cut a release, tag it, and then create a commit to further modify\n> the repository, the new commit is descended from the tag commit,\n> whereas in git, the tag is a \"bookmark\" --- perhaps signed via GPG,\n> but not part of the revision history.\n\nCouldn't you just keep the .hgtags file and have everyone interested\nin the tags use special scripts?\n\n(Admittedly, I'm horribly totally by Git's behavior in this area. I\nhaven't figured out yet under what circumstances tags are pushed and\npulled, so I'm not totally opposed to the Mercurial model. 8-/)\n"},{"id":"94540","messageId":"adf1fd3d0811010303g18b8077bvb80dc6475a9ada00@mail.gmail.com","threadId":"16046","inReplyTo":"87ljw3zx8i.fsf@mid.deneb.enyo.de","subject":"Re: Git/Mercurial interoperability (and what about bzr?)","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2008-11-01T10:03:56Z","receivedAt":"2008-11-01T10:03:56Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Sat, Nov 1, 2008 at 9:06 AM, Florian Weimer wrote:\n>\n> (Admittedly, I'm horribly totally by Git's behavior in this area. I\n> haven't figured out yet under what circumstances tags are pushed and\n> pulled, so I'm not totally opposed to the Mercurial model. 8-/)\n\nTag are pushed when you tell it so, and pulled if they are pointing to\nthe history you have, or you can ask to fetch them explicitly.\n\nHTH,\nSanti\n"},{"id":"94541","messageId":"Pine.LNX.4.64.0811011114170.29441@ds9.cixit.se","threadId":"16046","inReplyTo":"E026EBDF-F402-49AB-A7A8-0A0EFB513907@ai.rug.nl","subject":"Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2008-11-01T10:16:58Z","receivedAt":"2008-11-01T10:16:58Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Hi!\n\nPieter de Bie:\n\n> What would you want that the fast-export/imports are lacking? I think\n> they are excellent tools to build some integration on.\n\nSpeed. I am cloning from a rather overloaded server on the other side\nof the globe (the US). If I were to go the fast-export/import route, I\nfear it would take even longer.\n\n> You might want to look at my git-bzr script\n\nLooks very interesting. *adding to my things-to-examine list*\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"94542","messageId":"m3prlffzk2.fsf@localhost.localdomain","threadId":"16046","inReplyTo":"87ljw3zx8i.fsf@mid.deneb.enyo.de","subject":"Re: Git/Mercurial interoperability (and what about bzr?)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-11-01T10:33:43Z","receivedAt":"2008-11-01T10:33:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Florian Weimer writes:\n> * Theodore Tso:\n> \n> > In the past I've looked at the possibility of creating a\n> > bi-directional, incremental gateway between hg and git repositories.\n> > The main thing which makes this difficult is that hg stores tags\n> > in-band inside the change-controlled .hgtags file. This means that if\n> > you cut a release, tag it, and then create a commit to further modify\n> > the repository, the new commit is descended from the tag commit,\n> > whereas in git, the tag is a \"bookmark\" --- perhaps signed via GPG,\n> > but not part of the revision history.\n> \n> Couldn't you just keep the .hgtags file and have everyone interested\n> in the tags use special scripts?\n> \n> (Admittedly, I'm horribly totally by Git's behavior in this area. I\n> haven't figured out yet under what circumstances tags are pushed and\n> pulled, so I'm not totally opposed to the Mercurial model. 8-/)\n\nI think you don't understand the issue here.\n\nFirst, I think that we all agree here that by definition tags should\nnamed reference (for example 'v1.0' or '1.0') to some immutable\nsnapshot of a state of repository, so for example when somebody says\n'v1.0' everybody knows what it is. In Git tags are immutable (you\ncan't checkout a tag, you can only checkout state pointed by tag)\nexternal pointers to commits in the DAG (graph) of revisions.\n\nGlobal tags (tags used to mark releases like 'v1.0') have to _not\nversioned_ and _transferable_. Transferable (global) because we want\nto know for example what 'v1.0' version was in each clone / each\nrepository. Non-versioned because we want to have the same set of\ntags independent on what branch we are (when we are on 'master', we\nwant to be able to know about 'v1.0.1' which is on 'maint'), and what\nrevision we have checked out (for example during bisection, we want to\nbe able to compare to 'v1.0' even if we have checked out revision\nwhich is earlier than 'v1.0').\n\nDo you agree that global tags should be both non-versioned and\ntrasferable?\n\nNow Mercurial has chosen to use in-tree '.hgtags' file to have global\ntags transferable. Never mind the fact that it had to treat this file\nin special way to have it non-versioned (as opposed to for example\n.*ignore file, which should be both transferable and versioned); the\nfact that in-tree file is used means that tag is visible to outside\n(transferable) only after you commit changes in .hgtags file.\n\nIn Git tags are external to object database; they reside in\nrefs/tags/* namespace. They are of course non-versioned, as not being\nin-tree. In default configuration however (from what I understand) if\nyou transfer (get) some tagged commit, you also get a tag that points\nto transferred commit. You don't need to create \"PROJECT 1.0\" (or\n\"Tagged v1.0\") commit to make tag visible to outside.\n\n\nIn short, if you want to have bi-directional gateway between Mercurial\nand Git, Git has to be limited:\n * no octopus merges (with more than two parents)\n * always create 'tagging commits' (bump version number for example)\n for tagging purposes on Mercurial side.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"94543","messageId":"87abcjpvy2.fsf@mid.deneb.enyo.de","threadId":"16046","inReplyTo":"m3prlffzk2.fsf@localhost.localdomain","subject":"Re: Git/Mercurial interoperability (and what about bzr?)","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2008-11-01T10:44:21Z","receivedAt":"2008-11-01T10:44:21Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Jakub Narebski:\n\n> Florian Weimer writes:\n>> * Theodore Tso:\n>> \n>> > In the past I've looked at the possibility of creating a\n>> > bi-directional, incremental gateway between hg and git repositories.\n>> > The main thing which makes this difficult is that hg stores tags\n>> > in-band inside the change-controlled .hgtags file. This means that if\n>> > you cut a release, tag it, and then create a commit to further modify\n>> > the repository, the new commit is descended from the tag commit,\n>> > whereas in git, the tag is a \"bookmark\" --- perhaps signed via GPG,\n>> > but not part of the revision history.\n>> \n>> Couldn't you just keep the .hgtags file and have everyone interested\n>> in the tags use special scripts?\n>> \n>> (Admittedly, I'm horribly totally by Git's behavior in this area. I\n>> haven't figured out yet under what circumstances tags are pushed and\n>> pulled, so I'm not totally opposed to the Mercurial model. 8-/)\n>\n> I think you don't understand the issue here.\n\nProbably yes.\n\n> Do you agree that global tags should be both non-versioned and\n> trasferable?\n\nYes, I do. In case of Git, I've got trouble with understanding how to\nactually implement the \"transferable\" part with Git. The Mercurial\nway is easier to understand, but it means that tags may need some sort\nof \"tag at this revision\" qualifier to disambiguate, which is rather\nproblematic.\n\n> Now Mercurial has chosen to use in-tree '.hgtags' file to have global\n> tags transferable. Never mind the fact that it had to treat this file\n> in special way to have it non-versioned\n\nOops, thought this file was versioned. Things like\n\n \n\nsuggest it was at some point.\n"},{"id":"94548","messageId":"87hc6rog5c.fsf@mid.deneb.enyo.de","threadId":"16046","inReplyTo":"87abcjpvy2.fsf@mid.deneb.enyo.de","subject":"Re: Git/Mercurial interoperability (and what about bzr?)","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2008-11-01T11:10:55Z","receivedAt":"2008-11-01T11:10:55Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Florian Weimer:\n\n>> Now Mercurial has chosen to use in-tree '.hgtags' file to have global\n>> tags transferable. Never mind the fact that it had to treat this file\n>> in special way to have it non-versioned\n>\n> Oops, thought this file was versioned. Things like\n>\n> \n>\n> suggest it was at some point.\n\nOkay, checked it--.hgtags files are in fact versioned. So my\nsuggestion to preserve the .hgtags file on the Git side remains.\n"},{"id":"94550","messageId":"200811011326.25224.jnareb@gmail.com","threadId":"16046","inReplyTo":"87abcjpvy2.fsf@mid.deneb.enyo.de","subject":"Re: Git/Mercurial interoperability (and what about bzr?)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-11-01T12:26:24Z","receivedAt":"2008-11-01T12:26:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 1 Nov 2008, Florian Weimer wrote:\n> * Jakub Narebski:\n>> Florian Weimer writes:\n>>> * Theodore Tso:\n>>> \n>>>> In the past I've looked at the possibility of creating a\n>>>> bi-directional, incremental gateway between hg and git repositories.\n>>>> The main thing which makes this difficult is that hg stores tags\n>>>> in-band inside the change-controlled .hgtags file. This means that if\n>>>> you cut a release, tag it, and then create a commit to further modify\n>>>> the repository, the new commit is descended from the tag commit,\n>>>> whereas in git, the tag is a \"bookmark\" --- perhaps signed via GPG,\n>>>> but not part of the revision history.\n>>> \n>>> Couldn't you just keep the .hgtags file and have everyone interested\n>>> in the tags use special scripts?\n>>> \n>>> (Admittedly, I'm horribly totally by Git's behavior in this area. I\n>>> haven't figured out yet under what circumstances tags are pushed and\n>>> pulled, so I'm not totally opposed to the Mercurial model. 8-/)\n\n>> Do you agree that global tags should be both non-versioned and\n>> trasferable?\n> \n> Yes, I do. In case of Git, I've got trouble with understanding how to\n> actually implement the \"transferable\" part with Git. The Mercurial\n> way is easier to understand, but it means that tags may need some sort\n> of \"tag at this revision\" qualifier to disambiguate, which is rather\n> problematic.\n\nIn first page of git-fetch(1):\n\n When stores the fetched result in tracking branches, the tags\n that point at these branches are automatically followed. This is done by\n first fetching from the remote using the given s, and if the\n repository has objects that are pointed by remote tags that it does not yet\n have, then fetch those missing tags. If the other end has tags that point\n at branches you are not interested in, you will not get them.\n\nYou push tags explicitly (using \"tag \" refspec, or specifying\n--tags, --all or --mirror, or setting it up in a config) in git.\n \n>> Now Mercurial has chosen to use in-tree '.hgtags' file to have global\n>> tags transferable. Never mind the fact that it had to treat this file\n>> in special way to have it non-versioned\n> \n> Oops, thought this file was versioned. Things like\n> \n> \n> \n> suggest it was at some point.\n\nIt is half-versioned... :-X From what I remember of discussion on\n#revctrl and reading hgbok it is treated in special way: if you\nswitch branches or rewind to some older version, .hgtags is always\nchecked out the most recent version.\n\nI don't know how Mercurial deals with situation where one reposityr\nadded one tag, and other repository add other...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"94558","messageId":"20081101133931.GC8134@mit.edu","threadId":"16046","inReplyTo":"87abcjpvy2.fsf@mid.deneb.enyo.de","subject":"Re: Git/Mercurial interoperability (and what about bzr?)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-11-01T13:39:31Z","receivedAt":"2008-11-01T13:39:31Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Nov 01, 2008 at 11:44:21AM +0100, Florian Weimer wrote:\n> > Now Mercurial has chosen to use in-tree '.hgtags' file to have global\n> > tags transferable. Never mind the fact that it had to treat this file\n> > in special way to have it non-versioned\n> \n> Oops, thought this file was versioned. Things like\n> \n> \n\n.hgtags is stored as a versioned file in Mercurial. That's one of the\nproblems, and it leads to no shortage of headaches.\n\nSome of the problems are discussed here:\n\n http://www.selenic.com/mercurial/wiki/index.cgi/Tag\n\nSpecifically, to quote the Mercurial Wiki:\n\n The fact that tags identify changesets and are also parts of\n changesets has some potentially confusing implications:\n\n * The changeset that a tag refers to is always older than the\n changeset that commits the tag itself.\n\n * Updating a working dir to a particular tag will take that\n directory back to a point before the tag itself existed.\n\n * Cloning a repo to a particular tag will give you a new repo that\n does not have that tag.\n\nIn addition, Mercurial has to play interesting special case games in a\nrepository which has multiple heads (in git terms, \"branches\"). When\nlooking up a tag, it has to take the union of all of the .hgtags files\nat the tips of each of the branches. So if you have a large number of\nheads in your Mercurial repository, tags access doesn't scale well at\nall. Mercurial is very much optimized for having a single or at best\na few heads/branches in a repository.\n\nAs I mentioned earlier this makes it much more difficult to do a\nbidrectional hg/git gateway, since the two DAG's are not toplogically\nequivalent, and in fact, *when* you add a tag to a particular\ncommit/revision can make a distinct difference to the shape of the\nDAG. If you tag right after creating the revision in question, then\nthere is a tag commit right after the revision. If you commit a few\ndozen changes into the repository, and *then* tag a point many commits\nearlier, then the tag commit will be tacked onto the head of whatever\nbranch you happened to be on.\n\nIn fact, in the worst case, if you accidentally tag a revision on the\n\"maint\" branch while you happened to be on the \"devel\" branch, the tag\nfor the commit in the \"maint\" branch will be attached to the \"devel\"\nbranch, and while it will work just fine for *you*, someone who only\nfetches the \"maint\" branch might never see the tag that you placed on\nthe maint branch --- unless they happen to also pull the devel branch.\n\nWhat fun, eh?\n\n\t\t\t\t\t- Ted\n"},{"id":"94569","messageId":"alpine.LFD.2.00.0811011047050.3483@nehalem.linux-foundation.org","threadId":"16046","inReplyTo":"20081101133931.GC8134@mit.edu","subject":"Re: Git/Mercurial interoperability (and what about bzr?)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-01T17:51:51Z","receivedAt":"2008-11-01T17:51:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 1 Nov 2008, Theodore Tso wrote:\n> \n> .hgtags is stored as a versioned file in Mercurial. That's one of the\n> problems, and it leads to no shortage of headaches.\n\nI told people this was insane long long ago, and I thought the hg people \nhad learnt to use local tags. They act sanely, as far as I know (ie they \nact the same way git tags do).\n\nOf course, the problem with hg local tags is that hg apparently has no \nsane way to _propagate_ such local tag-space information from one \nrepository to another. But that's purely a problem with hg itself. I don't \nknow why that hasn't gotten fixed.\n\n\t\t\tLinus\n"},{"id":"94610","messageId":"20081102011328.GG8134@mit.edu","threadId":"16046","inReplyTo":"alpine.LFD.2.00.0811011047050.3483@nehalem.linux-foundation.org","subject":"Re: Git/Mercurial interoperability (and what about bzr?)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-11-02T01:13:28Z","receivedAt":"2008-11-02T01:13:28Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Nov 01, 2008 at 10:51:51AM -0700, Linus Torvalds wrote:\n> \n> \n> On Sat, 1 Nov 2008, Theodore Tso wrote:\n> > \n> > .hgtags is stored as a versioned file in Mercurial. That's one of the\n> > problems, and it leads to no shortage of headaches.\n> \n> I told people this was insane long long ago, and I thought the hg people \n> had learnt to use local tags. They act sanely, as far as I know (ie they \n> act the same way git tags do).\n> \n> Of course, the problem with hg local tags is that hg apparently has no \n> sane way to _propagate_ such local tag-space information from one \n> repository to another. But that's purely a problem with hg itself. I don't \n> know why that hasn't gotten fixed.\n\nYeah, well, hg calls them _local_ tags, and so people consider that by\ndesign, they aren't supposed to be propagated outside of the local\nrepository. As I recall, hg doesn't support GPG signing local tags,\nfor the same reason.\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"95058","messageId":"878wrwom88.fsf@softax.com.pl","threadId":"16046","inReplyTo":"20081028193841.GA23637@neumann","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Marcin Kasperski","fromEmail":"marcin.kasperski@softax.com.pl","sentAt":"2008-11-06T16:25:27Z","receivedAt":"2008-11-06T16:25:27Z","isPatch":false,"sender":{"key":"marcin.kasperski@softax.com.pl","avatar":"https://gravatar.com/avatar/876c331bb177f09eaebc1447c2c890dc36d7c46b3ac09754003b8da1633eb20b?d=mp&s=160"},"body":">> > How many perl gurus have skipped writing\n>> > stuff for hg because it's a \"python-or-bust\" thing?\n>> \n>> How many Python people decided to write an extension for hg, because it can \n>> very nicely be accessed via Python? \n>\n> And wouldn't they contribute at all, if there would be hg bindings for\n> other programming languages, would they?\n\nAre really programming languages that important? If I find a tool\nwhich is useful and has features I need, and while using it I find\nsome drawback, and I am able to find how could I work on it, I can\npick up enough of the language it is written in. I am not a \"guru\"\nif I can't. \n\nMain showstoppers in this area are not the programming languages, but\nlack of documentation, miserable APIs, or lack of process. Or ... the\nfact that the tool is so good that it does not really need extensions.\n\n\n\n-- \n----------------------------------------------------------------------\n| Marcin Kasperski | If we are to be successful, we must still have\n| http://mekk.waw.pl | the courage to put our faith in people as\n| | opposed to a process. (Booch,Martin,Newkirk)\n----------------------------------------------------------------------\n"},{"id":"95066","messageId":"123689c10811060941j4a7ffbe7s3cb0bb8c84777800@mail.gmail.com","threadId":"16046","inReplyTo":"878wrwom88.fsf@softax.com.pl","subject":"Re: [VOTE] git versus mercurial (for DragonflyBSD)","fromName":"Isaac Jurado","fromEmail":"diptongo@gmail.com","sentAt":"2008-11-06T17:41:50Z","receivedAt":"2008-11-06T17:41:50Z","isPatch":false,"sender":{"key":"diptongo@gmail.com","avatar":null},"body":"On Thu, Nov 6, 2008 at 5:25 PM, Marcin Kasperski\n wrote:\n>\n> Are really programming languages that important?\n\nConsidering the success of some of them, having the worst possible\nsyntax and semantics, I believe it does not matter much.\n\n> Main showstoppers in this area are not the programming languages, but\n> lack of documentation, miserable APIs, or lack of process. Or ... the\n> fact that the tool is so good that it does not really need extensions.\n\nI couldn't agree more. Sorry for such a useless reply, but I felt some\nemotion reading \"common sense\".\n\nCheers.\n\n-- \nIsaac Jurado Peinado\nhttp://www.krenel.net\n\n\"The noblest pleasure is the joy of understanding\"\nLeonardo da Vinci\n"}]}