{"thread":{"id":"5925","subject":"VCS comparison table","startedAt":"2006-10-14T15:07:18Z","lastAt":"2006-12-02T08:57:22Z","messageCount":777,"participants":["Jon Smirl","Jakub Narebski","Sean","Petr Baudis","Martin Pool","Aaron Bentley","Andy Whitcroft","Linus Torvalds","Nguyen Thai Ngoc Duy","Johannes Schindelin","Luben Tuikov","Sam Vilain","Shawn Pearce","Carl Worth","Junio C Hamano","Christian MICHON","Andreas Ericsson","Robert Collins","Matthias Kestenholz","Matthieu Moy","Olivier Galibert","J. Bruce Fields","Ryan Anderson","Jeff King","Peter Baumann","Erik Bågfors","Matthew D. Fuller","Jeff Licquia","Nicolas Pitre","Charles Duffy","Jan Hudec","Alexander Belchenko","Karl Hasselström","Tim Webster","Ramon Diaz-Uriarte","Jan Harkes","Nathaniel Smith","James Henstridge","Lachlan Patrick","David Lang"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"28765","messageId":"9e4733910610140807p633f5660q49dd2d2111c9f5fe@mail.gmail.com","threadId":"5925","inReplyTo":null,"subject":"VCS comparison table","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-10-14T15:07:18Z","receivedAt":"2006-10-14T15:07:18Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"I was reading Brendan's blog post about Mozilla 2\nhttp://weblogs.mozillazine.org/roadmap/archives/2006/10/mozilla_2.html\n\nIt refers to this comparison chart between source control systems.\nhttp://bazaar-vcs.org/RcsComparisons\n\nDoes it accurately reflect the current status of git? Is their\nassessment of git's rename capability correct?\n\nThey want changes via IRC. \"Please discuss changes to this table on\nthe freenode IRC network channel #bzr, or on the mailing list. The\nterms used in the table have precise meanings, and not all VCS's use\nthe same term in the same way - which means that some translation is\nneeded to fill it in properly.\"\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"28766","messageId":"egr3ud$nqm$1@sea.gmane.org","threadId":"5925","inReplyTo":"9e4733910610140807p633f5660q49dd2d2111c9f5fe@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-14T16:40:55Z","receivedAt":"2006-10-14T16:40:55Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jon Smirl wrote:\n\n> It refers to this comparison chart between source control systems.\n> http://bazaar-vcs.org/RcsComparisons\n\nIt is quite obvious that comparison of programs of given type (SMC)\non some program site (Bazaar-NG) is usually biased towards said program,\nperhaps unconsciously: by emphasizing the features which were important\nfor developers of said program.\n \n> Does it accurately reflect the current status of git? Is their\n> assessment of git's rename capability correct?\n\nFor example simple namespace for git: you can use shortened sha1\n(even to only 6 characters, although usually 8 are used), you can\nuse tags, you can use ref^m~n syntax.\n\nI'm not sure about \"No\" in \"Supports Repository\". Git supports multiple\nbranches in one repository, and what's better supports development using\nmultiple branches, but cannot for example do a diff or a cherry-pick\nbetween repositories (well, you can use git-format-patch/git-am to\ncherry-pick changes between repositories...).\n\nAbout \"checkouts\", i.e. working directories with repository elsewhere:\nyou can use GIT_DIR environmental variable or \"git --git-dir\" option,\nor symlinks, and if Nguyen Thai Ngoc D proposal to have .gitdir/.git\n\"symref\"-like file to point to repository passes, we can use that.\n\nPartial checkouts are only partially supported as of now; it means\nyou have to do some lowe level stuff to do partial checkout, and be\ncarefull when comitting. BTW it depends what you mean by partial\ncheckout, but they are somewhat incompatibile with atomic commits\nto snapshot based repository.\n\nGit supports renames in its own way; it doesn't use file ids, nor\nremember renames (the new \"note\" header for use e.g. by porcelains \ndidn't pass if I remember correctly). But it does *detect* moving\n_contents_, and even *copying* _contents_ when requested. And of\ncourse it detect renames in merges.\n\nGit doesn't have some \"plugin framework\", but because it has many\n\"plumbing\" commands, it is easy to add new commands, and also new\nmerge strategies, using shell scripts, Perl, Python and of course C.\nSo the answer would be \"Somewhat\", as git has plugable merge strategies,\nor even \"Yes\" at it is easy to add new git command.\n\n> They want changes via IRC. \"Please discuss changes to this table on\n> the freenode IRC network channel #bzr, or on the mailing list.\"\n\nGaah, subscribe-to-post mailing list!\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28767","messageId":"9e4733910610141018gdfa62a7o9a2bb2819d5c2ecc@mail.gmail.com","threadId":"5925","inReplyTo":"egr3ud$nqm$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-10-14T17:18:05Z","receivedAt":"2006-10-14T17:18:05Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 10/14/06, Jakub Narebski wrote:\n> Jon Smirl wrote:\n>\n> > It refers to this comparison chart between source control systems.\n> > http://bazaar-vcs.org/RcsComparisons\n>\n> It is quite obvious that comparison of programs of given type (SMC)\n> on some program site (Bazaar-NG) is usually biased towards said program,\n> perhaps unconsciously: by emphasizing the features which were important\n> for developers of said program.\n>\n> > Does it accurately reflect the current status of git? Is their\n> > assessment of git's rename capability correct?\n>\n> For example simple namespace for git: you can use shortened sha1\n> (even to only 6 characters, although usually 8 are used), you can\n> use tags, you can use ref^m~n syntax.\n>\n> I'm not sure about \"No\" in \"Supports Repository\". Git supports multiple\n> branches in one repository, and what's better supports development using\n> multiple branches, but cannot for example do a diff or a cherry-pick\n> between repositories (well, you can use git-format-patch/git-am to\n> cherry-pick changes between repositories...).\n>\n> About \"checkouts\", i.e. working directories with repository elsewhere:\n> you can use GIT_DIR environmental variable or \"git --git-dir\" option,\n> or symlinks, and if Nguyen Thai Ngoc D proposal to have .gitdir/.git\n> \"symref\"-like file to point to repository passes, we can use that.\n\nI believe they mean checking out only the latest few revisions instead\nof copying the whole repo. This issue is a problem for Mozilla. If you\nwant to change a line in the git version you have to download the\nentire 500MB tree with full history.\n\n>\n> Partial checkouts are only partially supported as of now; it means\n> you have to do some lowe level stuff to do partial checkout, and be\n> carefull when comitting. BTW it depends what you mean by partial\n> checkout, but they are somewhat incompatibile with atomic commits\n> to snapshot based repository.\n\nI believe partial checkout means being able to check one directory\ntree out of the repo and work on it while ignoring what is happening\nin the rest of the repo. This is another issue for Mozilla which has\nmultiple dependent projects checked into a single repo.\n\n>\n> Git supports renames in its own way; it doesn't use file ids, nor\n> remember renames (the new \"note\" header for use e.g. by porcelains\n> didn't pass if I remember correctly). But it does *detect* moving\n> _contents_, and even *copying* _contents_ when requested. And of\n> course it detect renames in merges.\n>\n> Git doesn't have some \"plugin framework\", but because it has many\n> \"plumbing\" commands, it is easy to add new commands, and also new\n> merge strategies, using shell scripts, Perl, Python and of course C.\n> So the answer would be \"Somewhat\", as git has plugable merge strategies,\n> or even \"Yes\" at it is easy to add new git command.\n>\n> > They want changes via IRC. \"Please discuss changes to this table on\n> > the freenode IRC network channel #bzr, or on the mailing list.\"\n>\n> Gaah, subscribe-to-post mailing list!\n\nIt is annoying, but subscribe with the no delivery option.\n\n> --\n> Jakub Narebski\n> Warsaw, Poland\n> ShadeHawk on #git\n>\n>\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"28768","messageId":"200610141942.32196.jnareb@gmail.com","threadId":"5925","inReplyTo":"9e4733910610141018gdfa62a7o9a2bb2819d5c2ecc@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-14T17:42:31Z","receivedAt":"2006-10-14T17:42:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jon Smirl wrote:\n>> About \"checkouts\", i.e. working directories with repository\n>> elsewhere: you can use GIT_DIR environmental variable or \"git\n>> --git-dir\" option, or symlinks, and if Nguyen Thai Ngoc D proposal\n>> to have .gitdir/.git \"symref\"-like file to point to repository\n>> passes, we can use that.\n>\n> I believe they mean checking out only the latest few revisions\n> instead of copying the whole repo. This issue is a problem for\n> Mozilla. If you want to change a line in the git version you have to\n> download the entire 500MB tree with full history.\n\n>From http://bazaar-vcs.org/RcsComparisons\n A \"Checkout\" is a working tree that points elsewhere for its RCS data.\n\nYou can always do like Linux kernel did, splitting repository into \ncurrent and historical part (which would contain also dead branches), \nand creating and publishing current-historical graft file, to join \nhistory if needed.\n\n>> Partial checkouts are only partially supported as of now; it means\n>> you have to do some lowe level stuff to do partial checkout, and be\n>> carefull when comitting. BTW it depends what you mean by partial\n>> checkout, but they are somewhat incompatibile with atomic commits\n>> to snapshot based repository.\n> \n> I believe partial checkout means being able to check one directory\n> tree out of the repo and work on it while ignoring what is happening\n> in the rest of the repo. This is another issue for Mozilla which has\n> multiple dependent projects checked into a single repo.\n\nSo split different projects into different repositories. There was some \nhelper program (git-splitrepo or something like that) for that posted \non git mailing list. And use \"superrepository\" to gather all projects \ntogether (see last discussion about subprojects on git mailing list).\n-- \nJakub Narebski\nPoland\n"},{"id":"28773","messageId":"egrgqe$1i9$1@sea.gmane.org","threadId":"5925","inReplyTo":"9e4733910610140807p633f5660q49dd2d2111c9f5fe@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-14T20:20:38Z","receivedAt":"2006-10-14T20:20:38Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jon Smirl wrote:\n\n> I was reading Brendan's blog post about Mozilla 2\n> http://weblogs.mozillazine.org/roadmap/archives/2006/10/mozilla_2.html\n\nYou mean:\n \"Oh, and isn't it time that we get off of CVS? The best way to do that\n without throwing 1.9 into an uproar is to develop Mozilla 2 using a new\n Version Control System (VCS) that can merge with CVS (since we will want\n to track changes to files not being revamped at first, or at all; and\n we'll probably find bugs whose fixes should flow back into 1.9). The\n problem with VCSes is that there are too many to choose from now.\n Nevertheless, looking for mostly green columns in that chart should help\n us make a quick decision. We don't need \"the best\" or the \"newest\", but we\n do need better merging, branching, and renaming support.\"\n\nThere is work by Jon Smirl and Shawn Pearce on CVS to Git importer which can\nmanage large and complicated (read: f*cked-up) Mozilla CVS repository.\n http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#cvs2git\n\nBy the way, I'd rather use SCM comparison table on neutral site, not on SCM\nsite.\n\n\nI think that Mozilla project should come with it's own set of requirements\nand weights for best SCM _for Mozilla project_.\n\n1. Converting existing CVS repository. This should be without data loss...\nwell, beside data loss that stems from using CVS in first place. \"Best\" SCM\nwould have:\n * Tool to convert CVS repository, which can then incrementally import\n changes.\n * It would be nice to have tool to exchange commits between SCM and CVS,\n be it like Tailor/git-svn, or via incremental import and exporting\n commits to CVS like git-cvsexportcommit. This would ease changing SCM,\n as both new SCM and CVS could be deployed in parallel, for a short time\n of course.\n * It would be nice to have CVS emulation like git-cvsserver, so users\n accustomed to CVS could still use it.\n\n2. Good support for system which most important developers use, and good\nsupport for system which most contributors use. If MS Windows is included\nin those, then Git perhaps wouldn't be the best choice.\n\n3. Good support for the workflow used in the project. Is it exchanging\npatches via email (hello, Git!), having ssh access to some central\nrepository with central repository to push changes to or net/mesh of\nrepositories exchanging information, posting patches on some bug tracking\nsoftware integrated with SCM. Is it using many branches (topic branches),\nor is it using few branches and merging.\n\nBut it is equally important to realize what would be the best workflow to\nuse, not constraining itself to the workflow imposed by limitations of CVS.\n\n4. Good support for _large_ project, with large history. Namely, that\ndeveloper wouldn't need to download many megabytes and/or wouldn't need\nmegabytes of working area. How that is solved, be it partial checkouts,\nlazy/shallow/sparse clone, subprojects, splitting into\nprojects/repositories and having some superproject or build-time\nsuperproject, splitting repository into current and historical... that of\ncourse depends on SCM.\n\n5. ....\n\nand probably few more\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28777","messageId":"9e4733910610141606g749d268eudd85791620e1363a@mail.gmail.com","threadId":"5925","inReplyTo":"egrgqe$1i9$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-10-14T23:06:10Z","receivedAt":"2006-10-14T23:06:10Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 10/14/06, Jakub Narebski wrote:\n> Jon Smirl wrote:\n>\n> > I was reading Brendan's blog post about Mozilla 2\n> > http://weblogs.mozillazine.org/roadmap/archives/2006/10/mozilla_2.html\n>\n> You mean:\n> \"Oh, and isn't it time that we get off of CVS? The best way to do that\n> without throwing 1.9 into an uproar is to develop Mozilla 2 using a new\n> Version Control System (VCS) that can merge with CVS (since we will want\n> to track changes to files not being revamped at first, or at all; and\n> we'll probably find bugs whose fixes should flow back into 1.9). The\n> problem with VCSes is that there are too many to choose from now.\n> Nevertheless, looking for mostly green columns in that chart should help\n> us make a quick decision. We don't need \"the best\" or the \"newest\", but we\n> do need better merging, branching, and renaming support.\"\n>\n> There is work by Jon Smirl and Shawn Pearce on CVS to Git importer which can\n> manage large and complicated (read: f*cked-up) Mozilla CVS repository.\n> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#cvs2git\n\nI am still working with the developers of the cvs2svn import tool to\nfix things so that Mozilla CVS can be correctly imported. There are\nstill outstanding bugs in cvs2svn preventing a correct import. MozCVS\ncan be imported, but the resulting repository is not entirely correct.\n\nOnce they get the base cvs2svn fixed I'll port my patches to turn it\ninto cvs2git again.\n\nThere is no existing CVS importer that will correctly import the\nMozilla CVS. I have tried them all.\n\n> By the way, I'd rather use SCM comparison table on neutral site, not on SCM\n> site.\n>\n>\n> I think that Mozilla project should come with it's own set of requirements\n> and weights for best SCM _for Mozilla project_.\n>\n> 1. Converting existing CVS repository. This should be without data loss...\n> well, beside data loss that stems from using CVS in first place. \"Best\" SCM\n> would have:\n> * Tool to convert CVS repository, which can then incrementally import\n> changes.\n> * It would be nice to have tool to exchange commits between SCM and CVS,\n> be it like Tailor/git-svn, or via incremental import and exporting\n> commits to CVS like git-cvsexportcommit. This would ease changing SCM,\n> as both new SCM and CVS could be deployed in parallel, for a short time\n> of course.\n\n>From what Brendan wrote they are looking to continue 1.9 in CVS and\nstart 2.0 in a new SCM. This pretty much mandates tracking CVS into\nthe new SCM for a long period of time. Possibly as much as two years.\nThere does not appear to be a need to push 2.0 back into CVS.\n\n\n> * It would be nice to have CVS emulation like git-cvsserver, so users\n> accustomed to CVS could still use it.\n\nThis can also solve some of the problems with Windows support.\n\n>\n> 2. Good support for system which most important developers use, and good\n> support for system which most contributors use. If MS Windows is included\n> in those, then Git perhaps wouldn't be the best choice.\n\nBetter Windows support is needed to make git the first choice among\nthe various SCMs.\n\n>\n> 3. Good support for the workflow used in the project. Is it exchanging\n> patches via email (hello, Git!), having ssh access to some central\n> repository with central repository to push changes to or net/mesh of\n> repositories exchanging information, posting patches on some bug tracking\n> software integrated with SCM. Is it using many branches (topic branches),\n> or is it using few branches and merging.\n>\n> But it is equally important to realize what would be the best workflow to\n> use, not constraining itself to the workflow imposed by limitations of CVS.\n\nA big problem for Mozilla is outside companies doing major work in a\nlocal CVS. Since CVS is not decentralized these local repos drift away\nfrom the main one over time making things hard to merge. Any new SCM\nwill have to be distributed.\n\n> 4. Good support for _large_ project, with large history. Namely, that\n> developer wouldn't need to download many megabytes and/or wouldn't need\n> megabytes of working area. How that is solved, be it partial checkouts,\n> lazy/shallow/sparse clone, subprojects, splitting into\n> projects/repositories and having some superproject or build-time\n> superproject, splitting repository into current and historical... that of\n> course depends on SCM.\n\ngit has issues here. The smallest Mozilla download we have built so\nfar is 450MB for the initial checkout.\n\n>\n> 5. ....\n>\n> and probably few more\n\n\nThe three most complex repositories are the kernel, gcc and Mozilla.\nGcc is in SVN now. Mozilla CVS and the kernel git.\n\nThere are much larger repositories around for some of the distros, but\nthey are doing things like checking ISO images in to the repo which\njust makes it big,, not complex.\n\nTop two git issues effecting Mozilla choosing it\n1) some way to avoid the initial 450MB download\n2) better windows support\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"28778","messageId":"egrs5i$ss$1@sea.gmane.org","threadId":"5925","inReplyTo":"9e4733910610141606g749d268eudd85791620e1363a@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-14T23:34:27Z","receivedAt":"2006-10-14T23:34:27Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jon Smirl wrote:\n\n> Top two git issues effecting Mozilla choosing it\n> 1) some way to avoid the initial 450MB download\n\nGive out CDs with Mozilla's git repository (and use alternates) ;-)\nJust kidding...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28781","messageId":"BAYC1-PASMTP08F9B6EA71E7C83DD93E8DAE080@CEZ.ICE","threadId":"5925","inReplyTo":"9e4733910610141606g749d268eudd85791620e1363a@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-15T00:03:56Z","receivedAt":"2006-10-15T00:03:56Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 14 Oct 2006 19:06:10 -0400\n\"Jon Smirl\" wrote:\n\n> Top two git issues effecting Mozilla choosing it\n> 1) some way to avoid the initial 450MB download\n\nWhy not split the repository up after you import it? Break it into\ntwo repositories, last year or two, and then everything else.\n\n> 2) better windows support\n\nHard to imagine native windows support existing in time to be used by \nthe Mozilla folks, maybe in time for 3.0 :o)\n\nSean\n"},{"id":"28782","messageId":"9e4733910610141734h581afdc9r4d330d6a5a5bd1aa@mail.gmail.com","threadId":"5925","inReplyTo":"BAYC1-PASMTP08F9B6EA71E7C83DD93E8DAE080@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-10-15T00:34:22Z","receivedAt":"2006-10-15T00:34:22Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 10/14/06, Sean wrote:\n> On Sat, 14 Oct 2006 19:06:10 -0400\n> \"Jon Smirl\" wrote:\n>\n> > Top two git issues effecting Mozilla choosing it\n> > 1) some way to avoid the initial 450MB download\n>\n> Why not split the repository up after you import it? Break it into\n> two repositories, last year or two, and then everything else.\n\nThat is possible but I wish git had tools supporting this. What do you\ndo about core developers that want the full repo syncing to other\ndevelopers that only have a partial copy?\n\n>\n> > 2) better windows support\n>\n> Hard to imagine native windows support existing in time to be used by\n> the Mozilla folks, maybe in time for 3.0 :o)\n>\n> Sean\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"28784","messageId":"200610150253.20974.jnareb@gmail.com","threadId":"5925","inReplyTo":"9e4733910610141606g749d268eudd85791620e1363a@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-15T00:53:20Z","receivedAt":"2006-10-15T00:53:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jon Smirl wrote:\n> On 10/14/06, Jakub Narebski wrote:\n\n>> * It would be nice to have tool to exchange commits between SCM and CVS,\n>> be it like Tailor/git-svn, or via incremental import and exporting\n>> commits to CVS like git-cvsexportcommit. This would ease changing SCM,\n>> as both new SCM and CVS could be deployed in parallel, for a short time\n>> of course.\n> \n> From what Brendan wrote they are looking to continue 1.9 in CVS and\n> start 2.0 in a new SCM. This pretty much mandates tracking CVS into\n> the new SCM for a long period of time. Possibly as much as two years.\n> There does not appear to be a need to push 2.0 back into CVS.\n\nThat of course limits what we can do in 1.9 to what CVS supports.\n\n> > * It would be nice to have CVS emulation like git-cvsserver, so users\n> > accustomed to CVS could still use it.\n> \n> This can also solve some of the problems with Windows support.\n\nWell, git-cvsserver (perhaps with some improvements) could also serve as\nCVS server for 1.9.\n \n> > 4. Good support for _large_ project, with large history. Namely, that\n> > developer wouldn't need to download many megabytes and/or wouldn't need\n> > megabytes of working area. How that is solved, be it partial checkouts,\n> > lazy/shallow/sparse clone, subprojects, splitting into\n> > projects/repositories and having some superproject or build-time\n> > superproject, splitting repository into current and historical... that of\n> > course depends on SCM.\n> \n> git has issues here. The smallest Mozilla download we have built so\n> far is 450MB for the initial checkout.\n\nOne way to reduce repository size would be to split fairly independent\nsubprojects (inependent = independently testable) into separate repositories,\nand perhaps use some kind of \"super-repository\" (common repository) to join\nall the project in one single entity. The split can be done using\ngit-splitrepo (or something like that) which was posted on git mailing list\n(most probably by some member of X.Org), or just cg-admin-rewritehist.\nWhile at it we could split repository into current work and historical repo;\nand clean up current work repository from the cruft accumulated (e.g. dead\nbranches, broken tags etc.).\n\n\nAnother way is to use grafts.\n\nLinux kernel has it's current repository (starting somewhere 2.6.x),\nand it's historical repository. I don't remember how they arrived at it\n(and don't want to check KernelTrap articles), if the seed for current\nwork repository was simply project import at some state, or (very slow)\nimport of BitKeeper history. But if I remember correctly it was born split.\nYou can join both repositories into one (wrt. log and diff for example)\nusing grafts.\n\nI'm not sure what happens if you pull from repository which has graft\nfile \"cauterizing\" history; would you get graft file and history up to\ncutoff point? What would happen if your repository, repository you pull to\nhas cauterization graft file; would it get cut history? Of course\nthe problem (and the source of proposal and troubles with implementing\nof shallow/sparse/lazy clone) lies if someone branches (in public repo)\nfrom below cutoff point. But that is a matter of policy.\n\nBut it is true that the size of Mozilla repository is a challenge.\nBTW. do you perchance know how other SCM dels with the repository\nof that size?\n\n-- \nJakub Narebski\nShadeHawk on #git\nPoland\n"},{"id":"28786","messageId":"BAYC1-PASMTP01D7FF6651E6563344419BAE080@CEZ.ICE","threadId":"5925","inReplyTo":"9e4733910610141734h581afdc9r4d330d6a5a5bd1aa@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-15T01:44:52Z","receivedAt":"2006-10-15T01:44:52Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 14 Oct 2006 20:34:22 -0400\n\"Jon Smirl\" wrote:\n\n> That is possible but I wish git had tools supporting this. What do you\n> do about core developers that want the full repo syncing to other\n> developers that only have a partial copy?\n\nI don't think that will be an issue at all.\n\nAs an example, take the current Linux kernel repo maintained by Linus,\nand one of the repos containing old historic kernel data imported into\nGit. Graft in the old historic data into your clone of Linus' repo,\nand you're done. Anyone can pull from you even if they don't have the\nhistoric data themselves.\n\nWith a little work you could do the same thing with the Mozilla data.\nAfter you decide where to make the split, you'd have to rewrite the\ncommit history for the \"current\" repository, so that it terminates\nat an initial commit rather than having a direct connection to the\nhistoric data. After that, the repos could be used just as described\nabove, separately or graphed together.\n\nAs far as I know though, there is still no way to use the git protocol\nfor the initial pull of such a combined repository. You have to pull\nboth repos separately and graft them together locally. This sounds\nharder than it is though and can be scripted easily.\n\nSean\n"},{"id":"28802","messageId":"egtkjp$b4u$1@sea.gmane.org","threadId":"5925","inReplyTo":"9e4733910610141606g749d268eudd85791620e1363a@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-15T15:37:51Z","receivedAt":"2006-10-15T15:37:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jon Smirl wrote:\n\n> The three most complex repositories are the kernel, gcc and Mozilla.\n> Gcc is in SVN now. Mozilla CVS and the kernel git.\n> \n> There are much larger repositories around for some of the distros, but\n> they are doing things like checking ISO images in to the repo which\n> just makes it big,, not complex.\n\nI guess that one of the important thinkgs is the _size_ of the repository;\nfor example 12GB (if I remember correctly value for Subversion/SVK) vs 500MB\nfor git...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28808","messageId":"20061015182303.GW20017@pasky.or.cz","threadId":"5925","inReplyTo":"9e4733910610141606g749d268eudd85791620e1363a@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-15T18:23:03Z","receivedAt":"2006-10-15T18:23:03Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Oct 15, 2006 at 01:06:10AM CEST, I got a letter\nwhere Jon Smirl said that...\n> On 10/14/06, Jakub Narebski wrote:\n> >There is work by Jon Smirl and Shawn Pearce on CVS to Git importer which \n> >can\n> >manage large and complicated (read: f*cked-up) Mozilla CVS repository.\n> > http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#cvs2git\n> \n> I am still working with the developers of the cvs2svn import tool to\n> fix things so that Mozilla CVS can be correctly imported. There are\n> still outstanding bugs in cvs2svn preventing a correct import. MozCVS\n> can be imported, but the resulting repository is not entirely correct.\n> \n> Once they get the base cvs2svn fixed I'll port my patches to turn it\n> into cvs2git again.\n\nSo what exactly is the cvs2git status now? AFAIU, there's a tool that\nparses the CVS repository and that is then \"piped\" to git-fastimport?\ngit-fastimport is available somewhere (perhaps it would be interesting\nto publish it at repo.or.cz or something), is the current cvs2git\nversion available as well?\n\n> >2. Good support for system which most important developers use, and good\n> >support for system which most contributors use. If MS Windows is included\n> >in those, then Git perhaps wouldn't be the best choice.\n> \n> Better Windows support is needed to make git the first choice among\n> the various SCMs.\n\nAnd this is probably not likely to happen soon.\n\nWell, I'm enlisted in a \"Programming in Windows\" course at my university\nnow and I had this kind of thoughts, but I really can't promise\nanything. :-)\n\n> >4. Good support for _large_ project, with large history. Namely, that\n> >developer wouldn't need to download many megabytes and/or wouldn't need\n> >megabytes of working area. How that is solved, be it partial checkouts,\n> >lazy/shallow/sparse clone, subprojects, splitting into\n> >projects/repositories and having some superproject or build-time\n> >superproject, splitting repository into current and historical... that of\n> >course depends on SCM.\n> \n> git has issues here. The smallest Mozilla download we have built so\n> far is 450MB for the initial checkout.\n\n(BTW, yes, grafting the old history could help this time, but it is a\nhack and not a good long-term solution - it is just putting the real\nsolution away until the project history will re-grew. Periodical\nregrafting is even worse hack, since at that moment you break\nfast-forwarding and this kind of \"restarting the history\" breaks deep\ninto the Git distributiveness.)\n\n> >5. ....\n> >\n> >and probably few more\n> \n> \n> The three most complex repositories are the kernel, gcc and Mozilla.\n> Gcc is in SVN now. Mozilla CVS and the kernel git.\n\nI believe OpenOffice CVS probably beats all three hands down very\neasily. KDE is also very big, and I don't think NetBSD is just ISO\nimages either (if it contains any at all).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n\n> (BTW, yes, grafting the old history could help this time, but it is a\n> hack and not a good long-term solution - it is just putting the real\n> solution away until the project history will re-grew. Periodical\n> regrafting is even worse hack, since at that moment you break\n> fast-forwarding and this kind of \"restarting the history\" breaks deep\n> into the Git distributiveness.)\n\nBut is there a better practical solution he can use today? I don't think\nthere is. And the experience of the Linux kernel has shown that it's not\nreally all that big a problem. You even made a nice script to help people\ndo it! ;o)\n\nIt's probably not the solution that should be used _next_ time the repository\ngrows too big, but it sure seems like the correct solution this time around.\nNot many people will want all that old history anyway (10+ years as i recall?).\n\nSean\n"},{"id":"28813","messageId":"20061015192458.GY18879@pasky.or.cz","threadId":"5925","inReplyTo":"20061015143956.86db3a8b.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-15T19:24:58Z","receivedAt":"2006-10-15T19:24:58Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Oct 15, 2006 at 08:39:56PM CEST, Sean wrote:\n> On Sun, 15 Oct 2006 20:23:03 +0200\n> Petr Baudis wrote:\n> \n> > (BTW, yes, grafting the old history could help this time, but it is a\n> > hack and not a good long-term solution - it is just putting the real\n> > solution away until the project history will re-grew. Periodical\n> > regrafting is even worse hack, since at that moment you break\n> > fast-forwarding and this kind of \"restarting the history\" breaks deep\n> > into the Git distributiveness.)\n> \n> But is there a better practical solution he can use today? I don't think\n> there is. And the experience of the Linux kernel has shown that it's not\n> really all that big a problem. You even made a nice script to help people\n> do it! ;o)\n> \n> It's probably not the solution that should be used _next_ time the repository\n> grows too big, but it sure seems like the correct solution this time around.\n> Not many people will want all that old history anyway (10+ years as i recall?).\n\nWell I'm not saying it's the incorrect solution today, only that we\nwon't get around the problem by suggesting grafting forever. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> > I am still working with the developers of the cvs2svn import tool to\n> > fix things so that Mozilla CVS can be correctly imported. There are\n> > still outstanding bugs in cvs2svn preventing a correct import. MozCVS\n> > can be imported, but the resulting repository is not entirely correct.\n> >\n> > Once they get the base cvs2svn fixed I'll port my patches to turn it\n> > into cvs2git again.\n>\n> So what exactly is the cvs2git status now? AFAIU, there's a tool that\n> parses the CVS repository and that is then \"piped\" to git-fastimport?\n> git-fastimport is available somewhere (perhaps it would be interesting\n> to publish it at repo.or.cz or something), is the current cvs2git\n> version available as well?\n\ncvs2git is a set of patches that get applied to cvs2svn. The patches\nmodify cvs2svn to output things in a format that git-fastimport can\nconsume.\n\nThe problem is that there are issues with cvs2svn and how it converts\nCVS into change sets that are not getting fixed. These issues are\nannoying for SVN users but they are fatal for git. The exact problem\nis a bug in the way CVS symbol dependencies are dealt with in cvs2svn.\nThe bug results in most branches and symbols being based off from 5-7\ndifferent change sets instead of a single change set. SVN then copies\nfrom the 5-7 change sets to build the branch base or symbol base.\nCopying from the 5-7 change sets is addressing the symptoms of the bug\ninstead of fixing the underlying problem which is incorrect ordering\nof the base change sets.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"28831","messageId":"20061016032314.GA20017@pasky.or.cz","threadId":"5925","inReplyTo":"9e4733910610151249m37c9f6abv37e07d7a801758bc@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-16T03:23:14Z","receivedAt":"2006-10-16T03:23:14Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Oct 15, 2006 at 09:49:08PM CEST, I got a letter\nwhere Jon Smirl said that...\n> On 10/15/06, Petr Baudis wrote:\n> >> I am still working with the developers of the cvs2svn import tool to\n> >> fix things so that Mozilla CVS can be correctly imported. There are\n> >> still outstanding bugs in cvs2svn preventing a correct import. MozCVS\n> >> can be imported, but the resulting repository is not entirely correct.\n> >>\n> >> Once they get the base cvs2svn fixed I'll port my patches to turn it\n> >> into cvs2git again.\n> >\n> >So what exactly is the cvs2git status now? AFAIU, there's a tool that\n> >parses the CVS repository and that is then \"piped\" to git-fastimport?\n> >git-fastimport is available somewhere (perhaps it would be interesting\n> >to publish it at repo.or.cz or something), is the current cvs2git\n> >version available as well?\n> \n> cvs2git is a set of patches that get applied to cvs2svn. The patches\n> modify cvs2svn to output things in a format that git-fastimport can\n> consume.\n\nBy the way, isn't what you want an incremental importer, because of the\n1.9 branch? According to its homepage, cvs2svn is not designed for\nincremental importing. Or are you fixing that as well?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> Dear diary, on Sun, Oct 15, 2006 at 09:49:08PM CEST, I got a letter\n> where Jon Smirl said that...\n> > On 10/15/06, Petr Baudis wrote:\n> > >> I am still working with the developers of the cvs2svn import tool to\n> > >> fix things so that Mozilla CVS can be correctly imported. There are\n> > >> still outstanding bugs in cvs2svn preventing a correct import. MozCVS\n> > >> can be imported, but the resulting repository is not entirely correct.\n> > >>\n> > >> Once they get the base cvs2svn fixed I'll port my patches to turn it\n> > >> into cvs2git again.\n> > >\n> > >So what exactly is the cvs2git status now? AFAIU, there's a tool that\n> > >parses the CVS repository and that is then \"piped\" to git-fastimport?\n> > >git-fastimport is available somewhere (perhaps it would be interesting\n> > >to publish it at repo.or.cz or something), is the current cvs2git\n> > >version available as well?\n> >\n> > cvs2git is a set of patches that get applied to cvs2svn. The patches\n> > modify cvs2svn to output things in a format that git-fastimport can\n> > consume.\n>\n> By the way, isn't what you want an incremental importer, because of the\n> 1.9 branch? According to its homepage, cvs2svn is not designed for\n> incremental importing. Or are you fixing that as well?\n\ncvsps works ok on small amounts of data, but it can't handle the full\nMozilla repo. The current idea is to convert the full repo with\ncvs2git and build the ini file needed by cvsps to support incremental\nimports. After that use cvsps.\n\n\n>\n> --\n> Petr \"Pasky\" Baudis\n> Stuff: http://pasky.or.cz/\n> #!/bin/perl -sp0777i $/=unpack('H*',$_);$_=`echo 16dio\\U$k\"SK$/SM$n\\EsN0p[lN*1\n> lK[d2%Sa2/d0$^Ixp\"|dc`;s/\\W//g;$_=pack('H*',/((..)*)$/)\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"28834","messageId":"20061016035326.GA8654@hope.sourcefrog.net","threadId":"5925","inReplyTo":"egr3ud$nqm$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Martin Pool","fromEmail":"mbp@canonical.com","sentAt":"2006-10-16T03:53:27Z","receivedAt":"2006-10-16T03:53:27Z","isPatch":false,"sender":{"key":"mbp@canonical.com","avatar":null},"body":"On 14 Oct 2006, Jakub Narebski wrote:\n> Jon Smirl wrote:\n> \n> > It refers to this comparison chart between source control systems.\n> > http://bazaar-vcs.org/RcsComparisons\n> \n> It is quite obvious that comparison of programs of given type (SMC)\n> on some program site (Bazaar-NG) is usually biased towards said program,\n> perhaps unconsciously: by emphasizing the features which were important\n> for developers of said program.\n\nI don't think I saw the original post but thanks for the feedback, we'll\nupdate it.\n\n> Gaah, subscribe-to-post mailing list!\n\nNo, it's just moderated for first time posters to avoid spam. Your\nmessage got through.\n"},{"id":"28873","messageId":"45340713.6000707@utoronto.ca","threadId":"5925","inReplyTo":"egr3ud$nqm$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-16T22:26:27Z","receivedAt":"2006-10-16T22:26:27Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJakub Narebski wrote:\n>>Does it accurately reflect the current status of git? Is their\n>>assessment of git's rename capability correct?\n> \n> \n> For example simple namespace for git: you can use shortened sha1\n> (even to only 6 characters, although usually 8 are used), you can\n> use tags, you can use ref^m~n syntax.\n\nBazaar's namespace is \"simple\" because all branches can be named by a\nURL, and all revisions can be named by a URL + a number.\n\nIf that's true of Git, then it certainly has a simple namespace. Using\neight-digit hex values doesn't sound simple to me, though.\n\n> I'm not sure about \"No\" in \"Supports Repository\". Git supports multiple\n> branches in one repository, and what's better supports development using\n> multiple branches, but cannot for example do a diff or a cherry-pick\n> between repositories (well, you can use git-format-patch/git-am to\n> cherry-pick changes between repositories...).\n\nThat sounds right. So those branches are persistent, and can be worked\non independently?\n\n> About \"checkouts\", i.e. working directories with repository elsewhere:\n> you can use GIT_DIR environmental variable or \"git --git-dir\" option,\n> or symlinks, and if Nguyen Thai Ngoc D proposal to have .gitdir/.git\n> \"symref\"-like file to point to repository passes, we can use that.\n\nIt sounds like the .gitdir/.git proposal would give Git \"checkouts\", by\nour meaning of the term.\n\n> Partial checkouts are only partially supported as of now; it means\n> you have to do some lowe level stuff to do partial checkout, and be\n> carefull when comitting. BTW it depends what you mean by partial\n> checkout, but they are somewhat incompatibile with atomic commits\n> to snapshot based repository.\n\nYes, I'm very much aware of that tension. It will be fun when Bazaar\ntries to support that... :-)\n\n> Git supports renames in its own way; it doesn't use file ids, nor\n> remember renames (the new \"note\" header for use e.g. by porcelains \n> didn't pass if I remember correctly). But it does *detect* moving\n> _contents_, and even *copying* _contents_ when requested. And of\n> course it detect renames in merges.\n\nYou'll note we referred to that bevhavior on the page. We don't think\nwhat Git does is the same as supporting renames. AIUI, some Git users\nfeel the same way.\n\n> Git doesn't have some \"plugin framework\", but because it has many\n> \"plumbing\" commands, it is easy to add new commands, and also new\n> merge strategies, using shell scripts, Perl, Python and of course C.\n> So the answer would be \"Somewhat\", as git has plugable merge strategies,\n> or even \"Yes\" at it is easy to add new git command.\n\nIt sounds like you're saying it's extensible, not that it supports\nplugins. Plugins have very simple installation requirements. They can\nprovide merge strategies, repository types, internet protocols, new\ncommands, etc., all seamlessly integrated.\n\nWhat you're describing actually sounds like the Arch approach to\nextensibility: provide a whole bunch of basic commands and let users\nbuild an RCS on top of that.\n\nAs the author of two different Arch front-ends, I can say I haven't\nfound that approach satisfactory. Invoking multiple commands tends\nre-invoke the same validation routines over and over, killing\nefficiency, and diagnostics tend to be pretty poorly integrated.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFNAb90F+nu1YWqI0RAvRDAJ9HHHdbhT1+aA3wOGeuUDkjRIr7BQCcDBKB\ncL+DAy5GdTDk8Iz9TUkQ//M=\n=AJAu\n-----END PGP SIGNATURE-----\n"},{"id":"28874","messageId":"45340949.9070606@shadowen.org","threadId":"5925","inReplyTo":"45340713.6000707@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-10-16T22:35:53Z","receivedAt":"2006-10-16T22:35:53Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Aaron Bentley wrote:\n\n>>> Git supports renames in its own way; it doesn't use file ids, nor\n>>> remember renames (the new \"note\" header for use e.g. by porcelains \n>>> didn't pass if I remember correctly). But it does *detect* moving\n>>> _contents_, and even *copying* _contents_ when requested. And of\n>>> course it detect renames in merges.\n> \n> You'll note we referred to that bevhavior on the page. We don't think\n> what Git does is the same as supporting renames. AIUI, some Git users\n> feel the same way.\n\nIn my experience there are two key features to rename support. The\nfirst that files move about efficiently ie. we don't have to carry a\ndifferent copy of the same file for each name it has had, this git\nhandles nicely. The second is the seemless following of history 'back',\nthis git does not do trivially (when limited to specific files). git\nlog on a renamed file pretty much stops at the rename point and you have\ndeal with it yourself.\n\nI would love to see someone respond with a pickaxe like command line\nwhich would list each and every change and its origin though merges and\nthe like.\n\nHmmm.\n\n-apw\n"},{"id":"28875","messageId":"eh12fn$i9v$1@sea.gmane.org","threadId":"5925","inReplyTo":"45340949.9070606@shadowen.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-16T22:53:07Z","receivedAt":"2006-10-16T22:53:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Whitcroft wrote:\n\n> Aaron Bentley wrote:\n> \n>>>> Git supports renames in its own way; it doesn't use file ids, nor\n>>>> remember renames (the new \"note\" header for use e.g. by porcelains \n>>>> didn't pass if I remember correctly). But it does *detect* moving\n>>>> _contents_, and even *copying* _contents_ when requested. And of\n>>>> course it detect renames in merges.\n>> \n>> You'll note we referred to that bevhavior on the page. We don't think\n>> what Git does is the same as supporting renames. AIUI, some Git users\n>> feel the same way.\n> \n> In my experience there are two key features to rename support. The\n> first that files move about efficiently ie. we don't have to carry a\n> different copy of the same file for each name it has had, this git\n> handles nicely. The second is the seemless following of history 'back',\n> this git does not do trivially (when limited to specific files). git\n> log on a renamed file pretty much stops at the rename point and you have\n> deal with it yourself.\n\nBoth git log and git diff follows renames (with -M) and even copies \n(with -C), but path _limiter_ doesn't follow renames. There is proposal\nto add --follow option to git rev-list to follow specified paths. There was\na patch adding this option here on git mailing list (check archives), not\nadded because it was fairly intrusive and not complete solution IIRC.\n\nI'd say that the second part is _partially_ supported, as we can follow\nhistory of renamed file with pathlimit, detect that file was renamed, and\nfollow using previous name as pathlimit. For example if you know all the\nnames the file had through history, you can get whole history providing all\nthose names as pathlimit (well, unless there is some conflict like creating\nnew file with the same name as file before rename; something that all\nfile-id based solutions have problem with).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28877","messageId":"200610170119.09066.jnareb@gmail.com","threadId":"5925","inReplyTo":"45340713.6000707@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-16T23:19:08Z","receivedAt":"2006-10-16T23:19:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> Jakub Narebski wrote:\n> >>Does it accurately reflect the current status of git? Is their\n> >>assessment of git's rename capability correct?\n> >\n> >\n> > For example simple namespace for git: you can use shortened sha1\n> > (even to only 6 characters, although usually 8 are used), you can\n> > use tags, you can use ref^m~n syntax.\n> \n> Bazaar's namespace is \"simple\" because all branches can be named by a\n> URL, and all revisions can be named by a URL + a number.\n\nWell, all refs (branches and tags) are named by [relative] path. So for\nexample we can have 'master', 'next', 'jc/diff' branches, 'v1.4.0' and\n'examples/tag' tags. Cogito for example uses #\nsyntax.\n\n> If that's true of Git, then it certainly has a simple namespace. Using\n> eight-digit hex values doesn't sound simple to me, though.\n\nWell, ~ means -th _parent_ of a given ref, which for branches\n(which constantly change) is a moving target.\n\nThere was proposal to add some kind of serial number to git (like \nSubversion revision numbers) and even solution how to do this...\nbut one must realize that any serial number must be _local_ to the\nrepository. One cannot have universally valid revision numbers (even\nonly per branch) in distributed development. Subversion can do that only\nbecause it is centralized SCM. Global numbering and distributed nature\ndoesn't mix... hence contents based sha1 as commit identifiers.\n\n\nBut this doesn't matter much, because you can have really lightweight\ntags in git (especially now with packed refs support). So you can have\nthe namespace you want.\n\n>> I'm not sure about \"No\" in \"Supports Repository\". Git supports multiple\n>> branches in one repository, and what's better supports development using\n>> multiple branches, but cannot for example do a diff or a cherry-pick\n>> between repositories (well, you can use git-format-patch/git-am to\n>> cherry-pick changes between repositories...).\n> \n> That sounds right. So those branches are persistent, and can be worked\n> on independently?\n\nBranches are persistent, have _separate_ (!) namespace (are not\nincorporated in repository URL according to some kind of convention\nlike in Subversion), can be worked independently, you can easily\nswitch between branches in one working directory. Branches are cheap\nin git (notion of topic branches).\n\nI wonder if any SCM other than git has easy way to \"rebase\" a branch,\ni.e. cut branch at branching point, and transplant it to the tip\nof other branch. For example you work on 'xx/topic' topic branch,\nand want to have changes in those branch but applied to current work,\nnot to the version some time ago when you have started working on\nsaid feature.\n\nWhat your comparison matrick lacks for example is if given SCM\nsaves information about branching point and merges, so you can\nget where two branches diverged, and when one branch was merged into\nanother.\n \n>> About \"checkouts\", i.e. working directories with repository elsewhere:\n>> you can use GIT_DIR environmental variable or \"git --git-dir\" option,\n>> or symlinks, and if Nguyen Thai Ngoc D proposal to have .gitdir/.git\n>> \"symref\"-like file to point to repository passes, we can use that.\n> \n> It sounds like the .gitdir/.git proposal would give Git \"checkouts\", by\n> our meaning of the term.\n\nActually it is better to work with clone of repository, perhaps either\nsymlinking object database, or by alternates mechanism (with alternates\nrepositories would share old history, but gather new independetly\nI think).\n\n>> Git doesn't have some \"plugin framework\", but because it has many\n>> \"plumbing\" commands, it is easy to add new commands, and also new\n>> merge strategies, using shell scripts, Perl, Python and of course C.\n>> So the answer would be \"Somewhat\", as git has plugable merge strategies,\n>> or even \"Yes\" at it is easy to add new git command.\n> \n> It sounds like you're saying it's extensible, not that it supports\n> plugins. Plugins have very simple installation requirements. They can\n> provide merge strategies, repository types, internet protocols, new\n> commands, etc., all seamlessly integrated.\n\nPlugins = API + detection ifrastructure + loading on demand.\nGit has API, has a kind of detection ifrastructure (for commands and\nmerge strategies only), doesn't have loading on demand. You can\neasily provide new commands (thanks to git wrapper) and new merge\nstrategies. \n\nDoes git needs \"plugin framework\"? I'm not sure. Now it is like\nLinux kernel without loadable modules support...\n\n> What you're describing actually sounds like the Arch approach to\n> extensibility: provide a whole bunch of basic commands and let users\n> build an RCS on top of that.\n>\n> As the author of two different Arch front-ends, I can say I haven't\n> found that approach satisfactory. Invoking multiple commands tends\n> re-invoke the same validation routines over and over, killing\n> efficiency, and diagnostics tend to be pretty poorly integrated.\n\nActually I think it is how git was made. First came low level stuff,\n\"plumbing\" in git parlance. Then there were scripts which used those\nlow level commands. There is ongoing project to rewrite them as builtin\ncommands (written in C); many of them got rewritten.\n\nWhen git had very few higher level commands, here came git-pasky,\nlater renamed to Cogito; higher level SCM built on top of Git (in bash\nshell). Now core git contains many high level commands, porcelanish\nin git jargon.\n\nWell, there is also StGit and it's alternative pg (Patchy Git), which\nimplement Quilt-like functionality (patch management) on top of Git.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"28879","messageId":"Pine.LNX.4.64.0610161625370.3962@g5.osdl.org","threadId":"5925","inReplyTo":"45340713.6000707@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-16T23:35:53Z","receivedAt":"2006-10-16T23:35:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 16 Oct 2006, Aaron Bentley wrote:\n> \n> Bazaar's namespace is \"simple\" because all branches can be named by a\n> URL, and all revisions can be named by a URL + a number.\n> \n> If that's true of Git, then it certainly has a simple namespace. Using\n> eight-digit hex values doesn't sound simple to me, though.\n\nHey, \"simple\" is in the eye of the beholder. You can always just define \nBazaar's naming convention to be simple. \n\nI pretty much _guarantee_ that a \"number\" is not a valid way to uniquely \nname a revision in a distributed environment, though. I bet the \"number\" \nreally only names a revision in one _single_ repository, right?\n\nWhich measn that it's actually not a \"name\" of the revision at all. It's \njust a local shorthand that has no meaning, and the exact same revision \nwill be called something different when in somebody elses repository.\n\nI wouldn't call that \"simple\". I'd call it \"insane\".\n\nIn contrast, in git, a revision is a revision is a revision. If you give \nthe SHA1 name, it's well-defined even between different repositories, and \nyou can tell somebody that \"revision XYZ is when the problem started\", and \nthey'll know _exactly_ which revision it is, even if they don't have your \nparticular repository.\n\nNow _that_ is true simplicity. It does automatically mean that the names \nare a bit longer, but in this case, \"longer\" really _does_ mean \"simpler\".\n\nIf you want a short, human-readable name, you _tag_ it. It takes all of a \nhundredth of a second to to or so.\n\n> > I'm not sure about \"No\" in \"Supports Repository\". Git supports multiple\n> > branches in one repository, and what's better supports development using\n> > multiple branches, but cannot for example do a diff or a cherry-pick\n> > between repositories (well, you can use git-format-patch/git-am to\n> > cherry-pick changes between repositories...).\n> \n> That sounds right. So those branches are persistent, and can be worked\n> on independently?\n\nYes.\n\n> > About \"checkouts\", i.e. working directories with repository elsewhere:\n> > you can use GIT_DIR environmental variable or \"git --git-dir\" option,\n> > or symlinks, and if Nguyen Thai Ngoc D proposal to have .gitdir/.git\n> > \"symref\"-like file to point to repository passes, we can use that.\n> \n> It sounds like the .gitdir/.git proposal would give Git \"checkouts\", by\n> our meaning of the term.\n\nWell, in the git world, it's really just one shared repository that has \nseparate branch-namespaces, and separate working trees (aka \"checkouts\"). \nSo yes, it probably matches what bazaar would call a checkout.\n\nAlmost nobody seems to actually use it that way in git - it's mostly more \nefficient to just have five different branches in the same working tree, \nand switch between them. When you switch between branches in git, git only \nrewrites the part of your working tree that actually changed, so switching \nis extremely efficient even with a large repo. \n\nSo there is seldom any real need or reason to actually have multiple \ncheckouts. But it certainly _works_.\n\n> You'll note we referred to that bevhavior on the page. We don't think\n> what Git does is the same as supporting renames. AIUI, some Git users\n> feel the same way.\n\nThe fact is, git supports renames better than just about anybody else. It \njust does them technically differently. The fact that it happens to be the \n_right_ way, and everybody else is incompetent, is not my fault ;)\n\n\t\t\tLinus\n"},{"id":"28880","messageId":"fcaeb9bf0610161639g34eea7e8nb21c881d79cb1c85@mail.gmail.com","threadId":"5925","inReplyTo":"200610170119.09066.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-10-16T23:39:09Z","receivedAt":"2006-10-16T23:39:09Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 10/17/06, Jakub Narebski wrote:\n> Aaron Bentley wrote:\n> > Jakub Narebski wrote:\n> >> About \"checkouts\", i.e. working directories with repository elsewhere:\n> >> you can use GIT_DIR environmental variable or \"git --git-dir\" option,\n> >> or symlinks, and if Nguyen Thai Ngoc D proposal to have .gitdir/.git\n> >> \"symref\"-like file to point to repository passes, we can use that.\n> >\n> > It sounds like the .gitdir/.git proposal would give Git \"checkouts\", by\n> > our meaning of the term.\n>\n> Actually it is better to work with clone of repository, perhaps either\n> symlinking object database, or by alternates mechanism (with alternates\n> repositories would share old history, but gather new independetly\n> I think).\nI agree. Each Git repository is designed to work with one working\ndirectory. Using .gitdir/.git proposal, you are likely to checkout two\nworking directories from one repo.\n-- \nDuy\n"},{"id":"28881","messageId":"Pine.LNX.4.63.0610170128350.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"45340713.6000707@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-16T23:45:34Z","receivedAt":"2006-10-16T23:45:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Aaron,\n\nOn Mon, 16 Oct 2006, Aaron Bentley wrote:\n\n> --[PinePGP]--------------------------------------------------[begin]--\n> Jakub Narebski wrote:\n> >>Does it accurately reflect the current status of git? Is their\n> >>assessment of git's rename capability correct?\n> >\n> >\n> > For example simple namespace for git: you can use shortened sha1\n> > (even to only 6 characters, although usually 8 are used), you can\n> > use tags, you can use ref^m~n syntax.\n> \n> Bazaar's namespace is \"simple\" because all branches can be named by a \n> URL, and all revisions can be named by a URL + a number.\n\nHow should this cope with a distributed project? IOW how does it deal with \n\"this revision and that revision are exactly the same\"?\n\nIf I understand you correctly, you are claiming that you are not really \nidentifying a revision, but a revision _at a certain place with a \nplace-dependent number_. This conflicts with my understanding of a \nrevision.\n\n> If that's true of Git, then it certainly has a simple namespace. Using \n> eight-digit hex values doesn't sound simple to me, though.\n\nIt depends on your usage. If you want to do anything interesting, like \nassure that you have the correct version, or assure that two different \nperson's tags actually tag the same revision, there is no simpler \nrepresentation.\n\n> > I'm not sure about \"No\" in \"Supports Repository\". Git supports multiple\n> > branches in one repository, and what's better supports development using\n> > multiple branches, but cannot for example do a diff or a cherry-pick\n> > between repositories (well, you can use git-format-patch/git-am to\n> > cherry-pick changes between repositories...).\n> \n> That sounds right. So those branches are persistent, and can be worked\n> on independently?\n\nOf course! Persistence (and reliability) are the number one goal of git. \nPerformance is the next one.\n\nAs an example of completely independet branches, look at the \"next\" and \nthe \"todo\" branch of git. They are _completely_ independent, i.e. not even \nsharing history, let alone files.\n\n> > Git supports renames in its own way; it doesn't use file ids, nor\n> > remember renames (the new \"note\" header for use e.g. by porcelains\n> > didn't pass if I remember correctly). But it does *detect* moving\n> > _contents_, and even *copying* _contents_ when requested. And of\n> > course it detect renames in merges.\n> \n> You'll note we referred to that bevhavior on the page. We don't think\n> what Git does is the same as supporting renames. AIUI, some Git users\n> feel the same way.\n\nOh, we start another flamewar again?\n\nHonestly, if you want to record renames, why don't you also support (with \na command for each of those purposes) code copying? And refactoring? And \ncopyright year bumps? _put your favourite here_\n\nIf you really, really think about it: it makes much more sense to record \nyour intention in the commit message. So, instead of recording for _every_ \n_single_ file in folder1/ that it was moved to folder2/, it is better to \nsay that you moved folder1/ to folder2/ _because of some special reason_!\n\nSame goes for all other thinkable examples.\n\nIf you want to track code, then let the tracker do its work, i.e. let \ngit-pickaxe figure where your code came from. It is likely being more \nprecise than any human ever can be.\n\n> > Git doesn't have some \"plugin framework\", but because it has many\n> > \"plumbing\" commands, it is easy to add new commands, and also new\n> > merge strategies, using shell scripts, Perl, Python and of course C.\n> > So the answer would be \"Somewhat\", as git has plugable merge strategies,\n> > or even \"Yes\" at it is easy to add new git command.\n> \n> It sounds like you're saying it's extensible, not that it supports\n> plugins. Plugins have very simple installation requirements. They can\n> provide merge strategies, repository types, internet protocols, new\n> commands, etc., all seamlessly integrated.\n> \n> What you're describing actually sounds like the Arch approach to\n> extensibility: provide a whole bunch of basic commands and let users\n> build an RCS on top of that.\n\nIt is more like the Unix way. Let each command do _one_ thing, but let it \ndo it _perfectly_.\n\n> As the author of two different Arch front-ends, I can say I haven't\n> found that approach satisfactory. Invoking multiple commands tends\n> re-invoke the same validation routines over and over, killing\n> efficiency, and diagnostics tend to be pretty poorly integrated.\n\nWelcome to git! Git's commands are very efficient, and you can even pipe \nthem efficiently! And now that we have GIT_TRACE, diagnostics are no \nconcern.\n\nCiao,\nDscho\n"},{"id":"28884","messageId":"200610170155.10536.jnareb@gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610161625370.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-16T23:55:10Z","receivedAt":"2006-10-16T23:55:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n>>> About \"checkouts\", i.e. working directories with repository elsewhere:\n>>> you can use GIT_DIR environmental variable or \"git --git-dir\" option,\n>>> or symlinks, and if Nguyen Thai Ngoc D proposal to have .gitdir/.git\n>>> \"symref\"-like file to point to repository passes, we can use that.\n>> \n>> It sounds like the .gitdir/.git proposal would give Git \"checkouts\", by\n>> our meaning of the term.\n> \n> Well, in the git world, it's really just one shared repository that has \n> separate branch-namespaces, and separate working trees (aka \"checkouts\"). \n> So yes, it probably matches what bazaar would call a checkout.\n> \n> Almost nobody seems to actually use it that way in git - it's mostly more \n> efficient to just have five different branches in the same working tree, \n> and switch between them. When you switch between branches in git, git only \n> rewrites the part of your working tree that actually changed, so switching \n> is extremely efficient even with a large repo. \n\nUnless you have branch(es) with totally different contents, like git.git\n'todo' branch.\n\n> So there is seldom any real need or reason to actually have multiple \n> checkouts. But it certainly _works_.\n\nBut without .git being either symlink, or .git/.gitdir \"symref\"-link,\nyou have to remember what to ser GIT_DIR to, or parameter for --git-dir\noption.\n\nI'd like to mention once again that in Git branches and tags have\ntotally separate namespace than repository namespace.\n-- \nJakub Narebski\nPoland\n"},{"id":"28885","messageId":"Pine.LNX.4.63.0610170157270.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"200610170155.10536.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-17T00:04:52Z","receivedAt":"2006-10-17T00:04:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 17 Oct 2006, Jakub Narebski wrote:\n\n> Linus Torvalds wrote:\n> >>> About \"checkouts\", i.e. working directories with repository elsewhere:\n> >>> you can use GIT_DIR environmental variable or \"git --git-dir\" option,\n> >>> or symlinks, and if Nguyen Thai Ngoc D proposal to have .gitdir/.git\n> >>> \"symref\"-like file to point to repository passes, we can use that.\n> >> \n> >> It sounds like the .gitdir/.git proposal would give Git \"checkouts\", by\n> >> our meaning of the term.\n> > \n> > Well, in the git world, it's really just one shared repository that has \n> > separate branch-namespaces, and separate working trees (aka \"checkouts\"). \n> > So yes, it probably matches what bazaar would call a checkout.\n> > \n> > Almost nobody seems to actually use it that way in git - it's mostly more \n> > efficient to just have five different branches in the same working tree, \n> > and switch between them. When you switch between branches in git, git only \n> > rewrites the part of your working tree that actually changed, so switching \n> > is extremely efficient even with a large repo. \n> \n> Unless you have branch(es) with totally different contents, like git.git\n> 'todo' branch.\n\nBut I _do_ work with it! I just don't need to \"checkout\" it! Example:\n\ngit -p cat-file -p todo:TODO\n\n(How about making git-cat be a short cuut to \"git -p cat-file -p\"?)\n\n> > So there is seldom any real need or reason to actually have multiple \n> > checkouts. But it certainly _works_.\n> \n> But without .git being either symlink, or .git/.gitdir \"symref\"-link,\n> you have to remember what to ser GIT_DIR to, or parameter for --git-dir\n> option.\n\nYou'd just use alternates for that.\n\nBut as Linus mentioned in another email, you mostly can use the _same_ \nworking directory. If you want to work on another branch, which is not all \nthat different from the current branch (say, you have a bug fix branch on \ntop of an upstream branch), you just _switch_ to it. Git recognizes those \nfiles which are changed, and updates only these. Therefore, if you have \nsomething like a Makefile system to build the project, you actually save \n(compile) time as compared to the multiple-checkout scenario.\n\nI use this system a lot, since I maintain a few bugfixes for a few \nprojects until the bugfixes are applied upstream. BTW the \nmultiple-branches-in-one-working-directory workflow was propagated by Jeff \na long time ago, and it really changed my way of working. Thanks, Jeff!\n\nCiao,\nDscho\n"},{"id":"28886","messageId":"Pine.LNX.4.64.0610161704240.3962@g5.osdl.org","threadId":"5925","inReplyTo":"200610170155.10536.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-17T00:08:55Z","receivedAt":"2006-10-17T00:08:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 17 Oct 2006, Jakub Narebski wrote:\n> > rewrites the part of your working tree that actually changed, so switching \n> > is extremely efficient even with a large repo. \n> \n> Unless you have branch(es) with totally different contents, like git.git\n> 'todo' branch.\n\nYes. I have to say, that's likely a fairly odd case, and I wouldn't be \nsurprised if other VCS's don't support that mode of operation at _all_.\n\nThe fact that git branches can be independent of each other is very \nnatural in the git world, but \n\n> > So there is seldom any real need or reason to actually have multiple \n> > checkouts. But it certainly _works_.\n> \n> But without .git being either symlink, or .git/.gitdir \"symref\"-link,\n> you have to remember what to ser GIT_DIR to, or parameter for --git-dir\n> option.\n\nI'd strongly suggest that people who do this should actually do\n\n\tgit clone -l\n\ninstead of actually playing games with symlinking .git/ itself or using \nGIT_DIR. It means that the two checkouts get separate branch namespaces, \nbut that's really what you'd want most of the time. \n\nYou _can_ share the whole branch namespace and do the symlink of .git (or \njust set GIT_DIR - but that's pretty inconvenient), and it might end up \nbeing \"closer\" to what some other VCS would do. But the natural thing to \ndo with git is to just share some of the objects through local \"slaving\" \nof the repositories, and consider them otherwise entirely independent.\n\n\t\tLinus\n"},{"id":"28887","messageId":"Pine.LNX.4.64.0610161714590.3962@g5.osdl.org","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610170157270.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-17T00:23:43Z","receivedAt":"2006-10-17T00:23:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 17 Oct 2006, Johannes Schindelin wrote:\n> > \n> > Unless you have branch(es) with totally different contents, like git.git\n> > 'todo' branch.\n> \n> But I _do_ work with it! I just don't need to \"checkout\" it! Example:\n> \n> git -p cat-file -p todo:TODO\n\nOk, if there ever was an example of a strange git command-line, that was \nit.\n\n> (How about making git-cat be a short cuut to \"git -p cat-file -p\"?)\n\nWell, you can just add\n\n\t[alias]\n\t\tcat=-p cat-file -p\n\nto your ~/.gitconfig file, and you're there.\n\n[ For all the non-git people here: the first \"-p\" is shorthand for \n \"--paginate\", and means that git will automatically start a pager for \n the output. The second \"-p\" is shorthand for \"pretty\" (there's no \n long-format command line switch for it, though), and means that git \n cat-file will show the result in a human-readable way, regardless of \n whether it's just a text-file, or a git directory ]\n\nSo then you can do just\n\n\tgit cat todo:TODO\n\nand you're done.\n\n[ So for the non-git people, what that will actually _do_ is to show the \n TODO file in the \"todo\" branch - regardless of whether it is checked out \n or not, and start a pager for you. ]\n\nI actually do this sometimes, but I've never done it for branches (and I \ndo it seldom enough that I haven't added the alias). I do it for things \nlike\n\n\tgit cat v2.6.16:Makefile\n\nto see what a file looked like in a certain tagged release.\n\nPeople sometimes find the git command line confusing, but I have to say, \nthe thing is _damn_ expressive. I've never seen anybody else do things \nlike the above that git does really naturally, with not that much \nconfusion really.\n\nEven that \"alias\" file is quite readable, although I'd suggest writing out \nthe switches in full, ie\n\n\t[alias]\n\t\tcat=--paginate cat-file -p\n\ninstead. That kind of helps explains what the alias does and avoids the \nquestion of why there are two \"-p\" switches.\n\n\t\t\tLinus\n"},{"id":"28888","messageId":"eh17q6$od$1@sea.gmane.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610161704240.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T00:24:03Z","receivedAt":"2006-10-17T00:24:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n>> > So there is seldom any real need or reason to actually have multiple \n>> > checkouts. But it certainly _works_.\n>> \n>> But without .git being either symlink, or .git/.gitdir \"symref\"-link,\n>> you have to remember what to ser GIT_DIR to, or parameter for --git-dir\n>> option.\n> \n> I'd strongly suggest that people who do this should actually do\n> \n>         git clone -l\n> \n> instead of actually playing games with symlinking .git/ itself or using \n> GIT_DIR. It means that the two checkouts get separate branch namespaces, \n> but that's really what you'd want most of the time. \n\nOr symlinking .git/objects (and perhaps .git/remotes and .git/branches).\nBTW. wouldn't it be rather git clone -l -s? What would happenm on repack,\nor on repack -a -d?\n\nBut it is true that there is no need to checkout different branches\nto different working areas.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28889","messageId":"20061017002956.79736.qmail@web31807.mail.mud.yahoo.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610161625370.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-17T00:29:56Z","receivedAt":"2006-10-17T00:29:56Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Linus Torvalds wrote:\n> Well, in the git world, it's really just one shared repository that has \n> separate branch-namespaces, and separate working trees (aka \"checkouts\"). \n> So yes, it probably matches what bazaar would call a checkout.\n> \n> Almost nobody seems to actually use it that way in git - it's mostly more \n> efficient to just have five different branches in the same working tree, \n> and switch between them. When you switch between branches in git, git only \n> rewrites the part of your working tree that actually changed, so switching \n> is extremely efficient even with a large repo. \n> \n> So there is seldom any real need or reason to actually have multiple \n> checkouts. But it certainly _works_.\n\nIt does work, very well at that.\n\nI have a directory for each separate branch and simply use\ncd(1) to change the current working directory to that branch.\nSo, instead of \"git checkout \", I do \"cd ../\".\n\nOne only needs to watch out when one updates the repository.\nIf there had been updates in those branches, then one needs\nto git-reset the \"branch\" directory... (you know what I mean)\n(For example when I come to work in the morning an sync up\n with home from my usb key...)\n\nThe script is called:\nUsage: git-mkdir-of-branch \n where is the name of an existing branch in /.git/refs/heads\n\nand uses simple symbolic links and some git plumbing to do the\njob. It can be found in my git trees. I never bothered to send\nit out to Junio, since it could be considered heretic. ;-)\n\n Luben\n"},{"id":"28892","messageId":"Pine.LNX.4.63.0610170233110.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610161714590.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-17T00:36:02Z","receivedAt":"2006-10-17T00:36:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 16 Oct 2006, Linus Torvalds wrote:\n\n> On Tue, 17 Oct 2006, Johannes Schindelin wrote:\n> \n> > (How about making git-cat be a short cuut to \"git -p cat-file -p\"?)\n> \n> Well, you can just add\n> \n> \t[alias]\n> \t\tcat=-p cat-file -p\n> \n> to your ~/.gitconfig file, and you're there.\n\nHa! I have that for a long time! Although I named it \"s\", since \"git s \ntodo:TODO\" is two letters shorter...\n\nCiao,\nDscho\n\nP.S.: BTW a certain person complained about ~/.gitconfig not being \ndocumented, but evidently the itch was not big enough for that person to \ndocument it himself...\n"},{"id":"28895","messageId":"fcaeb9bf0610161817tc521f8dmc815623b60c27afc@mail.gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610161714590.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-10-17T01:17:39Z","receivedAt":"2006-10-17T01:17:39Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 10/17/06, Linus Torvalds wrote:\n> So then you can do just\n>\n> git cat todo:TODO\n>\n> and you're done.\n>\n> [ So for the non-git people, what that will actually _do_ is to show the\n> TODO file in the \"todo\" branch - regardless of whether it is checked out\n> or not, and start a pager for you. ]\n>\n> I actually do this sometimes, but I've never done it for branches (and I\n> do it seldom enough that I haven't added the alias). I do it for things\n> like\n>\n> git cat v2.6.16:Makefile\n>\n> to see what a file looked like in a certain tagged release.\n\nThis very useful syntax (:) didn't get documented\n\"officially\" anywhere. It was actually documented in commit log\nv1.4.1^0~255^2. Maybe someone should copy and paste it to git\ndocumentation? Maybe core-tutorial.txt or git-rev-parse.txt, is there\nany better place?\n-- \nDuy\n"},{"id":"28896","messageId":"20061017024056.GE20017@pasky.or.cz","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610170128350.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-17T02:40:56Z","receivedAt":"2006-10-17T02:40:56Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Hi!\n\nDear diary, on Tue, Oct 17, 2006 at 01:45:34AM CEST, I got a letter\nwhere Johannes Schindelin said that...\n> On Mon, 16 Oct 2006, Aaron Bentley wrote:\n> > As the author of two different Arch front-ends, I can say I haven't\n> > found that approach satisfactory. Invoking multiple commands tends\n> > re-invoke the same validation routines over and over, killing\n> > efficiency, and diagnostics tend to be pretty poorly integrated.\n> \n> Welcome to git! Git's commands are very efficient, and you can even pipe \n> them efficiently! And now that we have GIT_TRACE, diagnostics are no \n> concern.\n\nI think Aaron rather meant that in case of an error, the error messages\nmay seem incoherent from the perspective of a porcelain user if it's\nbeen generated by the plumbing. And I had that problem in Cogito as well\nfew times in the past, but I think most of those are reasonable now (I\ncan't think of a counter-example off the top of my head).\n\nCalling multiple git commands _is_ a problem, especially in a loop, but\nI think it's more the inherent fork()+execve() overhead than whatever\nhappens over and over when main() takes over. Many git commands got\nadjusted so that you can call them just once and then feed from/to them\nover longer time period.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i cvsps works ok on small amounts of data, but it can't handle the full\n> Mozilla repo. The current idea is to convert the full repo with\n> cvs2git and build the ini file needed by cvsps to support incremental\n> imports. After that use cvsps.\n> \n\nLooking through the client.mk used to check out the sub-portions of the\nCVS repository, I have to ask;\n\nWhy are you trying to import this big collection of projects into a\nsingle git repository?\n\nView git's repositories not as a container for an entire community's\ncode base, but more as object partitions. Currently you are quite happy\nto use per-file version control partitions inherent to CVS. Now you are\nlooking at removing all of the partitions completely and hoping to end\nup with something managable. That it has been possible at all to fit it\ninto the space less than the size of a CD is staggering, but surely a\npiecemeal approach would be a pragmatic solution to this problem.\n\nSam.\n"},{"id":"28899","messageId":"45345AEF.6070107@utoronto.ca","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610161625370.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-17T04:24:15Z","receivedAt":"2006-10-17T04:24:15Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nLinus Torvalds wrote:\n> \n> On Mon, 16 Oct 2006, Aaron Bentley wrote:\n>> Bazaar's namespace is \"simple\" because all branches can be named by a\n>> URL, and all revisions can be named by a URL + a number.\n\n> I pretty much _guarantee_ that a \"number\" is not a valid way to uniquely \n> name a revision in a distributed environment, though. I bet the \"number\" \n> really only names a revision in one _single_ repository, right?\n\nRight. That's why I said all revisions can be named by a URL + a\nnumber, because it's the combination of the URL + a number that is\nunique. (In bzr, each branch has a URL.)\n\n> In contrast, in git, a revision is a revision is a revision. \n\nI agree that a revision is a revision, but I don't think that's a\nproperty unique to git. :-)\n\n> If you give \n> the SHA1 name, it's well-defined even between different repositories, and \n> you can tell somebody that \"revision XYZ is when the problem started\", and \n> they'll know _exactly_ which revision it is, even if they don't have your \n> particular repository.\n\nWhen two people have copies of the same revision, it's usually because\nthey are each pulling from a common branch, and so the revision in that\nbranch can be named. Bazaar does use unique ids internally, but it's\nextremely rare that the user needs to use them.\n\n> Now _that_ is true simplicity. It does automatically mean that the names \n> are a bit longer, but in this case, \"longer\" really _does_ mean \"simpler\".\n> \n> If you want a short, human-readable name, you _tag_ it. It takes all of a \n> hundredth of a second to to or so.\n\nBut tags have local meaning only, unless someone has access to your\nrepository, right?\n\n>>> About \"checkouts\", i.e. working directories with repository elsewhere:\n>>> you can use GIT_DIR environmental variable or \"git --git-dir\" option,\n>>> or symlinks, and if Nguyen Thai Ngoc D proposal to have .gitdir/.git\n>>> \"symref\"-like file to point to repository passes, we can use that.\n>> It sounds like the .gitdir/.git proposal would give Git \"checkouts\", by\n>> our meaning of the term.\n> \n> Well, in the git world, it's really just one shared repository that has \n> separate branch-namespaces, and separate working trees (aka \"checkouts\"). \n> So yes, it probably matches what bazaar would call a checkout.\n\nThe key thing about a checkout is that it's stored in a different\nlocation from its repository. This provides a few benefits:\n\n- - you can publish a repository without publishing its working tree,\n possibly using standard mirroring tools like rsync.\n\n- - you can have working trees on local systems while having the\n repository on a remote system. This makes it easy to work on one\n logical branch from multiple locations, without getting out of sync.\n\n- - you can use a checkout to maintain a local mirror of a read-only\n branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n\n> Almost nobody seems to actually use it that way in git - it's mostly more \n> efficient to just have five different branches in the same working tree, \n> and switch between them. When you switch between branches in git, git only \n> rewrites the part of your working tree that actually changed, so switching \n> is extremely efficient even with a large repo.\n\nYou can operate that way in bzr too, but I find it nicer to have one\ncheckout for each active branch, plus a checkout of bzr.dev. Our switch\ncommand also rewrites only the changed part of the working tree.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNFrv0F+nu1YWqI0RAgBHAJ9XpmdvuCNDysxFhnyeCmkEG/z0ggCggMsJ\nWyW6lqGMokh0k0It1KOdgtk=\n=L1SR\n-----END PGP SIGNATURE-----\n"},{"id":"28900","messageId":"45345CBE.8020209@utoronto.ca","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610161704240.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-17T04:31:58Z","receivedAt":"2006-10-17T04:31:58Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nLinus Torvalds wrote:\n> \n> On Tue, 17 Oct 2006, Jakub Narebski wrote:\n>> Unless you have branch(es) with totally different contents, like git.git\n>> 'todo' branch.\n> \n> Yes. I have to say, that's likely a fairly odd case, and I wouldn't be \n> surprised if other VCS's don't support that mode of operation at _all_.\n\nBazaar also supports multiple unrelated branches in a repository, as\ndoes CVS, SVN (depending how you squint), Arch, and probably Monotone.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNFy90F+nu1YWqI0RAgMeAJ99OikxXspSg+efnN6j3ySoPuOovQCfaKA6\nyPCRw5Kl/V+ThnU6fsPA8TQ=\n=DYAN\n-----END PGP SIGNATURE-----\n"},{"id":"28903","messageId":"45346290.6050300@utoronto.ca","threadId":"5925","inReplyTo":"200610170119.09066.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-17T04:56:48Z","receivedAt":"2006-10-17T04:56:48Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJakub Narebski wrote:\n> Well, ~ means -th _parent_ of a given ref, which for branches\n> (which constantly change) is a moving target.\n\nAh. Bazaar uses negative numbers to refer to th parents, and\npositive numbers to refer to the number of commits that have been made\nsince the branch was initialized.\n\n> One cannot have universally valid revision numbers (even\n> only per branch) in distributed development. Subversion can do that only\n> because it is centralized SCM. Global numbering and distributed nature\n> doesn't mix... hence contents based sha1 as commit identifiers.\n\nSure. Our UI approach is that unique identifiers can usefully be\nabstracted away with a combination of URL + number, in the vast majority\nof cases.\n\n> But this doesn't matter much, because you can have really lightweight\n> tags in git (especially now with packed refs support). So you can have\n> the namespace you want.\n\nThe nice thing about revision numbers is that they're implicit-- no one\nneeds to take any action to update them, and so you can always use them.\n\n> I wonder if any SCM other than git has easy way to \"rebase\" a branch,\n> i.e. cut branch at branching point, and transplant it to the tip\n> of other branch. For example you work on 'xx/topic' topic branch,\n> and want to have changes in those branch but applied to current work,\n> not to the version some time ago when you have started working on\n> said feature.\n\nIf I understand correctly, in Bazaar, you'd just merge the current work\ninto 'xx/topic'.\n\n> What your comparison matrick lacks for example is if given SCM\n> saves information about branching point and merges, so you can\n> get where two branches diverged, and when one branch was merged into\n> another.\n\nI'm not sure what you mean about divergence. For example, Bazaar\nrecords the complete ancestry of each branch, and determining the point\nof divergence is as simple as finding the last common ancestor. But are\nyou considering only the initial divergence? Or if the branches merge\nand then diverge again, would you consider that the point of divergence?\n\nmerge-point tracking is a prerequisite for Smart Merge, which does\nappear on our matrix.\n\n> Plugins = API + detection ifrastructure + loading on demand.\n> Git has API, has a kind of detection ifrastructure (for commands and\n> merge strategies only), doesn't have loading on demand. You can\n> easily provide new commands (thanks to git wrapper) and new merge\n> strategies.\n\nI'm not sure what you mean by API, unless you mean the commandline. If\nthat's what you mean, surely all unix commands are extensible in that\nregard.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNGKQ0F+nu1YWqI0RAsW+AJoDOsNRmBjo3raT43JL6qn7SuJNRwCfe9l5\noAZ9OyrxMQlHnwrruhcjz9Y=\n=RNuG\n-----END PGP SIGNATURE-----\n"},{"id":"28905","messageId":"4534656B.7080105@utoronto.ca","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610170128350.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-17T05:08:59Z","receivedAt":"2006-10-17T05:08:59Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJohannes Schindelin wrote:\n> On Mon, 16 Oct 2006, Aaron Bentley wrote:\n\n>> Bazaar's namespace is \"simple\" because all branches can be named by a \n>> URL, and all revisions can be named by a URL + a number.\n> \n> How should this cope with a distributed project? IOW how does it deal with \n> \"this revision and that revision are exactly the same\"?\n\nThere are two answers here. One is that the URL + number is UI, not\ninternals. A unique ID is used internally, so that can be compared.\n\nBut to fully ensure that there are no differences, i.e. that no one has\nreused an ID, you can generate a revision testament.\n\n> If I understand you correctly, you are claiming that you are not really \n> identifying a revision, but a revision _at a certain place with a \n> place-dependent number_. This conflicts with my understanding of a \n> revision.\n\nNo, I am claiming that a revision at a certain place with a\nplace-dependent number is one name for a revision, but it may have other\nnames.\n\n>> If that's true of Git, then it certainly has a simple namespace. Using \n>> eight-digit hex values doesn't sound simple to me, though.\n> \n> It depends on your usage. If you want to do anything interesting, like \n> assure that you have the correct version, or assure that two different \n> person's tags actually tag the same revision, there is no simpler \n> representation.\n\nI can use the 'bzr missing' command to check whether my branch is in\nsync with a remote branch. Or I can use the 'pull' command to update my\nbranch to a given revno in a remote branch.\n\n\n>> That sounds right. So those branches are persistent, and can be worked\n>> on independently?\n> \n> Of course! Persistence (and reliability) are the number one goal of git. \n> Performance is the next one.\n\nYou'd be surprised. When we last spoke to the Mercurial team, Mercurial\ndidn't support multiple persistent branches in one repository. Pulling\nfrom a remote repository could join two branches into one. I'm told\nthey're fixing that now.\n\n\n>> You'll note we referred to that bevhavior on the page. We don't think\n>> what Git does is the same as supporting renames. AIUI, some Git users\n>> feel the same way.\n> \n> Oh, we start another flamewar again?\n\nI'd hope not. It sounds as though you feel that supporting renames in\nthe data representation is *wrong*, and therefore it should be an insult\nto you if we said that Git fully supported renames.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNGVq0F+nu1YWqI0RAsXiAJ9hjH2sQGG3E9oIYP2SxscXvVQsJACdHtkj\n+r37JPSjbQCuchPo08P3px8=\n=5MHE\n-----END PGP SIGNATURE-----\n"},{"id":"28906","messageId":"20061017052019.GB21210@spearce.org","threadId":"5925","inReplyTo":"45346290.6050300@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-17T05:20:19Z","receivedAt":"2006-10-17T05:20:19Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Aaron Bentley wrote:\n> Jakub Narebski wrote:\n> > One cannot have universally valid revision numbers (even\n> > only per branch) in distributed development. Subversion can do that only\n> > because it is centralized SCM. Global numbering and distributed nature\n> > doesn't mix... hence contents based sha1 as commit identifiers.\n> \n> Sure. Our UI approach is that unique identifiers can usefully be\n> abstracted away with a combination of URL + number, in the vast majority\n> of cases.\n\nBut this only works when the URL is public. In Git I can just lookup\nthe unique SHA1 for a revision in my private repository and toss it\ninto an email with a quick copy and paste. With Bazaar it sounds\nlike I'd have to do that relative to some known public repository,\nwhich just sounds like more work to me.\n\nBut I don't want to see this otherwise interesting thread devolve into\na \"we do X better!\" match so I'm not going to say anything further here.\n \n> > I wonder if any SCM other than git has easy way to \"rebase\" a branch,\n> > i.e. cut branch at branching point, and transplant it to the tip\n> > of other branch. For example you work on 'xx/topic' topic branch,\n> > and want to have changes in those branch but applied to current work,\n> > not to the version some time ago when you have started working on\n> > said feature.\n> \n> If I understand correctly, in Bazaar, you'd just merge the current work\n> into 'xx/topic'.\n\nGit has two approaches:\n\n - merge: The two independent lines of development are merged\n together under a new single graph node. This is a merge commit\n and has two parent pointers, one for each independent line of\n development which was combined into one. Up to 16 independent\n lines can be merged at once, though 12 is the record.\n\n - rebase: The commits from one line of development are replayed\n onto a totally different line of development. This is often\n used to reapply your changes onto the upstream branch after the\n upstream has changed but before you send your changes upstream.\n It can often generate more readable commit history.\n\nI believe what you are talking about in Bazaar is the former (merge)\nwhile what Jakub was talking about was the latter (rebase).\n \n> > What your comparison matrick lacks for example is if given SCM\n> > saves information about branching point and merges, so you can\n> > get where two branches diverged, and when one branch was merged into\n> > another.\n> \n> I'm not sure what you mean about divergence. For example, Bazaar\n> records the complete ancestry of each branch, and determining the point\n> of divergence is as simple as finding the last common ancestor. But are\n> you considering only the initial divergence? Or if the branches merge\n> and then diverge again, would you consider that the point of divergence?\n\nI'm believe you nailed what Jakub was talking about on the head.\nAnd yes, I noticed its in your matrix but its not very clear.\nI think that some additional explanation there may help other\nreaders.\n \n-- \nShawn.\n"},{"id":"28907","messageId":"87fydn8qe0.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"4534656B.7080105@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-17T05:25:59Z","receivedAt":"2006-10-17T05:25:59Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 01:08:59 -0400, Aaron Bentley wrote:\n> >> If that's true of Git, then it certainly has a simple namespace. Using\n> >> eight-digit hex values doesn't sound simple to me, though.\n> >\n> > It depends on your usage. If you want to do anything interesting, like\n> > assure that you have the correct version, or assure that two different\n> > person's tags actually tag the same revision, there is no simpler\n> > representation.\n>\n> I can use the 'bzr missing' command to check whether my branch is in\n> sync with a remote branch. Or I can use the 'pull' command to update my\n> branch to a given revno in a remote branch.\n\nI think you missed the simplicity of the git naming here. With git, I\ncan receive a bug report that specifies a bug that appears in a\nrevision such as:\n\n\t71037f3612da9d11431567c05c17807499ab1746\n\nAnd since I have a commit object in my repository with that same name\nI have a strong assurance that I am testing the identical software as\nthe bug reporter without me ever needing any access to pull from the\nreporter's repository.\n\nAnd this works in an entirely distributed fashion. Any two users can\nbe certain they are working with identical software on both ends by\nexchanging and comparing a few bytes, (in email, irc, bugzilla, what\nhave you), without any need to refer to a common repository which both\nusers have access to.\n\n-Carl\n\n"},{"id":"28908","messageId":"20061017053106.GC21210@spearce.org","threadId":"5925","inReplyTo":"4534656B.7080105@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-17T05:31:06Z","receivedAt":"2006-10-17T05:31:06Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Aaron Bentley wrote:\n> Johannes Schindelin wrote:\n> > On Mon, 16 Oct 2006, Aaron Bentley wrote:\n> >> You'll note we referred to that bevhavior on the page. We don't think\n> >> what Git does is the same as supporting renames. AIUI, some Git users\n> >> feel the same way.\n> > \n> > Oh, we start another flamewar again?\n> \n> I'd hope not. It sounds as though you feel that supporting renames in\n> the data representation is *wrong*, and therefore it should be an insult\n> to you if we said that Git fully supported renames.\n\nIt would seem that the majority of folks on the Git list feel that\nway, myself among them. I don't know that we'd find it an insult\nto say Git fully supports renames but I do think we have had better\nresults from *not* recording them and looking for them after the\nfact with smart tools.\n\nJunio's recent work with git-pickaxe (or whatever its name finally\nsettles out to be) is a perfect example of this. Despite not having\n\"recorded renames\" git-pickaxe is able to fairly accurately detect\nblocks of code moving between files, of which renaming files is just\na special case. This provides some fairly accurate blame reporting\npointing to exactly which commit/author/datetime put a given line\nof code into the project.\n\nNo additional metadata required. All existing repositories can\nimmediately benefit from the new tool. Rather slick if you ask me.\n\n-- \nShawn.\n"},{"id":"28910","messageId":"7v64ejqx3a.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"4534656B.7080105@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-17T06:23:53Z","receivedAt":"2006-10-17T06:23:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Aaron Bentley writes:\n\n> Johannes Schindelin wrote:\n>\n>>> You'll note we referred to that bevhavior on the page. We don't think\n>>> what Git does is the same as supporting renames. AIUI, some Git users\n>>> feel the same way.\n>> \n>> Oh, we start another flamewar again?\n>\n> I'd hope not. It sounds as though you feel that supporting renames in\n> the data representation is *wrong*, and therefore it should be an insult\n> to you if we said that Git fully supported renames.\n\nNot recording and not supporting are quite different things.\n\nWhat we don't do is to _record_ renames in the data structure.\nI personally would not use a word as strong as _wrong_ (and\nLinus may disagree), but (1) we can support renames without\nrecording them just fine, (2) recording renames would not help\nto tell users about line movements across files which we would\nwant to do, and (3) we are getting closer to come up with a way\nto even do (2) without recording renames. Given these, perhaps\nI might say recording renames is _pointless_ when I am in good\nmood.\n"},{"id":"28912","messageId":"46d6db660610170026i23f53e66sae8fb10ea572712a@mail.gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610161714590.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2006-10-17T07:26:37Z","receivedAt":"2006-10-17T07:26:37Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 10/17/06, Linus Torvalds wrote:\n> Well, you can just add\n>\n> [alias]\n> cat=-p cat-file -p\n>\n> to your ~/.gitconfig file, and you're there.\n\n_WONDERFUL_. Really :)\n\n-- \nChristian\n"},{"id":"28915","messageId":"45348B5E.8000404@op5.se","threadId":"5925","inReplyTo":"45345AEF.6070107@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-17T07:50:54Z","receivedAt":"2006-10-17T07:50:54Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Aaron Bentley wrote:\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> Linus Torvalds wrote:\n>> On Mon, 16 Oct 2006, Aaron Bentley wrote:\n>>> Bazaar's namespace is \"simple\" because all branches can be named by a\n>>> URL, and all revisions can be named by a URL + a number.\n> \n>> I pretty much _guarantee_ that a \"number\" is not a valid way to uniquely \n>> name a revision in a distributed environment, though. I bet the \"number\" \n>> really only names a revision in one _single_ repository, right?\n> \n> Right. That's why I said all revisions can be named by a URL + a\n> number, because it's the combination of the URL + a number that is\n> unique. (In bzr, each branch has a URL.)\n> \n\nThe revision will change between different repos though, so \nrandom-contributor A that doesn't have his repo publicised needs to send \npatches and can't log his exact problem revision somewhere, which makes \nit hard for random contributor B that runs into a similar problem but on \na different project sometime later to find the offending code. I prefer \nthe git way, but I'm a git user and probably biased.\n\nThat said, it shouldn't be impossible to add fixed, user-friendly \nbazaar-like revision numbers for git. We just have to reverse the\n[^~] syntax to also accept +.\n\nThis would work marvelously with serial development but breaks horribly \nwith merges unless the first (or last) commit on each new branch gets \ngiven a tag or some such.\n\nEither way, I'm fairly certain both bazaar and git needs to distribute \ninformation to the user in need of finding the revision (which url and \nwhich number vs which sha). I also imagine that the bazaar users, just \nlike the git users, are sufficiently apt copy-paste people to never \nactually read the prerequisite information.\n\n> \n>> If you give \n>> the SHA1 name, it's well-defined even between different repositories, and \n>> you can tell somebody that \"revision XYZ is when the problem started\", and \n>> they'll know _exactly_ which revision it is, even if they don't have your \n>> particular repository.\n> \n> When two people have copies of the same revision, it's usually because\n> they are each pulling from a common branch, and so the revision in that\n> branch can be named. Bazaar does use unique ids internally, but it's\n> extremely rare that the user needs to use them.\n> \n\nWell, if two people have the same revision in git, you *know* they have \npulled from each other, because ALL objects are immutable. The point of \n\"naming\" the revision is moot, because it's something all SCM's can do.\n\n\n>> Now _that_ is true simplicity. It does automatically mean that the names \n>> are a bit longer, but in this case, \"longer\" really _does_ mean \"simpler\".\n>>\n>> If you want a short, human-readable name, you _tag_ it. It takes all of a \n>> hundredth of a second to to or so.\n> \n> But tags have local meaning only, unless someone has access to your\n> repository, right?\n> \n\nI imagine the bazaar-names with url+number only has local meaning unless \nsomeone has access to your repository too. One of the great benefits of \ngit is that each revision is *always exactly the same* no matter in \nwhich repository it appears. This includes file-content, filesystem \nlayout and, last but also most important, history.\n\n\n>>>> About \"checkouts\", i.e. working directories with repository elsewhere:\n>>>> you can use GIT_DIR environmental variable or \"git --git-dir\" option,\n>>>> or symlinks, and if Nguyen Thai Ngoc D proposal to have .gitdir/.git\n>>>> \"symref\"-like file to point to repository passes, we can use that.\n>>> It sounds like the .gitdir/.git proposal would give Git \"checkouts\", by\n>>> our meaning of the term.\n>> Well, in the git world, it's really just one shared repository that has \n>> separate branch-namespaces, and separate working trees (aka \"checkouts\"). \n>> So yes, it probably matches what bazaar would call a checkout.\n> \n> The key thing about a checkout is that it's stored in a different\n> location from its repository. This provides a few benefits:\n> \n> - - you can publish a repository without publishing its working tree,\n> possibly using standard mirroring tools like rsync.\n> \n\nCan't all scm's do this?\n\n> - - you can have working trees on local systems while having the\n> repository on a remote system. This makes it easy to work on one\n> logical branch from multiple locations, without getting out of sync.\n> \n\nThis I'm not so sure about. Anyone wanna fill out how shallow clones and \nall that jazz works?\n\n> - - you can use a checkout to maintain a local mirror of a read-only\n> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n> \n\nCheck. Well, actually, you just clone it as usual but with the --bare \nargument and it won't write out the working tree files.\n\n>> Almost nobody seems to actually use it that way in git - it's mostly more \n>> efficient to just have five different branches in the same working tree, \n>> and switch between them. When you switch between branches in git, git only \n>> rewrites the part of your working tree that actually changed, so switching \n>> is extremely efficient even with a large repo.\n> \n> You can operate that way in bzr too, but I find it nicer to have one\n> checkout for each active branch, plus a checkout of bzr.dev. Our switch\n> command also rewrites only the changed part of the working tree.\n> \n\nWorks in git as well, but each \"checkout\" (actually, locally referenced \nrepository clone) gets a separate branch/tag namespace.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"28920","messageId":"200610171015.42320.jnareb@gmail.com","threadId":"5925","inReplyTo":"45346290.6050300@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T08:15:41Z","receivedAt":"2006-10-17T08:15:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia wtorek 17. października 2006 06:56, Aaron Bentley napisał:\n> Jakub Narebski wrote:\n> > Well, ~ means -th _parent_ of a given ref, which for branches\n> > (which constantly change) is a moving target.\n> \n> Ah. Bazaar uses negative numbers to refer to th parents, and\n> positive numbers to refer to the number of commits that have been made\n> since the branch was initialized.\n> \n> > One cannot have universally valid revision numbers (even\n> > only per branch) in distributed development. Subversion can do that only\n> > because it is centralized SCM. Global numbering and distributed nature\n> > doesn't mix... hence contents based sha1 as commit identifiers.\n> \n> Sure. Our UI approach is that unique identifiers can usefully be\n> abstracted away with a combination of URL + number, in the vast majority\n> of cases.\n> \n> > But this doesn't matter much, because you can have really lightweight\n> > tags in git (especially now with packed refs support). So you can have\n> > the namespace you want.\n> \n> The nice thing about revision numbers is that they're implicit-- no one\n> needs to take any action to update them, and so you can always use them.\n> \n> > I wonder if any SCM other than git has easy way to \"rebase\" a branch,\n> > i.e. cut branch at branching point, and transplant it to the tip\n> > of other branch. For example you work on 'xx/topic' topic branch,\n> > and want to have changes in those branch but applied to current work,\n> > not to the version some time ago when you have started working on\n> > said feature.\n> \n> If I understand correctly, in Bazaar, you'd just merge the current work\n> into 'xx/topic'.\n> \n> > What your comparison matrick lacks for example is if given SCM\n> > saves information about branching point and merges, so you can\n> > get where two branches diverged, and when one branch was merged into\n> > another.\n> \n> I'm not sure what you mean about divergence. For example, Bazaar\n> records the complete ancestry of each branch, and determining the point\n> of divergence is as simple as finding the last common ancestor. But are\n> you considering only the initial divergence? Or if the branches merge\n> and then diverge again, would you consider that the point of divergence?\n> \n> merge-point tracking is a prerequisite for Smart Merge, which does\n> appear on our matrix.\n> \n> > Plugins = API + detection ifrastructure + loading on demand.\n> > Git has API, has a kind of detection ifrastructure (for commands and\n> > merge strategies only), doesn't have loading on demand. You can\n> > easily provide new commands (thanks to git wrapper) and new merge\n> > strategies.\n> \n> I'm not sure what you mean by API, unless you mean the commandline. If\n> that's what you mean, surely all unix commands are extensible in that\n> regard.\n> \n> Aaron\n> \n"},{"id":"28916","messageId":"45349162.90001@op5.se","threadId":"5925","inReplyTo":"45346290.6050300@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-17T08:16:34Z","receivedAt":"2006-10-17T08:16:34Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Aaron Bentley wrote:\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> Jakub Narebski wrote:\n>> Well, ~ means -th _parent_ of a given ref, which for branches\n>> (which constantly change) is a moving target.\n> \n> Ah. Bazaar uses negative numbers to refer to th parents, and\n> positive numbers to refer to the number of commits that have been made\n> since the branch was initialized.\n> \n\nWhat do you do once a branch has been thrown away, or has had 20 other \nbranches merged into it? Does the offset-number change for the revision \nthen, or do you track branch-points explicitly?\n\n>> One cannot have universally valid revision numbers (even\n>> only per branch) in distributed development. Subversion can do that only\n>> because it is centralized SCM. Global numbering and distributed nature\n>> doesn't mix... hence contents based sha1 as commit identifiers.\n> \n> Sure. Our UI approach is that unique identifiers can usefully be\n> abstracted away with a combination of URL + number, in the vast majority\n> of cases.\n> \n>> But this doesn't matter much, because you can have really lightweight\n>> tags in git (especially now with packed refs support). So you can have\n>> the namespace you want.\n> \n> The nice thing about revision numbers is that they're implicit-- no one\n> needs to take any action to update them, and so you can always use them.\n> \n>> I wonder if any SCM other than git has easy way to \"rebase\" a branch,\n>> i.e. cut branch at branching point, and transplant it to the tip\n>> of other branch. For example you work on 'xx/topic' topic branch,\n>> and want to have changes in those branch but applied to current work,\n>> not to the version some time ago when you have started working on\n>> said feature.\n> \n> If I understand correctly, in Bazaar, you'd just merge the current work\n> into 'xx/topic'.\n> \n\nmerge != rebase though, although they are indeed similar. Let's take the \nexample of a 'master' branch and topic branch topicA. If you rebase \ntopicA onto 'master', development will appear to have been serial. If \nyou instead merge them, it will either register as a real merge or, if \nthe branch tip of 'master' is the branch start-point of topicA, it will \nresult in a \"fast-forward\" where 'master' is just updated to the \nbranch-tip of 'topicA'.\n\n>> What your comparison matrick lacks for example is if given SCM\n>> saves information about branching point and merges, so you can\n>> get where two branches diverged, and when one branch was merged into\n>> another.\n> \n> I'm not sure what you mean about divergence. For example, Bazaar\n> records the complete ancestry of each branch, and determining the point\n> of divergence is as simple as finding the last common ancestor. But are\n> you considering only the initial divergence? Or if the branches merge\n> and then diverge again, would you consider that the point of divergence?\n> \n> merge-point tracking is a prerequisite for Smart Merge, which does\n> appear on our matrix.\n> \n>> Plugins = API + detection ifrastructure + loading on demand.\n>> Git has API, has a kind of detection ifrastructure (for commands and\n>> merge strategies only), doesn't have loading on demand. You can\n>> easily provide new commands (thanks to git wrapper) and new merge\n>> strategies.\n> \n> I'm not sure what you mean by API, unless you mean the commandline. If\n> that's what you mean, surely all unix commands are extensible in that\n> regard.\n> \n\nI'm fairly certain he's talking about the API in the sense it's being \ntalked about in every other application. Extensive work has been made to \nlibify a lot of the git code, which means that most git commands are \nmade up of less than 400 lines of C code, where roughly 80% of the code \nis command-specific (i.e., argument parsing and presentation).\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"28918","messageId":"20061017082159.GB5215@sourcefrog.net","threadId":"5925","inReplyTo":"20061017052019.GB21210@spearce.org","subject":"Re: VCS comparison table","fromName":"Martin Pool","fromEmail":"mbp@sourcefrog.net","sentAt":"2006-10-17T08:21:59Z","receivedAt":"2006-10-17T08:21:59Z","isPatch":false,"sender":{"key":"mbp@sourcefrog.net","avatar":null},"body":"On 17 Oct 2006, Shawn Pearce wrote:\n> Aaron Bentley wrote:\n> > Jakub Narebski wrote:\n> > > One cannot have universally valid revision numbers (even\n> > > only per branch) in distributed development. Subversion can do that only\n> > > because it is centralized SCM. Global numbering and distributed nature\n> > > doesn't mix... hence contents based sha1 as commit identifiers.\n> > \n> > Sure. Our UI approach is that unique identifiers can usefully be\n> > abstracted away with a combination of URL + number, in the vast majority\n> > of cases.\n> \n> But this only works when the URL is public. In Git I can just lookup\n> the unique SHA1 for a revision in my private repository and toss it\n> into an email with a quick copy and paste. \n\nYes, but then people need to know how to get it out of your private\nrepository. For stuff that goes into well-known repositories I suppose\nit just propagates.\n\n> With Bazaar it sounds like I'd have to do that relative to some known\n> public repository, which just sounds like more work to me.\n\nYou can also name a revision using its UUID, in which case things will\nwork similarly to git. We tend to often say \"in r1234 of dev\".\n\n> But I don't want to see this otherwise interesting thread devolve into\n> a \"we do X better!\" match so I'm not going to say anything further here.\n\nSure.\n\n> > > I wonder if any SCM other than git has easy way to \"rebase\" a branch,\n> > > i.e. cut branch at branching point, and transplant it to the tip\n> > > of other branch. For example you work on 'xx/topic' topic branch,\n> > > and want to have changes in those branch but applied to current work,\n> > > not to the version some time ago when you have started working on\n> > > said feature.\n> > \n> > If I understand correctly, in Bazaar, you'd just merge the current work\n> > into 'xx/topic'.\n> \n> Git has two approaches:\n> \n> - merge: The two independent lines of development are merged\n> together under a new single graph node. This is a merge commit\n> and has two parent pointers, one for each independent line of\n> development which was combined into one. Up to 16 independent\n> lines can be merged at once, though 12 is the record.\n> \n> - rebase: The commits from one line of development are replayed\n> onto a totally different line of development. This is often\n> used to reapply your changes onto the upstream branch after the\n> upstream has changed but before you send your changes upstream.\n> It can often generate more readable commit history.\n> \n> I believe what you are talking about in Bazaar is the former (merge)\n> while what Jakub was talking about was the latter (rebase).\n\nFor the 'rebase' operation in Bazaar you can use 'bzr graft':\n\n http://spacepants.org/src/bzrgraft/\n\n-- \nMartin\n"},{"id":"28919","messageId":"200610171030.35854.jnareb@gmail.com","threadId":"5925","inReplyTo":"45345AEF.6070107@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T08:30:35Z","receivedAt":"2006-10-17T08:30:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> Linus Torvalds wrote:\n\n>> If you want a short, human-readable name, you _tag_ it. It takes all of a\n>> hundredth of a second to to or so.\n> \n> But tags have local meaning only, unless someone has access to your\n> repository, right?\n\nTags are propagated during clone, and during fetch/pull (getting changes\nfrom repository). So in that sense they are global.\n\nIf you don't publish your repository, then neither tags, nor +\nhas any sense, any meaning to somebody other than local private repository.\n \n\n>> Well, in the git world, it's really just one shared repository that has\n>> separate branch-namespaces, and separate working trees (aka \"checkouts\").\n>> So yes, it probably matches what bazaar would call a checkout.\n> \n> The key thing about a checkout is that it's stored in a different\n> location from its repository. This provides a few benefits:\n> \n> - you can publish a repository without publishing its working tree,\n> possibly using standard mirroring tools like rsync.\n\ngit clone --bare\n \n> - you can have working trees on local systems while having the\n> repository on a remote system. This makes it easy to work on one\n> logical branch from multiple locations, without getting out of sync.\n\nIn git we usually use \"git clone --local\" (with repository database\nhardlinked) or \"git clone --shared\"/\"git clone --reference \"\n(which automatically sets alternates, i.e. file pointing to alternate\nrepository database) for that. This way one gets his/her own refs\nnamespace, so two people can work on different branches simultaneously.\n\nAlternate solution would be to symlink .git, or .git/objects (i.e.\nrepository \"database\").\n\n> - you can use a checkout to maintain a local mirror of a read-only\n> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n\nIn git you can access contents _without_ checkout/working area.\nFor example gitweb (one of git's web interfaces) uses only repository\ndatabase and doesn't need checkout/working area.\n\n>> Almost nobody seems to actually use it that way in git - it's mostly more\n>> efficient to just have five different branches in the same working tree,\n>> and switch between them. When you switch between branches in git, git only\n>> rewrites the part of your working tree that actually changed, so switching\n>> is extremely efficient even with a large repo.\n> \n> You can operate that way in bzr too, but I find it nicer to have one\n> checkout for each active branch, plus a checkout of bzr.dev. Our switch\n> command also rewrites only the changed part of the working tree.\n\nLuben (IIRC) works this way.\n"},{"id":"28923","messageId":"200610171120.09747.jnareb@gmail.com","threadId":"5925","inReplyTo":"45346290.6050300@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T09:20:09Z","receivedAt":"2006-10-17T09:20:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> Jakub Narebski wrote:\n>> Well, ~ means -th _parent_ of a given ref, which for branches\n>> (which constantly change) is a moving target.\n> \n> Ah. Bazaar uses negative numbers to refer to th parents, and\n> positive numbers to refer to the number of commits that have been made\n> since the branch was initialized.\n\nHow that works with branching point, and with merges? For example\nin the case depicted below, how you refer to commit marked by X?\n\n ---- time --->\n\n --*--*--*--*--*--*--*--*--*-- \n \\ /\n \\-*--X--*--/\n\nThe branch it used to be on is gone...\n\n\nBesides, in git commit object has pointers (in the form of sha1 ids)\nto all its parents. So ^ (parent of ), or ^ (m-th\nparent of ), or ~ (n-th parent in 1st-parent lineage\nof ) are natural, and fast. + (which would add yet another\ncharacter as forbidden in branch name) would need either serial number\n(per repository or per branch) to commit id database, or getting full\nhistory and looking it up in full history.\n\nBranches in git are remembered not by their starting points, but by\ntheir tips (ending points).\n\n>> One cannot have universally valid revision numbers (even\n>> only per branch) in distributed development. Subversion can do that\n>> only because it is centralized SCM. Global numbering and distributed\n>> nature doesn't mix... hence contents based sha1 as commit identifiers.\n> \n> Sure. Our UI approach is that unique identifiers can usefully be\n> abstracted away with a combination of URL + number, in the vast\n> majority of cases.\n\nGit could do that too, by having file (files) with serial number\nor branch/tag+serial number to commit id mapping. But this would\nhave to be local matter. And this would take some disk space, and\nwould seriously affect fetch performance (now git just downloads\nwhat it doesn't have and dumps it into repository database).\n\nBTW. what if repository is moved from one URL to another, for example\nmoving to different host? All \"abstracted away\" identifiers get\ninvalidated?\n\n>> But this doesn't matter much, because you can have really lightweight\n>> tags in git (especially now with packed refs support). So you can have\n>> the namespace you want.\n> \n> The nice thing about revision numbers is that they're implicit-- no one\n> needs to take any action to update them, and so you can always use them.\n\nTwo words: post-commit hook. You can automate action of adding tags\n(especially now with packed refs, which means that we can have huge number\nof tags and this doesn't affect performance doue to I/O nor repository size)\n\n>> I wonder if any SCM other than git has easy way to \"rebase\" a branch,\n>> i.e. cut branch at branching point, and transplant it to the tip\n>> of other branch. For example you work on 'xx/topic' topic branch,\n>> and want to have changes in those branch but applied to current work,\n>> not to the version some time ago when you have started working on\n>> said feature.\n> \n> If I understand correctly, in Bazaar, you'd just merge the current work\n> into 'xx/topic'.\n\nThat is the alternate solution, but this would mean that merge would be\nrecorded (unless you squash it). And for published branches (like 'next'\nfor example) it is better solution, because rebase is in fact rewriting\nhistory.\n\nBut rebase means that you had\n\n A---B---C topic\n /\n D---E---F---G master\n\nRebasing 'topic' branch on top of master would mean that you would get\n\n A'--B'--C' topic\n /\n D---E---F---G master\n\nwhere A', B', C' represent the same changeset as A, B, C up to resolved\nconflicts.\n\nAnd yes, that is \"bzr graft\"\n http://spacepants.org/src/bzrgraft/\nequivalent. Do I understand correctly that this is third-party\ncontribution?\n\n>> What your comparison matrick lacks for example is if given SCM\n>> saves information about branching point and merges, so you can\n>> get where two branches diverged, and when one branch was merged into\n>> another.\n> \n> I'm not sure what you mean about divergence. For example, Bazaar\n> records the complete ancestry of each branch, and determining the point\n> of divergence is as simple as finding the last common ancestor. But are\n> you considering only the initial divergence? Or if the branches merge\n> and then diverge again, would you consider that the point of divergence?\n> \n> merge-point tracking is a prerequisite for Smart Merge, which does\n> appear on our matrix.\n\nI was talking about point-of-divergence (branching point, fork point)\ntracking, and merge-point tracking (or saving merge information).\n\n>> Plugins = API + detection ifrastructure + loading on demand.\n>> Git has API, has a kind of detection ifrastructure (for commands and\n>> merge strategies only), doesn't have loading on demand. You can\n>> easily provide new commands (thanks to git wrapper) and new merge\n>> strategies.\n> \n> I'm not sure what you mean by API, unless you mean the commandline. If\n> that's what you mean, surely all unix commands are extensible in that\n> regard.\n\nI mean API in the most common sense. \n\nFor commands written in C it means \"engine\" (plumbing) functions and\ndata structures which do most work, so writing new command means some\ncommand specific code and calling some functions to do the work.\n\nFor commands written in shell it means having versatile plumbing\ncommands (like for example git-rev-parse, git-rev-list, git-merge-base,\ngit-cat-file, etc.) which can be joined together including pipes\n(--stdin option, --revs option to some commands), and git-sh-setup,\ncommon git shell setup code. \n\nFor commands writtent in Perl it means the same, with Git.pm module\ninstead of git-sh-setup.\n\n\nAbout new command detection: if you put program named git-\nin directory with the rest of git commands, then you can call it\nas \"git \" using git wrapper. I think.\n\nAbout adding new merge strategies: no autodoetection, you would\nhave to add new merge strategu to git-merge.sh.\n-- \nJakub Narebski\nPoland\n"},{"id":"28925","messageId":"1161077599.9020.66.camel@localhost.localdomain","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610170128350.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Robert Collins","fromEmail":"robertc@robertcollins.net","sentAt":"2006-10-17T09:33:19Z","receivedAt":"2006-10-17T09:33:19Z","isPatch":false,"sender":{"key":"robertc@robertcollins.net","avatar":null},"body":"On Tue, 2006-10-17 at 01:45 +0200, Johannes Schindelin wrote:\n> \n> If you really, really think about it: it makes much more sense to\n> record \n> your intention in the commit message. So, instead of recording for\n> _every_ \n> _single_ file in folder1/ that it was moved to folder2/, it is better\n> to \n> say that you moved folder1/ to folder2/ _because of some special\n> reason_!\n\nJust a small nit here: bzr does /not/ record the move of every file: it\nrecords the rename of folder1 to folder2. One piece of data is all thats\nrecorded - no new manifest for the subdirectory is needed.\n\nOf course, a user can choose to move all the contents of a folder and\nnot the folder itself - its up to the user.\n\nBy recording the folder rename rather than the contents rename, we get\nmerges of new files added to folder1 in other branches come into folder2\nautomatically, without needing to do arbitrarily deep history processing\nto determine that.\n\nThis also does not prevent us doing history analysis as well, to\ndetermine other interesting things - such as cross file 'blame' as has\nbeen mentioned in this thread. \n\n-Rob\n-- \nGPG key available at: .\n"},{"id":"28926","messageId":"1161077866.9020.69.camel@localhost.localdomain","threadId":"5925","inReplyTo":"200610170119.09066.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Robert Collins","fromEmail":"robertc@robertcollins.net","sentAt":"2006-10-17T09:37:45Z","receivedAt":"2006-10-17T09:37:45Z","isPatch":false,"sender":{"key":"robertc@robertcollins.net","avatar":null},"body":"On Tue, 2006-10-17 at 01:19 +0200, Jakub Narebski wrote:\n> \n> I wonder if any SCM other than git has easy way to \"rebase\" a branch,\n> i.e. cut branch at branching point, and transplant it to the tip\n> of other branch. For example you work on 'xx/topic' topic branch,\n> and want to have changes in those branch but applied to current work,\n> not to the version some time ago when you have started working on\n> said feature. \n\nPrecisely how does this rebase operate in git ? \nDoes it preserve revision ids for the existing work, or do they all\nchange?\n\n\nbzr has a graft plugin which walks one branch applying all its changes\nto another preserving the users metadata but changing the uuids for\nrevisions. \n\n-Rob\n\n-- \nGPG key available at: .\n"},{"id":"28927","messageId":"1161078035.9020.73.camel@localhost.localdomain","threadId":"5925","inReplyTo":"200610171120.09747.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Robert Collins","fromEmail":"robertc@robertcollins.net","sentAt":"2006-10-17T09:40:34Z","receivedAt":"2006-10-17T09:40:34Z","isPatch":false,"sender":{"key":"robertc@robertcollins.net","avatar":null},"body":"On Tue, 2006-10-17 at 11:20 +0200, Jakub Narebski wrote:\n> \n> ---- time --->\n> \n> --*--*--*--*--*--*--*--*--*-- \n> \\ /\n> \\-*--X--*--/\n> \n> The branch it used to be on is gone...\n\nIn bzr 0.12 this is :\n2.1.2\n\n(assuming the first * is numbered '1'.)\n\nThese numbers are fairly stable, in particular everything's number in\nthe mainline will be the same number in all the branches created from it\nat that point in time, but a branch that initially creates a revision or\nobtains it before the mainline will have a different number until they\nsyncronise with the mainline via pull.\n\n-Rob\n-- \nGPG key available at: .\n"},{"id":"28928","messageId":"eh28mn$3vh$1@sea.gmane.org","threadId":"5925","inReplyTo":"1161077599.9020.66.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T09:45:25Z","receivedAt":"2006-10-17T09:45:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Robert Collins wrote:\n\n> On Tue, 2006-10-17 at 01:45 +0200, Johannes Schindelin wrote:\n>> \n>> If you really, really think about it: it makes much more sense to record \n>> your intention in the commit message. So, instead of recording for _every_ \n>> _single_ file in folder1/ that it was moved to folder2/, it is better to \n>> say that you moved folder1/ to folder2/ _because of some special\n>> reason_!\n> \n> Just a small nit here: bzr does /not/ record the move of every file: it\n> records the rename of folder1 to folder2. One piece of data is all thats\n> recorded - no new manifest for the subdirectory is needed.\n> \n> Of course, a user can choose to move all the contents of a folder and\n> not the folder itself - its up to the user.\n> \n> By recording the folder rename rather than the contents rename, we get\n> merges of new files added to folder1 in other branches come into folder2\n> automatically, without needing to do arbitrarily deep history processing\n> to determine that.\n\nHmmm... I wonder how well git manages that (merge with renamed directory).\n\n folder1/a --> folder2/a --------> folder2/a\n folder1/b --> folder2/b / folder2/b\n \\ / folder2/c\n \\-------> folder1/a ---/\n folder1/b\n folder1/c\n\n\nI wonder how bzr manages \"separate some files into subdirectory\" (and how\nwell git does that), i.e. we have\n\n sub-file1\n sub-file2\n filea\n fileb\n\nIn the 'main' branch we separated \"sub-*\" files into subdirectory\n\n sub/file1\n sub/file2\n filea\n fileb\n\nHow would that merge with adding new sub-* file on the branch to be merged?\n\n sub-file1\n sub-file2\n sub-file3\n filea\n fileb\n\n\nOr how bzr manages sub-level movement, such as splitting file into two,\nor joining two files into one file.\n\n\nP.S. is anyone working on --follow option for renames following path\nlimiting?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28929","messageId":"4534A99D.4060208@op5.se","threadId":"5925","inReplyTo":"200610171120.09747.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-17T09:59:57Z","receivedAt":"2006-10-17T09:59:57Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> \n> About new command detection: if you put program named git-\n> in directory with the rest of git commands, then you can call it\n> as \"git \" using git wrapper. I think.\n> \n\nYup. The new command will also automagically appear in the \"git help -a\" \noutput. Those two functions have been available since the C wrapper was \nborn, although \"git help -a\" was the only available output for \"command \nnot found\" until someone introduced the more newbie-friendly list that \npops up now adays.\n"},{"id":"28930","messageId":"BAYC1-PASMTP07B8250B054F5CFF48C8C0AE0E0@CEZ.ICE","threadId":"5925","inReplyTo":"1161077866.9020.69.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T10:01:12Z","receivedAt":"2006-10-17T10:01:12Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 19:37:45 +1000\nRobert Collins wrote:\n\n> Precisely how does this rebase operate in git ? \n> Does it preserve revision ids for the existing work, or do they all\n> change?\n> \n> bzr has a graft plugin which walks one branch applying all its changes\n> to another preserving the users metadata but changing the uuids for\n> revisions. \n\ngit rebase does exactly the same as you describe, including changing\nthe sha1 for each commit it moves.\n\nSean\n"},{"id":"29297","messageId":"20061017060112.2d036f96.seanlkml__10841.6940704503$1161331464$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"1161077866.9020.69.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T10:01:12Z","receivedAt":"2006-10-17T10:01:12Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 19:37:45 +1000\nRobert Collins wrote:\n\n> Precisely how does this rebase operate in git ? \n> Does it preserve revision ids for the existing work, or do they all\n> change?\n> \n> bzr has a graft plugin which walks one branch applying all its changes\n> to another preserving the users metadata but changing the uuids for\n> revisions. \n\ngit rebase does exactly the same as you describe, including changing\nthe sha1 for each commit it moves.\n\nSean\n"},{"id":"28931","messageId":"eh29u4$8r1$1@sea.gmane.org","threadId":"5925","inReplyTo":"1161077866.9020.69.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T10:06:26Z","receivedAt":"2006-10-17T10:06:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Robert Collins wrote:\n\n> On Tue, 2006-10-17 at 01:19 +0200, Jakub Narebski wrote:\n>> \n>> I wonder if any SCM other than git has easy way to \"rebase\" a branch,\n>> i.e. cut branch at branching point, and transplant it to the tip\n>> of other branch. For example you work on 'xx/topic' topic branch,\n>> and want to have changes in those branch but applied to current work,\n>> not to the version some time ago when you have started working on\n>> said feature. \n> \n> Precisely how does this rebase operate in git ? \n> Does it preserve revision ids for the existing work, or do they all\n> change?\n\nRevision ids (commit ids) change of course. Therefore rebasing published\nbranches is not recommended, as it is in fact rewriting history.\n\nIt is however recommended before sending _series_ of patches (work on that\nseries should be done using topic branch) to rebase topic branch they sit\non for the patches to apply cleanly on top of current work. Or use StGit or\nother Quilt (patch management) equivalent.\n\n> bzr has a graft plugin which walks one branch applying all its changes\n> to another preserving the users metadata but changing the uuids for\n> revisions. \n\nThis looks like \"bzr graft\" is the same as \"git rebase\". It can deal with\nconflict, cannot it?\n\n\nP.S. It looks like we have yet another terminology conflict. In git \"graft\"\nmeans \"history graft\" i.e. file which changes parents of some commits. For\nexample if we have historical repositoy and current repositoy we can join\ntogether using grafts (otherwise we would need to rewrite history, as sha1\nwhich serves as commit id includes parents information), e.g.\n\n x--*--*--*--*....x--*--*--*--*\n\n historical current\n\nwhere 'x' is 'root' (parentless) commit, '--' denotes parentship, and '....'\ndenotes \"history graft\". \n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28932","messageId":"4534AB8B.8030505@op5.se","threadId":"5925","inReplyTo":"1161078035.9020.73.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-17T10:08:11Z","receivedAt":"2006-10-17T10:08:11Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Robert Collins wrote:\n> On Tue, 2006-10-17 at 11:20 +0200, Jakub Narebski wrote:\n>> ---- time --->\n>>\n>> --*--*--*--*--*--*--*--*--*-- \n>> \\ /\n>> \\-*--X--*--/\n>>\n>> The branch it used to be on is gone...\n> \n> In bzr 0.12 this is :\n> 2.1.2\n> \n\nWould it be a different number in a different version of bazaar?\n\n> (assuming the first * is numbered '1'.)\n> \n> These numbers are fairly stable, in particular everything's number in\n> the mainline will be the same number in all the branches created from it\n> at that point in time, but a branch that initially creates a revision or\n> obtains it before the mainline will have a different number until they\n> syncronise with the mainline via pull.\n> \n\nSo basically anyone can pull/push from/to each other but only so long as \nthey decide upon a common master that handles synchronizing of the \nnumber part of the url+number revision short-hands?\n\nOne thing that's been nagging me is how you actually find out the \nurl+number where the desired revision exists. That is, after you've \nsynced with master, or merged the mothership's master-branch into one of \nyour experimental branches where you've done some work that went before \nmothership's master's current tip, do you have to have access to the \nmothership's repo (as in, do you have to be online) to find out the \nnumber part of url+number shorthand, or can you determine it solely from \nwhat you have on your laptop?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"28933","messageId":"BAYC1-PASMTP08A746E5FA6B87BC65BD37AE0E0@CEZ.ICE","threadId":"5925","inReplyTo":"45345AEF.6070107@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T10:23:13Z","receivedAt":"2006-10-17T10:23:13Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 00:24:15 -0400\nAaron Bentley wrote:\n\n> The key thing about a checkout is that it's stored in a different\n> location from its repository. This provides a few benefits:\n> \n> - - you can publish a repository without publishing its working tree,\n> possibly using standard mirroring tools like rsync.\n\nYeah, even in git you typically don't publish your working tree when\nmaking it available for cloning. In fact the native git network\nprotocol doesn't even have a way to transfer working trees.\n\n> - - you can have working trees on local systems while having the\n> repository on a remote system. This makes it easy to work on one\n> logical branch from multiple locations, without getting out of sync.\n\nThat is a very nice feature. Git would be improved if it could\nsupport that mode of operation as well.\n\n> - - you can use a checkout to maintain a local mirror of a read-only\n> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n\nI'm not sure what you mean here. A bzr checkout doesn't have any history\ndoes it? So it's not a mirror of a branch, but just a checkout of the\nbranch head?\n\nIf so, Git can export a tarball of a branch (actually a snapshot as at\nany given commit) which can be mirrored out.\n\nSean\n"},{"id":"29298","messageId":"20061017062313.cd41e031.seanlkml__18990.3019847863$1161331470$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"45345AEF.6070107@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T10:23:13Z","receivedAt":"2006-10-17T10:23:13Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 00:24:15 -0400\nAaron Bentley wrote:\n\n> The key thing about a checkout is that it's stored in a different\n> location from its repository. This provides a few benefits:\n> \n> - - you can publish a repository without publishing its working tree,\n> possibly using standard mirroring tools like rsync.\n\nYeah, even in git you typically don't publish your working tree when\nmaking it available for cloning. In fact the native git network\nprotocol doesn't even have a way to transfer working trees.\n\n> - - you can have working trees on local systems while having the\n> repository on a remote system. This makes it easy to work on one\n> logical branch from multiple locations, without getting out of sync.\n\nThat is a very nice feature. Git would be improved if it could\nsupport that mode of operation as well.\n\n> - - you can use a checkout to maintain a local mirror of a read-only\n> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n\nI'm not sure what you mean here. A bzr checkout doesn't have any history\ndoes it? So it's not a mirror of a branch, but just a checkout of the\nbranch head?\n\nIf so, Git can export a tarball of a branch (actually a snapshot as at\nany given commit) which can be mirrored out.\n\nSean\n"},{"id":"28934","messageId":"BAYC1-PASMTP07106914CF555DFBBE4746AE0E0@CEZ.ICE","threadId":"5925","inReplyTo":"4534656B.7080105@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T10:23:41Z","receivedAt":"2006-10-17T10:23:41Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 01:08:59 -0400\nAaron Bentley wrote:\n\n> I can use the 'bzr missing' command to check whether my branch is in\n> sync with a remote branch. Or I can use the 'pull' command to update my\n> branch to a given revno in a remote branch.\n\nThe \"bzr missing\" command sounds like a handy one. \n\nSomeone on the xorg mailing list was recently lamenting that git does not\nhave an easy way to compare a local branch to a remote one. While this\nturns out to not be a big problem in git, it might be nice to have such\na command.\n\nSean\n"},{"id":"29299","messageId":"20061017062341.8a5c8530.seanlkml__27004.7138831162$1161331474$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"4534656B.7080105@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T10:23:41Z","receivedAt":"2006-10-17T10:23:41Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 01:08:59 -0400\nAaron Bentley wrote:\n\n> I can use the 'bzr missing' command to check whether my branch is in\n> sync with a remote branch. Or I can use the 'pull' command to update my\n> branch to a given revno in a remote branch.\n\nThe \"bzr missing\" command sounds like a handy one. \n\nSomeone on the xorg mailing list was recently lamenting that git does not\nhave an easy way to compare a local branch to a remote one. While this\nturns out to not be a big problem in git, it might be nice to have such\na command.\n\nSean\n"},{"id":"28935","messageId":"Pine.LNX.4.63.0610171229160.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"BAYC1-PASMTP08A746E5FA6B87BC65BD37AE0E0@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-17T10:30:27Z","receivedAt":"2006-10-17T10:30:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 17 Oct 2006, Sean wrote:\n\n> On Tue, 17 Oct 2006 00:24:15 -0400\n> Aaron Bentley wrote:\n> \n> > - - you can have working trees on local systems while having the\n> > repository on a remote system. This makes it easy to work on one\n> > logical branch from multiple locations, without getting out of sync.\n> \n> That is a very nice feature. Git would be improved if it could\n> support that mode of operation as well.\n\nIt would also make things slow as hell. How do you deal with something \nlike annotate in such a setup?\n\nCiao,\nDscho\n"},{"id":"28936","messageId":"BAYC1-PASMTP113CCEFC514ABBD0E38D77AE0E0@CEZ.ICE","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610171229160.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T10:35:49Z","receivedAt":"2006-10-17T10:35:49Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 12:30:27 +0200 (CEST)\nJohannes Schindelin wrote:\n\n> It would also make things slow as hell. How do you deal with something \n> like annotate in such a setup?\n\nSome commands like annotate might not make any sense in such a set up.\n\nBut one way to get the same (perhaps even better) feature into git \nwould be to support shallow clones, in which case even annotate would\ncontinue to work even if somewhat crippled by the lack of a complete\nhistory.\n\nSean\n"},{"id":"29300","messageId":"20061017063549.da130b5f.seanlkml__22659.4742890031$1161331475$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610171229160.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T10:35:49Z","receivedAt":"2006-10-17T10:35:49Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 12:30:27 +0200 (CEST)\nJohannes Schindelin wrote:\n\n> It would also make things slow as hell. How do you deal with something \n> like annotate in such a setup?\n\nSome commands like annotate might not make any sense in such a set up.\n\nBut one way to get the same (perhaps even better) feature into git \nwould be to support shallow clones, in which case even annotate would\ncontinue to work even if somewhat crippled by the lack of a complete\nhistory.\n\nSean\n"},{"id":"28938","messageId":"1161081933.26677.35.camel@localhost.localdomain","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610171229160.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Matthias Kestenholz","fromEmail":"lists@spinlock.ch","sentAt":"2006-10-17T10:45:33Z","receivedAt":"2006-10-17T10:45:33Z","isPatch":false,"sender":{"key":"lists@spinlock.ch","avatar":null},"body":"Hi,\n\nOn Tue, 2006-10-17 at 12:30 +0200, Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 17 Oct 2006, Sean wrote:\n> \n> > On Tue, 17 Oct 2006 00:24:15 -0400\n> > Aaron Bentley wrote:\n> > \n> > > - - you can have working trees on local systems while having the\n> > > repository on a remote system. This makes it easy to work on one\n> > > logical branch from multiple locations, without getting out of sync.\n> > \n> > That is a very nice feature. Git would be improved if it could\n> > support that mode of operation as well.\n> \n> It would also make things slow as hell. How do you deal with something \n> like annotate in such a setup?\n\nYou'd probably have to do all processing server-side (git log, blame,\nmerges... like in subversion, where you can merge and rename/move files\nremotely, IIRC). Of course, all the things which make git really useful\nfor me (gitk, git log with all its arguments etc.) would not be\navailable. Cheap checkouts would be made possible easily that way at the\ncost of higher server load and an abstraction layer over network for\nobject access.\n\nI don't know if that sounds reasonable at all.\n\n\tMatthias\n"},{"id":"28939","messageId":"vpqirij6wxd.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"4534AB8B.8030505@op5.se","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-17T10:47:42Z","receivedAt":"2006-10-17T10:47:42Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Andreas Ericsson writes:\n\n> Robert Collins wrote:\n>> On Tue, 2006-10-17 at 11:20 +0200, Jakub Narebski wrote:\n>>> ---- time --->\n>>>\n>>> --*--*--*--*--*--*--*--*--*-- \n>>> \\ /\n>>> \\-*--X--*--/\n>>>\n>>> The branch it used to be on is gone...\n>>\n>> In bzr 0.12 this is :\n>> 2.1.2\n>>\n>\n> Would it be a different number in a different version of bazaar?\n\nI can't say for bzr 0.>12 which do not exist ;-)\n\nFor previous versions, it didn't have that \"simple\" number, and you\nhad to use the rev-id.\n\n-- \nMatthieu\n"},{"id":"28942","messageId":"vpqejt76vgz.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"200610171030.35854.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-17T11:19:08Z","receivedAt":"2006-10-17T11:19:08Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n>> - you can use a checkout to maintain a local mirror of a read-only\n>> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n>\n> In git you can access contents _without_ checkout/working area.\n\nBazaar can do this too. For example,\n\"bzr cat http://something -r some-revision\" gets the content of a file\nat a given revision. But that's not what Aaron was refering to.\n\nIn Bazaar, checkouts can be two things:\n\n1) a working tree without any history information, pointing to some\n other location for the history itself (a la svn/CVS/...).\n (this is \"light checkout\")\n\n2) a bound branch. It's not _very_ different from a normal branch, but\n mostly \"commit\" behaves differently:\n - it commits both on the local and the remote branch (equivalent to\n \"commit\" + \"push\", but in a transactional way).\n - it refuses to commit if you're out of date with the branch you're\n bound to.\n (this is \"heavy checkout\")\n\nIn both cases, this has the side effect that you can't commit if the\n\"upstream\" branch is read-only. That's not fundamental, but handy.\n\nI use it for example to have several \"checkouts\" of the same branch on\ndifferent machines. When I commit, bzr tells me \"hey, boss, you're out\nof date, why don't you update first\" if I'm out of date. And if commit\nsucceeds, I'm sure it is already commited to the main branch. I'm sure\nI won't pollute my history with merges which would only be the result\nof forgetting to update.\n\nOnce more, that's not fundamental, but handy.\n\nThe more fundamental thing I suppose is that it allows people to work\nin a centralized way (checkout/commit/update/...), and Bazaar was\ndesigned to allow several different workflows, including the\ncentralized one.\n\n-- \nMatthieu\n"},{"id":"28943","messageId":"BAYC1-PASMTP02ADC5BEF688E61583283CAE0E0@CEZ.ICE","threadId":"5925","inReplyTo":"vpqejt76vgz.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T11:38:39Z","receivedAt":"2006-10-17T11:38:39Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 13:19:08 +0200\nMatthieu Moy wrote:\n\n> 1) a working tree without any history information, pointing to some\n> other location for the history itself (a la svn/CVS/...).\n> (this is \"light checkout\")\n\nGit can do this from a local repository, it just can't do it from\na remote repo (at least over the git native protocol). However,\nover gitweb you can grab and unpack a tarball from a remote repo.\nIn practice this is probably enough support for such a feature.\n\n> 2) a bound branch. It's not _very_ different from a normal branch, but\n> mostly \"commit\" behaves differently:\n> - it commits both on the local and the remote branch (equivalent to\n> \"commit\" + \"push\", but in a transactional way).\n> - it refuses to commit if you're out of date with the branch you're\n> bound to.\n> (this is \"heavy checkout\")\n\nThis doesn't sound right, at least in the spirit of git. Git really\nwants to have a local commit which you may or may not push to a\nremote repo at a later time. There is no upside to forcing it all to\nhappen in one step, and a lot of downsides. Gits focus is to support\ndistributed offline development, not requiring a remote repo to be\navailable at commit time.\n \n> In both cases, this has the side effect that you can't commit if the\n> \"upstream\" branch is read-only. That's not fundamental, but handy.\n\nAgain this seems really anti-git. There is no reason for your local\nbranch to be marked read only just because some upstream branch is\nso marked.\n\n> I use it for example to have several \"checkouts\" of the same branch on\n> different machines. When I commit, bzr tells me \"hey, boss, you're out\n> of date, why don't you update first\" if I'm out of date. And if commit\n> succeeds, I'm sure it is already commited to the main branch. I'm sure\n> I won't pollute my history with merges which would only be the result\n> of forgetting to update.\n\nThis is exactly the same in Git. You really only ever push upstream\nwhen your local changes fast forward the remote, (ie. you're up to date).\nGit will warn you if your changes don't fast forward the remote.\n \n> The more fundamental thing I suppose is that it allows people to work\n> in a centralized way (checkout/commit/update/...), and Bazaar was\n> designed to allow several different workflows, including the\n> centralized one.\n\nWhile Git really isn't meant to work in a centralized way there's nothing\npreventing such a work flow. It just requires the use of some surrounding\ninfrastructure.\n\nSean\n"},{"id":"29309","messageId":"20061017073839.3728d1e7.seanlkml__39722.0723833472$1161335159$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"vpqejt76vgz.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T11:38:39Z","receivedAt":"2006-10-17T11:38:39Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 13:19:08 +0200\nMatthieu Moy wrote:\n\n> 1) a working tree without any history information, pointing to some\n> other location for the history itself (a la svn/CVS/...).\n> (this is \"light checkout\")\n\nGit can do this from a local repository, it just can't do it from\na remote repo (at least over the git native protocol). However,\nover gitweb you can grab and unpack a tarball from a remote repo.\nIn practice this is probably enough support for such a feature.\n\n> 2) a bound branch. It's not _very_ different from a normal branch, but\n> mostly \"commit\" behaves differently:\n> - it commits both on the local and the remote branch (equivalent to\n> \"commit\" + \"push\", but in a transactional way).\n> - it refuses to commit if you're out of date with the branch you're\n> bound to.\n> (this is \"heavy checkout\")\n\nThis doesn't sound right, at least in the spirit of git. Git really\nwants to have a local commit which you may or may not push to a\nremote repo at a later time. There is no upside to forcing it all to\nhappen in one step, and a lot of downsides. Gits focus is to support\ndistributed offline development, not requiring a remote repo to be\navailable at commit time.\n \n> In both cases, this has the side effect that you can't commit if the\n> \"upstream\" branch is read-only. That's not fundamental, but handy.\n\nAgain this seems really anti-git. There is no reason for your local\nbranch to be marked read only just because some upstream branch is\nso marked.\n\n> I use it for example to have several \"checkouts\" of the same branch on\n> different machines. When I commit, bzr tells me \"hey, boss, you're out\n> of date, why don't you update first\" if I'm out of date. And if commit\n> succeeds, I'm sure it is already commited to the main branch. I'm sure\n> I won't pollute my history with merges which would only be the result\n> of forgetting to update.\n\nThis is exactly the same in Git. You really only ever push upstream\nwhen your local changes fast forward the remote, (ie. you're up to date).\nGit will warn you if your changes don't fast forward the remote.\n \n> The more fundamental thing I suppose is that it allows people to work\n> in a centralized way (checkout/commit/update/...), and Bazaar was\n> designed to allow several different workflows, including the\n> centralized one.\n\nWhile Git really isn't meant to work in a centralized way there's nothing\npreventing such a work flow. It just requires the use of some surrounding\ninfrastructure.\n\nSean\n"},{"id":"28944","messageId":"200610171345.32313.jnareb@gmail.com","threadId":"5925","inReplyTo":"vpqejt76vgz.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T11:45:31Z","receivedAt":"2006-10-17T11:45:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthieu Moy wrote:\n> Jakub Narebski writes:\n> \n>>> - you can use a checkout to maintain a local mirror of a read-only\n>>> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n>>\n>> In git you can access contents _without_ checkout/working area.\n> \n> Bazaar can do this too. For example,\n> \"bzr cat http://something -r some-revision\" gets the content of a file\n> at a given revision. But that's not what Aaron was refering to.\n\nGit cannot do that remotely (with exception of git-tar-tree/git-archive \nwhich has --remote option), yet. But you can get contents of a file \n(with \"git cat-file -p [:|::]\"), list \ndirectory (with \"git ls-tree \") and compare files or \ndirectories (git diff family of commands) without need for working \ndirectory.\n \nAFAICT working area is required _only_ to resolve conflicts during \nmerge.\n\n> In Bazaar, checkouts can be two things:\n> \n> 1) a working tree without any history information, pointing to some\n> other location for the history itself (a la svn/CVS/...).\n> (this is \"light checkout\")\n> \n> 2) a bound branch. It's not _very_ different from a normal branch, but\n> mostly \"commit\" behaves differently:\n> - it commits both on the local and the remote branch (equivalent to\n> \"commit\" + \"push\", but in a transactional way).\n> - it refuses to commit if you're out of date with the branch you're\n> bound to.\n> (this is \"heavy checkout\")\n\nIn git by default in the top directory of working area you have .git \ndirectory which contains whole repository (object database, refs (i.e. \nbranches and tags), information which branch is current, index aka. \ngitcache, configuration, etc.). You can share object database locally \n(which includes network filesystem).\n\nYou can have .git (usually .git then) directory without working \narea.\n\nAnd you can symlink (and in the future \"symref\"-link) .git directory.\n\n> In both cases, this has the side effect that you can't commit if the\n> \"upstream\" branch is read-only. That's not fundamental, but handy.\n\nThere was proposal to allow for tracking branches to be marked \nread-only, but it was not implemented yet.\n\nBut git has reverse check: it forbids (unless forced by user) to fetch \ninto branch which has local changes (does not fast-forward). This make \nsure that no information is lost.\n\nThe idea is that you fetch changes into tracking branch (e.g. 'master' \nbranch of some parent remote repository into 'origin' or \n'remotes//master' branch); you don't commit changes to \nsuch branch. You do your own work either on 'master' branch, then merge \n(typically using \"git pull\") corresponding 'origin' tracking branch, or \nuse separate private feature branch and use rebase after fetch.\n\n[...]\n> The more fundamental thing I suppose is that it allows people to work\n> in a centralized way (checkout/commit/update/...), and Bazaar was\n> designed to allow several different workflows, including the\n> centralized one.\n\nGit is designed for distributed workflows, not for centralized one.\nAll repositories are created equal :-)\n\n-- \nJakub Narebski\nShadeHawk on #git and #revctl\nPoland\n"},{"id":"28945","messageId":"4534C5CF.3000508@op5.se","threadId":"5925","inReplyTo":"vpqejt76vgz.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-17T12:00:15Z","receivedAt":"2006-10-17T12:00:15Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthieu Moy wrote:\n> Jakub Narebski writes:\n> \n>>> - you can use a checkout to maintain a local mirror of a read-only\n>>> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n>> In git you can access contents _without_ checkout/working area.\n> \n> Bazaar can do this too. For example,\n> \"bzr cat http://something -r some-revision\" gets the content of a file\n> at a given revision. But that's not what Aaron was refering to.\n> \n> In Bazaar, checkouts can be two things:\n> \n> 1) a working tree without any history information, pointing to some\n> other location for the history itself (a la svn/CVS/...).\n> (this is \"light checkout\")\n> \n> 2) a bound branch. It's not _very_ different from a normal branch, but\n> mostly \"commit\" behaves differently:\n> - it commits both on the local and the remote branch (equivalent to\n> \"commit\" + \"push\", but in a transactional way).\n> - it refuses to commit if you're out of date with the branch you're\n> bound to.\n> (this is \"heavy checkout\")\n> \n\nWhat about\n\n3) getting the repo with all the history while still not having to be \nonline to actually commit to *your* copy of the repo. When you later get \nonline, you can send all your changes in a big hunk, or let bazaar email \nthem to the maintainer as patches, or...\n\n> In both cases, this has the side effect that you can't commit if the\n> \"upstream\" branch is read-only. That's not fundamental, but handy.\n> \n\nIt appears we have different ideas of what's handy. Perhaps it's just a \ndifference in workflow, or lack of \"email-commits-as-patches\" tools in \nbazaar, but the ability to commit to whatever branch I like in my local \nrepo and then just send the diffs by email or please-pull requests to \nupstream authors is what makes git work so well for me. I can ofcourse \nalso pull the changes to another branch, or cherrypick them one by one, \nor...\n\nOTOH, if by \"commit\" you mean \"send your changes back to central \nserver\", and bazaar'ish for \"register my current set of changes in the \nlocal clone of the repo\" is called something else, it sounds very \nsimilar to what git does.\n\n> \n> The more fundamental thing I suppose is that it allows people to work\n> in a centralized way (checkout/commit/update/...), and Bazaar was\n> designed to allow several different workflows, including the\n> centralized one.\n> \n\nCentralized works in git too after a fashion. Most projects have a \nmaster repo hidden somewhere that frequently gets pushed out for \npublishing and which most (all?) contributors sync against from time to \ntime, but it's by no means a certainty. What *is* a certainty is that \nthe published branches are exactly identical to the ones in the master \nrepo, and all the downstream authors will get a history where they can \neasily track master's development.\n\nFor git, I suppose Junio has the hidden master repo which he publishes \nat kernel.org. Linus does the same with the Linux repo.\n\nOn a side-note, it sounds as though the \"bound branch\" scenario \nencourages making a big change as one mega-diff, so long as it \nimplements one feature, whereas the git workflow with topic-branches \nthat eventually gets merged to master allows changes to sort of \naccumulate up to a feature in the steps one actually has to take to make \nthe feature work.\n\nSide-note 2: Three really great things that have made work a lot easier \nand more enjoyable since we changed from cvs to git and that aren't \nmentioned in the comparison table:\n* Dependency/history graph display tools á la qgit/gitk\n* Bisection tool for finding bug introduction revisions.\n* Tools for sending commits as emails.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"28946","messageId":"200610171402.03373.jnareb@gmail.com","threadId":"5925","inReplyTo":"200610171345.32313.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T12:02:02Z","receivedAt":"2006-10-17T12:02:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n> In git by default in the top directory of working area you have .git \n> directory which contains whole repository (object database, refs (i.e. \n> branches and tags), information which branch is current, index aka. \n> gitcache, configuration, etc.). You can share object database locally \n> (which includes network filesystem).\n> \n> You can have .git (usually .git then) directory without working \n> area.\n\nSo called \"bare\" repository.\n> \n> And you can symlink (and in the future \"symref\"-link) .git directory.\n\nAnd you can use GIT_DIR environmental variable or --git-dir option\nto git wrapper.\n-- \nJakub Narebski\nPoland\n"},{"id":"28948","messageId":"vpqbqob5euu.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"BAYC1-PASMTP02ADC5BEF688E61583283CAE0E0@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-17T12:03:21Z","receivedAt":"2006-10-17T12:03:21Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Sean writes:\n\n> On Tue, 17 Oct 2006 13:19:08 +0200\n> Matthieu Moy wrote:\n>\n>> 1) a working tree without any history information, pointing to some\n>> other location for the history itself (a la svn/CVS/...).\n>> (this is \"light checkout\")\n>\n> Git can do this from a local repository, it just can't do it from\n> a remote repo (at least over the git native protocol). However,\n> over gitweb you can grab and unpack a tarball from a remote repo.\n> In practice this is probably enough support for such a feature.\n\nAnyway, given the price of disk space today, this only makes sense if\nyou have a fast access to the repository (otherwise, you consider your\nlocal repository as a cache, and you're ready to pay the disk space\nprice to save your bandwidth). In this case, it's often in your\nfilesystem (local or NFS).\n\n>> 2) a bound branch. It's not _very_ different from a normal branch, but\n>> mostly \"commit\" behaves differently:\n>> - it commits both on the local and the remote branch (equivalent to\n>> \"commit\" + \"push\", but in a transactional way).\n>> - it refuses to commit if you're out of date with the branch you're\n>> bound to.\n>> (this is \"heavy checkout\")\n>\n> This doesn't sound right, at least in the spirit of git. Git really\n> wants to have a local commit which you may or may not push to a\n> remote repo at a later time. There is no upside to forcing it all to\n> happen in one step, and a lot of downsides. Gits focus is to support\n> distributed offline development, not requiring a remote repo to be\n> available at commit time.\n\nI lied in my above description ;-).\n\nI should have said \"by default\" ... but you have \"commit --local\" if\nyou want to have a local commit on a bound branch (at this point, I\nshould remind that not all branches are \"bound branches\". \"bzr branch\"\ncreates branches similar to git ones).\n\n>> In both cases, this has the side effect that you can't commit if the\n>> \"upstream\" branch is read-only. That's not fundamental, but handy.\n>\n> Again this seems really anti-git. There is no reason for your local\n> branch to be marked read only just because some upstream branch is\n> so marked.\n\nWill, take the example of my bzr setup.\n\nI have one repository, say, $repo.\n\nIn it, I have one branch \"$repo/bzr.dev\" which is an exact mirror of\nhttp://bazaar-vcs.org's branch.\n\nI also have branches for patches (occasional in my case) that I'll\nsend to upstream. Say $repo/feature1, $repo/feature2, ...\n\nIf, by mistake, I start hacking on bzr.dev itself, I'll be warned at\ncommit time, create a branch, and commit in this new branch. I believe\ngit manages this in a different way, allowing you to commit in this\nbranch, and creating the branch next time you pull. But you know this\nbetter than I ;-), I never got time to give a real try to git.\n\n>> I use it for example to have several \"checkouts\" of the same branch on\n>> different machines. When I commit, bzr tells me \"hey, boss, you're out\n>> of date, why don't you update first\" if I'm out of date. And if commit\n>> succeeds, I'm sure it is already commited to the main branch. I'm sure\n>> I won't pollute my history with merges which would only be the result\n>> of forgetting to update.\n>\n> This is exactly the same in Git. You really only ever push upstream\n> when your local changes fast forward the remote, (ie. you're up to date).\n> Git will warn you if your changes don't fast forward the remote.\n\nYes, but you will have to do a merge at some point, right ? While I'm\nkeeping a purely linear history (not that it is good in the general\ncase, but for \"projects\" on which I'm the only developper, I find it\ngood. For example, my ${HOME}/etc/).\n\nBut don't get me wrong, I also prefer the decentralized way in most\ncase. And I'm happy that bzr and git work like this by default. Just\nthat at least *I* have cases where a centralized approach suits me\nbetter, and then I'm happy with that particular feature of bzr.\n\n-- \nMatthieu\n"},{"id":"28947","messageId":"BAYC1-PASMTP046FDC7A294B02BDB398D4AE0E0@CEZ.ICE","threadId":"5925","inReplyTo":"200610171345.32313.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T12:07:02Z","receivedAt":"2006-10-17T12:07:02Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 13:45:31 +0200\nJakub Narebski wrote:\n\n> Git cannot do that remotely (with exception of git-tar-tree/git-archive \n> which has --remote option), yet. But you can get contents of a file \n> (with \"git cat-file -p [:|::]\"), list \n> directory (with \"git ls-tree \") and compare files or \n> directories (git diff family of commands) without need for working \n> directory.\n\nInteresting, I didn't know about the --remote option. So in fact as long\nas the remote has enabled upload-tar then anyone can do a \"light checkout\".\nHowever, it appears that kernel.org for instance doesn't enable this feature.\n\nSean\n \n"},{"id":"29465","messageId":"20061017080702.615a3b2f.seanlkml__27953.817000571$1161408618$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"200610171345.32313.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T12:07:02Z","receivedAt":"2006-10-17T12:07:02Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 13:45:31 +0200\nJakub Narebski wrote:\n\n> Git cannot do that remotely (with exception of git-tar-tree/git-archive \n> which has --remote option), yet. But you can get contents of a file \n> (with \"git cat-file -p [:|::]\"), list \n> directory (with \"git ls-tree \") and compare files or \n> directories (git diff family of commands) without need for working \n> directory.\n\nInteresting, I didn't know about the --remote option. So in fact as long\nas the remote has enabled upload-tar then anyone can do a \"light checkout\".\nHowever, it appears that kernel.org for instance doesn't enable this feature.\n\nSean\n \n"},{"id":"28949","messageId":"200610171456.41548.jnareb@gmail.com","threadId":"5925","inReplyTo":"vpqbqob5euu.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T12:56:41Z","receivedAt":"2006-10-17T12:56:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthieu Moy wrote:\n>> This is exactly the same in Git.  You really only ever push upstream\n>> when your local changes fast forward the remote, (ie. you're up to date).\n>> Git will warn you if your changes don't fast forward the remote.\n> \n> Yes, but you will have to do a merge at some point, right ? While I'm\n> keeping a purely linear history (not that it is good in the general\n> case, but for \"projects\" on which I'm the only developper, I find it\n> good. For example, my ${HOME}/etc/).\n\nFast-forward doesn't result in merge.\n\nIf you have\n\n 1---2---3 \n \\\n 4---5 \n\nthen this is fast-forward case. After pull (or push) you have\n\n 1---2---3---4---5 \n\nwithout merge.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"28950","messageId":"BAYC1-PASMTP10E107E5EB0F7E69167F41AE0E0@CEZ.ICE","threadId":"5925","inReplyTo":"vpqbqob5euu.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T12:57:23Z","receivedAt":"2006-10-17T12:57:23Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 14:03:21 +0200\nMatthieu Moy wrote:\n\n> Anyway, given the price of disk space today, this only makes sense if\n> you have a fast access to the repository (otherwise, you consider your\n> local repository as a cache, and you're ready to pay the disk space\n> price to save your bandwidth). In this case, it's often in your\n> filesystem (local or NFS).\n\nThis is most likely the reason that people using Git don't clammor\nmore for the ability to work without a local repository. Disk is cheap\nand it just makes sense the vast majority of the time to have a complete\ncopy of the repository yourself. There are a lot of powerful things\nyou can do once you have all that information in your repo. Not the least\nof which is performing any and all operations while flying on a plane\nor sitting on a park bench.\n\n> I should have said \"by default\" ... but you have \"commit --local\" if\n> you want to have a local commit on a bound branch (at this point, I\n> should remind that not all branches are \"bound branches\". \"bzr branch\"\n> creates branches similar to git ones).\n\nWell, with Git the default is to only commit locally. Of course, you\ncould set your post commit hook to always push it to a remote if\nyou wanted to.\n\n> Will, take the example of my bzr setup.\n> \n> I have one repository, say, $repo.\n> \n> In it, I have one branch \"$repo/bzr.dev\" which is an exact mirror of\n> http://bazaar-vcs.org's branch.\n> \n> I also have branches for patches (occasional in my case) that I'll\n> send to upstream. Say $repo/feature1, $repo/feature2, ...\n> \n> If, by mistake, I start hacking on bzr.dev itself, I'll be warned at\n> commit time, create a branch, and commit in this new branch. I believe\n> git manages this in a different way, allowing you to commit in this\n> branch, and creating the branch next time you pull. But you know this\n> better than I ;-), I never got time to give a real try to git.\n\nWell, it's just a slight difference in perspective rather than any\nbig issue here. Git treats all repositories as peers, so it would never\nassume that just because one other particular repo has a branch marked\nas read only that it should be marked read only locally. It lets you\ncommit to it, and then push to say a third and fourth repo that are\nwritable as well. In practice this doesn't really cause any\ninsurmountable problems.\n\n> Yes, but you will have to do a merge at some point, right ? While I'm\n> keeping a purely linear history (not that it is good in the general\n> case, but for \"projects\" on which I'm the only developper, I find it\n> good. For example, my ${HOME}/etc/).\n\nWell if you're committing changes from multiple different machines,\nhow is that different from having say 3 different developers committing\nchanges to the central repo? How does bzr avoid a merge when you're\npushing changes from 3 separate machines? \n\nYou mentioned that if you try to push and you're not up to date you'll\nbe prompted to update (ie. pull from the upstream repo). When you do such\na pull do your local changes get rebased on top or is there a merge? By\nyour comments I guess you're saying they're rebased rather than merged, and\nthis is how you keep a linear history. Git can do this easily, but it's\nnot done by default.\n\nSean\n"},{"id":"29307","messageId":"20061017085723.7542ee6c.seanlkml__20673.2976054356$1161335024$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"vpqbqob5euu.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T12:57:23Z","receivedAt":"2006-10-17T12:57:23Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 14:03:21 +0200\nMatthieu Moy wrote:\n\n> Anyway, given the price of disk space today, this only makes sense if\n> you have a fast access to the repository (otherwise, you consider your\n> local repository as a cache, and you're ready to pay the disk space\n> price to save your bandwidth). In this case, it's often in your\n> filesystem (local or NFS).\n\nThis is most likely the reason that people using Git don't clammor\nmore for the ability to work without a local repository. Disk is cheap\nand it just makes sense the vast majority of the time to have a complete\ncopy of the repository yourself. There are a lot of powerful things\nyou can do once you have all that information in your repo. Not the least\nof which is performing any and all operations while flying on a plane\nor sitting on a park bench.\n\n> I should have said \"by default\" ... but you have \"commit --local\" if\n> you want to have a local commit on a bound branch (at this point, I\n> should remind that not all branches are \"bound branches\". \"bzr branch\"\n> creates branches similar to git ones).\n\nWell, with Git the default is to only commit locally. Of course, you\ncould set your post commit hook to always push it to a remote if\nyou wanted to.\n\n> Will, take the example of my bzr setup.\n> \n> I have one repository, say, $repo.\n> \n> In it, I have one branch \"$repo/bzr.dev\" which is an exact mirror of\n> http://bazaar-vcs.org's branch.\n> \n> I also have branches for patches (occasional in my case) that I'll\n> send to upstream. Say $repo/feature1, $repo/feature2, ...\n> \n> If, by mistake, I start hacking on bzr.dev itself, I'll be warned at\n> commit time, create a branch, and commit in this new branch. I believe\n> git manages this in a different way, allowing you to commit in this\n> branch, and creating the branch next time you pull. But you know this\n> better than I ;-), I never got time to give a real try to git.\n\nWell, it's just a slight difference in perspective rather than any\nbig issue here. Git treats all repositories as peers, so it would never\nassume that just because one other particular repo has a branch marked\nas read only that it should be marked read only locally. It lets you\ncommit to it, and then push to say a third and fourth repo that are\nwritable as well. In practice this doesn't really cause any\ninsurmountable problems.\n\n> Yes, but you will have to do a merge at some point, right ? While I'm\n> keeping a purely linear history (not that it is good in the general\n> case, but for \"projects\" on which I'm the only developper, I find it\n> good. For example, my ${HOME}/etc/).\n\nWell if you're committing changes from multiple different machines,\nhow is that different from having say 3 different developers committing\nchanges to the central repo? How does bzr avoid a merge when you're\npushing changes from 3 separate machines? \n\nYou mentioned that if you try to push and you're not up to date you'll\nbe prompted to update (ie. pull from the upstream repo). When you do such\na pull do your local changes get rebased on top or is there a merge? By\nyour comments I guess you're saying they're rebased rather than merged, and\nthis is how you keep a linear history. Git can do this easily, but it's\nnot done by default.\n\nSean\n"},{"id":"28951","messageId":"9e4733910610170559y392cb0a9v34becf0dc5fd98d6@mail.gmail.com","threadId":"5925","inReplyTo":"45345362.8040902@vilain.net","subject":"Re: VCS comparison table","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-10-17T12:59:32Z","receivedAt":"2006-10-17T12:59:32Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 10/16/06, Sam Vilain wrote:\n> Jon Smirl wrote:\n> > cvsps works ok on small amounts of data, but it can't handle the full\n> > Mozilla repo. The current idea is to convert the full repo with\n> > cvs2git and build the ini file needed by cvsps to support incremental\n> > imports. After that use cvsps.\n> >\n>\n> Looking through the client.mk used to check out the sub-portions of the\n> CVS repository, I have to ask;\n>\n> Why are you trying to import this big collection of projects into a\n> single git repository?\n\nAll of Mozilla is in a single CVS repo, client.mk is checking out\ndirectories from the mozilla project. This is how it has been\nhistorically for over ten years. It also allows commits that\nsimultaneously go to all subcomponents when interfaces are changed.\nEven if it was split into different git repos you still need to\ndownload about 70% of them to build the browser.\n\nI've been trying to simply translate the existing repo without\nchanging it's structure in any way. Changing structure is going to\nrequire a lot of buy-in from all of the developers.\n\n>\n> View git's repositories not as a container for an entire community's\n> code base, but more as object partitions. Currently you are quite happy\n> to use per-file version control partitions inherent to CVS. Now you are\n> looking at removing all of the partitions completely and hoping to end\n> up with something managable. That it has been possible at all to fit it\n> into the space less than the size of a CD is staggering, but surely a\n> piecemeal approach would be a pragmatic solution to this problem.\n>\n> Sam.\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"28952","messageId":"vpqlknf3wdz.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"4534C5CF.3000508@op5.se","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-17T13:27:36Z","receivedAt":"2006-10-17T13:27:36Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Andreas Ericsson writes:\n\n> What about\n>\n> 3) getting the repo with all the history while still not having to be\n> online to actually commit to *your* copy of the repo. When you later\n> get online, you can send all your changes in a big hunk, or let bazaar\n> email them to the maintainer as patches, or...\n\nWell, the discussion was about checkouts, so I was talking about\ncheckouts ;-).\n\nWhat you mention is the default behavior of Bazaar when you use \n\"bzr branch\" or \"bzr get\". BTW, it's also possible to do this with a\nheavy checkout, that's \"commit --local\".\n\n> It appears we have different ideas of what's handy. Perhaps it's just\n> a difference in workflow, or lack of \"email-commits-as-patches\" tools\n> in bazaar,\n\nYou have \"bzr bundle\" in Bazaar, and there was work to have it\nactually send the email ( http://bazaar-vcs.org/SubmitByMail ), but I\ndon't think it's finished yet.\n\nAnd yes, this is a great feature, the first time I used it was with\nDarcs, and I was impressed how easy I could submit a patch without any\nsetup and with a 5-lines tutorial. Even wiki seems complex after\nthat ;-).\n\n> but the ability to commit to whatever branch I like in my local repo\n> and then just send the diffs by email or please-pull requests to\n> upstream authors is what makes git work so well for me.\n\nSure. Once again, Bazaar does it this way too. There's an _additional\nfeature_ called checkout which allows you to work in another way,\nthough. As most \"feature\", it's not useful to everybody.\n\nAnd I repeat that I'm in no way arguing against the git model :-).\n\n> Side-note 2: Three really great things that have made work a lot\n> easier and more enjoyable since we changed from cvs to git and that\n> aren't mentioned in the comparison table:\n\nSure. And regarding this, hopufully, most modern VCS go in the same\ndirection.\n\n> * Dependency/history graph display tools á la qgit/gitk\n\nhttp://bazaar-vcs.org/bzr-gtk\nhttp://samba.org/~jelmer/bzr/bzrk.png\n\n> * Bisection tool for finding bug introduction revisions.\n\nThis took time to come in bzr, but that's the bisect plugin:\n\nhttp://bazaar-vcs.org/PluginRegistry\n\n> * Tools for sending commits as emails.\n\n(Surprisingly, I had added this in the table, but has been removed for\nsome obscure reasons)\n\n-- \nMatthieu\n"},{"id":"28953","messageId":"vpqk62z3w4k.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"200610171345.32313.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-17T13:33:15Z","receivedAt":"2006-10-17T13:33:15Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n> But git has reverse check: it forbids (unless forced by user) to fetch \n> into branch which has local changes (does not fast-forward).\n\nSame as bzr then I believe. \"bzr pull\" will suggest you to use \"merge\"\nin this situation, unless you say \"pull --overwrite\".\n\n>> The more fundamental thing I suppose is that it allows people to work\n>> in a centralized way (checkout/commit/update/...), and Bazaar was\n>> designed to allow several different workflows, including the\n>> centralized one.\n>\n> Git is designed for distributed workflows, not for centralized one.\n> All repositories are created equal :-)\n\nNote that \"bound branches\" and \"other branches\" in bzr are not so\ndifferent. The \"master\" (the one you make a checkout of) doesn't have\nto know it has checkouts, and the \"checkout\" just has one file\npointing to the \"master\", and you can switch from one flow to the\nother with \"bzr bind/unbind\".\n\nSo, in Bazaar, all repositories are /almost/ created equal ;-).\n\n-- \nMatthieu\n"},{"id":"28954","messageId":"vpqejt73vln.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"BAYC1-PASMTP10E107E5EB0F7E69167F41AE0E0@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-17T13:44:36Z","receivedAt":"2006-10-17T13:44:36Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Sean writes:\n\n>> Yes, but you will have to do a merge at some point, right ? While I'm\n>> keeping a purely linear history (not that it is good in the general\n>> case, but for \"projects\" on which I'm the only developper, I find it\n>> good. For example, my ${HOME}/etc/).\n>\n> Well if you're committing changes from multiple different machines,\n> how is that different from having say 3 different developers committing\n> changes to the central repo?\n\nThe workflow is different.\n\nIf I commit broken changes on a repository shared by multiple\ndevelopers, they'll insult me, and they'll be right. While I find\nnothing wrong in commiting broken changes to my ${HOME}/etc/ when\nleaving the office, and fix it from home.\n\n> How does bzr avoid a merge when you're pushing changes from 3\n> separate machines?\n\nErr, the same way people have been doing for years ;-). If you don't\nhave local commits, \"bzr update\" will work in the same way as \"cvs\nupdate\", it keeps your local changes, without recording history. Like\n\"git pull\" does if you have uncommited changes I think.\n"},{"id":"28955","messageId":"4534DF18.8080302@utoronto.ca","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610171229160.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-17T13:48:08Z","receivedAt":"2006-10-17T13:48:08Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJohannes Schindelin wrote:\n> On Tue, 17 Oct 2006, Sean wrote:\n>>Aaron Bentley wrote:\n\n>>>- - you can have working trees on local systems while having the\n>>> repository on a remote system. This makes it easy to work on one\n>>> logical branch from multiple locations, without getting out of sync.\n>>\n>>That is a very nice feature. Git would be improved if it could\n>>support that mode of operation as well.\n> \n> \n> It would also make things slow as hell. How do you deal with something \n> like annotate in such a setup?\n\nFor the particular case of annotate, bzr is designed to store\nannotations at commit time. So annotate should require remote access to\na small amount of data from two files-- not a great cost.\n\nBut our default form of checkout contains a local copy of all history\ndata, so that readonly operations happen at local speed.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFNN8Y0F+nu1YWqI0RAqXtAJ4qKGQ5ZwlMF795kz3udeuRTcRy6wCghr53\ntjw9cNVxzrQ0XSUO2v52ZIo=\n=W6q7\n-----END PGP SIGNATURE-----\n"},{"id":"28956","messageId":"200610171555.56778.jnareb@gmail.com","threadId":"5925","inReplyTo":"vpqlknf3wdz.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T13:55:55Z","receivedAt":"2006-10-17T13:55:55Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthieu Moy wrote:\n>> Side-note 2: Three really great things that have made work a lot\n>> easier and more enjoyable since we changed from cvs to git and that\n>> aren't mentioned in the comparison table:\n> \n> Sure. And regarding this, hopufully, most modern VCS go in the same\n> direction.\n> \n> > * Dependency/history graph display tools á la qgit/gitk\n> \n> http://bazaar-vcs.org/bzr-gtk\n> http://samba.org/~jelmer/bzr/bzrk.png\n\nHmmm... most of the tools look similar. Git has gitk (Tcl/Tk, now in \ngit.git repository), QGit (Qt), GitView (GTK+, in contrib/), \ngit-browser (JavaScript, uses High Performance JavaScript Graphics \nLibrary by Walter Zorn, http://www.walterzorn.com, for graphics).\n\nTig (Text-mode Interface for Git, ncurses) also in it's git version has \na kind of history graph using ascii-art.\n\n\nThat is very important tool to have for any SCM which allows (and \nencourages) nonlinear history development.\n \n>> * Bisection tool for finding bug introduction revisions.\n> \n> This took time to come in bzr, but that's the bisect plugin:\n> \n> http://bazaar-vcs.org/PluginRegistry\n\nHmmm... I winder which SCM had it first.\n \n>> * Tools for sending commits as emails.\n> \n> (Surprisingly, I had added this in the table, but has been removed for\n> some obscure reasons)\n\nWhile email can be used to exchange patches (git-format-patch to \ngenerate patches, git-send-mail to send patches if you don't want to \nuse ordinary email client, git-am to apply patches) it cannot be used \nto exchange all information (one cannot send for example tags, or merge \ncommits).\n\nIt is very usefull tool to have for \"accidental\" developer. You don't \nhave to have constant on-line presence in the form of web server or git \nserver somewhere for sending pull requests (although http://repo.or.cz \npublic git repo hosting can help with that), you don't have to have \naccess (ssh perhaps limited, or WebDAV one) to do push to somebody else \nrepository, you can just send email to some mailing list.\n\nBTW. git can provide binary patch for binary files (e.g. adding favicon \nfor gitweb in git.git).\n\n\nOther often and not-so-often used tools include:\n * git-rerere - Reuse recorded resolve (of merge conflicts)\n * reflog - Records where was given branch at given time (no UI yet)\n * git-diff -S'text' aka. pickaxe - find commits which added or removed\n given 'text'; and other revision limiters\n"},{"id":"28957","messageId":"4534E246.10105@op5.se","threadId":"5925","inReplyTo":"vpqlknf3wdz.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-17T14:01:42Z","receivedAt":"2006-10-17T14:01:42Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthieu Moy wrote:\n> Andreas Ericsson writes:\n> \n>> What about\n>>\n>> 3) getting the repo with all the history while still not having to be\n>> online to actually commit to *your* copy of the repo. When you later\n>> get online, you can send all your changes in a big hunk, or let bazaar\n>> email them to the maintainer as patches, or...\n> \n> Well, the discussion was about checkouts, so I was talking about\n> checkouts ;-).\n> \n\nDifferences in nomenclature is really messing this discussion up. In \ngit, a \"checkout\" is the act of pulling objects from the object database \ninto the working tree. I.e., the act of \"clothing\" a \"bare\" repository.\n\n\n>> but the ability to commit to whatever branch I like in my local repo\n>> and then just send the diffs by email or please-pull requests to\n>> upstream authors is what makes git work so well for me.\n> \n> Sure. Once again, Bazaar does it this way too. There's an _additional\n> feature_ called checkout which allows you to work in another way,\n> though. As most \"feature\", it's not useful to everybody.\n> \n\nNow I'm really confused. Does bazaar have both \"clone\" (git-style \nfetching a full repo and all the branches) and \"checkout\" (cvs-style \nfetching only the working tree)?\n\n> \n>> Side-note 2: Three really great things that have made work a lot\n>> easier and more enjoyable since we changed from cvs to git and that\n>> aren't mentioned in the comparison table:\n> \n> Sure. And regarding this, hopufully, most modern VCS go in the same\n> direction.\n> \n>> * Dependency/history graph display tools á la qgit/gitk\n> \n> http://bazaar-vcs.org/bzr-gtk\n> http://samba.org/~jelmer/bzr/bzrk.png\n> \n>> * Bisection tool for finding bug introduction revisions.\n> \n> This took time to come in bzr, but that's the bisect plugin:\n> \n> http://bazaar-vcs.org/PluginRegistry\n> \n>> * Tools for sending commits as emails.\n> \n> (Surprisingly, I had added this in the table, but has been removed for\n> some obscure reasons)\n> \n\nMerge-conflict with the webpage? ;-)\n\nHowever, I know that bazaar has many of these features. I was merely \ncommenting on the absence of these killer-features in the table. It \nmight help people pick the right scm for their project, which is always \na Good Thing(tm).\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"28958","messageId":"BAYC1-PASMTP10F617306F1477E66FA441AE0E0@CEZ.ICE","threadId":"5925","inReplyTo":"vpqejt73vln.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T14:01:50Z","receivedAt":"2006-10-17T14:01:50Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 15:44:36 +0200\nMatthieu Moy wrote:\n\n> > How does bzr avoid a merge when you're pushing changes from 3\n> > separate machines?\n> \n> Err, the same way people have been doing for years ;-). If you don't\n> have local commits, \"bzr update\" will work in the same way as \"cvs\n> update\", it keeps your local changes, without recording history. Like\n> \"git pull\" does if you have uncommited changes I think.\n\nAh, okay. Well Git can definitely manage this. Just means you have to\nrebase any local changes before pushing. This will keep the history\nlinear and make sure that no merges are needed in the case you were asking\nabout.\n\nSo far, it sounds to me like bazaar and git are more alike than they are\ndifferent. Each have a few commands the other doesn't but all in all\nthey sound very similar. But i'm a Git fanboy so I aint switching\nnow ;o)\n\nSean\n"},{"id":"29462","messageId":"20061017100150.b4919aac.seanlkml__6612.46223976395$1161404460$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"vpqejt73vln.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T14:01:50Z","receivedAt":"2006-10-17T14:01:50Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 15:44:36 +0200\nMatthieu Moy wrote:\n\n> > How does bzr avoid a merge when you're pushing changes from 3\n> > separate machines?\n> \n> Err, the same way people have been doing for years ;-). If you don't\n> have local commits, \"bzr update\" will work in the same way as \"cvs\n> update\", it keeps your local changes, without recording history. Like\n> \"git pull\" does if you have uncommited changes I think.\n\nAh, okay. Well Git can definitely manage this. Just means you have to\nrebase any local changes before pushing. This will keep the history\nlinear and make sure that no merges are needed in the case you were asking\nabout.\n\nSo far, it sounds to me like bazaar and git are more alike than they are\ndifferent. Each have a few commands the other doesn't but all in all\nthey sound very similar. But i'm a Git fanboy so I aint switching\nnow ;o)\n\nSean\n"},{"id":"28960","messageId":"4534E335.8070203@utoronto.ca","threadId":"5925","inReplyTo":"45348B5E.8000404@op5.se","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-17T14:05:41Z","receivedAt":"2006-10-17T14:05:41Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nAndreas Ericsson wrote:\n> Aaron Bentley wrote:\n\n>> When two people have copies of the same revision, it's usually because\n>> they are each pulling from a common branch, and so the revision in that\n>> branch can be named. Bazaar does use unique ids internally, but it's\n>> extremely rare that the user needs to use them.\n>>\n> \n> Well, if two people have the same revision in git, you *know* they have\n> pulled from each other\n\nNo, you don't. They may have each pulled from a different repository.\n\nTake revision 00aabbcc, created by Linus. Linus has it because he\ncommitted it. I have it because I pulled Linus' repository. You have\nit because Andrew Morton pulled Linus' repository, and you pulled Andrew\nMorton's repository.\n\n>> But tags have local meaning only, unless someone has access to your\n>> repository, right?\n>>\n> \n> I imagine the bazaar-names with url+number only has local meaning unless\n> someone has access to your repository too.\n\nYes. That phrasing was from Linus' description of revnos.\n\n> One of the great benefits of\n> git is that each revision is *always exactly the same* no matter in\n> which repository it appears. This includes file-content, filesystem\n> layout and, last but also most important, history.\n\nIn Bazaar, a revision id always refers to the same logical entity, but\nit may be stored in different formats in different repositories.\n\n>> - - you can publish a repository without publishing its working tree,\n>> possibly using standard mirroring tools like rsync.\n>>\n> \n> Can't all scm's do this?\n\nWith most SCMs that store the repository in the root of the tree,\ndisentangling the tree and repository requires care. OTOH, this is just\nas easy with Arch, CVS and SVN as it is with Bazaar.\n\n>> - - you can use a checkout to maintain a local mirror of a read-only\n>> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n>>\n> \n> Check. Well, actually, you just clone it as usual but with the --bare\n> argument and it won't write out the working tree files.\n\nNo, I *want* the working tree files. I run bzr from a checkout of bzr.dev.\n\n>> You can operate that way in bzr too, but I find it nicer to have one\n>> checkout for each active branch, plus a checkout of bzr.dev. Our switch\n>> command also rewrites only the changed part of the working tree.\n>>\n> \n> Works in git as well, but each \"checkout\" (actually, locally referenced\n> repository clone) gets a separate branch/tag namespace.\n\nIn our terminology, if it can diverge from the original, it's a branch,\nnot a checkout.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFNOM10F+nu1YWqI0RAvNUAJwN/QviOs+sUuN9ep4Otyrgax9SmwCfSH7t\nXdxOxo7smshNlzU3qoxq6Nw=\n=nxsM\n-----END PGP SIGNATURE-----\n"},{"id":"28961","messageId":"vpqr6x711cm.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"200610171555.56778.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-17T14:08:41Z","receivedAt":"2006-10-17T14:08:41Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n> While email can be used to exchange patches (git-format-patch to \n> generate patches, git-send-mail to send patches if you don't want to \n> use ordinary email client, git-am to apply patches) it cannot be used \n> to exchange all information (one cannot send for example tags, or merge \n> commits).\n\nIn bzr, the \"bundle\" appears like a patch, but it actually contain the\nsame information as the revision(s) it contains (I believe this\napplies to hg and Darcs too). A bundle can be used almost like a\nbranch. That's a key point, since revision identity is not based on\ncontent's hash, so applying a patch is very different from merging a\nbundle.\n\n> It is very usefull tool to have for \"accidental\" developer.\n\nThat's the key point, but patch review for non-accidental developpers\nis also good :-).\n\n> BTW. git can provide binary patch for binary files (e.g. adding favicon \n> for gitweb in git.git).\n\nBazaar's bundle use base64 encoding for binaries. I don't think that's\nefficient binary diff (xdelta-like) though. Aaron has been fighting\nquite a lot with MUA and MTA mixing up the patches (line ending in\nparticular) ...\n"},{"id":"28963","messageId":"vpqlknf10u5.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"BAYC1-PASMTP10F617306F1477E66FA441AE0E0@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-17T14:19:46Z","receivedAt":"2006-10-17T14:19:46Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Sean writes:\n\n> Ah, okay. Well Git can definitely manage this. Just means you have to\n> rebase any local changes before pushing. This will keep the history\n> linear and make sure that no merges are needed in the case you were asking\n> about.\n\nSure. As I said before, the little add-on of checkouts is that you say\nonce \"I don't want to do local commit here\", and bzr reminds you this\neach time you commit. Well, where it can make a difference is that it\ndoes it in a transactional way, that is, you don't have that little\nwindow between the time you pull and the time you push your next\ncommit. But this would really be bad luck ;-).\n\n> So far, it sounds to me like bazaar and git are more alike than they are\n> different. Each have a few commands the other doesn't but all in all\n> they sound very similar.\n\nSure. And at least, if you want to prove that your decentralized SCM\nis the best, you'd better look at features other than the ability to\ncommit on a local branch ;-). If you want a _real_ flamewar, better\ntalk about rename management or revision identity.\n\nThe thing is that most people migrated from CVS/svn, so they found\ntheir new SCM to be incredibly better the existing. But it's generally\nnot _so_ much better than the other modern alternatives ;-). (and\ndon't forget to thank Darcs and Monotone who brought most of the good\nideas you and I are using)\n\n> But i'm a Git fanboy so I aint switching now ;o)\n\nProbably not going to switch either, but that might happen.\n\n-- \nMatthieu\n"},{"id":"28962","messageId":"20061017141953.GA689@dspnet.fr.eu.org","threadId":"5925","inReplyTo":"vpqejt76vgz.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2006-10-17T14:19:53Z","receivedAt":"2006-10-17T14:19:53Z","isPatch":false,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"On Tue, Oct 17, 2006 at 01:19:08PM +0200, Matthieu Moy wrote:\n> I use it for example to have several \"checkouts\" of the same branch on\n> different machines. When I commit, bzr tells me \"hey, boss, you're out\n> of date, why don't you update first\" if I'm out of date.\n\nYou're not telling us bzr still follows the utterly stupid\nupdate-before-commit model, right? Right?\n\n OG.\n"},{"id":"28964","messageId":"vpqhcy310m7.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"4534E246.10105@op5.se","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-17T14:24:32Z","receivedAt":"2006-10-17T14:24:32Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Andreas Ericsson writes:\n\n> Now I'm really confused. Does bazaar have both \"clone\" (git-style\n> fetching a full repo and all the branches) and \"checkout\" (cvs-style\n> fetching only the working tree)?\n\nYes, it has both. That's \"bzr branch\" (git clone) and \"bzr checkout\"\n(cvs checkout).\n\nDifference between \"bzr branch\" and \"git clone\" is that bzr doesn't\nfetch all the branches. It fetches one \"branch\" (succession of\nrevisions) with all the ancestors of the revisions of the branch.\n\n-- \nMatthieu\n"},{"id":"28965","messageId":"BAYC1-PASMTP018A5B086047BE4212EFF8AE0E0@CEZ.ICE","threadId":"5925","inReplyTo":"4534E335.8070203@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T14:34:23Z","receivedAt":"2006-10-17T14:34:23Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 10:05:41 -0400\nAaron Bentley wrote:\n\n\n> No, you don't. They may have each pulled from a different repository.\n> \n> Take revision 00aabbcc, created by Linus. Linus has it because he\n> committed it. I have it because I pulled Linus' repository. You have\n> it because Andrew Morton pulled Linus' repository, and you pulled Andrew\n> Morton's repository.\n\nWell his point was that they have pulled from each other directly or\nindirectly. You can safely say that rev 00aabbcc.. in _any_ repository\nis the same rev. This discussion started because of doubt expressed\nby some here on the list that the \"simple\" numbering scheme used by\nbzr can offer the same guarantee. That is, rev 1.2.1 may be completely\ndifferent commits in different repos in bazaar.\n \n> With most SCMs that store the repository in the root of the tree,\n> disentangling the tree and repository requires care. OTOH, this is just\n> as easy with Arch, CVS and SVN as it is with Bazaar.\n\nJust in case it wasn't clear, this is drop dead easy in Git too.\n\n> No, I *want* the working tree files. I run bzr from a checkout of bzr.dev.\n\nWhy? Uncommitted changes shouldn't be propagated. Once you have cloned\nthe repo, you can checkout your own copy of the working tree files.\n\nSean\n"},{"id":"28966","messageId":"200610171641.04455.jnareb@gmail.com","threadId":"5925","inReplyTo":"vpqr6x711cm.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T14:41:02Z","receivedAt":"2006-10-17T14:41:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthieu Moy wrote:\n> Jakub Narebski writes:\n> \n>> While email can be used to exchange patches (git-format-patch to \n>> generate patches, git-send-mail to send patches if you don't want to \n>> use ordinary email client, git-am to apply patches) it cannot be used \n>> to exchange all information (one cannot send for example tags, or\n>> merge commits).\n> \n> In bzr, the \"bundle\" appears like a patch, but it actually contain the\n> same information as the revision(s) it contains (I believe this\n> applies to hg and Darcs too). A bundle can be used almost like a\n> branch. That's a key point, since revision identity is not based on\n> content's hash, so applying a patch is very different from merging a\n> bundle.\n\nThe patch generated by git-format-patch has author information (in \n\"From:\" header), original commit date (in \"Date:\" header), commit \nmessage (first line in \"Subject:\", rest in message body), place for \ncomments which are not to be included in commit message, diffstat for \neasier patch review, and git extended diff (with information about \nrenames detection, mode changes, 7-characters wide shortcuts of file \ncontents identifiers). It does not record parent information, original \ncomitter and comitter date, which branch we are on etc. You can quite \neasily provide ordering of patches.\n\nSending patches via email prohibits first line of commit message to be \nenclosed in brackets (subject usually is \"[PATCH] Commit description\" \nor \"[PATCH n/m] Commit description\") and enforces git convention of \ncommit message to consist of first line describing commit shortly, \nseparated by empty line from the longer description and signoff lines.\n\n\"Bundle\" equivalent, although binary in nature, would be thin pack.\n \n>> It is very usefull tool to have for \"accidental\" developer.\n> \n> That's the key point, but patch review for non-accidental developpers\n> is also good :-).\n\nHow very true...\n \n>> BTW. git can provide binary patch for binary files (e.g. adding\n>> favicon for gitweb in git.git).\n> \n> Bazaar's bundle use base64 encoding for binaries. I don't think that's\n> efficient binary diff (xdelta-like) though. Aaron has been fighting\n> quite a lot with MUA and MTA mixing up the patches (line ending in\n> particular) ...\n\nIf I remember correctly git binary diff format is xdiff based, and uses \nkind of ascii85 encoding (PostScript).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"28968","messageId":"Pine.LNX.4.64.0610170737280.3962@g5.osdl.org","threadId":"5925","inReplyTo":"45345AEF.6070107@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-17T15:03:06Z","receivedAt":"2006-10-17T15:03:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 17 Oct 2006, Aaron Bentley wrote:\n> \n> But tags have local meaning only, unless someone has access to your\n> repository, right?\n\nEhh. Exactly like the bzr numbers? You have to have access to the original \nrepo to name it.\n\nSo your point is?\n\nIf you do\n\n\tgit log v2.6.17\n\nin a kernel repository, you'll see exactly what I see - because you'll \nhave gotten the tags, aka the \"easy revision names\".\n\nNow, I'm obviously biased, but the thing is, git really does do this \nright. No meaningless numbers. You give _meaningful_ revision names, and \nthey can be extremely powerful.\n\nAnd no, it's not just tags or the raw SHA1 numbers. You can do \nrelationships like\n\n\tgit log HEAD~5..\n\nwhich means \"show the log for everything since five parents ago\" (which is \n_not_ the same as \"show the last five revisions\", because one of them may \nhave been a merge, and brought in a lot more of new commits).\n\nOr, you can say\n\n\tgit diff mybranch@{2.days.ago}..nextbranch\n\nwhich says exactly what you'd read it as: show the diff between what \n\"mybranch\" looked like 2 days ago and what \"nextbranch\" looks like right \nnow.\n\nOr, since the namespace is the same for commit history _and_ for actual \nfile contents, and since some commands don't need commits, you can decide \nto name not a revision, but a specific file or subdirectory in a revision, \nand do things like\n\n\tgit -p grep -1 request_irq v2.6.17~2:drivers/char\n\nwhere the \"revision\" is not a commit revision at all, it's a _tree_ \nrevision, because we've looked up the revision for \"v2.6.17~2\" (which \nmeans \"the grandparent of the tag 2.6.17\"), and then within that commit we \nlooked up the tree \"drivers/char\", and then we grepped (recursively) for \nthe string \"request_irq\" within that subtree (with one line of context), \nand then we paginated the output through \"less\" (or whatever your pager is \nset to).\n\nIn other words, yes, the above does _exactly_ what you'd expect it to do.\n\nThe fact is, nobody ever uses the SHA1 names directly in their normal \nwork. You'd use the branch names, tag-names, or some relationship operator \nlike \"this long ago\" or \"the parent of\" or similar).\n\nThe only time you use actual SHA1 names is when you tell somebody _else_ \nsomething. Or when you use \"gitk\" to look something up, and select a \ncommit, and then paste that commit name into \"git show\" (which is \nobviously telling \"somebody else\" - it's communicating between two \nprograms).\n\nThere's simply no reason to ever use the SHA1 names directly normally. But \nthey are there, and they are the _real_ revision numbers, and they \nactually have real meaning between different repositories.\n\nSo that \"git grep\" example above is actually 100% equivalent to\n\n\tgit -p grep -1 request_irq 3ff4e205e1\n\nbut why would I ever write that? That's just insane. But in case you care, \nthe way I got that \"3ff4e205e1\" number, it was just by doing\n\n\tgit rev-parse v2.6.17~2:drivers/char\n\nand cutting-and-pasting the first ten hex-digits to make sure I had \nenough of a name to make it unique.\n\nSo the SHA1 names always exist, and they are what git _internally_ uses, \nbut you'd normally not use them that much in your daily life. \n\nThey are great for explaining things, though. For example, when somebody \nreports a bug, and has used \"git bisect\" to figure out where the bug \nstarted happening, that's when the \"real name\" matters - since we normally \ndidn't tag that commit as being buggy when we created it ;)\n\nSo that's when you'd say: \"I bisected the problem, and it started \nhappening in commit 0123456789abcdef\". And now everybody with a git \nrepository of the kernel can just look it up locally by \ncutting-and-pasting that one number.\n\n> The key thing about a checkout is that it's stored in a different\n> location from its repository. This provides a few benefits:\n\nActually, git does something even better.\n\nGit allows the repository to be split up.\n\nYou can get a git repository on a CD or DVD, and do\n\n\tgit clone -l -s /mount/cdrom myrepo\n\nand that \"-s\" means that the new \"myrepo\" actually is linked to the \noriginal CDROM repository, and you can now _commit_ stuff and make changes \nin myrepo, even though all the old history is on that CD-ROM. It won't add \nany unnecessary stuff at all to the new repo.\n\nOr, you could do the \"totally naked\" checkout, so that the whole \nrepository is somewhere else (if that \"somewhere else\" is the CD-ROM, you \nobviously cannot change anything ;)\n\nOr you can have different repositories that are all related, and all \ncontain just the part that _they_ care about.\n\n\t\tLinus\n"},{"id":"28969","messageId":"4534F133.1090003@op5.se","threadId":"5925","inReplyTo":"4534E335.8070203@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-17T15:05:23Z","receivedAt":"2006-10-17T15:05:23Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Aaron Bentley wrote:\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> Andreas Ericsson wrote:\n>> Aaron Bentley wrote:\n> \n>>> When two people have copies of the same revision, it's usually because\n>>> they are each pulling from a common branch, and so the revision in that\n>>> branch can be named. Bazaar does use unique ids internally, but it's\n>>> extremely rare that the user needs to use them.\n>>>\n>> Well, if two people have the same revision in git, you *know* they have\n>> pulled from each other\n> \n> No, you don't. They may have each pulled from a different repository.\n> \n\nI realized it as I read it now. What I meant was that you know you have \nthe exact same revision as the original author once committed.\n\n> \n>>> But tags have local meaning only, unless someone has access to your\n>>> repository, right?\n>>>\n>> I imagine the bazaar-names with url+number only has local meaning unless\n>> someone has access to your repository too.\n> \n> Yes. That phrasing was from Linus' description of revnos.\n> \n>> One of the great benefits of\n>> git is that each revision is *always exactly the same* no matter in\n>> which repository it appears. This includes file-content, filesystem\n>> layout and, last but also most important, history.\n> \n> In Bazaar, a revision id always refers to the same logical entity, but\n> it may be stored in different formats in different repositories.\n> \n\nThis I don't understand. Let's say Alice has revision-154 in her repo, \nlocated at alice.example.com. Let's say that commit is accessible with \nthe url \"alice.example.com:revision-154\". Bob pulls from her repo into \nhis own, which is located at bob.example.com.\n\nLots of questions here, so I'll split them up. Feel free to delete the \nnon-applicable ones.\n\nWill the commit in Bob's repo be accessible at \n\"bob.example.com:revision-154\"?\n\nIf it's not, how can you backtrack from old bugreports and find the \nerror being discussed?\n\nIf it is, how does that work if Bob suddenly wants to commit things \nbefore Alice is done working with her changes?\n\nAlso, suppose they both push to a master-repo where Caesar has pushed \nhis changes and nicked the slot for revision-154. Does the master repo \nre-organize everything and then invalidate Bob's and Alice's changes, or \ndoes it tell Alice and Bob that they need to update and then reorganize \ntheir repos before they're allowed to push?\n\nI really can't get my head around the usefulness of revision-numbers \nhopping around which is probably why I'm having such a trouble groking \nhow it works.\n\n> \n>>> - - you can use a checkout to maintain a local mirror of a read-only\n>>> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n>>>\n>> Check. Well, actually, you just clone it as usual but with the --bare\n>> argument and it won't write out the working tree files.\n> \n> No, I *want* the working tree files. I run bzr from a checkout of bzr.dev.\n> \n\nYou get the working tree files by default. Use --bare if you don't want \nthem to be checked out (i.e. written to the working tree) after the \nclone is complete.\n\n>>> You can operate that way in bzr too, but I find it nicer to have one\n>>> checkout for each active branch, plus a checkout of bzr.dev. Our switch\n>>> command also rewrites only the changed part of the working tree.\n>>>\n>> Works in git as well, but each \"checkout\" (actually, locally referenced\n>> repository clone) gets a separate branch/tag namespace.\n> \n> In our terminology, if it can diverge from the original, it's a branch,\n> not a checkout.\n> \n\nThis clears things up immensely. bazaar checkout != git checkout.\nI still fail to see how a local copy you can't commit to is useful, but \nit doesn't really matter to me as I've already found a tool that does \neverything I want wrt scm needs.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"28970","messageId":"BAYC1-PASMTP074A2D2B30CAF96E374229AE0E0@CEZ.ICE","threadId":"5925","inReplyTo":"vpqlknf10u5.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T15:06:55Z","receivedAt":"2006-10-17T15:06:55Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 16:19:46 +0200\nMatthieu Moy wrote:\n\n> Sure. As I said before, the little add-on of checkouts is that you say\n> once \"I don't want to do local commit here\", and bzr reminds you this\n> each time you commit. Well, where it can make a difference is that it\n> does it in a transactional way, that is, you don't have that little\n> window between the time you pull and the time you push your next\n> commit. But this would really be bad luck ;-).\n\nYeah, it would be bad luck, but Git wouldn't actually let the push\nsucceed if someone had changed the upstream repo in that small window.\nIt would complain that your push wasn't a fast forward and ask you\nto update before pushing.\n\n> Sure. And at least, if you want to prove that your decentralized SCM\n> is the best, you'd better look at features other than the ability to\n> commit on a local branch ;-). If you want a _real_ flamewar, better\n> talk about rename management or revision identity.\n> \n> The thing is that most people migrated from CVS/svn, so they found\n> their new SCM to be incredibly better the existing. But it's generally\n> not _so_ much better than the other modern alternatives ;-). (and\n> don't forget to thank Darcs and Monotone who brought most of the good\n> ideas you and I are using)\n\nHeh, true enough. And the fact is they're all \"borrowing\" the\nbest ideas from one another. All of a sudden the others are all\ngetting git-like bisect and gitk guis. And of course Linus has\nsaid that he got quite a bit of inspiration from Monotone\noriginally.\n\nBeyond the distributed offline nature of using Git, the killer\n\"feature\" for me is its raw speed and flexibility[1]. It's\nreally nice to be able to branch in under a second and try\nout a line of development etc. Maybe this is just as easy\nin Bazaar but it's not true of say Mercurial. Honestly, I\njust can't imagine any other SCM meeting my needs better than\nGit. So I have a hard time taking complaints about rename\nmanagement or revision identity seriously.\n\nWhile they don't affect my usage, IMHO the two biggest failings\nof Git are its lack of a shallow clone and its reliance on shell\nand other scripting languages so there is no native Windows version.\nI'm sure both of these areas are handled better by Bazaar and/or\nsome of the other new SCMs where they'd be a better choice than\nGit.\n\nSean\n\n[1] As an aside, I don't understand why bazaar pushes the idea\nof \"plugins\". For instance someone mentioned that bazaar has\na bisect \"plugin\". Well Git was able to add a bisect \"command\"\nwithout needing a plugin architecture.. so i'm at a loss as \nto why plugins are seen as an advantage.\n"},{"id":"29314","messageId":"20061017110655.f7bcf3f1.seanlkml__7594.06292713738$1161336447$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"vpqlknf10u5.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T15:06:55Z","receivedAt":"2006-10-17T15:06:55Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 16:19:46 +0200\nMatthieu Moy wrote:\n\n> Sure. As I said before, the little add-on of checkouts is that you say\n> once \"I don't want to do local commit here\", and bzr reminds you this\n> each time you commit. Well, where it can make a difference is that it\n> does it in a transactional way, that is, you don't have that little\n> window between the time you pull and the time you push your next\n> commit. But this would really be bad luck ;-).\n\nYeah, it would be bad luck, but Git wouldn't actually let the push\nsucceed if someone had changed the upstream repo in that small window.\nIt would complain that your push wasn't a fast forward and ask you\nto update before pushing.\n\n> Sure. And at least, if you want to prove that your decentralized SCM\n> is the best, you'd better look at features other than the ability to\n> commit on a local branch ;-). If you want a _real_ flamewar, better\n> talk about rename management or revision identity.\n> \n> The thing is that most people migrated from CVS/svn, so they found\n> their new SCM to be incredibly better the existing. But it's generally\n> not _so_ much better than the other modern alternatives ;-). (and\n> don't forget to thank Darcs and Monotone who brought most of the good\n> ideas you and I are using)\n\nHeh, true enough. And the fact is they're all \"borrowing\" the\nbest ideas from one another. All of a sudden the others are all\ngetting git-like bisect and gitk guis. And of course Linus has\nsaid that he got quite a bit of inspiration from Monotone\noriginally.\n\nBeyond the distributed offline nature of using Git, the killer\n\"feature\" for me is its raw speed and flexibility[1]. It's\nreally nice to be able to branch in under a second and try\nout a line of development etc. Maybe this is just as easy\nin Bazaar but it's not true of say Mercurial. Honestly, I\njust can't imagine any other SCM meeting my needs better than\nGit. So I have a hard time taking complaints about rename\nmanagement or revision identity seriously.\n\nWhile they don't affect my usage, IMHO the two biggest failings\nof Git are its lack of a shallow clone and its reliance on shell\nand other scripting languages so there is no native Windows version.\nI'm sure both of these areas are handled better by Bazaar and/or\nsome of the other new SCMs where they'd be a better choice than\nGit.\n\nSean\n\n[1] As an aside, I don't understand why bazaar pushes the idea\nof \"plugins\". For instance someone mentioned that bazaar has\na bisect \"plugin\". Well Git was able to add a bisect \"command\"\nwithout needing a plugin architecture.. so i'm at a loss as \nto why plugins are seen as an advantage.\n"},{"id":"28971","messageId":"vpqodsbrm9o.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"4534F133.1090003@op5.se","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-17T15:32:19Z","receivedAt":"2006-10-17T15:32:19Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Andreas Ericsson writes:\n\n> This I don't understand. Let's say Alice has revision-154 in her repo,\n> located at alice.example.com. Let's say that commit is accessible with\n> the url \"alice.example.com:revision-154\". Bob pulls from her repo into\n> his own, which is located at bob.example.com.\n\nAnother equation can help.\n\nRevision Identity != Revision Number.\n\n$ bzr log --show-ids\n------------------------------------------------------------\nrevno: 1\nrevision-id: Matthieu.Moy@imag.fr-20061017152029-4c5a2861bcf23b7d\ncommitter: Matthieu Moy \nbranch nick: foo\ntimestamp: Tue 2006-10-17 17:20:29 +0200\nmessage:\n some message\n\n\nSee, bzr has this unique revision identifier (not based on a hashsum).\nThe design choice of bzr is to hide it as much as possible from the\nuser interface.\n\nThen, if I'm in the branch in which I typed this command, I can reffer\nto this revision with simply\n\n bzr whatever -r 1\n\nIn the general case, I can access it with\n\n bzr whatever -r revid:Matthieu.Moy@imag.fr-20061017152029-4c5a2861bcf23b7d\n\n(There's currently a lack in the UI to specify a remote revision-id,\nbut that's not a problem in the model itself)\n\nbzr's internal use almost exclusively revision ID (ancestry\ninformation is all about revision id), and revno are a UI layered on\ntop of it.\n\nI don't have strong needs in revision control, but I actually never\nencountered a case where I had to access a revision by providing its\nID. So, for people like me, revision numbers are sufficient, and they\nare simple (for example, I can tell without running any command that\nrevision 42 is older than revision 56 in a particular branch).\n"},{"id":"28973","messageId":"vpqk62zrm0j.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"20061017141953.GA689@dspnet.fr.eu.org","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-17T15:37:48Z","receivedAt":"2006-10-17T15:37:48Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Olivier Galibert writes:\n\n> You're not telling us bzr still follows the utterly stupid\n> update-before-commit model, right? Right?\n\nOne last time:\n\nbzr _CAN_ follow the utterly stupid update-before-commit model.\n\nIt doesn't force you to do so, obviously.\n"},{"id":"28976","messageId":"Pine.LNX.4.64.0610170921540.3962@g5.osdl.org","threadId":"5925","inReplyTo":"1161078035.9020.73.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-17T16:41:12Z","receivedAt":"2006-10-17T16:41:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 17 Oct 2006, Robert Collins wrote:\n\n> On Tue, 2006-10-17 at 11:20 +0200, Jakub Narebski wrote:\n> > \n> > ---- time --->\n> > \n> > --*--*--*--*--*--*--*--*--*-- \n> > \\ /\n> > \\-*--X--*--/\n> > \n> > The branch it used to be on is gone...\n> \n> In bzr 0.12 this is :\n> 2.1.2\n> \n> (assuming the first * is numbered '1'.)\n> \n> These numbers are fairly stable\n\nAnd here, by \"fairly stable\", you really mean \"totally idiotic\", don't \nyou?\n\nGuys, let's be blunt here, and just say you're wrong. The fact is, I've \nused a system that uses the same naming bzr does, and I've used it likely \nlonger and with a bigger project than anybody has likely _ever_ used bzr \nfor.\n\nIt sounds like bzr is doing _exactly_ what bitkeeper did. \n\nThose \"simple\" numbers are totally idiotic. And when I say \"totally \nidiotic\", please go back up a few sentences, and read those again. I know \nwhat I'm talking about. I know probably better than anybody in the bzr \ncamp.\n\nThose \"simple\" numbers are anything but. They may be short, most of the \ntime, but when you bandy things like \"-r 56\" around, what you're ignoring \nis that for a _real_ project you actually get numbers like \"1.517.3.57\", \nwhich isn't really any simpler or shorter than saying \"7786ce19\". You \nstill want to cut-and-paste it.\n\nAnd the \"simple\" numbers have a real downside, which is that THEY CHANGE.\n\nWhat happens is that somebody else started _another_ branch at revision 2, \nand did important work, and and they also had a \"2.1.2\" revision, and then \nthey merged your work, and you merged their merge back, that \"simple\" \nrevision number changed, didn't it? Suddenly \"2.1.2\" means something \ndifferent for one of the users.\n\nWe had people in the bitkeeper world that _never_ actually understood that \nthe numbers changed. The \"simple\" numbers were stable enough that a lot of \npeople thought they were real revisions, and then they were really \n_really_ confused when a number like \"1.517.3.57\" suddenly went away after \na merge, and became something else instead.\n\nAnd yes, bitkeeper had a \"real key\" internally too. If you actually wanted \nto give a real revision, you had to give something that looked a lot like \nwhat the bzr internal revision numbers look like.\n\nOf course, most users didn't even _know_ or understand those revision \nnumbers, so as a result, you had tons of people who used the \"simple\" \nthing (which was what \"bk log\" and all other tools would show), and since \nit worked quite often, they thought it was ok. And then sometimes it \ndidn't work at all, or it \"worked\" by giving the wrong commit, and it was \njust a total disaster.\n\nSomething that works \"most of the time\" is not simple to use. It's just a \nway to make people _believe_ it is simple, and then be really confused \nwhen it doesn't work.\n\nSo trust me, naming things so that the name depend on the local shape of \nthe history is idiotic. I _know_. Been there, done that.\n\nThe thing is, when I designed git, I actually had years of experience \nworking with a big project in a truly distributed manner. I _knew_ that \nhandling renames specially is a bad idea (not that you should even need to \nhave used BK to know that).\n\nAnd I _knew_ that the simple revision numbers aren't real and just cause \nconfusion.\n\n\t\t\tLinus\n"},{"id":"28986","messageId":"20061017185225.GE2867@fieldses.org","threadId":"5925","inReplyTo":"7v64ejqx3a.fsf@assigned-by-dhcp.cox.net","subject":"Re: VCS comparison table","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-10-17T18:52:25Z","receivedAt":"2006-10-17T18:52:25Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Oct 16, 2006 at 11:23:53PM -0700, Junio C Hamano wrote:\n> Aaron Bentley writes:\n> \n> > Johannes Schindelin wrote:\n> >\n> >>> You'll note we referred to that bevhavior on the page. We don't think\n> >>> what Git does is the same as supporting renames. AIUI, some Git users\n> >>> feel the same way.\n> >> \n> >> Oh, we start another flamewar again?\n> >\n> > I'd hope not. It sounds as though you feel that supporting renames in\n> > the data representation is *wrong*, and therefore it should be an insult\n> > to you if we said that Git fully supported renames.\n> \n> Not recording and not supporting are quite different things.\n\nYes. There's a risk of confusing a feature with an implementation\ndetail. From http://bazaar-vcs.org/RcsComparisons:\n\n\t\"If a user can rename a file in the RCS without loosing the RCS\n\thistory for a file, then renames are considered supported. If\n\tthe operation resultes in a delete/add (aka \"DA pair\"), then\n\trenames are not considered supported. If the operation results\n\tin a copy/delete pair, renames are considered \"somewhat\"\n\tsupported. The problem with copy support is that it is hard to\n\tdefine sane merge semantics for copies.\"\n\nThe first sentence sounds like a description of a user-visible feature.\nThe rest of it sounds like implementation.\n\nAnd git probably has some deficiencies here, but it'd be more useful to\nidentify them in terms of things a user can't do.\n\n--b.\n"},{"id":"28989","messageId":"eh39uk$k06$1@sea.gmane.org","threadId":"5925","inReplyTo":"20061017185225.GE2867@fieldses.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T19:12:54Z","receivedAt":"2006-10-17T19:12:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"J. Bruce Fields wrote:\n\n> On Mon, Oct 16, 2006 at 11:23:53PM -0700, Junio C Hamano wrote:\n>> Aaron Bentley writes:\n>> \n>> > Johannes Schindelin wrote:\n>> >\n>> >>> You'll note we referred to that bevhavior on the page. We don't think\n>> >>> what Git does is the same as supporting renames. AIUI, some Git users\n>> >>> feel the same way.\n>> >> \n>> >> Oh, we start another flamewar again?\n>> >\n>> > I'd hope not. It sounds as though you feel that supporting renames in\n>> > the data representation is *wrong*, and therefore it should be an insult\n>> > to you if we said that Git fully supported renames.\n>> \n>> Not recording and not supporting are quite different things.\n> \n> Yes. There's a risk of confusing a feature with an implementation\n> detail. From http://bazaar-vcs.org/RcsComparisons:\n> \n> \"If a user can rename a file in the RCS without loosing the RCS\n> history for a file, then renames are considered supported. If\n> the operation resultes in a delete/add (aka \"DA pair\"), then\n> renames are not considered supported. If the operation results\n> in a copy/delete pair, renames are considered \"somewhat\"\n> supported. The problem with copy support is that it is hard to\n> define sane merge semantics for copies.\"\n> \n> The first sentence sounds like a description of a user-visible feature.\n> The rest of it sounds like implementation.\n\nThe proper description would be: if we get history of file up to rename\nunrelated to the history of file before rename (\"DA pair\"), where\n\"unrelated\" means that SCM doesn't store this relation (or equivalent\ninformation), renames are not considered supported. If we get full\nhistory of file under new name, and unrelated history of file up to rename\n(\"CD pair\"), renames are not considered supported ;-)\n \n> And git probably has some deficiencies here, but it'd be more useful to\n> identify them in terms of things a user can't do.\n\nFor example:\n * if we rename (or delete) file on one branch, and then merge changes\n with other branch where such rename didn't make place, do merge do\n the correct thing.\n * can we get whole history of file, before and after rename. Can we do\n this automatically, in one go.\n * do renames are (can be) marked as such in diff output.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28991","messageId":"453532A5.6060701@utoronto.ca","threadId":"5925","inReplyTo":"4534F133.1090003@op5.se","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-17T19:44:37Z","receivedAt":"2006-10-17T19:44:37Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nAndreas Ericsson wrote:\n>> In Bazaar, a revision id always refers to the same logical entity, but\n>> it may be stored in different formats in different repositories.\n>>\n> \n> This I don't understand. Let's say Alice has revision-154 in her repo,\n> located at alice.example.com. Let's say that commit is accessible with\n> the url \"alice.example.com:revision-154\". Bob pulls from her repo into\n> his own, which is located at bob.example.com.\n> \n> Lots of questions here, so I'll split them up. Feel free to delete the\n> non-applicable ones.\n> \n> Will the commit in Bob's repo be accessible at\n> \"bob.example.com:revision-154\"?\n\nbzr differentiates between pull and merge. Pull is a mirroring command.\n So with pull, yes revision-154 will be accessible at\nbob.example.com:revision-154.\n\nWith merge, it won't. Bob can refer to it as \"154:alice.example.com\",\nthough.\n\n> If it's not, how can you backtrack from old bugreports and find the\n> error being discussed?\n\nRefer to it as 'alice.example.com revno 154' or by its revision-id.\n\n> If it is, how does that work if Bob suddenly wants to commit things\n> before Alice is done working with her changes?\n\nI don't see how this applies. You can always commit in a branch. If\nalice and bob both commit, then they are diverged and can't pull. If\nalice merges bob, then they converge and bob can pull alice.\n\n> Also, suppose they both push to a master-repo where Caesar has pushed\n> his changes and nicked the slot for revision-154. Does the master repo\n> re-organize everything and then invalidate Bob's and Alice's changes, or\n> does it tell Alice and Bob that they need to update and then reorganize\n> their repos before they're allowed to push?\n\nThey must merge from the master-repo before they can push to it.\n\n>> In our terminology, if it can diverge from the original, it's a branch,\n>> not a checkout.\n>>\n> \n> This clears things up immensely. bazaar checkout != git checkout.\n> I still fail to see how a local copy you can't commit to is useful\n\nMy bzr is run from a local copy I can't commit to. To get the latest\nchanges from http://bazaar-vcs.org, I can run \"bzr update ~/bzr/dev\".\nTo merge the latest changes into my branch, I can run\n\"bzr merge ~/bzr/dev\". It's also convenient for applying other peoples'\npatches to.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFNTKl0F+nu1YWqI0RAhRkAJ0d5KyRElEiFm/m5iRrTIk00RyqywCfe2IY\ndhW46SYWm+FTQpN30VY5tPs=\n=6SFm\n-----END PGP SIGNATURE-----\n"},{"id":"28992","messageId":"4535345C.6090905@utoronto.ca","threadId":"5925","inReplyTo":"BAYC1-PASMTP08A746E5FA6B87BC65BD37AE0E0@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-17T19:51:56Z","receivedAt":"2006-10-17T19:51:56Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nSean wrote:\n> On Tue, 17 Oct 2006 00:24:15 -0400\n> Aaron Bentley wrote:\n>>- - you can use a checkout to maintain a local mirror of a read-only\n>> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n> \n> \n> I'm not sure what you mean here. A bzr checkout doesn't have any history\n> does it?\n\nBy default, they do. You must use a flag to get a checkout with no history.\n\n> So it's not a mirror of a branch, but just a checkout of the\n> branch head?\n\nIt's a mirror of a branch, and a copy of the branch's working tree.\n\n> If so, Git can export a tarball of a branch (actually a snapshot as at\n> any given commit) which can be mirrored out.\n\nSure, and so can bzr. But using a checkout of the branch head means:\n- - No one has to do anything special to provide a working tree of a given\n revision\n- - I can still run any readonly operations I desire\n- - I can update to the latest version of bzr.dev with one command.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFNTRc0F+nu1YWqI0RAsL2AKCCG0bP8m01WVllfPMzCdFZjmgEgACfeToz\n57HERFJ6ZkkS3VrxLRnVPAs=\n=3CX7\n-----END PGP SIGNATURE-----\n"},{"id":"28993","messageId":"453536AE.6060601@utoronto.ca","threadId":"5925","inReplyTo":"45349162.90001@op5.se","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-17T20:01:50Z","receivedAt":"2006-10-17T20:01:50Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nAndreas Ericsson wrote:\n> Aaron Bentley wrote:\n>> Ah. Bazaar uses negative numbers to refer to th parents, and\n>> positive numbers to refer to the number of commits that have been made\n>> since the branch was initialized.\n>>\n> \n> What do you do once a branch has been thrown away, or has had 20 other\n> branches merged into it? Does the offset-number change for the revision\n> then, or do you track branch-points explicitly?\n\nWe always track the number of parents since the initial commit in the\nproject. Sorry, I don't think I said that clearly before.\n\n>> If I understand correctly, in Bazaar, you'd just merge the current work\n>> into 'xx/topic'.\n>>\n> \n> merge != rebase though, although they are indeed similar. Let's take the\n> example of a 'master' branch and topic branch topicA. If you rebase\n> topicA onto 'master', development will appear to have been serial.\n\nAh, now I see what you mean, and the \"graft\" plugin mentioned by others\nfills that role. I've never used it, though.\n\n> If\n> you instead merge them, it will either register as a real merge or, if\n> the branch tip of 'master' is the branch start-point of topicA, it will\n> result in a \"fast-forward\" where 'master' is just updated to the\n> branch-tip of 'topicA'.\n\nInteresting. We don't do 'fast-forward' in that case.\n\n>> I'm not sure what you mean by API, unless you mean the commandline. If\n>> that's what you mean, surely all unix commands are extensible in that\n>> regard.\n>>\n> \n> I'm fairly certain he's talking about the API in the sense it's being\n> talked about in every other application. Extensive work has been made to\n> libify a lot of the git code, which means that most git commands are\n> made up of less than 400 lines of C code, where roughly 80% of the code\n> is command-specific (i.e., argument parsing and presentation).\n\nAh, okay.\n\nSo it sounds to me like git is extensible, though not as thoroughly as bzr.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFNTat0F+nu1YWqI0RAn9aAJ9WzMrM72be+3SlwCpvJXQ/X2Y3nQCfeYk3\nNTIJuZSze9URUaAsiO4Hu5o=\n=9nvr\n-----END PGP SIGNATURE-----\n"},{"id":"28998","messageId":"200610172301.27101.jnareb@gmail.com","threadId":"5925","inReplyTo":"453536AE.6060601@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T21:01:26Z","receivedAt":"2006-10-17T21:01:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> Andreas Ericsson wrote:\n>> Aaron Bentley wrote:\n>>> Ah. Bazaar uses negative numbers to refer to th parents, and\n>>> positive numbers to refer to the number of commits that have been made\n>>> since the branch was initialized.\n>>>\n>>\n>> What do you do once a branch has been thrown away, or has had 20 other\n>> branches merged into it? Does the offset-number change for the revision\n>> then, or do you track branch-points explicitly?\n> \n> We always track the number of parents since the initial commit in the\n> project. Sorry, I don't think I said that clearly before.\n\nWhile this I think is quite reliable (there was idea to store \"generation\nnumber\" with each commit, e.g. using not implemented \"note\" header, or\ncommit-id to generation number \"database\" as a better heuristic than\ntimestamp for revision ordering in git-rev-list output), and probably\nindependent on repository (it is global property of commit history,\nand commit history is included in sha1 of its parents), numbering branching\npoints is unreliable, as is relying on branch names.\n \n>>> If I understand correctly, in Bazaar, you'd just merge the current work\n>>> into 'xx/topic'.\n>>>\n>>\n>> merge != rebase though, although they are indeed similar. Let's take the\n>> example of a 'master' branch and topic branch topicA. If you rebase\n>> topicA onto 'master', development will appear to have been serial.\n> \n> Ah, now I see what you mean, and the \"graft\" plugin mentioned by others\n> fills that role. I've never used it, though.\n\nVery useful as a kind of poor-man's-Quilt (or StGit). You develop some\nfeature step by step, commit by commit in your repository cooking it\nin topic branch. Then before sending it to mailing list or maintainer\nas a series of patches (using git-format-patch and git-send-email)\nyou rebase it on top of current work (current state), to ensure that\nit would apply cleanly.\n \n>> If\n>> you instead merge them, it will either register as a real merge or, if\n>> the branch tip of 'master' is the branch start-point of topicA, it will\n>> result in a \"fast-forward\" where 'master' is just updated to the\n>> branch-tip of 'topicA'.\n> \n> Interesting. We don't do 'fast-forward' in that case.\n\nFast-forward is a really good idea. Perhaps you could implement it,\nif it is not hidden under different name?\n \n>>> I'm not sure what you mean by API, unless you mean the commandline. If\n>>> that's what you mean, surely all unix commands are extensible in that\n>>> regard.\n>>>\n>>\n>> I'm fairly certain he's talking about the API in the sense it's being\n>> talked about in every other application. Extensive work has been made to\n>> libify a lot of the git code, which means that most git commands are\n>> made up of less than 400 lines of C code, where roughly 80% of the code\n>> is command-specific (i.e., argument parsing and presentation).\n> \n> Ah, okay.\n> \n> So it sounds to me like git is extensible, though not as thoroughly as bzr.\n\nI think having good API for C, shell and Perl (and to lesser extent for any\nscripting language) means that it is extensible more. Git is not as of yet\nlibified; when it would be we could think about bindings for other\nprogramming languages (there is preliminary Java binding/interface).\n-- \nJakub Narebski\nPoland\n"},{"id":"29000","messageId":"45354AD0.1020107@utoronto.ca","threadId":"5925","inReplyTo":"200610172301.27101.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-17T21:27:44Z","receivedAt":"2006-10-17T21:27:44Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJakub Narebski wrote:\n>>Ah, now I see what you mean, and the \"graft\" plugin mentioned by others\n>>fills that role. I've never used it, though.\n> \n> \n> Very useful as a kind of poor-man's-Quilt (or StGit). You develop some\n> feature step by step, commit by commit in your repository cooking it\n> in topic branch. Then before sending it to mailing list or maintainer\n> as a series of patches (using git-format-patch and git-send-email)\n> you rebase it on top of current work (current state), to ensure that\n> it would apply cleanly.\n\nWhat is the bad side of using merge in this situation?\n\n>>Interesting. We don't do 'fast-forward' in that case.\n> \n> \n> Fast-forward is a really good idea. Perhaps you could implement it,\n> if it is not hidden under different name?\n\nWe support it as 'pull', but merge doesn't do it automatically, because\nwe'd rather have merge behave the same all the time, and because 'pull'\nthrows away your local commit ordering.\n\n>>So it sounds to me like git is extensible, though not as thoroughly as bzr.\n> \n> \n> I think having good API for C, shell and Perl (and to lesser extent for any\n> scripting language) means that it is extensible more.\n\nI guess it's a value judgement on which is more important to extensibility:\n\nGit has more language support.\n\nBzr has plugin autoloading, Protocol plugins, Repository format plugins,\nand more. Because Python supports monkey-patching, a plugin can change\nabsolutely anything.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFNUrP0F+nu1YWqI0RAizXAJ0Wnf2ZoIRpaba3mX2L4pN9XcWDPQCePtg/\nG/W6Oxm+kd8SzhGEEfLAxL8=\n=VqC7\n-----END PGP SIGNATURE-----\n"},{"id":"29003","messageId":"200610172351.17377.jnareb@gmail.com","threadId":"5925","inReplyTo":"45354AD0.1020107@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T21:51:16Z","receivedAt":"2006-10-17T21:51:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> Jakub Narebski wrote:\n\n>>>Ah, now I see what you mean, and the \"graft\" plugin mentioned by others\n>>>fills that role. I've never used it, though.\n>>\n>> Very useful as a kind of poor-man's-Quilt (or StGit). You develop some\n>> feature step by step, commit by commit in your repository cooking it\n>> in topic branch. Then before sending it to mailing list or maintainer\n>> as a series of patches (using git-format-patch and git-send-email)\n>> you rebase it on top of current work (current state), to ensure that\n>> it would apply cleanly.\n> \n> What is the bad side of using merge in this situation?\n\nWe want linear history, not polluted by merges. For example you cannot\nsend merge commit via email. Another problem is that you want to\nsend _series_ of patches, string of commits (revisions), creating feature\npart by part, with clean history; with merge you get _final result_\nwhich will apply cleanly, with rebase you would get that series\nof patches will apply cleanly.\n \n>>>Interesting. We don't do 'fast-forward' in that case.\n>>\n>> Fast-forward is a really good idea. Perhaps you could implement it,\n>> if it is not hidden under different name?\n> \n> We support it as 'pull', but merge doesn't do it automatically, because\n> we'd rather have merge behave the same all the time, and because 'pull'\n> throws away your local commit ordering.\n\nI smell yet another terminology conflict (although this time fault is\non the git side), namely that in git terminology \"pull\" is \"fetch\"\n(i.e. getting changes done in remote repository since laste \"fetch\"\nor since \"clone\") followed by merge. pull = fetch + merge.\n\n>>>So it sounds to me like git is extensible, though not as thoroughly as bzr.\n>>\n>>\n>> I think having good API for C, shell and Perl (and to lesser extent for any\n>> scripting language) means that it is extensible more.\n> \n> I guess it's a value judgement on which is more important to extensibility:\n> \n> Git has more language support.\n> \n> Bzr has plugin autoloading, Protocol plugins, Repository format plugins,\n> and more. Because Python supports monkey-patching, a plugin can change\n> absolutely anything.\n\nWhich is _not_ a good idea. Git is created in such way, that the repository\nis abstracted away (introduction of pack format, and improving pack format\ncan and was done \"behind the scenes\", not changing any porcelanish (user)\ncommands), but we don't want any chage that would change this abstraction.\nChanging repository format is not a good idea for \"dumb\" protocols; native\nprotocol is quite extensible (for example there was introduced multi-ack\nextension for better downloading of multiple branches with lesser number\nof object in the pack sent; even earlier there were intoduced thin packs),\nand does a kind of feature detection between client and server. Adding\ncURL based FTP read-only support to existing HTTP support was a matter\nof few lines, if I remember correctly.\n\nBesides, if monkey-patching is something akin to advices, I guess that\nperformance might suffer.\n\n\nTo make perhaps not that good analogy. In git adding new commands is\nlike adding new filesystem to Linux kernel using existing VFS interface,\nor existing FUSE/LUFS interface. In Bazaar adding new command is like\nwriting new filesystem support (plugin) in mikrokernel like L4/Mach.\n(And please take note for what project git was created for :-))\n\n-- \nJakub Narebski\nShadeHawk on #git\nPoland\n"},{"id":"29005","messageId":"BAYC1-PASMTP07AB11A64250AAF683424DAE0E0@CEZ.ICE","threadId":"5925","inReplyTo":"45354AD0.1020107@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T22:00:51Z","receivedAt":"2006-10-17T22:00:51Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 17:27:44 -0400\nAaron Bentley wrote:\n\n> Bzr has plugin autoloading, Protocol plugins, Repository format plugins,\n> and more. Because Python supports monkey-patching, a plugin can change\n> absolutely anything.\n\nBut really why does any of that matter? This is the open source world.\nWe don't need plugins to extend features, we just add the feature to\nthe source. The example I asked about earlier is a case in point. \nApparently in bzr \"bisect\" was implemented as a plugin, yet in Git it\nwas implemented as a command without any issue at all, no plugins\nneeded, and its compiled and runs at machine speed.\n\nSean\n"},{"id":"29313","messageId":"20061017180051.5453ba90.seanlkml__46087.8169666559$1161336406$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"45354AD0.1020107@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T22:00:51Z","receivedAt":"2006-10-17T22:00:51Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 17:27:44 -0400\nAaron Bentley wrote:\n\n> Bzr has plugin autoloading, Protocol plugins, Repository format plugins,\n> and more. Because Python supports monkey-patching, a plugin can change\n> absolutely anything.\n\nBut really why does any of that matter? This is the open source world.\nWe don't need plugins to extend features, we just add the feature to\nthe source. The example I asked about earlier is a case in point. \nApparently in bzr \"bisect\" was implemented as a plugin, yet in Git it\nwas implemented as a command without any issue at all, no plugins\nneeded, and its compiled and runs at machine speed.\n\nSean\n"},{"id":"29006","messageId":"Pine.LNX.4.64.0610171448150.3962@g5.osdl.org","threadId":"5925","inReplyTo":"45354AD0.1020107@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-17T22:03:34Z","receivedAt":"2006-10-17T22:03:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 17 Oct 2006, Aaron Bentley wrote:\n> \n> >>Interesting. We don't do 'fast-forward' in that case.\n> > \n> > Fast-forward is a really good idea. Perhaps you could implement it,\n> > if it is not hidden under different name?\n> \n> We support it as 'pull', but merge doesn't do it automatically, because\n> we'd rather have merge behave the same all the time, and because 'pull'\n> throws away your local commit ordering.\n\nExcuse me? What does that \"throws away your local commit ordering\" mean?\n\nA fast-forward does no such thing. It leaves the local commit ordering \nalone, it just appends other things on top of it. It's the only sane thing \nyou can do, since the work you merged was already based on your top \ncommit.\n\nSo generating an extra \"merge\" commit would be actively wrong, and adds \n\"history\" that is not history at all.\n\nIt also means that if people merge back and forth from each other, you get \ninto an endless loop of useless merge commits. What's the point? They only \nclutter up the history, and they mean that you can never agree on a common \nstate.\n\nThere's no reason _ever_ to not just fast-forward if one repository is a \nstrict superset of the other.\n\nYou must be doing something wrong. Is it just that people want to pee in \nthe snow and leave their mark?\n\n\t\tLinus\n"},{"id":"29008","messageId":"1161124078.9020.88.camel@localhost.localdomain","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610170921540.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Robert Collins","fromEmail":"robertc@robertcollins.net","sentAt":"2006-10-17T22:27:58Z","receivedAt":"2006-10-17T22:27:58Z","isPatch":false,"sender":{"key":"robertc@robertcollins.net","avatar":null},"body":"On Tue, 2006-10-17 at 09:41 -0700, Linus Torvalds wrote:\n> \n> On Tue, 17 Oct 2006, Robert Collins wrote:\n> \n> > On Tue, 2006-10-17 at 11:20 +0200, Jakub Narebski wrote:\n> > > \n> > > ---- time --->\n> > > \n> > > --*--*--*--*--*--*--*--*--*-- \n> > > \\ /\n> > > \\-*--X--*--/\n> > > \n> > > The branch it used to be on is gone...\n> > \n> > In bzr 0.12 this is :\n> > 2.1.2\n> > \n> > (assuming the first * is numbered '1'.)\n> > \n> > These numbers are fairly stable\n> \n> And here, by \"fairly stable\", you really mean \"totally idiotic\", don't \n> you?\n> \n> Guys, let's be blunt here, and just say you're wrong. The fact is, I've \n> used a system that uses the same naming bzr does, and I've used it likely \n> longer and with a bigger project than anybody has likely _ever_ used bzr \n> for.\n> \n> It sounds like bzr is doing _exactly_ what bitkeeper did. \n> \n> Those \"simple\" numbers are totally idiotic. And when I say \"totally \n> idiotic\", please go back up a few sentences, and read those again. I know \n> what I'm talking about. I know probably better than anybody in the bzr \n> camp.\n\nBe as blunt as you want. You're expressing an opinion, and thats fine. I\nhappen to think that we're right : users appear to really appreciate\nthis bit of the UI, and I've not yet seen any evidence of confusion\nabout it - though I will admit there is the possibility of that\noccurring.\n\nI think its completely ok that git and bzr have made different choices\nin this regard, but I *dont* think our choice is in any regard 'totally\nidiotic'.\n\n[snip examples that are clearly predicated on how bk worked, not on how\nbzr works].\n\n-Rob\n-- \nGPG key available at: .\n"},{"id":"29009","messageId":"4535590C.4000004@utoronto.ca","threadId":"5925","inReplyTo":"200610172351.17377.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-17T22:28:28Z","receivedAt":"2006-10-17T22:28:28Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJakub Narebski wrote:\n> Aaron Bentley wrote:\n\n>> What is the bad side of using merge in this situation?\n> \n> We want linear history, not polluted by merges. For example you cannot\n> send merge commit via email.\n\nOh. Bazaar supports sending merge commits by email.\n\n> Another problem is that you want to\n> send _series_ of patches, string of commits (revisions), creating feature\n> part by part, with clean history; with merge you get _final result_\n> which will apply cleanly, with rebase you would get that series\n> of patches will apply cleanly.\n\nYes, that's something that I'd heard about the kernel development\nmethodology-- that a series of small patches is preferred to one patch\nthat makes the whole change.\n\nThat's not the way we operate. We like to review all the changes at\nonce. But because bundles are applied with a 'merge' command, not a\n'patch' command, an old bundle will tend to apply more cleanly than an\nold patch would.\n\n> I smell yet another terminology conflict (although this time fault is\n> on the git side), namely that in git terminology \"pull\" is \"fetch\"\n> (i.e. getting changes done in remote repository since laste \"fetch\"\n> or since \"clone\") followed by merge. pull = fetch + merge.\n\nI guess so, since git merge will do fast-forward after a fetch.\n\n>> and more. Because Python supports monkey-patching, a plugin can change\n>> absolutely anything.\n> \n> Which is _not_ a good idea. Git is created in such way, that the repository\n> is abstracted away (introduction of pack format, and improving pack format\n> can and was done \"behind the scenes\", not changing any porcelanish (user)\n> commands), but we don't want any chage that would change this abstraction.\n\nI'm not sure what you think Bazaar does. In Bazaar, a repository format\nplugin implements the same API that a native repository format does.\n\nThis is how bzr supports Subversion, Mercurial and Git repositories.\n\n> Changing repository format is not a good idea for \"dumb\" protocols; \n\nI can't parse this. Repository formats and protocols are different\nthings, right?\n\n> native\n> protocol is quite extensible\n\nI was meaning dumb protocol extension. I can't say how extensible the\nbzr native protocol is.\n> Adding\n> cURL based FTP read-only support to existing HTTP support was a matter\n> of few lines, if I remember correctly.\n\nWe support read and write over native, ftp and WebDAV (a plugin). We\nalso have readonly http support.\n\n> Besides, if monkey-patching is something akin to advices, I guess that\n> performance might suffer.\n\nNo, monkey-patched code executes at the same speed as unpatched code.\nThere are arguments against monkey-patching, but speed is not one of them.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNVkM0F+nu1YWqI0RAjCaAJwOcWSUdVy7RpUZROJVxAC9aj/V/wCfUg0T\nuHkdc9k6i+v0QnhEvTXdszM=\n=YO8G\n-----END PGP SIGNATURE-----\n"},{"id":"29010","messageId":"45355CBB.80108@utoronto.ca","threadId":"5925","inReplyTo":"BAYC1-PASMTP07AB11A64250AAF683424DAE0E0@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-17T22:44:11Z","receivedAt":"2006-10-17T22:44:11Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nSean wrote:\n> On Tue, 17 Oct 2006 17:27:44 -0400\n> Aaron Bentley wrote:\n> \n>> Bzr has plugin autoloading, Protocol plugins, Repository format plugins,\n>> and more. Because Python supports monkey-patching, a plugin can change\n>> absolutely anything.\n> \n> But really why does any of that matter? This is the open source world.\n> We don't need plugins to extend features, we just add the feature to\n> the source.\n\nThat can lead to feature bloat. Some plugins are not useful to\neveryone, e.g. Mercurial repository support. Some plugins introduce\nadditional dependencies that we don't want to have in the core (e.g. the\nrsync, baz-import and graph-ancestry commands).\n\nPlugins also don't have a Bazaar's rigid release cycle, testing\nrequirements and coding conventions, so they are a convenient way to try\nout an idea, before committing to the effort of getting it merged into\nthe core.\n\n> The example I asked about earlier is a case in point. \n> Apparently in bzr \"bisect\" was implemented as a plugin, yet in Git it\n> was implemented as a command without any issue at all, no plugins\n> needed, and its compiled and runs at machine speed.\n\nThe bisect plugin is just as performant as any other bzr command. (The\nwhole VCS is in Python.) Most people don't use it, so we don't ship it\nas part of the base install, but anyone who wants it can have it.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNVy70F+nu1YWqI0RAnlxAJ9+ZXryG/KJxi6hjpz+U/gU3y06MQCdH2Ez\ncFlnxwWksB+q2b1dXI3cfwo=\n=HAy6\n-----END PGP SIGNATURE-----\n"},{"id":"29011","messageId":"45355EEE.3060105@utoronto.ca","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610171448150.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-17T22:53:34Z","receivedAt":"2006-10-17T22:53:34Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nLinus Torvalds wrote:\n> \n> On Tue, 17 Oct 2006, Aaron Bentley wrote:\n>>>> Interesting. We don't do 'fast-forward' in that case.\n>>> Fast-forward is a really good idea. Perhaps you could implement it,\n>>> if it is not hidden under different name?\n>> We support it as 'pull', but merge doesn't do it automatically, because\n>> we'd rather have merge behave the same all the time, and because 'pull'\n>> throws away your local commit ordering.\n> \n> Excuse me? What does that \"throws away your local commit ordering\" mean?\n\nSay this is the ordering in branch A:\n\na\n|\nb\n|\nc\n\nSay this is the ordering in branch B:\n\na\n|\nb\n|\\\nd c\n|/\ne\n\nWhen A pulls B, it gets the same ordering as B has. If B did not have e\nand c, the pull would fail.\n\n> So generating an extra \"merge\" commit would be actively wrong, and adds \n> \"history\" that is not history at all.\n\nIt's not a tree change, but it records the fact that one branch merged\nthe other.\n\n> It also means that if people merge back and forth from each other, you get \n> into an endless loop of useless merge commits.\n\nYou can pull if you don't want that. We haven't found that people are\nvery fussed about it.\n\n> There's no reason _ever_ to not just fast-forward if one repository is a \n> strict superset of the other.\n\nMaybe not in Git.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNV7u0F+nu1YWqI0RAhGtAJwOlWpl088pbl63EHyF04qQCYlXBgCfW0Tm\ncfXuE0vqeWelfFbpzffiCNI=\n=McQ2\n-----END PGP SIGNATURE-----\n"},{"id":"29012","messageId":"BAYC1-PASMTP01369CD694D75CB61ACCC7AE0E0@CEZ.ICE","threadId":"5925","inReplyTo":"45355CBB.80108@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T22:56:22Z","receivedAt":"2006-10-17T22:56:22Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 18:44:11 -0400\nAaron Bentley wrote:\n\n> That can lead to feature bloat. Some plugins are not useful to\n> everyone, e.g. Mercurial repository support. Some plugins introduce\n> additional dependencies that we don't want to have in the core (e.g. the\n> rsync, baz-import and graph-ancestry commands).\n\nShrug, it's really not that tough to do in regular ole source code.\nOn Fedora for instance you have your choice of which rpms you want\nto install to get the features of Git you want.\n\n> Plugins also don't have a Bazaar's rigid release cycle, testing\n> requirements and coding conventions, so they are a convenient way to try\n> out an idea, before committing to the effort of getting it merged into\n> the core.\n\nHmm.. It's pretty easy to test out Git ideas too. People do it all\nthe time, and without plugins. Junio maintains several such trees\nfor instance. Dunno.. I just think plugs _sounds_ good to developers\nwithout much real benefit to users over regular ole source code.\n\n> The bisect plugin is just as performant as any other bzr command. (The\n> whole VCS is in Python.) Most people don't use it, so we don't ship it\n> as part of the base install, but anyone who wants it can have it.\n\nSure, and anyone who wants to use StGit on top of Git can download and\nuse it as well.\n\nSean\n"},{"id":"29306","messageId":"20061017185622.30fbc6c0.seanlkml__41847.3392761827$1161334883$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"45355CBB.80108@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T22:56:22Z","receivedAt":"2006-10-17T22:56:22Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 18:44:11 -0400\nAaron Bentley wrote:\n\n> That can lead to feature bloat. Some plugins are not useful to\n> everyone, e.g. Mercurial repository support. Some plugins introduce\n> additional dependencies that we don't want to have in the core (e.g. the\n> rsync, baz-import and graph-ancestry commands).\n\nShrug, it's really not that tough to do in regular ole source code.\nOn Fedora for instance you have your choice of which rpms you want\nto install to get the features of Git you want.\n\n> Plugins also don't have a Bazaar's rigid release cycle, testing\n> requirements and coding conventions, so they are a convenient way to try\n> out an idea, before committing to the effort of getting it merged into\n> the core.\n\nHmm.. It's pretty easy to test out Git ideas too. People do it all\nthe time, and without plugins. Junio maintains several such trees\nfor instance. Dunno.. I just think plugs _sounds_ good to developers\nwithout much real benefit to users over regular ole source code.\n\n> The bisect plugin is just as performant as any other bzr command. (The\n> whole VCS is in Python.) Most people don't use it, so we don't ship it\n> as part of the base install, but anyone who wants it can have it.\n\nSure, and anyone who wants to use StGit on top of Git can download and\nuse it as well.\n\nSean\n"},{"id":"29013","messageId":"200610180057.25411.jnareb@gmail.com","threadId":"5925","inReplyTo":"4535590C.4000004@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T22:57:25Z","receivedAt":"2006-10-17T22:57:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> Jakub Narebski wrote:\n>> Aaron Bentley wrote:\n> \n>>> What is the bad side of using merge in this situation?\n>>\n>> We want linear history, not polluted by merges. For example you cannot\n>> send merge commit via email.\n> \n> Oh. Bazaar supports sending merge commits by email.\n> \n>> Another problem is that you want to\n>> send _series_ of patches, string of commits (revisions), creating feature\n>> part by part, with clean history; with merge you get _final result_\n>> which will apply cleanly, with rebase you would get that series\n>> of patches will apply cleanly.\n> \n> Yes, that's something that I'd heard about the kernel development\n> methodology-- that a series of small patches is preferred to one patch\n> that makes the whole change.\n> \n> That's not the way we operate. We like to review all the changes at\n> once. But because bundles are applied with a 'merge' command, not a\n> 'patch' command, an old bundle will tend to apply more cleanly than an\n> old patch would.\n\nPerhaps it would be nice to have \"bundles\" in git too. As of now\nwe can save arbitrary part of history in a pack, but it is binary\nnot textual representation.\n\nSome of git workflow stems from old, pre-SCM Linux kernel workflow\nof sending _patches_ via email.\n\n\nBy the way, are bzr \"bundles\" compatibile with ordinary patch?\ngit-format-patch patches are. They have additional metainfo,\nbut they are patches in heart.\n \n>>> and more. Because Python supports monkey-patching, a plugin can change\n>>> absolutely anything.\n>>\n>> Which is _not_ a good idea. Git is created in such way, that the repository\n>> is abstracted away (introduction of pack format, and improving pack format\n>> can and was done \"behind the scenes\", not changing any porcelanish (user)\n>> commands), but we don't want any chage that would change this abstraction.\n> \n> I'm not sure what you think Bazaar does. In Bazaar, a repository format\n> plugin implements the same API that a native repository format does.\n> \n> This is how bzr supports Subversion, Mercurial and Git repositories.\n\nBut if I remember correctly Subversion does not remember merge points\n(merge commits), so how can you provide full Bazaar-NG compatibility\nwith Subversion repository as backend? Some repository formats lack\nsome features. Besides, as I said repository database and stuff is\nquite well abstracted away.\n\nIn git we have import tools (most of them capable of incremental import),\na few exchange tools like git-cvsexportcommit, git-cvsserver, and\nTailor-like git-svn.\n \n>> Changing repository format is not a good idea for \"dumb\" protocols;\n> \n> I can't parse this. Repository formats and protocols are different\n> things, right?\n\n\"Dumb\" protocols in git are protocols for which server provides access\nto contents git repository plus some additional info (usually generated\nusing hooks). The client (be it git-fetch or git-push) discovers which\nfiles to download or what to upload, but it only can download repository\n\"as is\". So if server repository was created with repository format plugin,\nand client doesn't have said plugin, you are out of luck.\n \n>> native protocol is quite extensible\n> \n> I was meaning dumb protocol extension. I can't say how extensible the\n> bzr native protocol is.\n\nNative git protocol (git:// and git+ssh://) does feature discovery, then\nnegotiates what contents has to be send, and finally tries to send minimal\nnumber of objects.\n\n>> Adding\n>> cURL based FTP read-only support to existing HTTP support was a matter\n>> of few lines, if I remember correctly.\n> \n> We support read and write over native, ftp and WebDAV (a plugin). We\n> also have readonly http support.\n\nGit has read-only access over git:// protocol (served by git-daemon on\nport 9418), read-write access over git+ssh:// protocol (you can limit\nexposition using git-shell), read-only access via HTTP, HTTPS, FTP \"dumb\"\nprotocols, read-write access via WebDAV \"dumb\" protocol.\n\nGit is open-source, we don't need plugins ;-)\n-- \nJakub Narebski\nShadeHawk on #git\nPoland\n"},{"id":"29014","messageId":"200610180059.27799.jnareb@gmail.com","threadId":"5925","inReplyTo":"200610180057.25411.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T22:59:27Z","receivedAt":"2006-10-17T22:59:27Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> Git has read-only access over git:// protocol (served by git-daemon on\n> port 9418), read-write access over git+ssh:// protocol (you can limit\n> exposition using git-shell), read-only access via HTTP, HTTPS, FTP \"dumb\"\n> protocols, read-write access via WebDAV \"dumb\" protocol.\n\nAnd deprecated read-only (I think), deprecated, suggested to use only\nfor cloning, rsync:// \"dumb\" protocol.\n-- \nJakub Narebski\nPoland\n"},{"id":"29015","messageId":"Pine.LNX.4.64.0610171605440.3962@g5.osdl.org","threadId":"5925","inReplyTo":"45355EEE.3060105@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-17T23:09:33Z","receivedAt":"2006-10-17T23:09:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 17 Oct 2006, Aaron Bentley wrote:\n> > \n> > Excuse me? What does that \"throws away your local commit ordering\" mean?\n> \n> Say this is the ordering in branch A:\n> \n> a\n> |\n> b\n> |\n> c\n> \n> Say this is the ordering in branch B:\n> \n> a\n> |\n> b\n> |\\\n> d c\n> |/\n> e\n> \n> When A pulls B, it gets the same ordering as B has. If B did not have e\n> and c, the pull would fail.\n\nSure. But that doesn't throw away any local commit ordering. The original \norder (a->b->c) is still very much there. The fact that there was a branch \noff 'b' and there is also (a->b->d) and a merge of the two at 'e' doesn't \ntake away anything from the original local commit ordering. \n\n> > So generating an extra \"merge\" commit would be actively wrong, and adds \n> > \"history\" that is not history at all.\n> \n> It's not a tree change, but it records the fact that one branch merged\n> the other.\n\nBut that's a totally specious \"record\". It has no meaning in a distributed \nSCM. There is absolutely zero semantic information in it.\n\nThe fact that you _locally_ want to remember where you were is a total \nnon-issue for a true distributed system. You shouldn't force everybody \nelse to see your local view - since it has no relevance to them, and \ndoesn't add any information.\n\n> Maybe not in Git.\n\nI don't think there is any in bzr either. Can you explain?\n\nIn other words, the empty merge is totally semantically empty even in the \nbazaar world. Why does it exist?\n\n\t\tLinus\n"},{"id":"29016","messageId":"200610180111.09068.jnareb@gmail.com","threadId":"5925","inReplyTo":"BAYC1-PASMTP01369CD694D75CB61ACCC7AE0E0@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T23:11:08Z","receivedAt":"2006-10-17T23:11:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"/me too post ;-)\n\nSean wrote:\n> On Tue, 17 Oct 2006 18:44:11 -0400\n> Aaron Bentley wrote:\n> \n> > That can lead to feature bloat. Some plugins are not useful to\n> > everyone, e.g. Mercurial repository support. Some plugins introduce\n> > additional dependencies that we don't want to have in the core (e.g. the\n> > rsync, baz-import and graph-ancestry commands).\n> \n> Shrug, it's really not that tough to do in regular ole source code.\n> On Fedora for instance you have your choice of which rpms you want\n> to install to get the features of Git you want.\n\ngit-core, git-email, git-arch, git-cvs, git-svn, gitk\n(and git-debuginfo).\n\ngitk and gitweb were developed in its own repositories, but some time\nago got incorporated into git repository. We have contrib/ area.\nQGit, Cogito, StGit are developed separately.\n\n> > Plugins also don't have a Bazaar's rigid release cycle, testing\n> > requirements and coding conventions, so they are a convenient way to try\n> > out an idea, before committing to the effort of getting it merged into\n> > the core.\n> \n> Hmm.. It's pretty easy to test out Git ideas too. People do it all\n> the time, and without plugins. Junio maintains several such trees\n> for instance. Dunno.. I just think plugs _sounds_ good to developers\n> without much real benefit to users over regular ole source code.\n\nThanks to many low lewel (plumbing in git-speak) commands it is very\neasy to prototype (write actually) new command in language suitable\nfor fast prototyping, i.e. shell or Perl (or Python, too). Then if it is\nperformance critical, or if it get troublesome to manage shell script\nversion, it gets rewritten in C as builtin command.\n"},{"id":"29017","messageId":"Pine.LNX.4.64.0610171610270.3962@g5.osdl.org","threadId":"5925","inReplyTo":"200610180057.25411.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-17T23:16:15Z","receivedAt":"2006-10-17T23:16:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Jakub Narebski wrote:\n> \n> Perhaps it would be nice to have \"bundles\" in git too. As of now\n> we can save arbitrary part of history in a pack, but it is binary\n> not textual representation.\n> \n> Some of git workflow stems from old, pre-SCM Linux kernel workflow\n> of sending _patches_ via email.\n\nActually, the reason to _not_ have bundles very much stems from the fact \nthat BK did have bundles, and they were pretty horrid.\n\nIt would be easy to send the exact same data as the native git protocol \nsends over ssh (or the git port) as an email encoding. We did that a few \ntimes with BK (there it's called \"bk send\" and \"bk receive\" to pack and \nunpack those things), and after doing it about five times, I absolutely \nrefused to ever do it again. There's just no point, except to make your \nmailbox grow without bounds, and it was really annoying. \n\nSo sending things as patches is just a lot more convenient if you want \nemails. And if you want to sync two repos directly, I think we've gotten \nsufficiently past the old UUCP days when you want to use email as a \npacketization medium.\n\nThat said, \"bundles\" certainly wouldn't be _hard_ to do. And as long as \nnobody tries to send _me_ any of them, I won't mind ;)\n\n\t\tLinus\n"},{"id":"29018","messageId":"BAYC1-PASMTP05863EBDBCACA3C4F20E1CAE0E0@CEZ.ICE","threadId":"5925","inReplyTo":"1161124078.9020.88.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T23:18:38Z","receivedAt":"2006-10-17T23:18:38Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 18 Oct 2006 08:27:58 +1000\nRobert Collins wrote:\n\n> Be as blunt as you want. You're expressing an opinion, and thats fine. I\n> happen to think that we're right : users appear to really appreciate\n> this bit of the UI, and I've not yet seen any evidence of confusion\n> about it - though I will admit there is the possibility of that\n> occurring.\n\nYeah, but it's an opinion that is based on a huge real world project with\nhundreds of developers. If Bazaar is ever used in a project of that\nsize it may just see the same type of issues as Bk. As has been mentioned\nelsewhere, Git users really appreciate the short forms it provides for\nreferencing commits, so much so that there is no reason to invent a\nnew (unstable) numbering system or attempt to hide the true underlying\ncommit identities.\n\nJust out of curiosity is there a Bazaar repo of the Linux kernel available\nsomewhere?\n\nSean\n"},{"id":"29305","messageId":"20061017191838.1c36499b.seanlkml__27169.9432204061$1161334600$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"1161124078.9020.88.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-17T23:18:38Z","receivedAt":"2006-10-17T23:18:38Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 18 Oct 2006 08:27:58 +1000\nRobert Collins wrote:\n\n> Be as blunt as you want. You're expressing an opinion, and thats fine. I\n> happen to think that we're right : users appear to really appreciate\n> this bit of the UI, and I've not yet seen any evidence of confusion\n> about it - though I will admit there is the possibility of that\n> occurring.\n\nYeah, but it's an opinion that is based on a huge real world project with\nhundreds of developers. If Bazaar is ever used in a project of that\nsize it may just see the same type of issues as Bk. As has been mentioned\nelsewhere, Git users really appreciate the short forms it provides for\nreferencing commits, so much so that there is no reason to invent a\nnew (unstable) numbering system or attempt to hide the true underlying\ncommit identities.\n\nJust out of curiosity is there a Bazaar repo of the Linux kernel available\nsomewhere?\n\nSean\n"},{"id":"29019","messageId":"200610180124.28048.jnareb@gmail.com","threadId":"5925","inReplyTo":"45355EEE.3060105@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T23:24:27Z","receivedAt":"2006-10-17T23:24:27Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n\n[...]\n\n>> So generating an extra \"merge\" commit would be actively wrong, and adds\n>> \"history\" that is not history at all.\n> \n> It's not a tree change, but it records the fact that one branch merged\n> the other.\n> \n>> It also means that if people merge back and forth from each other, you get\n>> into an endless loop of useless merge commits.\n> \n> You can pull if you don't want that.  We haven't found that people are\n> very fussed about it.\n> \n>> There's no reason _ever_ to not just fast-forward if one repository is a\n>> strict superset of the other.\n> \n> Maybe not in Git.\n\nThink what the existence of merge commit is for. It is a place where\nwe can record how we resolved conflicts. It means: we _merged_ (joined)\ntwo (or more: does bzr support octopus merge?) lines of development.\n\nMerge commit in fast-forward case is only marking \"here we did a pull\"\n(here we downloaded from other repository). It is just a marker which\nplace is in reflog, not in history. It is only cluttering history.\n\n\nBesides one of canonical workflows used and encouraged by git is:\n\n * repository A stores does it's own work on branch 'master',\n and fetches changes from 'master' branch of repository B\n into branch 'origin'. \"git pull origin\" when on branch 'master'\n fetches changes from 'master' branch of repository B (requiring\n usually that it fast-forwards) into branch 'origin', then\n merges branch 'origin' into branch 'master', automatically\n creating merge commit message.\n\n * repository B does it's own work on branch 'master',\n and fetches changes from 'master' branch of repository A\n into [tracking] branch 'origin'. (...)\n\nInstead of pull/fetch, we could use push.\n-- \nJakub Narebski\nPoland\n"},{"id":"29020","messageId":"20061017232818.GF20017@pasky.or.cz","threadId":"5925","inReplyTo":"453532A5.6060701@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-17T23:28:18Z","receivedAt":"2006-10-17T23:28:18Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Oct 17, 2006 at 09:44:37PM CEST, I got a letter\nwhere Aaron Bentley said that...\n> Andreas Ericsson wrote:\n> >> In our terminology, if it can diverge from the original, it's a branch,\n> >> not a checkout.\n> >>\n> > \n> > This clears things up immensely. bazaar checkout != git checkout.\n> > I still fail to see how a local copy you can't commit to is useful\n> \n> My bzr is run from a local copy I can't commit to. To get the latest\n> changes from http://bazaar-vcs.org, I can run \"bzr update ~/bzr/dev\".\n> To merge the latest changes into my branch, I can run\n> \"bzr merge ~/bzr/dev\". It's also convenient for applying other peoples'\n> patches to.\n\nThe question is, why is it useful to enforce the \"no commit\" rule? Git\ncan work exactly the same, it just doesn't _enforce_ the rule. And is\nthe capability of enforcing such a rule important enough to warrant its\nown column in the comparison table?\n"},{"id":"29026","messageId":"20061017233305.GG20017@pasky.or.cz","threadId":"5925","inReplyTo":"20061017191838.1c36499b.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-17T23:33:05Z","receivedAt":"2006-10-17T23:33:05Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Oct 18, 2006 at 01:18:38AM CEST, I got a letter\nwhere Sean said that...\n> On Wed, 18 Oct 2006 08:27:58 +1000\n> Robert Collins wrote:\n> \n> > Be as blunt as you want. You're expressing an opinion, and thats fine. I\n> > happen to think that we're right : users appear to really appreciate\n> > this bit of the UI, and I've not yet seen any evidence of confusion\n> > about it - though I will admit there is the possibility of that\n> > occurring.\n> \n> Yeah, but it's an opinion that is based on a huge real world project with\n> hundreds of developers. If Bazaar is ever used in a project of that\n> size it may just see the same type of issues as Bk. As has been mentioned\n> elsewhere, Git users really appreciate the short forms it provides for\n> referencing commits, so much so that there is no reason to invent a\n> new (unstable) numbering system or attempt to hide the true underlying\n> commit identities.\n\nBTW, I think it's fine to build a system optimized for small-scale\nprojects (if that's the intent), simplifying some things in favour of\nmostly straight histories instead of more complicated merge situations\n(although I tend to agree with Linus that if you don't behave in the way\nthe users are used to in 100% cases, the more frequently you behave so\nthe worse it comes back to bite in the rare cases you do). Just as RCS\nis fine when maintaining individual files for personal usage (I still\nactually occassionaly use it for few files).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Aaron Bentley wrote:\n> By the way, are bzr \"bundles\" compatibile with ordinary patch?\n> git-format-patch patches are. They have additional metainfo,\n> but they are patches in heart.\n\nYes, they are.\n\n>> I'm not sure what you think Bazaar does. In Bazaar, a repository format\n>> plugin implements the same API that a native repository format does.\n>>\n>> This is how bzr supports Subversion, Mercurial and Git repositories.\n> \n> But if I remember correctly Subversion does not remember merge points\n> (merge commits), so how can you provide full Bazaar-NG compatibility\n> with Subversion repository as backend? Some repository formats lack\n> some features.\n\nThat's true. We support merge points in a way that's compatible with\nsvk. Subversion allows revisions to have arbitrary properties, and svk\nsets a property to indicate merges.\n\n> In git we have import tools (most of them capable of incremental import),\n> a few exchange tools like git-cvsexportcommit, git-cvsserver, and\n> Tailor-like git-svn.\n\nBzr's subversion support is quite nice. You can commit, merge, run\nhistory viewers.\n\nThere are screenshots and stuff here:\nhttp://bazaar-vcs.org/BzrForeignBranches/Subversion\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNWhc0F+nu1YWqI0RAkH7AJ4/S648shA8IKg42xcGWdjnjmA+PgCdEDhg\nAf/mcG+XTy3Tsb9b1x3rYcg=\n=xnjF\n-----END PGP SIGNATURE-----\n"},{"id":"29021","messageId":"200610180135.24606.jnareb@gmail.com","threadId":"5925","inReplyTo":"200610172301.27101.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T23:35:24Z","receivedAt":"2006-10-17T23:35:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia wtorek 17. października 2006 23:01, Jakub Narebski napisał:\n> Aaron Bentley wrote:\n> > Andreas Ericsson wrote:\n> >> Aaron Bentley wrote:\n> >>> Ah.  Bazaar uses negative numbers to refer to th parents, and\n> >>> positive numbers to refer to the number of commits that have been made\n> >>> since the branch was initialized.\n> >>>\n> >>\n> >> What do you do once a branch has been thrown away, or has had 20 other\n> >> branches merged into it? Does the offset-number change for the revision\n> >> then, or do you track branch-points explicitly?\n> > \n> > We always track the number of parents since the initial commit in the\n> > project.  Sorry, I don't think I said that clearly before.\n> \n> While this I think is quite reliable (there was idea to store \"generation\n> number\" with each commit, e.g. using not implemented \"note\" header, or\n> commit-id to generation number \"database\" as a better heuristic than\n> timestamp for revision ordering in git-rev-list output), and probably\n> independent on repository (it is global property of commit history,\n> and commit history is included in sha1 of its parents), numbering branching\n> points is unreliable, as is relying on branch names.\n\nTake for example the following situation:\n\n\nIn the following we had\n\n A--B--C--D - repository A\n\nwe have cloned repository\n\n A--B--C--D - repository B\n\nThen, in parallel/independently we branched off C in repository A, and\nbranched off B in repository B\n\n -x\n /\n A--B--C--D - repository A\n\n\n A--B--C--D - repository B\n \\\n -y\n\nIf we then fetch changes from B into A, and fetch changes from A into B,\nwe will have that in repository A branch off C appeared earlier, and\nin repository B branch off C appeared later.\n-- \nJakub Narebski\nPoland\n"},{"id":"29027","messageId":"200610180139.41647.jnareb@gmail.com","threadId":"5925","inReplyTo":"453532A5.6060701@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-17T23:39:41Z","receivedAt":"2006-10-17T23:39:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n>> This clears things up immensely. bazaar checkout != git checkout.\n>> I still fail to see how a local copy you can't commit to is useful\n> \n> My bzr is run from a local copy I can't commit to.  To get the latest\n> changes from http://bazaar-vcs.org, I can run \"bzr update ~/bzr/dev\".\n> To merge the latest changes into my branch, I can run\n> \"bzr merge ~/bzr/dev\".  It's also convenient for applying other peoples'\n> patches to.\n\nCan you do \"bzr log\" in 'checkout', without need to specify \"~/bzr/dev\"?\nIf not, how this differs from checking out (in git terminology) outside \ndefault working area, and requiring providing GIT_DIR or --git-dir for\nstuff?\n-- \nJakub Narebski\nPoland\n"},{"id":"29025","messageId":"Pine.LNX.4.64.0610171642480.3962@g5.osdl.org","threadId":"5925","inReplyTo":"200610180124.28048.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-17T23:50:22Z","receivedAt":"2006-10-17T23:50:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Jakub Narebski wrote:\n> \n> Merge commit in fast-forward case is only marking \"here we did a pull\"\n> (here we downloaded from other repository). It is just a marker which\n> place is in reflog, not in history. It is only cluttering history.\n\nFor non-git people (and maybe even git people who didn't follow some of \nthe \"reflog\" work):\n\n - git does actually have \"local view\" support, but it is very much \n _defined_ to be local. It does not pollute any history as seen by \n anybody else. It's called \"reflog\" (where \"ref\" is just the git name \n for any reference into a tree, and the \"log\" part is hopefully obvious)\n\nSo each git repository can have (if you enable it) a full log of all the \nchanges to each branch. But it's not in the core git datastructures that \nget replicated - because the local view of how the branches have changed \nreally _is_ just a local view. It's just a local log to each repository \n(actually, one per branch).\n\nIt's what allows a git person to say\n\n\tgit diff \"master@{5.hours.ago}\"\n\nbecause while \"5 hours ago\" is _not_ well-defined in a distributed \nenvironment (five hours ago for _whom_?) it's perfectly well-defined in a \npurely _local_ sense of one particular branch.\n\nSo there's no need for a fakey \"merge\" that isn't a real merge and that \ndoesn't make sense for anybody else because it doesn't actually add any \nreal knowledge about the _history_ of the tree (only about a single \nrepository). If you want to see how the history of a particular repository \nhas evolved, you can just look at the reflog (although admittedly, common \ntools like \"gitk\" don't even show it - the data is there if they would \nwant to, but the most common usage is the above kind of \"show me what \nhappened in the last five hours in my current branch\".\n\n\t\t\tLinus\n"},{"id":"29022","messageId":"20061018000026.GH20017@pasky.or.cz","threadId":"5925","inReplyTo":"200610171641.04455.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T00:00:26Z","receivedAt":"2006-10-18T00:00:26Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Oct 17, 2006 at 04:41:02PM CEST, I got a letter\nwhere Jakub Narebski said that...\n> \"Bundle\" equivalent, although binary in nature, would be thin pack.\n\nIt should be noted that there's no user interface for sending/receiving\nthat and I suspect no reasonably usable user interface for creating it.\n\nHow frequently are the bundles used in practice?\n\nIt's a cultural difference, I suspect. Git comes from an environment\nbased on intensive exchanges of patches and patch series and an\nenvironment not mandating developers to use any tool besides diff/patch,\nso Git is very focused at good support for applying patches and there\nsimply has been no big conscious demand for bundles support given this.\n\nAnother aspect of this is that Git (Linus ;) is very focused on getting\nthe history right, nice and clean (though it does not _mandate_ it and\nyou can just wildly do one commit after another; it just provides tools\nto easily do it). This means that the downstream maintainers have to\nrebase patches, possibly reorder them, and update the changesets with\nbugfixes instead of stacking the bugfixes upon them in separate changes\n- then Linus merges the patches and only at that point they are \"etched\"\nforever. This means that the history will contain neatly laid out way\nof how $FEATURE was achieved, but of course also more work for\ndownstream maintainers.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i said that...\n> [1] As an aside, I don't understand why bazaar pushes the idea\n> of \"plugins\". For instance someone mentioned that bazaar has\n> a bisect \"plugin\". Well Git was able to add a bisect \"command\"\n> without needing a plugin architecture.. so i'm at a loss as \n> to why plugins are seen as an advantage.\n\nGreater flexibility, you can \"provide this great Git addon that will\nlet you push over FTP\" without requiring users to patch their Git\ninstallations or wait for new Git version that might include it.\nEspecially important if you want a lot of users test out your\nexperimental feature or if it's something project-specific etc.\n\nBTW, I'm thinking about implementing some plugin functionality for\ngitweb so that you can add your own views, so that git-browser can\nintegrate to it more reasonably. (Currently it has completely different\nUI and you have to patch gitweb in order to get the proper links at\nproper places.) Sure, git-browser might get fully integrated to gitweb\nlater but that needs to be done sensitively so that people are not\nscared by the horrible javascript blobs, etc.; currently git-browser is\nvery experimental, and adding it would be quite intrusive.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i \n> On Tue, 17 Oct 2006, Aaron Bentley wrote:\n>>> Excuse me? What does that \"throws away your local commit ordering\" mean?\n>> Say this is the ordering in branch A:\n>>\n>> a\n>> |\n>> b\n>> |\n>> c\n>>\n>> Say this is the ordering in branch B:\n>>\n>> a\n>> |\n>> b\n>> |\\\n>> d c\n>> |/\n>> e\n>>\n>> When A pulls B, it gets the same ordering as B has. If B did not have e\n>> and c, the pull would fail.\n> \n> Sure. But that doesn't throw away any local commit ordering. The original \n> order (a->b->c) is still very much there.\n\nAfter the pull, it's no longer the mainline ordering for the branch. c\nis represented a revision that was merged into the branch, while d is\nrepresented as a commit on the mainline of the branch.\n\n> The fact that there was a branch \n> off 'b' and there is also (a->b->d) and a merge of the two at 'e' doesn't \n> take away anything from the original local commit ordering.\n\nIt means the the order that revisions are shown in log commands changes,\nand the revision numbers can change.\n\n> But that's a totally specious \"record\". It has no meaning in a distributed \n> SCM. There is absolutely zero semantic information in it.\n\nIt records the committer, the date, the commit message, the parent\nrevisions.\n\n> The fact that you _locally_ want to remember where you were is a total \n> non-issue for a true distributed system. You shouldn't force everybody \n> else to see your local view - since it has no relevance to them, and \n> doesn't add any information.\n\nNobody is forced to use your local view.\n\n> In other words, the empty merge is totally semantically empty even in the \n> bazaar world. Why does it exist?\n\nIt exists because it is useful. Because it makes the behavior of bzr\nmerge uniform. Because in some workflows, commits show that a person\nhas signed off on a change.\n\nIt's not something special-- it's just another commit, like regular\ncommits, and merge commits. It would be harder to forbid than it is to\npermit.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNXQQ0F+nu1YWqI0RAnxDAJ4hbuLkEK1eBlyoEOz7NAlqLVth9gCfed4w\nnfeiR2KVvN+N9zdSrC8MKcY=\n=et73\n-----END PGP SIGNATURE-----\n"},{"id":"29031","messageId":"45357454.6060909__18071.3461748839$1161134364$gmane$org@utoronto.ca","threadId":"5925","inReplyTo":"200610180139.41647.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-18T00:24:52Z","receivedAt":"2006-10-18T00:24:52Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJakub Narebski wrote:\n> Aaron Bentley wrote:\n>>> This clears things up immensely. bazaar checkout != git checkout.\n>>> I still fail to see how a local copy you can't commit to is useful\n>> My bzr is run from a local copy I can't commit to. To get the latest\n>> changes from http://bazaar-vcs.org, I can run \"bzr update ~/bzr/dev\".\n>> To merge the latest changes into my branch, I can run\n>> \"bzr merge ~/bzr/dev\". It's also convenient for applying other peoples'\n>> patches to.\n> \n> Can you do \"bzr log\" in 'checkout', without need to specify \"~/bzr/dev\"?\n\nSure.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNXRU0F+nu1YWqI0RAptIAJ0btflKFEjF9a7Kt/qVZufK003DpACeK7Dc\nleW4ICG1LbOC9DGrAd5ztlY=\n=JGvL\n-----END PGP SIGNATURE-----\n"},{"id":"29032","messageId":"20061018002523.GJ20017@pasky.or.cz","threadId":"5925","inReplyTo":"vpqbqob5euu.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T00:25:23Z","receivedAt":"2006-10-18T00:25:23Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Oct 17, 2006 at 02:03:21PM CEST, I got a letter\nwhere Matthieu Moy said that...\n> Sean writes:\n> \n> > On Tue, 17 Oct 2006 13:19:08 +0200\n> > Matthieu Moy wrote:\n> >\n> >> 1) a working tree without any history information, pointing to some\n> >> other location for the history itself (a la svn/CVS/...).\n> >> (this is \"light checkout\")\n> >\n> > Git can do this from a local repository, it just can't do it from\n> > a remote repo (at least over the git native protocol). However,\n> > over gitweb you can grab and unpack a tarball from a remote repo.\n> > In practice this is probably enough support for such a feature.\n> \n> Anyway, given the price of disk space today,\n\n(In rich countries. This may still be very different in poorer\ncountries. E.g. some actual mplayer developer(s) from Turkey opposed\ntransition to a distributed version control system simply because they\nhave trouble affording the required additional diskspace for the full\nhistory. SVN is already very space-hungry for them. (It stores\nbasically two complete checkouts in parallel.))\n\nBut the much bigger practical problem is bandwidth, plenty of people\nstill have internet connections where downloading several tens/hundreds\nof megabytes of the complete history is quite a big thing, and the\nservers ain't gonna be happy from that either, nor those paying the\nbandwidth bills. ;-) And this is one of the big problems the Mozilla\nguys have - having everyone download 450M worth of the full CVS-imported\nhistory (and I'll bet no other VCS will beat that size) seems to be not\nan option at all.\n\n> this only makes sense if\n> you have a fast access to the repository (otherwise, you consider your\n> local repository as a cache, and you're ready to pay the disk space\n> price to save your bandwidth). In this case, it's often in your\n> filesystem (local or NFS).\n\nSo how is the light checkout actually implemented? Do you grab the\ncomplete new snapshot each time the remote repository is updated? Do all\nthe (at least read-only, like \"log\" and \"diff\", perhaps \"status\")\ncommands work on such a light checkout?\n\nThis is something sorely missing in Git but if it's really only \"we just\nprovide bandwidth-expensive way to keep your tree up-to-date and that's\nall,\" that would not be hard at all to implement in Git too, using\ngit-archive --remote.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i How frequently are the bundles used in practice?\n\nMany times each day. Most submission to the bzr mainline are done with\nbundles.\n\n> Another aspect of this is that Git (Linus ;) is very focused on getting\n> the history right, nice and clean (though it does not _mandate_ it and\n> you can just wildly do one commit after another; it just provides tools\n> to easily do it).\n\nYes, rebasing is very uncommon in the bzr community. We would rather\nevaluate the complete change than walk through its history. (Bundles\nonly show the changes you made, not the changes you merged from the\nmainline.)\n\nIn an earlier form, bundles contained a patch for every revision, and\npeople *hated* reading them. So there's definitely a cultural\ndifference there.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNXWW0F+nu1YWqI0RAuRnAJ9aZVLo4T1sfmyGC2t364UyHX+6wACff7sM\npeal5rAdk/T515RGeKXkWlo=\n=O61J\n-----END PGP SIGNATURE-----\n"},{"id":"29036","messageId":"4535778D.40006__48886.5832718604$1161134805$gmane$org@utoronto.ca","threadId":"5925","inReplyTo":"20061018002523.GJ20017@pasky.or.cz","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-18T00:38:37Z","receivedAt":"2006-10-18T00:38:37Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nPetr Baudis wrote:\n>> this only makes sense if\n>> you have a fast access to the repository (otherwise, you consider your\n>> local repository as a cache, and you're ready to pay the disk space\n>> price to save your bandwidth). In this case, it's often in your\n>> filesystem (local or NFS).\n> \n> So how is the light checkout actually implemented? Do you grab the\n> complete new snapshot each time the remote repository is updated?\n\nNo, the lightweight checkouts store very little. They have\n- - a copy of tree shape (filenames, paths, sha1 sums) from the last\n commit.\n- - a copy of tree shape for the current working directory\n- - a map from stat values to sha-1 hashes\n\n\n> Do all\n> the (at least read-only, like \"log\" and \"diff\", perhaps \"status\")\n> commands work on such a light checkout?\n\nYes. And if you check out from a read-write branch, all write commands,\nwork, too.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNXeN0F+nu1YWqI0RAsdrAJ0bUj4swxm5sod9WnsbPZ9yIQ7FVQCdE4UB\n8x0ddFkbr5cPISTihw96d8c=\n=/XAr\n-----END PGP SIGNATURE-----\n"},{"id":"29039","messageId":"20061018003920.GK20017__14424.2265880623$1161134820$gmane$org@pasky.or.cz","threadId":"5925","inReplyTo":"45357596.8050702@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T00:39:20Z","receivedAt":"2006-10-18T00:39:20Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Oct 18, 2006 at 02:30:14AM CEST, I got a letter\nwhere Aaron Bentley said that...\n> Petr Baudis wrote:\n> > Another aspect of this is that Git (Linus ;) is very focused on getting\n> > the history right, nice and clean (though it does not _mandate_ it and\n> > you can just wildly do one commit after another; it just provides tools\n> > to easily do it).\n> \n> Yes, rebasing is very uncommon in the bzr community. We would rather\n> evaluate the complete change than walk through its history. (Bundles\n> only show the changes you made, not the changes you merged from the\n> mainline.)\n> \n> In an earlier form, bundles contained a patch for every revision, and\n> people *hated* reading them. So there's definitely a cultural\n> difference there.\n\nBTW, I think what describes the Git's (kernel's) stance very nicely is\nwhat I call the Al Viro's \"homework problem\":\n\n\thttp://lkml.org/lkml/2005/4/7/176\n\nIf I understand you right, the bzr approach is what's described as \"the\ndumbest kind\" there? (No offense meant!)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i said that...\n> Petr Baudis wrote:\n> >> this only makes sense if\n> >> you have a fast access to the repository (otherwise, you consider your\n> >> local repository as a cache, and you're ready to pay the disk space\n> >> price to save your bandwidth). In this case, it's often in your\n> >> filesystem (local or NFS).\n> > \n> > So how is the light checkout actually implemented? Do you grab the\n> > complete new snapshot each time the remote repository is updated?\n> \n> No, the lightweight checkouts store very little. They have\n> - a copy of tree shape (filenames, paths, sha1 sums) from the last\n> commit.\n> - a copy of tree shape for the current working directory\n> - a map from stat values to sha-1 hashes\n\nI see, I guess that means \"the index file and tree objects for the last\ncommit\" in git-speak. Thanks.\n\n> > Do all\n> > the (at least read-only, like \"log\" and \"diff\", perhaps \"status\")\n> > commands work on such a light checkout?\n> \n> Yes. And if you check out from a read-write branch, all write commands,\n> work, too.\n\nOk, one last question - do you do most of the work locally, fetching\nbits of data as you need, or remotely, only taking input/producing\noutput over the network (the pserver model)?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Linus Torvalds wrote:\n>>\n>> On Tue, 17 Oct 2006, Aaron Bentley wrote:\n> >>> Excuse me? What does that \"throws away your local commit ordering\" mean?\n> >> Say this is the ordering in branch A:\n> >>\n> >> a\n> >> |\n> >> b\n> >> |\n> >> c\n> >>\n> >> Say this is the ordering in branch B:\n> >>\n> >> a\n> >> |\n> >> b\n> >> |\\\n> >> d c\n> >> |/\n> >> e\n> >>\n> >> When A pulls B, it gets the same ordering as B has. If B did not have e\n> >> and c, the pull would fail.\n> >\n> > Sure. But that doesn't throw away any local commit ordering. The original\n> > order (a->b->c) is still very much there.\n> \n> After the pull, it's no longer the mainline ordering for the branch. c\n> is represented a revision that was merged into the branch, while d is\n> represented as a commit on the mainline of the branch.\n\nWell, that is another example while generation number is/can be global,\nany numbering of branches must be local-only.\n\n> > The fact that there was a branch\n> > off 'b' and there is also (a->b->d) and a merge of the two at 'e' doesn't\n> > take away anything from the original local commit ordering.\n> \n> It means the the order that revisions are shown in log commands changes,\n\nThat doesn't matter...\n\n> and the revision numbers can change.\n\n...but that means that revision numers are totally, absolutely useless.\nUnless by some miracle of engineering, or adding namespace, they can be\nmade unchangeable.\n\n> > But that's a totally specious \"record\". It has no meaning in a distributed\n> > SCM. There is absolutely zero semantic information in it.\n> \n> It records the committer, the date, the commit message, the parent\n> revisions.\n\nAll totally empty information. What should be commit message? I have\nfetched changes from remote repository? You can remove one of parents\n(the one of pointing to before fast-forward \"merge\") without changing\nreachability.\n\n ---------\n / \\\n *--*---x---*---*---y---*\n\n> > The fact that you _locally_ want to remember where you were is a total\n> > non-issue for a true distributed system. You shouldn't force everybody\n> > else to see your local view - since it has no relevance to them, and\n> > doesn't add any information.\n> \n> Nobody is forced to use your local view.\n\nBut if you record \"fast-forward merge\", you force all people pulling\nfrom your repository to have this purely local and without any significant\ninformation \"I have fetched then\" marker.\n\n> > In other words, the empty merge is totally semantically empty even in the\n> > bazaar world. Why does it exist?\n> \n> It exists because it is useful. Because it makes the behavior of bzr\n> merge uniform. Because in some workflows, commits show that a person\n> has signed off on a change.\n\nSigning off the fact of fetching changes? For true merge you are signing\noff the fact that there were no conflicts, or you sign off your conflict\nresolution.\n\n> It's not something special-- it's just another commit, like regular\n> commits, and merge commits. It would be harder to forbid than it is to\n> permit.\n\nActualy the check is very easy. And you have to do similar check when\nfetchin/pushing to ensure that you don't clobber your changes.\n-- \nJakub Narebski\nPoland\n"},{"id":"29047","messageId":"200610180248.49713.jnareb__4216.28244589574$1161134967$gmane$org@gmail.com","threadId":"5925","inReplyTo":"4535778D.40006@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-18T00:48:49Z","receivedAt":"2006-10-18T00:48:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> Petr Baudis wrote:\n>>> this only makes sense if\n>>> you have a fast access to the repository (otherwise, you consider your\n>>> local repository as a cache, and you're ready to pay the disk space\n>>> price to save your bandwidth). In this case, it's often in your\n>>> filesystem (local or NFS).\n>>\n>> So how is the light checkout actually implemented? Do you grab the\n>> complete new snapshot each time the remote repository is updated?\n> \n> No, the lightweight checkouts store very little. They have\n> - a copy of tree shape (filenames, paths, sha1 sums) from the last\n> commit.\n> - a copy of tree shape for the current working directory\n> - a map from stat values to sha-1 hashes\n\nAh. So in git terminology it stores index and working directory\n(and perhaps the name of branch). \n\n-- \nJakub Narebski\nPoland\n"},{"id":"29048","messageId":"45357A6E.3050603__32055.0519078553$1161135026$gmane$org@utoronto.ca","threadId":"5925","inReplyTo":"20061018004209.GL20017@pasky.or.cz","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-18T00:50:54Z","receivedAt":"2006-10-18T00:50:54Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nPetr Baudis wrote:\n\n> Ok, one last question - do you do most of the work locally, fetching\n> bits of data as you need, or remotely, only taking input/producing\n> output over the network (the pserver model)?\n\nPersonally, I do not do remote commits over slow links. At home, I use\na single machine, and mirror my repository to a public machine using\nrsync. At work, I store my repository on an NFS server, and push my\nrepository to a public machine using rsync.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNXpu0F+nu1YWqI0RAjPTAJ4w9YOM5XLpnIP9jYywtfMr+LZLvACfdycA\n/TYAGUVGweR5+cPtDVAIBq4=\n=rsNR\n-----END PGP SIGNATURE-----\n"},{"id":"29050","messageId":"20061018005700.GM20017@pasky.or.cz","threadId":"5925","inReplyTo":"45357A6E.3050603@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T00:57:00Z","receivedAt":"2006-10-18T00:57:00Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Oct 18, 2006 at 02:50:54AM CEST, I got a letter\nwhere Aaron Bentley said that...\n> Petr Baudis wrote:\n> \n> > Ok, one last question - do you do most of the work locally, fetching\n> > bits of data as you need, or remotely, only taking input/producing\n> > output over the network (the pserver model)?\n> \n> Personally, I do not do remote commits over slow links. At home, I use\n> a single machine, and mirror my repository to a public machine using\n> rsync. At work, I store my repository on an NFS server, and push my\n> repository to a public machine using rsync.\n\nI meant the work of the commands (bzr log and such), not your personal\nworkflow. :-) Sorry for being unclear.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Aaron Bentley wrote:\n>> Linus Torvalds wrote:\n>>> On Tue, 17 Oct 2006, Aaron Bentley wrote:\n>>>>> Excuse me? What does that \"throws away your local commit ordering\" mean?\n>>>> Say this is the ordering in branch A:\n>>>>\n>>>> a\n>>>> |\n>>>> b\n>>>> |\n>>>> c\n>>>>\n>>>> Say this is the ordering in branch B:\n>>>>\n>>>> a\n>>>> |\n>>>> b\n>>>> |\\\n>>>> d c\n>>>> |/\n>>>> e\n>>>>\n>>>> When A pulls B, it gets the same ordering as B has. If B did not have e\n>>>> and c, the pull would fail.\n>>> Sure. But that doesn't throw away any local commit ordering. The original\n>>> order (a->b->c) is still very much there.\n>> After the pull, it's no longer the mainline ordering for the branch. c\n>> is represented a revision that was merged into the branch, while d is\n>> represented as a commit on the mainline of the branch.\n> \n> Well, that is another example while generation number is/can be global,\n> any numbering of branches must be local-only.\n\nNo. The numbering always follows the leftmost parent. So each revision\nhas a permanent (but non-unique) number.\n\n> That doesn't matter...\n\nIt has significant UI impact.\n\n>> and the revision numbers can change.\n> \n> ...but that means that revision numers are totally, absolutely useless.\n> Unless by some miracle of engineering, or adding namespace, they can be\n> made unchangeable.\n\nNo, because no one pulls unless they're trying to maintain a mirror of\nthe other branch, or else they decide to throw their local history away.\n\n>> Nobody is forced to use your local view.\n> \n> But if you record \"fast-forward merge\", you force all people pulling\n> from your repository to have this purely local and without any significant\n> information \"I have fetched then\" marker.\n\nEven if I agreed that the revision was meaningless, the cost of such a\nrevision is miniscule.\n\n>>> In other words, the empty merge is totally semantically empty even in the\n>>> bazaar world. Why does it exist?\n>> It exists because it is useful. Because it makes the behavior of bzr\n>> merge uniform. Because in some workflows, commits show that a person\n>> has signed off on a change.\n> \n> Signing off the fact of fetching changes? For true merge you are signing\n> off the fact that there were no conflicts, or you sign off your conflict\n> resolution.\n\nYou sign off on the contents of the revision you fetched. You say \"I\nhave reviewed this revision, and approved it.\"\n\n>> It's not something special-- it's just another commit, like regular\n>> commits, and merge commits. It would be harder to forbid than it is to\n>> permit.\n> \n> Actualy the check is very easy.\n\nAgreed. It's just that not checking is easier still.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNXzD0F+nu1YWqI0RAiGvAJsEbPNNlqZ7QCH7EE39YABqEm/BtwCaAxIo\nNHqG4NVZpvymTUlCLYyCqKM=\n=YUdC\n-----END PGP SIGNATURE-----\n"},{"id":"29053","messageId":"45357DE3.70206@utoronto.ca","threadId":"5925","inReplyTo":"20061018005700.GM20017@pasky.or.cz","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-18T01:05:39Z","receivedAt":"2006-10-18T01:05:39Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nPetr Baudis wrote:\n> Dear diary, on Wed, Oct 18, 2006 at 02:50:54AM CEST, I got a letter\n> where Aaron Bentley said that...\n>> Petr Baudis wrote:\n>>\n>>> Ok, one last question - do you do most of the work locally, fetching\n>>> bits of data as you need, or remotely, only taking input/producing\n>>> output over the network (the pserver model)?\n>> Personally, I do not do remote commits over slow links. At home, I use\n>> a single machine, and mirror my repository to a public machine using\n>> rsync. At work, I store my repository on an NFS server, and push my\n>> repository to a public machine using rsync.\n> \n> I meant the work of the commands (bzr log and such), not your personal\n> workflow. :-) Sorry for being unclear.\n\nWhen using the native network protocol, work can happen remotely. (But\nthe native protocol is quite new, and support for \"smart\" operations is\ncurrently limited.) When using the dumb protocols, data is fetched from\nthe remote system and processed locally. Light checkouts are not\nrecommended when the server is on a slow link, but heavyweight checkouts\nare quite suitable in that situation.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNX3j0F+nu1YWqI0RAtRcAJ0fEZam6H3hs3YHY/dEYEhk3A73BQCdENHY\ns9+KZTfqnDJg8mHNmC2C/Ok=\n=Nqcn\n-----END PGP SIGNATURE-----\n"},{"id":"29023","messageId":"20061018011147.GN20017@pasky.or.cz","threadId":"5925","inReplyTo":"vpqbqob5euu.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T01:11:47Z","receivedAt":"2006-10-18T01:11:47Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Oct 17, 2006 at 02:03:21PM CEST, I got a letter\nwhere Matthieu Moy said that...\n> I have one repository, say, $repo.\n> \n> In it, I have one branch \"$repo/bzr.dev\" which is an exact mirror of\n> http://bazaar-vcs.org's branch.\n> \n> I also have branches for patches (occasional in my case) that I'll\n> send to upstream. Say $repo/feature1, $repo/feature2, ...\n> \n> If, by mistake, I start hacking on bzr.dev itself, I'll be warned at\n> commit time, create a branch, and commit in this new branch. I believe\n> git manages this in a different way, allowing you to commit in this\n> branch, and creating the branch next time you pull. But you know this\n> better than I ;-), I never got time to give a real try to git.\n\nIn fact, in Git the branch is actually created at the moment you clone.\n\nFor simplicity sake, let's say you cloned just a single branch, not the\nwhole repository (or imagine a repository with a single branch). Then,\nin your local repository, two branches will be created: 'origin' and\n'master'. The origin branch is considered readonly (though Git does\nnot enforce it) and only mirrors the branch in the remote repository.\nThe master branch is the branch you do your work on, and it corresponds\nto the contents of your working tree.\n\nThus, when you are \"updating\" your repository (we also call that\n\"pull\"), what happens is that new commits are _fetched_ from the remote\nrepository to your 'origin' branch and then the 'origin' branch is\n_merged_ to the 'master' branch. (You can even separate those two steps\nand do them manually. So you can e.g. periodically fetch but just check\ndiffs with your master branch and never actually merge, or whatever.)\n\nIf you never do any local commits on the repository, every time you\nmerge the 'master' branch is ancestor of the 'origin' branch and only\nso-called fast-forward merge happens - the 'master' branch is updated to\npoint at the same commit as the 'origin' branch.\n\nIf you _did_ do some local commits, a real merge of the two branches\nhappens and a new merge commit tying the current master and origin\nhistory together is recorded on the merge branch.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Jakub Narebski wrote:\n> > Well, that is another example while generation number is/can be global,\n> > any numbering of branches must be local-only.\n>\n> No. The numbering always follows the leftmost parent. So each revision\n> has a permanent (but non-unique) number.\n\nAaron, thanks for carrying this thread along and helping to bridge\nsome communication gaps. For example, when I saw your original two two\ndiagrams I was totally mystified how you were claiming that appending\na couple of nodes and edges to a DAG could change the \"order\" of the\nDAG.\n\nI think I understand what you're describing with the leftmost-parent\nordering now. But it's definitely an ordering that I would describe as\nlocal-only. That is, the ordering has meaning only with respect to a\nparticular linearization of the DAG and that linearization is\ndifferent from one repository to the next.\n\n> > ...but that means that revision numers are totally, absolutely useless.\n> > Unless by some miracle of engineering, or adding namespace, they can be\n> > made unchangeable.\n>\n> No, because no one pulls unless they're trying to maintain a mirror of\n> the other branch, or else they decide to throw their local history away.\n\nIf in practice, nobody does the mirroring \"pull\" operation then how\nare the numbers useful? For example, given your examples above, if\nI'm understanding the concepts and terminology correctly, then if A\nand B both \"merge\" from each other (and don't \"pull\") then they will\neach end up with identical DAGs for the revision history but totally\ndistinct numbers. Correct?\n\nSo in that situation the numbers will not help A and B determine that\nthey have identical history or even identical working trees. So what\ngood are the numbers?\n\nI can see that the numbers would have applicability with reference to\na single repository, (or equivalently a mirror of that repository),\nbut no utility as soon as there is any distributed development\nhappening.\n\n-Carl\n"},{"id":"29042","messageId":"200610180328.31234.jnareb@gmail.com","threadId":"5925","inReplyTo":"45357596.8050702@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-18T01:28:30Z","receivedAt":"2006-10-18T01:28:30Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> Petr Baudis wrote:\n>>\n>> Another aspect of this is that Git (Linus ;) is very focused on getting\n>> the history right, nice and clean (though it does not _mandate_ it and\n>> you can just wildly do one commit after another; it just provides tools\n>> to easily do it).\n> \n> Yes, rebasing is very uncommon in the bzr community. We would rather\n> evaluate the complete change than walk through its history. (Bundles\n> only show the changes you made, not the changes you merged from the\n> mainline.)\n> \n> In an earlier form, bundles contained a patch for every revision, and\n> people *hated* reading them. So there's definitely a cultural\n> difference there.\n\nTake for example \n \"[PATCH 0/6] ref deletion and D/F conflict avoidance with packed-refs.\"\n http://thread.gmane.org/gmane.comp.version-control.git/28150/focus=28154\n\n> This series cleans up the area that was affected by the recent\n> addition of \"packed-refs\". Christian Couder and Jeff King CC'ed\n> since they seem to be touching in the general vicinity of the\n> code these patches touch.\n> \n> [1/6] ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.\n> [2/6] refs: minor restructuring of cached refs data.\n> [3/6] lock_ref_sha1(): do not sometimes error() and sometimes die().\n> [4/6] lock_ref_sha1(): check D/F conflict with packed ref when creating.\n> [5/6] delete_ref(): delete packed ref\n> [6/6] git-branch: remove D/F check done by hand.\n> \n> I opted for removing from the packed-ref file when a ref that is\n> packed is deleted.\n\nIsn't it easier to review than \"bundle\", aka. mega-patch?\n"},{"id":"29054","messageId":"eh40e1$9g1$1@sea.gmane.org","threadId":"5925","inReplyTo":"20061018001455.GI20017@pasky.or.cz","subject":"Re: Integrating gitweb and git-browser (was: Re: VCS comparison table)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-18T01:36:36Z","receivedAt":"2006-10-18T01:36:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis wrote:\n\n> BTW, I'm thinking about implementing some plugin functionality for\n> gitweb \n\nFeatures support is kind of plugin system for gitweb. But certainly we could\nsplit gitweb into modules.\n\n> so that you can add your own views, so that git-browser can \n> integrate to it more reasonably. (Currently it has completely different\n> UI and you have to patch gitweb in order to get the proper links at\n> proper places.) Sure, git-browser might get fully integrated to gitweb\n> later but that needs to be done sensitively so that people are not\n> scared by the horrible javascript blobs, etc.; currently git-browser is\n> very experimental, and adding it would be quite intrusive.\n\nI was thinking about adding using JavaScript, in shortlog (and perhaps\nshortlog-extended, i.e. with date and author) views one extra \"diagram\"\ncolumn, with width set using JavaScript generated embedded style, and use\nonly part of git-browser that generates diagram to draw it there.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29056","messageId":"87zmbucs86.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"200610180328.31234.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-18T01:44:57Z","receivedAt":"2006-10-18T01:44:57Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 18 Oct 2006 03:28:30 +0200, Jakub Narebski wrote:\n>\n> Isn't it easier to review than \"bundle\", aka. mega-patch?\n\nThere are even more important reasons to prefer a series of\nmicro-commits over a mega-patch than just ease of merging.\n\nIn the cairo project, I've often reviewed a single patch and said:\n\n\t\"This all looks like perfectly good code and I'd be happy to\n\thave it all in the tree. But please rebuild this as a series\n\tof independent patches (perhaps along the lines of a, b, c,\n\t...)\"\n\nI do that not just to make the history \"look nice\" but because code\nhistory is something we _use_ a lot and separate commits for separate\nactions just make the history so much more usable.\n\nWe have great tools like bisect to identify commits that introduce\nbugs. I know that I'd be delighted to see bisect comes back pointing\nat some minimal commit as causing a bug, (which would make finding the\nbug so much easier).\n\nBut it's also been my experience that the largest commits are also the\nmost likely to be the things returned by bisect. Big commits really do\nintroduce bugs more frequently than small commits.\n\nFinally, if someone had gone through the useful work to create small,\nindependent changes, (and likely finding and fixing bugs in the\nprocess), what a horrible shame it would be to throw away that work\nand merge it as a single patch, (welcome to the pain of CVS branch\nmerging).\n\nNow, I do admit that it is often useful to take the overall view of a\npatch series being submitted. This is often the case when a patch\nseries is in some sub-module of the code for which I don't have as\nmuch direct involvement. In cases like that I will often do review\nonly of the diff between the tips of the mainline and the branch of\ninterest, (or if I trust the maintainer enough, perhaps just the\ndiffstat between the two). But I'm still very glad that what lands in\nthe history is the series of independent changes, and not one mega\ncommit.\n\n-Carl\n"},{"id":"29057","messageId":"20061018014624.GO20017@pasky.or.cz","threadId":"5925","inReplyTo":"vpqejt76vgz.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T01:46:24Z","receivedAt":"2006-10-18T01:46:24Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Oct 17, 2006 at 01:19:08PM CEST, I got a letter\nwhere Matthieu Moy said that...\n> 2) a bound branch. It's not _very_ different from a normal branch, but\n> mostly \"commit\" behaves differently:\n> - it commits both on the local and the remote branch (equivalent to\n> \"commit\" + \"push\", but in a transactional way).\n> - it refuses to commit if you're out of date with the branch you're\n> bound to.\n> (this is \"heavy checkout\")\n\nIt isn't very nice because it enforces the update-before-commit\nworkflow, which was complaint of many CVS users and I can remember it\nbeing one of the selling points of the distributed VCSes in 2001 or so,\nalthough it is not so emphasized lately. (I understand that this is\nsomething optional in Bazaar.)\n\nBTW, merge commits aren't bad. They reflect what really happenned,\nexplicitly record the merge resolution taken, if there was any, and\nprotect you from accidentally losing or damaging [any portion of] your\nchanges. And they aren't cluttery either since we hide them from\nnon-graphical history listings by default.\n\nStill, I can recognize that in some scenarios, people might find it\nuseful, and I can remember some people asking for it in the past. So I\ncouldn't resist and implemented it in Cogito as cg-commit --push. Pushed\nout now. Took me about 5 minutes implementing it and 10 minutes documenting\nit. ;-)\n\n\nP.S.: A general note for bleeding-edge Cogito users, I've rewritten the\nlocal changes handling so that we always do three-way merge now instead\nof that braindead patches diffing/applying, but it's not completely\nstable yet, some testcases still fail. So be a bit careful when\nupdating/uncommitting/switching/... with uncommitted changes in the\nworking tree.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i said that...\n> Petr Baudis wrote:\n> \n> > BTW, I'm thinking about implementing some plugin functionality for\n> > gitweb \n> \n> Features support is kind of plugin system for gitweb. But certainly we could\n> split gitweb into modules.\n> \n> > so that you can add your own views, so that git-browser can \n> > integrate to it more reasonably. (Currently it has completely different\n> > UI and you have to patch gitweb in order to get the proper links at\n> > proper places.) Sure, git-browser might get fully integrated to gitweb\n> > later but that needs to be done sensitively so that people are not\n> > scared by the horrible javascript blobs, etc.; currently git-browser is\n> > very experimental, and adding it would be quite intrusive.\n> \n> I was thinking about adding using JavaScript, in shortlog (and perhaps\n> shortlog-extended, i.e. with date and author) views one extra \"diagram\"\n> column, with width set using JavaScript generated embedded style, and use\n> only part of git-browser that generates diagram to draw it there.\n\nShortlog is paginated and that's not very practical for diagrams, I\nthink - you need to gradually extend it instead in that case. But yes,\nkeeping the _visual_ difference of git-browser and gitweb as small as\npossible has been the main reason for me to think about integrating it\nmore tightly.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Dear diary, on Wed, Oct 18, 2006 at 03:36:36AM CEST, I got a letter\n> where Jakub Narebski said that...\n>> Petr Baudis wrote:\n>>\n>>> so that you can add your own views, so that git-browser can \n>>> integrate to it more reasonably. (Currently it has completely different\n>>> UI and you have to patch gitweb in order to get the proper links at\n>>> proper places.) Sure, git-browser might get fully integrated to gitweb\n>>> later but that needs to be done sensitively so that people are not\n>>> scared by the horrible javascript blobs, etc.; currently git-browser is\n>>> very experimental, and adding it would be quite intrusive.\n>> \n>> I was thinking about adding using JavaScript, in shortlog (and perhaps\n>> shortlog-extended, i.e. with date and author) views one extra \"diagram\"\n>> column, with width set using JavaScript generated embedded style, and use\n>> only part of git-browser that generates diagram to draw it there.\n> \n> Shortlog is paginated and that's not very practical for diagrams, I\n> think - you need to gradually extend it instead in that case. But yes,\n> keeping the _visual_ difference of git-browser and gitweb as small as\n> possible has been the main reason for me to think about integrating it\n> more tightly.\n\nYou can have paginated graph (diagram). Although it is more natural\nto have diagram on the first page only, just like gitk --max-count=100.\n\nThe idea is for gitweb to generate (short)log, perhaps with pagination\nturned off (CSS overflow: scroll), and git-browser part to generate\ndiagram and add it to log.\n-- \nJakub Narebski\nPoland\n"},{"id":"29061","messageId":"20061018020224.GR20017@pasky.or.cz","threadId":"5925","inReplyTo":"200610180358.03669.jnareb@gmail.com","subject":"Re: Integrating gitweb and git-browser (was: Re: VCS comparison table)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T02:02:24Z","receivedAt":"2006-10-18T02:02:24Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Oct 18, 2006 at 03:58:03AM CEST, I got a letter\nwhere Jakub Narebski said that...\n> You can have paginated graph (diagram). Although it is more natural\n> to have diagram on the first page only, just like gitk --max-count=100.\n\nOf course you _can_ have it, but you're going to have a lot of trouble\nfollowing the threads over page boundaries, especially if some branch\nhas no commits whatsoever at some page(s).\n\n> The idea is for gitweb to generate (short)log, perhaps with pagination\n> turned off (CSS overflow: scroll), and git-browser part to generate\n> diagram and add it to log.\n\nWhat's missing there is the scary AJAXish thing for fetching more\ncommits. You do not want to load the whole kernel history at once, but\ninstead on demand fetch more revisions.\n\nBTW, I'm most probably not the one going to hack git-browser to fit in\nthis. My javascript knowledge is barely enough to implement a web\nbrowser support for it. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Aaron, thanks for carrying this thread along and helping to bridge\n> some communication gaps. For example, when I saw your original two two\n> diagrams I was totally mystified how you were claiming that appending\n> a couple of nodes and edges to a DAG could change the \"order\" of the\n> DAG.\n> \n> I think I understand what you're describing with the leftmost-parent\n> ordering now. But it's definitely an ordering that I would describe as\n> local-only. That is, the ordering has meaning only with respect to a\n> particular linearization of the DAG and that linearization is\n> different from one repository to the next.\n\nWell, the linarization for any particular head is well-defined, but\nsince different branches have different heads...\n\n> If in practice, nobody does the mirroring \"pull\" operation then how\n> are the numbers useful? For example, given your examples above, if\n> I'm understanding the concepts and terminology correctly, then if A\n> and B both \"merge\" from each other (and don't \"pull\") then they will\n> each end up with identical DAGs for the revision history but totally\n> distinct numbers. Correct?\n\nThe DAGs will be different. If A merges B, we get:\n\na\n|\nb\n|\\\nc d\n|\\|\n| e\n|/\nf\n\nIf B merges A before this, nothing happens, because B is already a\nsuperset of A.\n\nIf B merges afterward, we get this:\na\n|\nb\n|\\\nd c\n|/|\ne |\n|\\|\n| f\n|/\ng\n\n> So in that situation the numbers will not help A and B determine that\n> they have identical history or even identical working trees.\n\nThey don't really have identical history.\n\n> So what good are the numbers?\n\nThey are good for naming mainline revisions that introduced particular\nchanges.\n\n> I can see that the numbers would have applicability with reference to\n> a single repository, (or equivalently a mirror of that repository),\n> but no utility as soon as there is any distributed development\n> happening.\n\nWell, there's distributed, and then there's *DISTRIBUTED*. We don't\nquasi-randomly merge each others' branches. We have a star topology\naround bzr.dev. So when we refer to revnos, they're usually in bzr.dev.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNZsp0F+nu1YWqI0RAkmWAJ9PkrkubIHVgAn5Wbdkg9IBAHCviACdFx2x\n6ClmK4GmC1pRuRQACcSijNM=\n=SM1Y\n-----END PGP SIGNATURE-----\n"},{"id":"29066","messageId":"87dcb0bd0610172025l25d6646dq761dd08792e2b290@mail.gmail.com","threadId":"5925","inReplyTo":"45357411.20500@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Ryan Anderson","fromEmail":"rda@google.com","sentAt":"2006-10-18T03:25:03Z","receivedAt":"2006-10-18T03:25:03Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On 10/17/06, Aaron Bentley wrote:\n> > In other words, the empty merge is totally semantically empty even in the\n> > bazaar world. Why does it exist?\n>\n> It exists because it is useful. Because it makes the behavior of bzr\n> merge uniform. Because in some workflows, commits show that a person\n> has signed off on a change.\n\nIn the Git world that happens via \"git tag -s\", i.e, a\ncryptographically strong \"signoff\".\n(There's also the secondary convention of appending Signed-off-by: to\nemail-applied patches, but that's something that would translate\neffectively to any other system, since it's outside the SCM.)\n"},{"id":"29067","messageId":"45359F36.6050609@utoronto.ca","threadId":"5925","inReplyTo":"87zmbucs86.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-18T03:27:50Z","receivedAt":"2006-10-18T03:27:50Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nCarl Worth wrote:\n> On Wed, 18 Oct 2006 03:28:30 +0200, Jakub Narebski wrote:\n>> Isn't it easier to review than \"bundle\", aka. mega-patch?\n> \n> There are even more important reasons to prefer a series of\n> micro-commits over a mega-patch than just ease of merging.\n\nA bundle isn't a mega-patch. It contains all the source revisions. So\nwhen you merge or pull it, you get all the original revisions in your\nrepository.\n\n\n> We have great tools like bisect to identify commits that introduce\n> bugs. I know that I'd be delighted to see bisect comes back pointing\n> at some minimal commit as causing a bug, (which would make finding the\n> bug so much easier).\n\nBisect should work equally well with revisions pulled or merged from a\nbundle as revisions re-committed from patches.\n\n> But it's also been my experience that the largest commits are also the\n> most likely to be the things returned by bisect. Big commits really do\n> introduce bugs more frequently than small commits.\n\nThe number of changes shown in the diff has nothing to do with the\nnumber of changes made per commit.\n\n> Now, I do admit that it is often useful to take the overall view of a\n> patch series being submitted. This is often the case when a patch\n> series is in some sub-module of the code for which I don't have as\n> much direct involvement. In cases like that I will often do review\n> only of the diff between the tips of the mainline and the branch of\n> interest, (or if I trust the maintainer enough, perhaps just the\n> diffstat between the two). But I'm still very glad that what lands in\n> the history is the series of independent changes, and not one mega\n> commit.\n\nSo the difference here is that bundles preserve the original commits the\nchanges came from, so even though it's presented as an overview, you\nstill have a series of independent changes in your history.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNZ820F+nu1YWqI0RAjNyAJ90HMCAiopuAMvkKlcCEdc4F6QKLwCdGEWI\nVOZThAQrvqybe5z93eC44BY=\n=xBZM\n-----END PGP SIGNATURE-----\n"},{"id":"29068","messageId":"Pine.LNX.4.64.0610172014250.3962@g5.osdl.org","threadId":"5925","inReplyTo":"45357CC3.4040507@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-18T03:35:07Z","receivedAt":"2006-10-18T03:35:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 17 Oct 2006, Aaron Bentley wrote:\n> \n> > That doesn't matter...\n> \n> It has significant UI impact.\n\nRight. You have to do it your way, because of the \"simple revision \nnumbers\".\n\nWhich gets us back to where we started: \"simple\" is in the eye of the \nbeholder. I personally think that git revision naming is a lot simpler, \nexactly because it doesn't impose arbitrary rules on users.\n\nFor example, what happens is that:\n - you like the simple revision numbers\n - that in turn means that you can never allow a mainline-merge to be done \n by anybody else than the main maintainer\n - that in turn means that the whole situation is no longer distributed, \n it's more like a \"disconnected access to a central repository\"\n\nThe \"main trunk matters\" mentality (which has deep roots in CVS - don't \nget me wrong, I don't think you're the first one to do this) is \nfundamentally antithetical to truly distributed system, because it \nbasically assumes that some maintainer is \"more important\" than others. \n\nThat special maintainer is the maintainer whose merge-trunk is followed, \nand whose revision numbers don't change when they are merged back. \n\nThat may even be _true_ in many cases. But please do realize that it's a \nreal issue, and that it has real impact - it does two things:\n\n - it impacts the technology and workflow directly itself: \"pull\" and \n \"merge\" are different: a central maintainer would tend to do a \"merge\", \n and one more in the outskirts would tend to do more of a \"pull\", \n expecting his work to then be merged back to the \"trunk\" at some later \n point)\n\n - it will result in _psychological_ damage, in the sense that there's \n always one group that is the \"trunk\" group, and while you can pass the \n baton around (like the perl people do), it's always clear who sits \n centrally.\n\nMaybe this is fine. It's certainly how most projects tend to work. \n\nI'll just point out that one of my design goals for git was to make every \nsingle repository 100% equal. That means that there MUST NOT be a \"trunk\", \nor a special line of development. There is no \"vendor branch\". It's \nsomething that a lot of people on the git lists understand now, but it \ntook a while for it to sink in - people used to believe that the \"first \nparent\" of a merge was somehow special, and I had to point out several \ntimes on the git list that no, that's not how it works - because the merge \nmight have been done by somebody _else_ than the person who you think of \nas being \"on the trunk\".\n\nSo when I say that your \"simple\" revision numbers are totally broken and \nhorrible, I say that not because I think a number like \"1.45.3.17\" is \nugly, but because I think that the deeper _implications_ of using a number \nlike that is ugly. It implies one of two things:\n\n - the numbers change all the time as things get merged both ways\n\nOR\n\n - people try to maintain a \"trunk\" mentality\n\nand I think both of those situations are simply not good situations.\n\nIn git, the fact that everybody is on an equal footing is something that I \nthink is really good. For example, when I was away for effectively three \nweeks during August, all the git-level merging for the kernel was done by \nGreg KH.\n\nAnd realize that he didn't use \"my tree\". No baton was passed. I emailed \nwith him (and some others) before-hand, so that everybody knew that I \nexpected to be just pull from Greg when I came back, but it was _his_ tree \nthat he merged in, and he just worked the same way I did.\n\nAnd when I did come back, I did a \"pull\" from his tree. At no point is \nthere a big merge-commit with a sign saying\n\n\t\"I now merged all the work that Greg did while I was away\"\n\nNo. Because the way git works, my pull just fast-forwarded my tree, \nbecause while I was away, Greg's tree _was_ the main tree, thanks to the \nfact that git believes that everybody is 100% equal.\n\nSo it's actually a big conceptual thing. \n\nI'm actually very happy with the design of git, and a large part of that \nis that I think the data structures and the basic design was really good. \nNow, I know I'm smarter than anybody else (\"Bow down before me, you \nworthless scum\"), but the thing is, the way to do good basic design isn't \nactually to be really smart about it, but to try to have a few basic \nconcepts.\n\nAnd the \"every repository is equal\" is one such concept. The naming \nfollows from that - you simply _cannot_ use numbers if everybody is on the \nsame footing (at least not _stable_ numbers). \n\nBtw, BK did get this right. I didn't _like_ the naming in BK, and it was \nnumbers, but it worked. But it only worked when people understood that the \nnumbers were ephemeral, and it _did_ cause confusion. But hey, the \nconfusion wasn't _that_ big of a problem.\n\n> Even if I agreed that the revision was meaningless, the cost of such a\n> revision is miniscule.\n\nNo. The _cost_ of the revision is the \"trunk mentality\". THAT is the true \ncost. The belief that there is one \"main line of development\".\n\n\t\tLinus\n"},{"id":"29071","messageId":"1161147348.3423.24.camel@localhost.localdomain","threadId":"5925","inReplyTo":"4534AB8B.8030505@op5.se","subject":"Re: VCS comparison table","fromName":"Robert Collins","fromEmail":"robertc@robertcollins.net","sentAt":"2006-10-18T04:55:48Z","receivedAt":"2006-10-18T04:55:48Z","isPatch":false,"sender":{"key":"robertc@robertcollins.net","avatar":null},"body":"On Tue, 2006-10-17 at 12:08 +0200, Andreas Ericsson wrote:\n> Robert Collins wrote:\n> > On Tue, 2006-10-17 at 11:20 +0200, Jakub Narebski wrote:\n> >> ---- time --->\n> >>\n> >> --*--*--*--*--*--*--*--*--*-- \n> >> \\ /\n> >> \\-*--X--*--/\n> >>\n> >> The branch it used to be on is gone...\n> > \n> > In bzr 0.12 this is :\n> > 2.1.2\n> > \n> \n> Would it be a different number in a different version of bazaar?\n\nThe dotted decimal display has only been introduced in bzr 0.12\n\n> > (assuming the first * is numbered '1'.)\n> > \n> > These numbers are fairly stable, in particular everything's number in\n> > the mainline will be the same number in all the branches created from it\n> > at that point in time, but a branch that initially creates a revision or\n> > obtains it before the mainline will have a different number until they\n> > syncronise with the mainline via pull.\n> > \n> \n> So basically anyone can pull/push from/to each other but only so long as \n> they decide upon a common master that handles synchronizing of the \n> number part of the url+number revision short-hands?\n\nAnyone can push and pull from each other - full stop. Whenever they\n'pull' in bzr terms, they get fast-forward happening (if I understand\nthe git fast-forward behaviour correctly). After a fast-forward, the\ndotted decimal revision numbers in the two branches are identical - and\nthey remain immutable until another fast forward occurs. Push always\nfast forwards, so the public copy of ones own repository that others\npull or merge from is identical to your own. In a 'collection of\nbranches with no mainline' scenario, people usually have fast forward\noccur from time to time, keeping the numbers consistent from the point\nyour branch was last pulled by someone else, or you pulled them.\n\n> One thing that's been nagging me is how you actually find out the \n> url+number where the desired revision exists. That is, after you've \n> synced with master, or merged the mothership's master-branch into one of \n> your experimental branches where you've done some work that went before \n> mothership's master's current tip, do you have to have access to the \n> mothership's repo (as in, do you have to be online) to find out the \n> number part of url+number shorthand, or can you determine it solely from \n> what you have on your laptop?\n\nYou can determine it locally - if you know any of the motherships\nrevisions locally, we can generate the dotted-revnos that the\nmotherships master-branch would have from the local data - and the last\nmerge of mothership you did will have given you that details. I dont\nthink we have a ui command to spit this out just yet, but it will be\ntrivial to whip one up.\n\nMore commonly though, like git users have 'origin' and 'master'\nbranches, bzr users tend to have a branch that is the 'origin' (for bzr\nitself this is usually called bzr.dev), as well as N other branches for\ntheir own work, which is probably why we haven't seen the need to have a\nui command to spit out the revnos for an arbitrary branch.\n\n-Rob\n\n-- \nGPG key available at: .\n"},{"id":"29073","messageId":"1161149200.3423.34.camel@localhost.localdomain","threadId":"5925","inReplyTo":"20061017233305.GG20017@pasky.or.cz","subject":"Re: VCS comparison table","fromName":"Robert Collins","fromEmail":"robertc@robertcollins.net","sentAt":"2006-10-18T05:26:40Z","receivedAt":"2006-10-18T05:26:40Z","isPatch":false,"sender":{"key":"robertc@robertcollins.net","avatar":null},"body":"On Wed, 2006-10-18 at 01:33 +0200, Petr Baudis wrote:\n> \n> BTW, I think it's fine to build a system optimized for small-scale\n> projects (if that's the intent), simplifying some things in favour of\n> mostly straight histories instead of more complicated merge situations\n> (although I tend to agree with Linus that if you don't behave in the\n> way the users are used to in 100% cases, the more frequently you\n> behave so the worse it comes back to bite in the rare cases you do).\n> Just as RCS is fine when maintaining individual files for personal\n> usage (I still actually occassionaly use it for few files).\n\nrevnos visibly change as your work is merged into the mainline - we've\nbeen doing this for years without trouble: ones own commits to a branch\nget '3', '4', '5' etc as revnos, and when they are merged to the\nmainline they used to stop having revnos at all, but now they will be\ngiven this dotted decimal revno. If you pull from the mainline after the\nmerge, you see the new numbers, and when you look at mainline you can\nsee the difference. So while I agree that the surprise the user gets is\ninversely related to the frequency with which they see the behaviour, I\nthink our users see it a lot, so are not surprised much.\n\nFWIW, we're not optimising for mostly straight histories as I understand\nsuch things : our own history has 3 commits on branches to every one on\nthe mainline.\n\n-Rob\n-- \nGPG key available at: .\n"},{"id":"29072","messageId":"20061018053647.GA3507@coredump.intra.peff.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610171610270.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-18T05:36:47Z","receivedAt":"2006-10-18T05:36:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 17, 2006 at 04:16:15PM -0700, Linus Torvalds wrote:\n\n> It would be easy to send the exact same data as the native git protocol \n> sends over ssh (or the git port) as an email encoding. We did that a few \n> times with BK (there it's called \"bk send\" and \"bk receive\" to pack and \n[...]\n> That said, \"bundles\" certainly wouldn't be _hard_ to do. And as long as \n> nobody tries to send _me_ any of them, I won't mind ;)\n\nI never used BK, but my understanding is that it was based on\nchangesets, so a bundle was a group of changesets. Because a git commit\nrepresents the entire tree state, how can we avoid sending the entire\ntree in each bundle? The interactive protocols can ask \"what do you\nhave?\" but an email bundle is presumably meant to work without a round\ntrip.\n\nWe could always make a guess (\"git send --remote-has master~10\") but\nthat seems awfully error-prone. I assume a changeset-oriented system\nwould implicitly keep some concept of \"I think Linus is at master~10\"\nand do it automatically.\n\n-Peff\n"},{"id":"29074","messageId":"7vpscqgo9e.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"20061018053647.GA3507@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-18T05:57:01Z","receivedAt":"2006-10-18T05:57:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> We could always make a guess (\"git send --remote-has master~10\") but\n> that seems awfully error-prone. I assume a changeset-oriented system\n> would implicitly keep some concept of \"I think Linus is at master~10\"\n> and do it automatically.\n\nWe could always anchor at a well known point (\"git send v2.6.18..\").\nIf you as the recipient do not have the preimage, the \"bundle\" would\nidentify what the assumed common ancestor is and you can fetch\nit before proceeding.\n"},{"id":"29077","messageId":"vpqpscqm9d6.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"200610172351.17377.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-18T06:22:13Z","receivedAt":"2006-10-18T06:22:13Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n>>> Fast-forward is a really good idea. Perhaps you could implement it,\n>>> if it is not hidden under different name?\n>> \n>> We support it as 'pull', but merge doesn't do it automatically, because\n>> we'd rather have merge behave the same all the time, and because 'pull'\n>> throws away your local commit ordering.\n>\n> I smell yet another terminology conflict (although this time fault is\n> on the git side), namely that in git terminology \"pull\" is \"fetch\"\n> (i.e. getting changes done in remote repository since laste \"fetch\"\n> or since \"clone\") followed by merge. pull = fetch + merge.\n\nAAUI, the initial claim was that after a rebase, git can do a\nfast-forward, but Aaron has missed the /after a rebase/ part.\n\nAnd yes, it the bzr terminology, bzr can do a \"pull\" after a \"graft\".\nI don't think there's a fundamental difference here.\n"},{"id":"29078","messageId":"20061018063308.GB3507@coredump.intra.peff.net","threadId":"5925","inReplyTo":"20061017062341.8a5c8530.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-18T06:33:08Z","receivedAt":"2006-10-18T06:33:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 17, 2006 at 06:23:41AM -0400, Sean wrote:\n\n> The \"bzr missing\" command sounds like a handy one. \n> \n> Someone on the xorg mailing list was recently lamenting that git does not\n> have an easy way to compare a local branch to a remote one. While this\n> turns out to not be a big problem in git, it might be nice to have such\n> a command.\n\nWhat's wrong with:\n\n git-fetch\n gitk master...origin\n\nThe git model is to do operations on local refs and objects, so the\nfetch is a natural part of that. The only downside I see is that you\nactually end up fetching the data rather than simply peeking at where\nthe remote is. But a useful comparison will include at least grabbing\nthe commit objects, and probably the tree objects (to do diffs) anyway.\n\n-Peff\n"},{"id":"29079","messageId":"vpqlknem8bi.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"20061018011147.GN20017@pasky.or.cz","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-18T06:44:49Z","receivedAt":"2006-10-18T06:44:49Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Petr Baudis writes:\n\n> The origin branch is considered readonly (though Git does\n> not enforce it) and only mirrors the branch in the remote repository.\n\nBy curiosity, what happens if you accidentally commit to it?\n\n-- \nMatthieu\n"},{"id":"29082","messageId":"20061018071627.GC4678@spearce.org","threadId":"5925","inReplyTo":"vpqlknem8bi.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-18T07:16:27Z","receivedAt":"2006-10-18T07:16:27Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Matthieu Moy wrote:\n> Petr Baudis writes:\n> \n> > The origin branch is considered readonly (though Git does\n> > not enforce it) and only mirrors the branch in the remote repository.\n> \n> By curiosity, what happens if you accidentally commit to it?\n\nIt will quietly accept the commit.\n\nLater when you attempt to run `git fetch` to download any changes\nfrom the remote repository to your local origin branch the fetch\ncommand will fail as it won't be a strict fast-forward due to\nthere being changes in origin which aren't in the remote repository\nbeing downloaded.\n\nThe user can force those changes to be thrown away with `git fetch\n--force`, though they probably would want to first examine the\nbranch with `git log origin` to see what commits (if any) should\nbe saved, and either extract them to patches for reapplication or\ncreate a holder branch via `git branch holder origin` to allow them\nto later merge the holder branch (or parts thereof) after the fetch\nhas forced origin to match the remote repository.\n\nSo in short by default Git stops and tells the user something fishy\nis going on, but the error message isn't obvious about what that\nis and how they can resolve it easily.\n\nThere has been discussion about marking these branches that we\nknow the user fetches into as read-only, to prevent `git commit`\nfrom actually committing to such a branch (we also have the same\ncase with the special bisect branch), but I don't think anyone has\nstepped forward with the complete implementation of that yet.\n\nLike anything I think people get used to the idea that those branches\nare strictly for fetching and shouldn't be used for anything else.\nThere's really no reason to checkout a fetched into branch anyway;\ntemporary branches are less than 1 second away with\n`git checkout -b tmp origin` (for example).\n\n-- \nShawn.\n"},{"id":"29084","messageId":"4535E21B.4040203@op5.se","threadId":"5925","inReplyTo":"4535685C.4010502@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-18T08:13:15Z","receivedAt":"2006-10-18T08:13:15Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Aaron Bentley wrote:\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> Jakub Narebski wrote:\n>> Aaron Bentley wrote:\n>> By the way, are bzr \"bundles\" compatibile with ordinary patch?\n>> git-format-patch patches are. They have additional metainfo,\n>> but they are patches in heart.\n> \n> Yes, they are.\n> \n\nSounds a bit like [PATCH 0/8] would have the output of\n\n\tgit diff $(git merge-base master)..topic-branch\n\nfor any given patch-series. It might be easier to review the whole \npatch-series in some cases. Especially with patch-series where more than \none patch touches the same part of the code.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"29085","messageId":"4535E844.8010604@op5.se","threadId":"5925","inReplyTo":"45359B2A.1070102@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-18T08:39:32Z","receivedAt":"2006-10-18T08:39:32Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Aaron Bentley wrote:\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> Carl Worth wrote:\n>> Aaron, thanks for carrying this thread along and helping to bridge\n>> some communication gaps. For example, when I saw your original two two\n>> diagrams I was totally mystified how you were claiming that appending\n>> a couple of nodes and edges to a DAG could change the \"order\" of the\n>> DAG.\n>>\n>> I think I understand what you're describing with the leftmost-parent\n>> ordering now. But it's definitely an ordering that I would describe as\n>> local-only. That is, the ordering has meaning only with respect to a\n>> particular linearization of the DAG and that linearization is\n>> different from one repository to the next.\n> \n> Well, the linarization for any particular head is well-defined, but\n> since different branches have different heads...\n> \n>> If in practice, nobody does the mirroring \"pull\" operation then how\n>> are the numbers useful? For example, given your examples above, if\n>> I'm understanding the concepts and terminology correctly, then if A\n>> and B both \"merge\" from each other (and don't \"pull\") then they will\n>> each end up with identical DAGs for the revision history but totally\n>> distinct numbers. Correct?\n> \n> The DAGs will be different. If A merges B, we get:\n> \n> a\n> |\n> b\n> |\\\n> c d\n> |\\|\n> | e\n> |/\n> f\n> \n> If B merges A before this, nothing happens, because B is already a\n> superset of A.\n> \n> If B merges afterward, we get this:\n> a\n> |\n> b\n> |\\\n> d c\n> |/|\n> e |\n> |\\|\n> | f\n> |/\n> g\n> \n\nSeems like an awful lot of merge commits. In git, I think these trees \nwould be identical (actually both to bazaar and to each other), with the \nexception that the 'g' commit wouldn't exist, since git does \nfast-forward and relies on dependency-chain only to present the graph \ninstead of mucking around with info in external files (recording of \nfetches).\n\n>> So in that situation the numbers will not help A and B determine that\n>> they have identical history or even identical working trees.\n> \n> They don't really have identical history.\n> \n\nAs explained above, they would be identical in git. The fact that you \nregister a fast-forward as a merge makes them not so, but this is \nsomething most gitizens are against, as it can quickly clutter up the DAG.\n\n>> So what good are the numbers?\n> \n> They are good for naming mainline revisions that introduced particular\n> changes.\n> \n>> I can see that the numbers would have applicability with reference to\n>> a single repository, (or equivalently a mirror of that repository),\n>> but no utility as soon as there is any distributed development\n>> happening.\n> \n> Well, there's distributed, and then there's *DISTRIBUTED*. We don't\n> quasi-randomly merge each others' branches. We have a star topology\n> around bzr.dev. So when we refer to revnos, they're usually in bzr.dev.\n> \n\nSo in essence, the revnos work wonderfully so long as there is a central \nserver to make them immutable?\n\nDoesn't this mean that one of your key features doesn't actually work in \na completely distributed setup (i.e., each dev has his own repo, there \nis no mother-ship, everyone pulls from each other)?\n\nI can see the six-line hook that lays the groundwork for this in git \nbefore me right now. I'll happily refuse to write it down anywhere. I \nget the feeling that sha's are easier to handle in the long run, while \nrevno's might be good to use in development work. In git, we have \n~ syntax for this.\n\nIn my experience, finding the revision sha of an old bug is what takes \ntime. Copy-paste is just as fast with 20 bytes as with 4 bytes. Honestly \nnow, do you actually remember the revno for a bug that you stopped \nworking on three weeks ago, or do you have to go look it up? If someone \nwants to notify you about the revision a bug was introduced, do they not \ncommunicate the revno to you by email/irc/somesuch?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"29086","messageId":"4535EB7C.7030209@op5.se","threadId":"5925","inReplyTo":"1161147348.3423.24.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-18T08:53:16Z","receivedAt":"2006-10-18T08:53:16Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Robert Collins wrote:\n> On Tue, 2006-10-17 at 12:08 +0200, Andreas Ericsson wrote:\n>> Robert Collins wrote:\n>>> On Tue, 2006-10-17 at 11:20 +0200, Jakub Narebski wrote:\n>>>> ---- time --->\n>>>>\n>>>> --*--*--*--*--*--*--*--*--*-- \n>>>> \\ /\n>>>> \\-*--X--*--/\n>>>>\n>>>> The branch it used to be on is gone...\n>>> In bzr 0.12 this is :\n>>> 2.1.2\n>>>\n>> Would it be a different number in a different version of bazaar?\n> \n> The dotted decimal display has only been introduced in bzr 0.12\n> \n>>> (assuming the first * is numbered '1'.)\n>>>\n>>> These numbers are fairly stable, in particular everything's number in\n>>> the mainline will be the same number in all the branches created from it\n>>> at that point in time, but a branch that initially creates a revision or\n>>> obtains it before the mainline will have a different number until they\n>>> syncronise with the mainline via pull.\n>>>\n>> So basically anyone can pull/push from/to each other but only so long as \n>> they decide upon a common master that handles synchronizing of the \n>> number part of the url+number revision short-hands?\n> \n> Anyone can push and pull from each other - full stop. Whenever they\n> 'pull' in bzr terms, they get fast-forward happening (if I understand\n> the git fast-forward behaviour correctly). After a fast-forward, the\n> dotted decimal revision numbers in the two branches are identical - and\n> they remain immutable until another fast forward occurs.\n\n\nThis is where it breaks down for me. \"until another fast forward occurs\" \nis just not good enough, imo.\n\n> \n>> One thing that's been nagging me is how you actually find out the \n>> url+number where the desired revision exists. That is, after you've \n>> synced with master, or merged the mothership's master-branch into one of \n>> your experimental branches where you've done some work that went before \n>> mothership's master's current tip, do you have to have access to the \n>> mothership's repo (as in, do you have to be online) to find out the \n>> number part of url+number shorthand, or can you determine it solely from \n>> what you have on your laptop?\n> \n> You can determine it locally - if you know any of the motherships\n> revisions locally, we can generate the dotted-revnos that the\n> motherships master-branch would have from the local data - and the last\n> merge of mothership you did will have given you that details.\n\n\nTo me, this means bazaar isn't distributed at all and I could achieve \nmuch the same distributedness(?) by rsyncing an SVN repo, working \nagainst that and then rsyncing it back with some fancy merging. In other \nwords, bazaar requires there to be one Lord of the Code, or some of the \nkey features break down.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"29091","messageId":"802d21790610180204h132984d9q70d52e241c68388f@mail.gmail.com","threadId":"5925","inReplyTo":"4535E844.8010604@op5.se","subject":"Re: VCS comparison table","fromName":"Peter Baumann","fromEmail":"peter.baumann@gmail.com","sentAt":"2006-10-18T09:04:46Z","receivedAt":"2006-10-18T09:04:46Z","isPatch":false,"sender":{"key":"peter.baumann@gmail.com","avatar":null},"body":"2006/10/18, Andreas Ericsson :\n> Aaron Bentley wrote:\n> > -----BEGIN PGP SIGNED MESSAGE-----\n> > Hash: SHA1\n> >\n> > Carl Worth wrote:\n> >> Aaron, thanks for carrying this thread along and helping to bridge\n> >> some communication gaps. For example, when I saw your original two two\n> >> diagrams I was totally mystified how you were claiming that appending\n> >> a couple of nodes and edges to a DAG could change the \"order\" of the\n> >> DAG.\n> >>\n> >> I think I understand what you're describing with the leftmost-parent\n> >> ordering now. But it's definitely an ordering that I would describe as\n> >> local-only. That is, the ordering has meaning only with respect to a\n> >> particular linearization of the DAG and that linearization is\n> >> different from one repository to the next.\n> >\n> > Well, the linarization for any particular head is well-defined, but\n> > since different branches have different heads...\n> >\n> >> If in practice, nobody does the mirroring \"pull\" operation then how\n> >> are the numbers useful? For example, given your examples above, if\n> >> I'm understanding the concepts and terminology correctly, then if A\n> >> and B both \"merge\" from each other (and don't \"pull\") then they will\n> >> each end up with identical DAGs for the revision history but totally\n> >> distinct numbers. Correct?\n> >\n> > The DAGs will be different. If A merges B, we get:\n> >\n> > a\n> > |\n> > b\n> > |\\\n> > c d\n> > |\\|\n> > | e\n> > |/\n> > f\n> >\n> > If B merges A before this, nothing happens, because B is already a\n> > superset of A.\n> >\n> > If B merges afterward, we get this:\n> > a\n> > |\n> > b\n> > |\\\n> > d c\n> > |/|\n> > e |\n> > |\\|\n> > | f\n> > |/\n> > g\n> >\n>\n> Seems like an awful lot of merge commits. In git, I think these trees\n> would be identical (actually both to bazaar and to each other), with the\n> exception that the 'g' commit wouldn't exist, since git does\n> fast-forward and relies on dependency-chain only to present the graph\n> instead of mucking around with info in external files (recording of\n> fetches).\n>\n\nOk. This I don't get. Let me recaptulize:\n\nBranch A\na\n|\nb\n|\nc\n\nBranch B\na\n|\nb\n| \\\nd c\n| /\ne\n\nIn branch A, do merge branch B (git pull B) you get as result branch B, because\nA fastforwards to B and you don't get a merge commit f\n\nIn branch B, do merge branch A (git pull A), the result would be\nbranch B, because\nwe are already uptodate.\n\nYou _never_ have a commit f or g.\n\n-Peter\n"},{"id":"29092","messageId":"200610181107.35173.jnareb@gmail.com","threadId":"5925","inReplyTo":"4535E844.8010604@op5.se","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-18T09:07:34Z","receivedAt":"2006-10-18T09:07:34Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson wrote:\n> Aaron Bentley wrote:\n>> Well, there's distributed, and then there's *DISTRIBUTED*. We don't\n>> quasi-randomly merge each others' branches. We have a star topology\n>> around bzr.dev. So when we refer to revnos, they're usually in bzr.dev.\n>> \n> \n> So in essence, the revnos work wonderfully so long as there is a central \n> server to make them immutable?\n> \n> Doesn't this mean that one of your key features doesn't actually work in \n> a completely distributed setup (i.e., each dev has his own repo, there \n> is no mother-ship, everyone pulls from each other)?\n> \n> I can see the six-line hook that lays the groundwork for this in git \n> before me right now. I'll happily refuse to write it down anywhere. I \n> get the feeling that sha's are easier to handle in the long run, while \n> revno's might be good to use in development work. In git, we have \n> ~ syntax for this.\n> \n> In my experience, finding the revision sha of an old bug is what takes \n> time. Copy-paste is just as fast with 20 bytes as with 4 bytes. Honestly \n> now, do you actually remember the revno for a bug that you stopped \n> working on three weeks ago, or do you have to go look it up? If someone \n> wants to notify you about the revision a bug was introduced, do they not \n> communicate the revno to you by email/irc/somesuch?\n\nRevnos were supposed to be superior to using sha1 (or shortened sha1)\nas commit identifiers because of two key features:\n 1. They were simplier than sha1, therefore easier to use\n 2. Given two revisions related by lineage (i.e. one is ancestor of\n the other) you can from a glance know which revision was earlier\n\nBut the details invalidated 1.: for complicated history, for a large\nproject, with many contributors and nonlinear development we have \nwww.repository.com:127.2.31.57 vs 988859a (7 chars shortcut of sha1)\nto have immutable revno. And we have to use _immutable_ (up to few\nyears) revison identifiers, unless we want our \"simple ids\" scheme\nto make a mess...\n\nAnd I'm not sure if 2. is true, if even for revisions with direct\nlineage we don't have to compare 127.15.2.16 with 210.2.20.3 for\nexample. Having generation number would solve 2.; as of now git\ncheck for fast-forward case by checking if merge-base of two\nrevisions is one of the revisions.\n-- \nJakub Narebski\nPoland\n"},{"id":"29094","messageId":"200610181120.49749.jnareb@gmail.com","threadId":"5925","inReplyTo":"45359F36.6050609@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-18T09:20:49Z","receivedAt":"2006-10-18T09:20:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> Carl Worth wrote:\n>> On Wed, 18 Oct 2006 03:28:30 +0200, Jakub Narebski wrote:\n>>> Isn't it easier to review than \"bundle\", aka. mega-patch?\n>>\n>> There are even more important reasons to prefer a series of\n>> micro-commits over a mega-patch than just ease of merging.\n> \n> A bundle isn't a mega-patch. It contains all the source revisions. So\n> when you merge or pull it, you get all the original revisions in your\n> repository.\n\nBut what patch reviewer see is a mega-patch showing the changeset\nof a whole \"bundle\", isn't it?\n[...]\n>> Now, I do admit that it is often useful to take the overall view of a\n>> patch series being submitted. This is often the case when a patch\n>> series is in some sub-module of the code for which I don't have as\n>> much direct involvement. In cases like that I will often do review\n>> only of the diff between the tips of the mainline and the branch of\n>> interest, (or if I trust the maintainer enough, perhaps just the\n>> diffstat between the two). But I'm still very glad that what lands in\n>> the history is the series of independent changes, and not one mega\n>> commit.\n> \n> So the difference here is that bundles preserve the original commits the\n> changes came from, so even though it's presented as an overview, you\n> still have a series of independent changes in your history.\n\nI think it is much better to review series of patches commit by commit;\nbesides it allows to correct some inner patches before applying the whole\nseries or drop one of patches in series (and it happened from time to time\non git mailing list).\n\nSo if git introduces bundles, I think they would take form of series\nof \"patch\" mails + introductory email with series description (currently\nit is not saved anywhere), shortlog, diffstat and perhaps more metainfo\nlike bundle parent (which I think should be email form of branch really),\ntags introduced etc.\n-- \nJakub Narebski\nPoland\n"},{"id":"29095","messageId":"845b6e870610180228m39829c49nf37e07e76e744250@mail.gmail.com","threadId":"5925","inReplyTo":"20061018003920.GK20017@pasky.or.cz","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-18T09:28:32Z","receivedAt":"2006-10-18T09:28:32Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"On 10/18/06, Petr Baudis wrote:\n> Dear diary, on Wed, Oct 18, 2006 at 02:30:14AM CEST, I got a letter\n> where Aaron Bentley said that...\n> > Petr Baudis wrote:\n> > > Another aspect of this is that Git (Linus ;) is very focused on getting\n> > > the history right, nice and clean (though it does not _mandate_ it and\n> > > you can just wildly do one commit after another; it just provides tools\n> > > to easily do it).\n> >\n> > Yes, rebasing is very uncommon in the bzr community. We would rather\n> > evaluate the complete change than walk through its history. (Bundles\n> > only show the changes you made, not the changes you merged from the\n> > mainline.)\n> >\n> > In an earlier form, bundles contained a patch for every revision, and\n> > people *hated* reading them. So there's definitely a cultural\n> > difference there.\n>\n> BTW, I think what describes the Git's (kernel's) stance very nicely is\n> what I call the Al Viro's \"homework problem\":\n>\n> http://lkml.org/lkml/2005/4/7/176\n>\n> If I understand you right, the bzr approach is what's described as \"the\n> dumbest kind\" there? (No offense meant!)\n\nYes and no, The bundle includes both the full final thing, and each\nstep along the way. Each step along the way is something you'll get\nwhen you merge it.\n\nOnce merged, it will be \"next one\" in the description above. It would\ntypically look something like this in \"bzr log\"(shortened) In this\nexample, doing C requires doing A and B as well...\n\ncommitter: foobar@foobar.com\nmessage: merged in C\n -------\n committer: bar@bar.com\n message: opps, fix bug in A\n -------\n committer: bar@bar.com\n message: implement B\n -------\n committer: bar@bar.com\n message: implement A\n\nSo, you'll get full history, including errors made :) You can also\nsee who approved it to this branch (foobar) and who did the actual\nwork (bar)\n\n/Erik\n"},{"id":"29103","messageId":"20061018103220.GS75501@over-yonder.net","threadId":"5925","inReplyTo":"4535E844.8010604@op5.se","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-18T10:32:21Z","receivedAt":"2006-10-18T10:32:21Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Wed, Oct 18, 2006 at 10:39:32AM +0200 I heard the voice of\nAndreas Ericsson, and lo! it spake thus:\n>\n> So in essence, the revnos work wonderfully so long as there is a\n> central server to make them immutable?\n\nIt seems from my somewhat detached perspective that there's a lot of\nconflation of 'conventions' with 'capabilities' around this thread...\n\n\nWith a single linear branch, revnos work wonderfully, and are probably\nmuch more useful than any sort of UUID. It would be silly in this day\nand age to design a VCS aimed specifically for this use case, of\ncourse. That doesn't mean a VCS shouldn't make it easy, though.\n\n\nWith a star config, revnos are useful locally and with reference to\nthe \"main\" branch[es]. And, most of the world is star configs of one\nsort or another. Actually, one might say that practically ALL the\nworld outside of linux-kernel is star-configs ;)\n\nIn many cases in the star setup, a revno (particularly along the\n'trunk') is more directly useful than a UUID; consider particularly\nthe case of somebody who's just mirroring/following, not actively\ndeveloping. In some cases, the UUID is more useful. Certainly, using\na revno in a case where the UUID is more appropriate is Bad, but\nthat's just a matter of using the right tool.\n\n\nWith a uber-distributed full-mesh setup, revnos may be basically\nuseless for anything except local lookups (which boils down to\n\"useless for most anything you'd identify a revision for\"). For that\ncase, you'd practically always use the UUID, and pretend revnos don't\nexist.\n\n\nThe merge revno forms (123.5.2.17 and the like), I'm somewhat\nambivalent about in many ways. But, you don't have to use them any\nmore than you have to use \"top-level\" revnos. If either form of revno\nis Wrong for your case (whether it be because \"I hate numbers\nwholesale\", or because \"Numbers don't cover this case usefully\"), then\nyou just use the UUID and pretend the number isn't there. If you\nwanted them completely out of sight, I wouldn't expect it to be very\nhard to talk bzr into never showing the revnos and just showing the\nUUID (\"revid\").\n\n\n\n[ I don't speak for bzr, despite the fact that I'm about to appear to ]\n\n>From where I sit, revnos are quite useful in the first 1.5 or 2 cases.\nSome would argue that they're not useless in the third case as well,\nbut that's no necessary point to hash out; it certainly does no\ntechnical harm to have them there, since you can just ignore them if\nthey don't help you. I think a good case could be made that the vast\nmajority of VCS use in the world is a form of case 2.\n\nGit comes out of a world where case 3 is All, and the other cases are,\nif not actively ignored, at least far secondary considerations, so it\ncan hardly be surprising that it doesn't have or want something that\nadds practically nothing to its case.\n\nbzr, both in its own development schema, and in the expected audience,\nis overwhelmingly case 2 (of which case 1 is really just a degenerate\nversion), but that doesn't mean case 3 is ignored or impossible. The\nUUID's are there for when you need them, and can be used anywhere you\nmight use a number, and just as easily. It's a community convention\nto organize development in such a way that the number is \"usually\"\nuseful, and when it is, it's certainly easier. That doesn't mean you\nHAVE to use it in cases where it doesn't fit, though. \"bzr people\nlike to avoid using UUID's\" doesn't lead to \"bzr can't handle the\ncases where UUID's are necessary\".\n\n\n> Doesn't this mean that one of your key features doesn't actually\n> work in a completely distributed setup\n\nThat's one way of phrasing it, I guess. I'd say rather \"a particular\nfeature isn't applicable to a completely distributed setup\". I'm sure\ngit has a lot of features that are key for somebody that \"don't work\"\nfor someone else, just because they're doing something that person\ndoesn't want done. Just because somebody else thinks their toaster\noven is a great way to solder, doesn't mean you have to sell yours.\nYou can just leave it in the cupboard and use an iron instead.\n\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29104","messageId":"20061018110841.GS20017@pasky.or.cz","threadId":"5925","inReplyTo":"845b6e870610180228m39829c49nf37e07e76e744250@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T11:08:41Z","receivedAt":"2006-10-18T11:08:41Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Oct 18, 2006 at 11:28:32AM CEST, I got a letter\nwhere Erik B?gfors said that...\n> On 10/18/06, Petr Baudis wrote:\n> >Dear diary, on Wed, Oct 18, 2006 at 02:30:14AM CEST, I got a letter\n> >where Aaron Bentley said that...\n> >> Petr Baudis wrote:\n> >> > Another aspect of this is that Git (Linus ;) is very focused on getting\n> >> > the history right, nice and clean (though it does not _mandate_ it and\n> >> > you can just wildly do one commit after another; it just provides tools\n> >> > to easily do it).\n> >>\n> >> Yes, rebasing is very uncommon in the bzr community. We would rather\n> >> evaluate the complete change than walk through its history. (Bundles\n> >> only show the changes you made, not the changes you merged from the\n> >> mainline.)\n> >>\n> >> In an earlier form, bundles contained a patch for every revision, and\n> >> people *hated* reading them. So there's definitely a cultural\n> >> difference there.\n> >\n> >BTW, I think what describes the Git's (kernel's) stance very nicely is\n> >what I call the Al Viro's \"homework problem\":\n> >\n> > http://lkml.org/lkml/2005/4/7/176\n> >\n> >If I understand you right, the bzr approach is what's described as \"the\n> >dumbest kind\" there? (No offense meant!)\n> \n> Yes and no, The bundle includes both the full final thing, and each\n> step along the way. Each step along the way is something you'll get\n> when you merge it.\n> \n> Once merged, it will be \"next one\" in the description above. It would\n> typically look something like this in \"bzr log\"(shortened) In this\n> example, doing C requires doing A and B as well...\n> \n> committer: foobar@foobar.com\n> message: merged in C\n> -------\n> committer: bar@bar.com\n> message: opps, fix bug in A\n> -------\n> committer: bar@bar.com\n> message: implement B\n> -------\n> committer: bar@bar.com\n> message: implement A\n> \n> So, you'll get full history, including errors made :) You can also\n> see who approved it to this branch (foobar) and who did the actual\n> work (bar)\n\nI see, that's what I've been missing, thanks. So it's the middle path\n(as any other commonly used VCS for that matter, expect maybe darcs?;\npatch queues and rebasing count but it's a hack, not something properly\nsupported by the design of Git, since at this point the development\ncannot be fully distributed).\n\nI also assume that given this is the case, the big diff does really not\nserve any purpose besides human review?\n\nBut somewhere else in the thread it's been said that bundles can also\ncontain merges. Does that means that bundles can look like:\n\n 1\n / \\\n 2 4\n | | _\n 3 5 |\n \\ / | a bundle\n 6 |\n ~\n\nIn that case, against what the big diff from 6 is done? 2? 4? Or even 1?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i said that...\n> Robert Collins wrote:\n> >Anyone can push and pull from each other - full stop. Whenever they\n> >'pull' in bzr terms, they get fast-forward happening (if I understand\n> >the git fast-forward behaviour correctly). After a fast-forward, the\n> >dotted decimal revision numbers in the two branches are identical - and\n> >they remain immutable until another fast forward occurs.\n..snip..\n> >You can determine it locally - if you know any of the motherships\n> >revisions locally, we can generate the dotted-revnos that the\n> >motherships master-branch would have from the local data - and the last\n> >merge of mothership you did will have given you that details.\n> \n> \n> To me, this means bazaar isn't distributed at all and I could achieve \n> much the same distributedness(?) by rsyncing an SVN repo, working \n> against that and then rsyncing it back with some fancy merging. In other \n> words, bazaar requires there to be one Lord of the Code, or some of the \n> key features break down.\n\nWell as far as I understand, the Lord of the Code is whoever you pulled\nfrom the last time.\n\nIt's just a different focus here. If I understood everything in this\nthread correctly, both Git and Bazaar have persistent (SHA1, UUID) and\nvolatile (revspec, revision number) revision ids. The only difference is\nthat Git primarily presents the user with the SHA1 ids while Bazaar\nprimarily presents the user with a revision number (and that revspecs\nchange after every commit while revision numbers change only after a\nmerge).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i But somewhere else in the thread it's been said that bundles can also\n> contain merges. Does that means that bundles can look like:\n>\n>    1\n>   / \\\n>  2   4\n>  |   | _\n>  3   5  |\n>   \\ /   | a bundle\n>    6    |\n>        ~\n>\n> In that case [merge bundle], against what the big diff from 6 is done?\n> 2? 4? Or even 1? \n\nOr do you use equivalent of git combined diff format?\nhttp://www.kernel.org/pub/software/scm/git/docs/git-diff-tree.html\n-- \nJakub Narebski\nPoland\n"},{"id":"29108","messageId":"45360DAE.8000702@op5.se","threadId":"5925","inReplyTo":"20061018103220.GS75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-18T11:19:10Z","receivedAt":"2006-10-18T11:19:10Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthew D. Fuller wrote:\n> On Wed, Oct 18, 2006 at 10:39:32AM +0200 I heard the voice of\n> Andreas Ericsson, and lo! it spake thus:\n>> So in essence, the revnos work wonderfully so long as there is a\n>> central server to make them immutable?\n> \n> \n> With a star config, revnos are useful locally and with reference to\n> the \"main\" branch[es]. And, most of the world is star configs of one\n> sort or another. Actually, one might say that practically ALL the\n> world outside of linux-kernel is star-configs ;)\n> \n\nThat might be the case today. However, since we introduced git at the \noffice, mini-projects are cropping up like mad, and pieces of toy-code \nare being pushed around among the employees. When something is found to \nbe useful enough to attract management attention, it's given a spot at \nthe \"master site\". It doesn't need one. It's just that we have this one \nplace where gitweb is installed, which management likes whereas devs \ndon't have that on their laptop. It's also convenient to have one place \nto find all changes rather than pulling from 1-to-N different people \njust to have a look at what they've done.\n\nThe point I'm trying to make here is that the star config might be the \nmost common case today because\na) old scm's enforced this use case and it is therefor the most common \nway just out of habit.\nb) projects you actually *see* have gotten past the \"Joe made some cool \nchanges, pull his 'jukebox-ui' branch\".\n\n\n> In many cases in the star setup, a revno (particularly along the\n> 'trunk') is more directly useful than a UUID; consider particularly\n> the case of somebody who's just mirroring/following, not actively\n> developing. In some cases, the UUID is more useful. Certainly, using\n> a revno in a case where the UUID is more appropriate is Bad, but\n> that's just a matter of using the right tool.\n> \n\nI can easily imagine the use case Linus pointed out with BK. Because \nrevnos work wonderfully 80% of the time, people get confused, frustrated \nand downright pissed off when they don't.\n\n> \n> With a uber-distributed full-mesh setup, revnos may be basically\n> useless for anything except local lookups (which boils down to\n> \"useless for most anything you'd identify a revision for\"). For that\n> case, you'd practically always use the UUID, and pretend revnos don't\n> exist.\n> \n\nBut they *do* exist, and they *usually* work, so people are bound to try \nthem first. Teaching them when they work and when they don't (or rather, \nwhen they should and when they shouldn't, cause they will work by \naccident sometimes too) is bound to be a lot harder than sending them a \n10 char irc message.\n\n> \n> The merge revno forms (123.5.2.17 and the like), I'm somewhat\n> ambivalent about in many ways. But, you don't have to use them any\n> more than you have to use \"top-level\" revnos. If either form of revno\n> is Wrong for your case (whether it be because \"I hate numbers\n> wholesale\", or because \"Numbers don't cover this case usefully\"), then\n> you just use the UUID and pretend the number isn't there. If you\n> wanted them completely out of sight, I wouldn't expect it to be very\n> hard to talk bzr into never showing the revnos and just showing the\n> UUID (\"revid\").\n> \n\nSo what's the point in having them? You can't seriously tell me that you \nthink of 123.5.2.17 as something you can easily remember, do you? Count \nthe times, during one day, where you use the revnos and type them manually.\n\n> \n> \n> [ I don't speak for bzr, despite the fact that I'm about to appear to ]\n> \n>>From where I sit, revnos are quite useful in the first 1.5 or 2 cases.\n> Some would argue that they're not useless in the third case as well,\n> but that's no necessary point to hash out; it certainly does no\n> technical harm to have them there, since you can just ignore them if\n> they don't help you. I think a good case could be made that the vast\n> majority of VCS use in the world is a form of case 2.\n> \n> Git comes out of a world where case 3 is All, and the other cases are,\n> if not actively ignored, at least far secondary considerations, so it\n> can hardly be surprising that it doesn't have or want something that\n> adds practically nothing to its case.\n> \n\nNot really. It's just that case 3 is the most flexible of them all. It's \ntrivial to enforce linear development in git. Just add a hook that \nforbids merge commits. Set up a \"master repo\" and put the hook there and \nyou've turned it into CVS with off-line log-browsing (more or less).\n\nSet up a master-server and enable the reflog there and you've turned it \ninto bazaar, more or less.\n\nIn git, the mothership repo is there for conveniance, because it's nice \nto have one place to set up mailing-list hooks, gitweb, git-daemon and \nthe likes. Everything works *exactly* as it would have done without it \nin all repos around the world.\n\n\n> bzr, both in its own development schema, and in the expected audience,\n> is overwhelmingly case 2 (of which case 1 is really just a degenerate\n> version), but that doesn't mean case 3 is ignored or impossible. The\n> UUID's are there for when you need them, and can be used anywhere you\n> might use a number, and just as easily. It's a community convention\n> to organize development in such a way that the number is \"usually\"\n> useful, and when it is, it's certainly easier. That doesn't mean you\n> HAVE to use it in cases where it doesn't fit, though. \"bzr people\n> like to avoid using UUID's\" doesn't lead to \"bzr can't handle the\n> cases where UUID's are necessary\".\n> \n\nHave a look at the list of things that CVS \"can handle\" and compare it \nmentally to the things CVS \"handles gracefully\" and you'll see why \npeople have stopped using it.\n\n> \n>> Doesn't this mean that one of your key features doesn't actually\n>> work in a completely distributed setup\n> \n> That's one way of phrasing it, I guess. I'd say rather \"a particular\n> feature isn't applicable to a completely distributed setup\".\n\nSo how come it's in the same list of features as the \"distributed \nrepository model\", and both are marked as supported when they're \napparently mutually exclusive?\n\n\n> I'm sure\n> git has a lot of features that are key for somebody that \"don't work\"\n> for someone else, just because they're doing something that person\n> doesn't want done.\n\nThe main point, the *important* point about git is that everything it \nshows always makes sense and works in exactly the same way no matter \nwhich setup you use. There are no features in git that are mutually \nexclusive, or only sane in one particular setup but not in others. You \ncan use them all or pick which ones you like. Whatever you choose, it \nnever comes at the expense of losing something else.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"29110","messageId":"20061018124320.GT75501@over-yonder.net","threadId":"5925","inReplyTo":"45360DAE.8000702@op5.se","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-18T12:43:20Z","receivedAt":"2006-10-18T12:43:20Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Wed, Oct 18, 2006 at 01:19:10PM +0200 I heard the voice of\nAndreas Ericsson, and lo! it spake thus:\n> \n> It's just that we have this one place where gitweb is installed,\n> which management likes whereas devs don't have that on their laptop.\n> It's also convenient to have one place to find all changes rather\n> than pulling from 1-to-N different people just to have a look at\n> what they've done.\n\nI think this just by itself lends support to:\n\n> The point I'm trying to make here is that the star config might be\n> the most common case today because\n\nc) Stars work well as a mental model for humans.\n\nHeck, in large, Linux is star-ish. There s \"2.6.1\", \"2.6.2\", etc;\nthat's a trunk. Any time you have releases, you're establishing a\n\"master\" branch. For most people using Linux, there's a trunk,\nwhether it's the kernel.org trunk, or the \"What Redhat ships\" trunk,\netc. The closer you drill to the day-to-day work on the kernel, the\nfarther it gets from trunks, but if it were full-mesh at all levels I\ndon't think it would be nearly as usable for regular computing tasks\nas it is.\n\n\nPerhaps someday a heavy full-mesh setup will be the common case for\nVCS usage. I find that very difficult to buy for various reasons, but\nit could happen. If it does, bzr may well revisit the choice and\ndecide revnos contribute little enough marginal value as to be a loss,\nand discard them. But that's not today.\n\n\n> But they *do* exist, and they *usually* work, so people are bound to\n> try them first. Teaching them when they work and when they don't (or\n> rather, when they should and when they shouldn't, cause they will\n> work by accident sometimes too) is bound to be a lot harder than\n> sending them a 10 char irc message.\n\nPerhaps, for some projects. And in those cases, perhaps you'd want to\nflip a hypothetical \"dump those numbers in the bin\" switch. That\ndoesn't mean every project wants to, or that those projects who don't\nand have no trouble and discernible gain from revno usage are\nhypothetical.\n\n\n> So what's the point in having them? You can't seriously tell me that\n> you think of 123.5.2.17 as something you can easily remember, do\n> you? Count the times, during one day, where you use the revnos and\n> type them manually.\n\nNo, I don't. But I don't use merge revnos for various reasons, one of\nthe primary ones being that they don't currently intuitively follow\nfrom me (and that intuitiveness is the major attraction of revnos in\nthe first place).\n\nI rarely refer to non-mainline revisions at all, in fact. And I use\nrevnos for mainline revisions regularly. Heck, I communicate revnos\n_verbally_; people handle that easily with numbers, not so easily with\nhex strings. The vast majority of my branches are simple cases, and I\nlike simple tools that match simple mental models for them. For the\nmore intricate cases, revids provide a more rigorous tool, and I WANT\na VCS that lets me choose which is appropriate. If I wanted a\ncomputer to tell me how to work, I'd run Windows ;)\n\n\n> Not really. It's just that case 3 is the most flexible of them all.\n\nYes, but this doesn't necessarily mean everything you seem to try and\ncover with it. The more rigorous tool will cover the simplest case\n(those being just a degenerate form of the more complex after all),\nbut that doesn't mean it's the EASIEST way of handling that case.\n\n\n> Everything works *exactly* as it would have done without it in all\n> repos around the world.\n\nAnd if you use the UUID's, the same applies to bzr.\n\nThat is, if you use git like you use git, the above is true. If you\nuse bzr like you use git, the above is ALSO true.\n\nThe difference is that bzr ALSO chooses to support and optimize for a\ndifferent case in the default UI presentation, because We[0] consider\nthat far and away the common case on the one hand, and that people\ntrying to use the more complex case are ipso facto more able to use a\nbehavior differing from the norm on the other.\n\n\n[0] Note how adroitly I again speak for other people. Practice,\n practice!\n\n\n> >That's one way of phrasing it, I guess. I'd say rather \"a\n> >particular feature isn't applicable to a completely distributed\n> >setup\".\n> \n> So how come it's in the same list of features as the \"distributed\n> repository model\", and both are marked as supported when they're\n> apparently mutually exclusive?\n\nI assume in this you're referring to the RcsComparisons page that\nstarted the thread. First off, I don't agree with all the\ncharacterizations on the page, so don't expect me to support it as\ngospel. That said, they're not \"mutually exclusive\"; one is just\ninapplicable in extreme cases of the other. \"Plugins\" is on the same\nlist as \"distributed repository model\" too. And you can't count on\nother people having the same plugins as you, so it's just as \"mutually\nexclusive\" with distributed.\n\n\n> The main point, the *important* point about git is that everything\n> it shows always makes sense and works in exactly the same way no\n> matter which setup you use. There are no features in git that are\n> mutually exclusive, or only sane in one particular setup but not in\n> others.\n\nI find it really hard to believe that that's strictly true, just as a\ngeneral rule. For that matter, I think it's demonstrably false: using\nSHA1 hashes as revision identifiers in a simple linear tree with 5\nrevs doesn't strike me as \"sane\". But that aside...\n\nI don't think of that as a positive thing. There are lots of things\nthat make sense in certain setups that don't in others. We have two\ntechniques, A and B, and two general cases, X and Y. A works really\nwell for X, and is useless with Y. B works ok for X, and handles Y\nwell. \"Use A for X and B for Y\" seems like a heck of a lot better\nanswer than \"Only support B\". You certainly CAN shape wood joints\nwith just a claw hammer, but I wouldn't want to. A jigsaw makes it\nmuch easier, no matter how useless it may be for forging iron.\n\n\nYour position seems to be, in essence, \"This feature can be misused,\ntherefore it should be eliminated\". And you should certainly use a\ntool that provides the behavior you want. So, too, should other\npeople.\n\nI don't want to use git for any number of reasons, which sum up\nconcisely if undescriptively as \"It doesn't work for me\", but it seems\nto work great for the community it was built for, and that's\nexcellent. Not all aspects of that design work well for other people,\nthough, no matter how poorly some capability \"fits\" you\n(non-specific), it can still fit others very well. This particular\nitem certainly seems one of those significant divides.\n\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29111","messageId":"BAYC1-PASMTP05B3E4A82F968CA2E22589AE0F0@CEZ.ICE","threadId":"5925","inReplyTo":"20061018124320.GT75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-18T13:02:18Z","receivedAt":"2006-10-18T13:02:18Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 18 Oct 2006 07:43:20 -0500\n\"Matthew D. Fuller\" wrote:\n\n> The difference is that bzr ALSO chooses to support and optimize for a\n> different case in the default UI presentation, because We[0] consider\n> that far and away the common case on the one hand, and that people\n> trying to use the more complex case are ipso facto more able to use a\n> behavior differing from the norm on the other.\n> \n> [0] Note how adroitly I again speak for other people. Practice,\n> practice!\n\nJust to be clear here, Git is also able to supports this model if\nyou so choose. It's quite easy for a server to generate Git tags\nfor every commit it gets.\n\nIt's just that this is basically a non issue in the Git world. People\nwho use Git aren't crying out for salvation from sha1 numbers. So I\nthink this entire discussion is a bit overblown.\n\nBut just to be clear, there is nothing in the Git model that prohibits\ntagging every commit with something you find less objectionable than\nsha1's. They can appear in the log listings and in gitk etc, and\neveryone who pulls from the central server will get them. In fact,\nfor some imports of other VCS into Git, exactly that is done; so every\ncommit can be referenced by its sha1 _or_ the \"friendly\" number it was\nknown by in its original VCS.\n\nSean\n"},{"id":"29311","messageId":"20061018090218.35f0326b.seanlkml__34760.2584785365$1161335526$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"20061018124320.GT75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-18T13:02:18Z","receivedAt":"2006-10-18T13:02:18Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 18 Oct 2006 07:43:20 -0500\n\"Matthew D. Fuller\" wrote:\n\n> The difference is that bzr ALSO chooses to support and optimize for a\n> different case in the default UI presentation, because We[0] consider\n> that far and away the common case on the one hand, and that people\n> trying to use the more complex case are ipso facto more able to use a\n> behavior differing from the norm on the other.\n> \n> [0] Note how adroitly I again speak for other people. Practice,\n> practice!\n\nJust to be clear here, Git is also able to supports this model if\nyou so choose. It's quite easy for a server to generate Git tags\nfor every commit it gets.\n\nIt's just that this is basically a non issue in the Git world. People\nwho use Git aren't crying out for salvation from sha1 numbers. So I\nthink this entire discussion is a bit overblown.\n\nBut just to be clear, there is nothing in the Git model that prohibits\ntagging every commit with something you find less objectionable than\nsha1's. They can appear in the log listings and in gitk etc, and\neveryone who pulls from the central server will get them. In fact,\nfor some imports of other VCS into Git, exactly that is done; so every\ncommit can be referenced by its sha1 _or_ the \"friendly\" number it was\nknown by in its original VCS.\n\nSean\n"},{"id":"29114","messageId":"845b6e870610180609l70daa727wbda9b03ab99ba301@mail.gmail.com","threadId":"5925","inReplyTo":"20061018110841.GS20017@pasky.or.cz","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-18T13:09:35Z","receivedAt":"2006-10-18T13:09:35Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"On 10/18/06, Petr Baudis wrote:\n> Dear diary, on Wed, Oct 18, 2006 at 11:28:32AM CEST, I got a letter\n> where Erik B?gfors said that...\n> > On 10/18/06, Petr Baudis wrote:\n> > >Dear diary, on Wed, Oct 18, 2006 at 02:30:14AM CEST, I got a letter\n> > >where Aaron Bentley said that...\n> > >> Petr Baudis wrote:\n> > >> > Another aspect of this is that Git (Linus ;) is very focused on getting\n> > >> > the history right, nice and clean (though it does not _mandate_ it and\n> > >> > you can just wildly do one commit after another; it just provides tools\n> > >> > to easily do it).\n> > >>\n> > >> Yes, rebasing is very uncommon in the bzr community. We would rather\n> > >> evaluate the complete change than walk through its history. (Bundles\n> > >> only show the changes you made, not the changes you merged from the\n> > >> mainline.)\n> > >>\n> > >> In an earlier form, bundles contained a patch for every revision, and\n> > >> people *hated* reading them. So there's definitely a cultural\n> > >> difference there.\n> > >\n> > >BTW, I think what describes the Git's (kernel's) stance very nicely is\n> > >what I call the Al Viro's \"homework problem\":\n> > >\n> > > http://lkml.org/lkml/2005/4/7/176\n> > >\n> > >If I understand you right, the bzr approach is what's described as \"the\n> > >dumbest kind\" there? (No offense meant!)\n> >\n> > Yes and no, The bundle includes both the full final thing, and each\n> > step along the way. Each step along the way is something you'll get\n> > when you merge it.\n> >\n> > Once merged, it will be \"next one\" in the description above. It would\n> > typically look something like this in \"bzr log\"(shortened) In this\n> > example, doing C requires doing A and B as well...\n> >\n> > committer: foobar@foobar.com\n> > message: merged in C\n> > -------\n> > committer: bar@bar.com\n> > message: opps, fix bug in A\n> > -------\n> > committer: bar@bar.com\n> > message: implement B\n> > -------\n> > committer: bar@bar.com\n> > message: implement A\n> >\n> > So, you'll get full history, including errors made :) You can also\n> > see who approved it to this branch (foobar) and who did the actual\n> > work (bar)\n>\n> I see, that's what I've been missing, thanks. So it's the middle path\n> (as any other commonly used VCS for that matter, expect maybe darcs?;\n> patch queues and rebasing count but it's a hack, not something properly\n> supported by the design of Git, since at this point the development\n> cannot be fully distributed).\n>\n> I also assume that given this is the case, the big diff does really not\n> serve any purpose besides human review?\n>\n> But somewhere else in the thread it's been said that bundles can also\n> contain merges. Does that means that bundles can look like:\n>\n> 1\n> / \\\n> 2 4\n> | | _\n> 3 5 |\n> \\ / | a bundle\n> 6 |\n> ~\n>\n> In that case, against what the big diff from 6 is done? 2? 4? Or even 1?\n\nWhen you run the \"bundle\" command, you can tell it what you want the\nbundle to be created against. So, If I just commited 5, I can run\n\"bzr bundle -r-1\" to get the bundle against 4, or I can do \"bzr bundle\npath/to/other/branch\" to get a bundle that relates to it.\n\nTo merge a bundle into a branch, the parrent of the first revision in\nthe bundle, has to exist in the branch is't being merged into. (well,\nunless you use patch, but that's outside of bzr, and bzr wouldn't know\nabout each revision in them)\n\nThis command will find a common root and create a bundle that\ncorresponds to it. The \"big diff\" as you call it, would be the\nchanges between the point where the branch was created, and the last\ncommit.\n\nIn the case of just committing 5, and you want to create a bundle that\ncan be merged back at point 6, the \"big diff\" would be against 1 since\nthat's the branch point.\n\n/Erik\n"},{"id":"29113","messageId":"200610181510.23095.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061018124320.GT75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-18T13:10:22Z","receivedAt":"2006-10-18T13:10:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia środa 18. października 2006 14:43, Matthew D. Fuller napisał:\n> On Wed, Oct 18, 2006 at 01:19:10PM +0200 I heard the voice of\n> Andreas Ericsson, and lo! it spake thus:\n> > \n> > It's just that we have this one place where gitweb is installed,\n> > which management likes whereas devs don't have that on their laptop.\n> > It's also convenient to have one place to find all changes rather\n> > than pulling from 1-to-N different people just to have a look at\n> > what they've done.\n> \n> I think this just by itself lends support to:\n> \n> > The point I'm trying to make here is that the star config might be\n> > the most common case today because\n> \n> c) Stars work well as a mental model for humans.\n> \n> Heck, in large, Linux is star-ish. There s \"2.6.1\", \"2.6.2\", etc;\n> that's a trunk. Any time you have releases, you're establishing a\n> \"master\" branch. For most people using Linux, there's a trunk,\n> whether it's the kernel.org trunk, or the \"What Redhat ships\" trunk,\n> etc. The closer you drill to the day-to-day work on the kernel, the\n> farther it gets from trunks, but if it were full-mesh at all levels I\n> don't think it would be nearly as usable for regular computing tasks\n> as it is.\n\nNo, it is not. If you consider only published Linus repository, and\nprivate repositories of other people, it usually is star-ish (although\nmentioned situaltion where somebody else repository took place of center\nof star-ish configuration wouldn't be possible in tru star-ish model).\nBut please take note of stable repository, -mm repository; the changes\nare exchanged there and back again. And \"What Redhat ships\" is AFAIK\nmix of different repositories and own patches. \n \n-- \nJakub Narebski\nPoland\n"},{"id":"29119","messageId":"Pine.LNX.4.64.0610180739230.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061018053647.GA3507@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-18T14:52:25Z","receivedAt":"2006-10-18T14:52:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Jeff King wrote:\n> \n> I never used BK, but my understanding is that it was based on\n> changesets, so a bundle was a group of changesets.\n\nYes.\n\n> Because a git commit represents the entire tree state, how can we avoid \n> sending the entire tree in each bundle?\n\nThat's not the problem. That's easy to handle - and we already do. That's \nthe whole point of the wire-transfer protocol (ie sending deltas, and only \nsending enough to actually matter).\n\n> The interactive protocols can ask \"what do you have?\" but an email \n> bundle is presumably meant to work without a round trip.\n\nRight, but they can do exactly what bk did: you have to have a reference \nto what the other side has. In git, that's usually even simpler: you'd do\n\n\tgit send origin..\n\nand that \"origin\" is what the other end is expected to already have.\n\nOf course, if you send an unconnected bundle (ie you give an origin that \nthe other end _doesn't_ have), you're screwed.\n\nIn other words, to get such a pack, we'd _literally_ just do something \nlike\n\n\tgit-rev-list --objects-edge origin.. |\n\t\tgit-pack-objects --stdout |\n\t\tuuencode\n\nand that would be it. You'd still need to add a \"diffstat\" to the thing, \nand tell the other end what the current HEAD is (so that it knows what \nit's supposed to fast-forward to), but it _literally_ is that simple.\n\n\"plug-in architecture\" my ass. \"I recognize this - it's UNIX!\".\n\n\t\tLinus\n"},{"id":"29121","messageId":"Pine.LNX.4.64.0610180820210.3962@g5.osdl.org","threadId":"5925","inReplyTo":"1161147348.3423.24.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-18T15:31:05Z","receivedAt":"2006-10-18T15:31:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Robert Collins wrote:\n> \n> More commonly though, like git users have 'origin' and 'master'\n> branches, bzr users tend to have a branch that is the 'origin' (for bzr\n> itself this is usually called bzr.dev), as well as N other branches for\n> their own work, which is probably why we haven't seen the need to have a\n> ui command to spit out the revnos for an arbitrary branch.\n\nYou mis-understand.\n\ngit doesn't have a \"ui command to spit out the revnos for an arbitrary \nbranch\" either.\n\nNormally, you'd just use the branch-name. Nobody ever uses the SHA1's \ndirectly.\n\nWhat git does (and does very well) is to be _scriptable_. It was designed \nthat way. I'm a UNIX guy. I think piping is very powerful. And when you \nscript things, your scripts pass SHA1's around internally.\n\nSo for example, to repack a git archive, you'd normally do\n\n\tgit repack -a -d\n\nand you don't have any \"UI\" with SHA1 numbers. But internally, this used \nto be\n\n\tgit-rev-list --all --objects |\n\t\tgit-pack-objects \n\nwhere \"git-rev-list\" is the one that lists all object names (which are the \nSHA1 numbers), and \"git-pack-objects\" is the one that takes a list of \nobjects and packs them. \n\n(These days, since our internal C libraries have become so much better, \nthe object traversal is done internally to packing, so we don't actually \nuse the pipe any more for repacking an archive, but that's just an \nimplementation detail)\n\nYou seem to think that we use SHA1 names as _humans_. We don't. The SHA1 \nnames are used internally, and humans just use the branch names.\n\nThe only case you'd (as a human) use the SHA1 name is when you want to \npass it on to another person that may have a different archive (ie you \nmail somebody a revision that is problematic). It would obviously be \ntotally unworkable to say \"it's the grand-parent of my current HEAD \ncommit\", since that's a local description. So instead, you'd say \"it's \ncommit 9550e59c4587f637d9aa34689e32eea460e6f50c\".\n\nSo I think people (totally incorrectly) think that git users use a lot of \nSHA1 names, just because they see the git users on the kernel mailing list \nsending each others SHA1 names. But that's because you see only the case \nwhere you _want_ to communicate a stable revision name to another side. \nSending a number like 1.57.8.312 to describe what commit broke would be a \n_bug_, because a person who has a differently shaped tree wouldn't even \n_have_ that revision.\n\nBut normally? You'd be hard-pressed to find anything but the branch (and \ntag) names on a command line.\n\nSee?\n\n\t\t\tLinus\n"},{"id":"29122","messageId":"87y7rdd47j.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"45359B2A.1070102@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-18T15:38:24Z","receivedAt":"2006-10-18T15:38:24Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 17 Oct 2006 23:10:34 -0400, Aaron Bentley wrote:\n> If B merges A before this, nothing happens, because B is already a\n> superset of A.\n>\n> If B merges afterward, we get this:\n\nWow. Thanks for elucidating---again I was making some incorrect\nassumptions about the system, so your answer was surprising and\nappreciated.\n\nSo, am I correct in my understanding now that it's impossible for two\nusers to establish identical code history on both sides through merge?\nIf the two kept merging back and forth the history would pick up a new\ncommit each time even though there were no code changes. Right?\n\nThat's a startling property. I'm surprised to learn that the\ngenerally-used mechanism for getting new changes doesn't have a mode\nwhere it says \"you're already up to date---doing nothing\".\n\nI do understand that there's a separate \"pull\" that does allow for\ncorrect synchronization of a local repository with a remote\nrepository, and it does have the \"up to date---doing nothing\"\nbehavior. But as you already said, it's often avoided specifically\nbecause it destroys locally-created revision numbers.\n\nAnother way of describing bzr's \"pull\" is that it establishes a\nmaster-slave relationship between the remote and local repository,\n(his numbers are more important than mine, so I'll throw mine away).\nI think Linus already provided a good argument in this thread about\nwhy that kind of asymmetry is bad for software projects and why tools\nshould not provide it.\n\nSo there are some aspects of the bzr design that rob from its ability\nto function as a distributed version control system. It really does\nbias itself toward centralization, (the so called \"star topoloogy\" as\nopposed to something \"fully\" distributed).\n\nAnd by the way, some people seem to have the opinion that there's\nsomething unique about the way the linux kernel is developed that\nallows is to benefit from a fully distributed system. The assumption\nseems to be that projects with a central tree won't benefit the same\nway, and don't really need the full set of features of a distributed\nsystem. That's not true in my experience.\n\nWith cairo, for example, we had been using cvs. Obviously, it imposes\na centralized model, but most of the active developers had been using\nrsync or other repository synchronization so that we could at least do\noffline history browsing. So even with cvs we had as much of a star\ntopology as possible, (but we didn't have offline commits to our\nroaming repositories, nor did we have any sharing between them).\n\nNow, after the switch from cvs to git, we still do have a central\nrepository that all developers share and push into, (this is distinct\nfrom how linux or the git project itself use git). And git supports\nthis kind of shared central repository perfectly well.\n\nBut a lot of the big advantages the cairo project gets from git come\nfrom our ability to now easily share branches among ourselves without\ngoing through the central repository. We only push fully-cooked\nbranches to the central tree. But now, with everyone owning their own\npublicly-visible repository with all their work in it, we can now\neasily share the half-baked ideas we have with all their history. One\nperson can start an idea, and others can easily pick it up, (without\nhaving to drop down to a mega-patch like we would have done with\ncvs). And people actually have the ability to collaborate on turning\nan answer into a solution, (in Al Viro's terminology).\n\nSo even a project that's very oriented around a single, central tree\ncan get a lot of benefit from being able to share things arbitrarily\nbetween any two given repositories. And I think that any project will\nnaturally start doing more of this kind of sharing, (and benefitting\nconsiderably from it), as it adopts tools that support it well.\n\n-Carl\n"},{"id":"29123","messageId":"200610181750.32888.jnareb@gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610180820210.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-18T15:50:32Z","receivedAt":"2006-10-18T15:50:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n> \n> On Wed, 18 Oct 2006, Robert Collins wrote:\n>> \n>> More commonly though, like git users have 'origin' and 'master'\n>> branches, bzr users tend to have a branch that is the 'origin' (for bzr\n>> itself this is usually called bzr.dev), as well as N other branches for\n>> their own work, which is probably why we haven't seen the need to have a\n>> ui command to spit out the revnos for an arbitrary branch.\n> \n> You mis-understand.\n> \n> git doesn't have a \"ui command to spit out the revnos for an arbitrary \n> branch\" either.\n> \n> Normally, you'd just use the branch-name. Nobody ever uses the SHA1's \n> directly.\n\nWith the exception of having sometimes commit-ids in the commit messages,\nfor example \"Fixes bug introduced by aabbcc00\" (although usually you just\nwrite \"Fixes bug in some_function in some_file\"), and automatically\ngenerated \n This reverts d119e3de13ea1493107bd57381d0ce9c9dd90976 commit.\n(in addition to 'Revert \"\") for git-revert generated\ncommit messages.\n\nAnd it is true that you usually use branchname, or branchname~n syntax.\nGit even has git-name-rev to convert from sha1 to temporary, local\nref^m~n... syntax.\n\n\nBy the way, git has very powerfull syntax to get revisions, and\nrevision lists. For example \"git-rev-list foo bar ^baz\" means\n\"list all the commits which are included in foo and bar lineage,\nbut not in baz\", or more useful \"git log origin..next\".\n\nHow's that in bzr?\n-- \nJakub Narebski\nPoland\n"},{"id":"29125","messageId":"Pine.LNX.4.64.0610180855270.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061018124320.GT75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-18T16:07:10Z","receivedAt":"2006-10-18T16:07:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Matthew D. Fuller wrote:\n\n> On Wed, Oct 18, 2006 at 01:19:10PM +0200 I heard the voice of\n> Andreas Ericsson, and lo! it spake thus:\n> > \n> > It's just that we have this one place where gitweb is installed,\n> > which management likes whereas devs don't have that on their laptop.\n> > It's also convenient to have one place to find all changes rather\n> > than pulling from 1-to-N different people just to have a look at\n> > what they've done.\n> \n> I think this just by itself lends support to:\n> \n> > The point I'm trying to make here is that the star config might be\n> > the most common case today because\n> \n> c) Stars work well as a mental model for humans.\n\nI really don't think that's even true.\n\nMost projects do tend to have a star-like setup, but I think that's \nlargely due to historical tools, not mental models. \n\nFor example, I used CVS professionally for too long a few years ago, and \nthe thing I _really_ hated was exactly how it forced people who were \nworking on \"experimental stuff\" to be so tightly organized around the \ncentral repository (and how they had to do things that were visible and \nannoying to the mainline).\n\nAnd I think that's where the \"star-like\" situation breaks down: when you \nhave a group of people who go off to do something experimental. Suddenly \nthe \"mainline\" in that case isn't the central and most important \nrepository any more, and instead you really have another second (and \nthird, fourth etc) \"centerpoint\" that another group works around.\n\nNow, what does that mean? It means that whenever you look at a big project \nfrom the outside, you tend to see a star-like thing: there's the \"big \ncommon thing\", and you won't even be _seeing_ the off-shoots, because they \ntend to be used by developers to try out new ideas etc. So it looks like a \nstar, but it really isn't, and shouldn't be.\n\nAn SCM should support the _developers_, not the users. The users don't \nneed an SCM, they just need a place to fetch the \"standard\" thing \n(preferably with a vendor that supports them or at least makes them feel \ncomfy). But an SCM really should support the off-shoots, because that's \nwhere the exciting stuff happens.\n\nBtw, this is also why distribution is so fundamentally important:\n\nMost of the off-shoots tend to be failures, but that is as it should be. \nAgain, this is where SVN and CVS and other centralized models fail \n_miserably_. Because branches are in a centralized repository, the cost of \nfailure is visible to all, and thus people don't like creating branches \nfor things that don't look \"obviously viable\" to the people around the \ncentral repository.\n\nIn contrast, in a truly distributed environmen, a failed branch is \nsomething that people don't even KNOW about. Anybody can take the kernel \ngit tree, start his own development line (with ten other people) and try \nto improve it. And if it fails, I'd never even know: there is literally \n_zero_ cost to everybody else from failed branches. And if they succeed, \nthey'll just say \"hey, pull this, it works, and it makes Xyz go five times \nfaster\".\n\n\t\tLinus\n"},{"id":"29127","messageId":"Pine.LNX.4.64.0610180918160.3962@g5.osdl.org","threadId":"5925","inReplyTo":"200610181750.32888.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-18T16:22:58Z","receivedAt":"2006-10-18T16:22:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Jakub Narebski wrote:\n> > \n> > Normally, you'd just use the branch-name. Nobody ever uses the SHA1's \n> > directly.\n> \n> With the exception of having sometimes commit-ids in the commit messages,\n> for example \"Fixes bug introduced by aabbcc00\" (although usually you just\n> write \"Fixes bug in some_function in some_file\"), and automatically\n> generated \n> This reverts d119e3de13ea1493107bd57381d0ce9c9dd90976 commit.\n\nYes. But in both cases, that's usually because you literally ended up \nhaving the commit name because somebody else (which _can_ be you) searched \nfor it (with something like \"bisect\") and gave it to you.\n\nSo even that case is really about communicating a stable name from one \nplace (the \"find the bug\") to another (the \"revert the buggy commit\").\n\nSo yes, _communication_ should always happen by full SHA1's, because those \nare the only thing that always remain stable.\n\n(The fact that \"gitk\" and I think \"gitweb\" can then turn them into \nhyperlinks in the commit message is obviously one reason we then tend to \ngive them such prominent visibility - they actually end up being very \nuseful later on).\n\nIn bzr, either you don't get the hyperlinks, or you need to use the \nnon-simple name in the commit messages, since the simple names don't \nactually work. Either way, it's an inferior setup.\n\n\t\t\tLinus\n"},{"id":"29128","messageId":"453656F8.3000504@utoronto.ca","threadId":"5925","inReplyTo":"200610181120.49749.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-18T16:31:52Z","receivedAt":"2006-10-18T16:31:52Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJakub Narebski wrote:\n> Aaron Bentley wrote:\n> \n>>Carl Worth wrote:\n>>>There are even more important reasons to prefer a series of\n>>>micro-commits over a mega-patch than just ease of merging.\n>>\n>>A bundle isn't a mega-patch. It contains all the source revisions. So\n>>when you merge or pull it, you get all the original revisions in your\n>>repository.\n> \n> \n> But what patch reviewer see is a mega-patch showing the changeset\n> of a whole \"bundle\", isn't it?\n> [...]\n\nYes. Carl was saying that, aside from the issue of what a reviewer\nsees, a bundle is bad for other reasons. I am saying those other\nreasons don't apply. I wasn't addressing the issue of what a reviewer sees.\n\nTo me, seeing the individual patches is like reading a book where every\npage has a different word on it, and so it's hard to put it together\ninto a full sentence. I'm not saying my way is The Right Way, just my\npersonal preference.\n\nFor larger pieces of work, we try to split them up into logical units,\nand merge those units independently.\n\nThe Bundle format can also support a patch-by-patch output, but we don't\nhave UI to select that.\n\n> I think it is much better to review series of patches commit by commit;\n> besides it allows to correct some inner patches before applying the whole\n> series or drop one of patches in series (and it happened from time to time\n> on git mailing list).\n\nIt's important to remember that bundles represent revisions, not\npatches. When you merge a bundle, you\n\n1. install those revisions into your repository. These revisions are\n latent, as though they were on another branch.\n2. merge the head revision of the bundle into your branch.\n\nVirtually any merge selection process that works with branches would\nalso work with bundles. So tweaking before merging is really a matter\nof replacing the UI for 2.\n\n> So if git introduces bundles, I think they would take form of series\n> of \"patch\" mails + introductory email with series description (currently\n> it is not saved anywhere), shortlog, diffstat and perhaps more metainfo\n> like bundle parent (which I think should be email form of branch really),\n> tags introduced etc.\n\nThe parent in a bundle revision is the revision-id of the parent of that\nrevision in the branch. I don't think it's possible to change that\nparent id into something else, without changing the meaning of a bundle.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFNlb40F+nu1YWqI0RAnxxAJ9ETibey1Qyvz/zVxdGipaHGtnddgCfTtzt\nCQUZ2dK64BS5K5WYecFAsfM=\n=bJxq\n-----END PGP SIGNATURE-----\n"},{"id":"29132","messageId":"1161194590.4467.34.camel@localhost.localdomain","threadId":"5925","inReplyTo":"200610171555.56778.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Jeff Licquia","fromEmail":"jeff@licquia.org","sentAt":"2006-10-18T18:03:10Z","receivedAt":"2006-10-18T18:03:10Z","isPatch":false,"sender":{"key":"jeff@licquia.org","avatar":null},"body":"On Tue, 2006-10-17 at 15:55 +0200, Jakub Narebski wrote:\n> Matthieu Moy wrote:\n> > This took time to come in bzr, but that's the bisect plugin:\n> > \n> > http://bazaar-vcs.org/PluginRegistry\n> \n> Hmmm... I winder which SCM had it first.\n\nYou did. The plugin is largely based on my experiences with the git\nversion, and explicitly gives credit in the comments.\n"},{"id":"29133","messageId":"20061018185225.GU20017@pasky.or.cz","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610180739230.3962@g5.osdl.org","subject":"[ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T18:52:25Z","receivedAt":"2006-10-18T18:52:25Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Oct 18, 2006 at 04:52:25PM CEST, I got a letter\nwhere Linus Torvalds said that...\n> In other words, to get such a pack, we'd _literally_ just do something \n> like\n> \n> \tgit-rev-list --objects-edge origin.. |\n> \t\tgit-pack-objects --stdout |\n> \t\tuuencode\n> \n> and that would be it. You'd still need to add a \"diffstat\" to the thing, \n> and tell the other end what the current HEAD is (so that it knows what \n> it's supposed to fast-forward to), but it _literally_ is that simple.\n> \n> \"plug-in architecture\" my ass. \"I recognize this - it's UNIX!\".\n\nTook me exactly an hour from mkdir cogito-bundle to cg-push to\nkernel.org. :-)\n\ncogito-bundle is an example on how to create third-party addons or\nplugins adding own commands to Cogito and using Cogito's infrastructure.\nIt's not _that_ easy currently since you have to replicate large part of\nthe build infrastructure locally; that could be fixed by installing some\n\"library makefiles\" and asciidoc toolkit to /usr/share or something, if\nthere would be a real demand for such an addon API. cg-help and the cg\nwrapper will pick up the newly installed commands automagically. The\nonly thing missing is updating cogito(7) to list the addon commands,\nwhich would take a bit more work.\n\nThough it's an example, it's actually supposed to be useful, by doing\nexactly what is outlined above - l - it lets you exchange commits over\nmail by so-called \"bundles\", similar to e.g. Bazaar bundles - basically,\nit is like push or fetch, but over email, and the commit ids are\npreserved when transferred in bundles (if you just send patches, the\ncommit ids will end up different).\n\nThe provided cg-bundle and cg-unbundle commands are rather crude and\ndon't support many things - they don't actually include a diff, only a\ndiffstat, etc. The uuencoded bundle is inlined in the mail, which I\nsuspect isn't very useful; perhaps it would be more practical to just\nattach it binarily. Feel free to send patches (or bundles ;).\n\nAn example bundle is available at\n\n\thttp://pasky.or.cz/~pasky/cp/example-bundle.txt\n\nas generated by\n\n\tcogito.master$ cg-bundle -r v0.18 -m\"Subject is this\" \\\n\t\t-m\"And some body now...\" --stdout\n\nand cogito-bundle is available at\n\n\tgit://git.kernel.org/pub/scm/cogito/cogito-bundle.git/\n\t(gitweb http://kernel.org/git/?p=cogito/cogito-bundle.git)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i said that...\n> Dear diary, on Wed, Oct 18, 2006 at 04:52:25PM CEST, I got a letter\n> where Linus Torvalds said that...\n> > In other words, to get such a pack, we'd _literally_ just do something \n> > like\n> > \n> > \tgit-rev-list --objects-edge origin.. |\n> > \t\tgit-pack-objects --stdout |\n> > \t\tuuencode\n> > \n> > and that would be it. You'd still need to add a \"diffstat\" to the thing, \n> > and tell the other end what the current HEAD is (so that it knows what \n> > it's supposed to fast-forward to), but it _literally_ is that simple.\n> > \n> > \"plug-in architecture\" my ass. \"I recognize this - it's UNIX!\".\n> \n> Took me exactly an hour from mkdir cogito-bundle to cg-push to\n> kernel.org. :-)\n\nBy the way, originally I just wanted to index and save the pack, but\nwhen trying to feed it to git-index-pack, I kept getting\n\n\tfatal: packfile '.git/objects/pack/pack-b2ab684daebea5b9c5a6492fa732e0d2e1799c8e.pack' has unresolved deltas\n\nwhile feeding it to git-unpack-objects works fine. Any idea what's wrong?\n\n(BTW, I got the id by sha1summing the pack file; is there an existing\nway to name a pack properly if I have it lying around, unnamed? sha1sum\nseems to be specific to a fairly new GNU coreutils version.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i writes:\n\n> Dear diary, on Wed, Oct 18, 2006 at 08:52:25PM CEST, I got a letter\n> where Petr Baudis said that...\n>> Dear diary, on Wed, Oct 18, 2006 at 04:52:25PM CEST, I got a letter\n>> where Linus Torvalds said that...\n>> > In other words, to get such a pack, we'd _literally_ just do something \n>> > like\n>> > \n>> > \tgit-rev-list --objects-edge origin.. |\n>> > \t\tgit-pack-objects --stdout |\n>> > \t\tuuencode\n>> > \n>> > and that would be it. You'd still need to add a \"diffstat\" to the thing, \n>> > and tell the other end what the current HEAD is (so that it knows what \n>> > it's supposed to fast-forward to), but it _literally_ is that simple.\n>> > \n>> > \"plug-in architecture\" my ass. \"I recognize this - it's UNIX!\".\n>> \n>> Took me exactly an hour from mkdir cogito-bundle to cg-push to\n>> kernel.org. :-)\n>\n> By the way, originally I just wanted to index and save the pack, but\n> when trying to feed it to git-index-pack, I kept getting\n>\n> \tfatal: packfile '.git/objects/pack/pack-b2ab684daebea5b9c5a6492fa732e0d2e1799c8e.pack' has unresolved deltas\n>\n> while feeding it to git-unpack-objects works fine. Any idea what's wrong?\n\nYes. You told the pipeline, with --objects-edge, to create a\nthin pack. By definition that is _not_ indexable.\n"},{"id":"29137","messageId":"Pine.LNX.4.64.0610181506030.1971@xanadu.home","threadId":"5925","inReplyTo":"20061018185907.GV20017@pasky.or.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-10-18T19:09:41Z","receivedAt":"2006-10-18T19:09:41Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 18 Oct 2006, Petr Baudis wrote:\n\n> By the way, originally I just wanted to index and save the pack, but\n> when trying to feed it to git-index-pack, I kept getting\n> \n> \tfatal: packfile '.git/objects/pack/pack-b2ab684daebea5b9c5a6492fa732e0d2e1799c8e.pack' has unresolved deltas\n> \n> while feeding it to git-unpack-objects works fine. Any idea what's wrong?\n\nDid you really manage to miss the \"heads-up: git-index-pack in \"next\" is \nbroken\" thread?\n\nThe fix:\n\ndiff --git a/index-pack.c b/index-pack.c\nindex fffddd2..56c590e 100644\n--- a/index-pack.c\n+++ b/index-pack.c\n@@ -23,6 +23,12 @@ union delta_base {\n \tunsigned long offset;\n };\n \n+/*\n+ * Even if sizeof(union delta_base) == 24 on 64-bit archs, we really want\n+ * to memcmp() only the first 20 bytes.\n+ */\n+#define UNION_BASE_SZ\t20\n+\n struct delta_entry\n {\n \tstruct object_entry *obj;\n@@ -211,7 +217,7 @@ static int find_delta(const union delta_\n struct delta_entry *delta = &deltas[next];\n int cmp;\n \n- cmp = memcmp(base, &delta->base, sizeof(*base));\n+ cmp = memcmp(base, &delta->base, UNION_BASE_SZ);\n if (!cmp)\n return next;\n if (cmp < 0) {\n@@ -232,9 +238,9 @@ static int find_delta_childs(const union\n \n \tif (first < 0)\n \t\treturn -1;\n-\twhile (first > 0 && !memcmp(&deltas[first - 1].base, base, sizeof(*base)))\n+\twhile (first > 0 && !memcmp(&deltas[first - 1].base, base, UNION_BASE_SZ))\n \t\t--first;\n-\twhile (last < end && !memcmp(&deltas[last + 1].base, base, sizeof(*base)))\n+\twhile (last < end && !memcmp(&deltas[last + 1].base, base, UNION_BASE_SZ))\n \t\t++last;\n \t*first_index = first;\n \t*last_index = last;\n@@ -312,7 +318,7 @@ static int compare_delta_entry(const voi\n {\n \tconst struct delta_entry *delta_a = a;\n \tconst struct delta_entry *delta_b = b;\n-\treturn memcmp(&delta_a->base, &delta_b->base, sizeof(union delta_base));\n+\treturn memcmp(&delta_a->base, &delta_b->base, UNION_BASE_SZ);\n }\n \n static void parse_pack_objects(void)\n\n\nNicolas\n"},{"id":"29138","messageId":"Pine.LNX.4.64.0610181510510.1971@xanadu.home","threadId":"5925","inReplyTo":"7vy7rd1m4q.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-10-18T19:13:15Z","receivedAt":"2006-10-18T19:13:15Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 18 Oct 2006, Junio C Hamano wrote:\n\n> Petr Baudis writes:\n> \n> > By the way, originally I just wanted to index and save the pack, but\n> > when trying to feed it to git-index-pack, I kept getting\n> >\n> > \tfatal: packfile '.git/objects/pack/pack-b2ab684daebea5b9c5a6492fa732e0d2e1799c8e.pack' has unresolved deltas\n> >\n> > while feeding it to git-unpack-objects works fine. Any idea what's wrong?\n> \n> Yes. You told the pipeline, with --objects-edge, to create a\n> thin pack. By definition that is _not_ indexable.\n\nAh true. I missed the \"thin\" pack.\n\nAny idea why we should still prevent this? It is not like it was a \ntechnical limitation.\n\n\nNicolas\n"},{"id":"29139","messageId":"20061018191834.GA18829@spearce.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181510510.1971@xanadu.home","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-18T19:18:35Z","receivedAt":"2006-10-18T19:18:35Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre wrote:\n> On Wed, 18 Oct 2006, Junio C Hamano wrote:\n> \n> > Petr Baudis writes:\n> > \n> > > By the way, originally I just wanted to index and save the pack, but\n> > > when trying to feed it to git-index-pack, I kept getting\n> > >\n> > > \tfatal: packfile '.git/objects/pack/pack-b2ab684daebea5b9c5a6492fa732e0d2e1799c8e.pack' has unresolved deltas\n> > >\n> > > while feeding it to git-unpack-objects works fine. Any idea what's wrong?\n> > \n> > Yes. You told the pipeline, with --objects-edge, to create a\n> > thin pack. By definition that is _not_ indexable.\n> \n> Ah true. I missed the \"thin\" pack.\n> \n> Any idea why we should still prevent this? It is not like it was a \n> technical limitation.\n\nIt still is in sha1-file.c; or at least the last time I looked at\nthat code. The base is always resolved from the same pack/index\nas the delta. If you fix sha1-file.c sure, I don't see why you\ncan't allow indexing thin packs.\n\n-- \nShawn.\n"},{"id":"29141","messageId":"Pine.LNX.4.64.0610181525410.1971@xanadu.home","threadId":"5925","inReplyTo":"20061018191834.GA18829@spearce.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-10-18T19:33:21Z","receivedAt":"2006-10-18T19:33:21Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 18 Oct 2006, Shawn Pearce wrote:\n\n> Nicolas Pitre wrote:\n> > On Wed, 18 Oct 2006, Junio C Hamano wrote:\n> > \n> > > Petr Baudis writes:\n> > > \n> > > > By the way, originally I just wanted to index and save the pack, but\n> > > > when trying to feed it to git-index-pack, I kept getting\n> > > >\n> > > > \tfatal: packfile '.git/objects/pack/pack-b2ab684daebea5b9c5a6492fa732e0d2e1799c8e.pack' has unresolved deltas\n> > > >\n> > > > while feeding it to git-unpack-objects works fine. Any idea what's wrong?\n> > > \n> > > Yes. You told the pipeline, with --objects-edge, to create a\n> > > thin pack. By definition that is _not_ indexable.\n> > \n> > Ah true. I missed the \"thin\" pack.\n> > \n> > Any idea why we should still prevent this? It is not like it was a \n> > technical limitation.\n> \n> It still is in sha1-file.c; or at least the last time I looked at\n> that code. The base is always resolved from the same pack/index\n> as the delta. \n\nYep. I mean this doesn't have to be like that fundamentally.\n\n> If you fix sha1-file.c sure, I don't see why you\n> can't allow indexing thin packs.\n\nIf there are advantages to do so then maybe. That would be for another \nday though, as I've been burned a bit with packs recently.\n\n\nNicolas\n"},{"id":"29140","messageId":"7vr6x51ks3.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181510510.1971@xanadu.home","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-18T19:33:32Z","receivedAt":"2006-10-18T19:33:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> Ah true. I missed the \"thin\" pack.\n>\n> Any idea why we should still prevent this? It is not like it was a \n> technical limitation.\n\nIt is a technical limitation. We have never assumed that the\nvirtual address space is big enough to hold more than one whole\npack mmapped at the same time.\n\nLifting this needs the piecemeal mmap() change somebody was\ntalking about.\n\nI might bite the bullet and do that myself but I've been hoping\nto get an appliable patch from somewhere else ;-).\n"},{"id":"29143","messageId":"BAYC1-PASMTP08F10B1B8BCDB04B2AD771AE0F0@CEZ.ICE","threadId":"5925","inReplyTo":"20061018185225.GU20017@pasky.or.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-18T19:57:04Z","receivedAt":"2006-10-18T19:57:04Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 18 Oct 2006 20:52:25 +0200\nPetr Baudis wrote:\n\n> Took me exactly an hour from mkdir cogito-bundle to cg-push to\n> kernel.org. :-)\n\nNicely done :-).\n\n> cogito-bundle is an example on how to create third-party addons or\n> plugins adding own commands to Cogito and using Cogito's infrastructure.\n> It's not _that_ easy currently since you have to replicate large part of\n> the build infrastructure locally; that could be fixed by installing some\n> \"library makefiles\" and asciidoc toolkit to /usr/share or something, if\n> there would be a real demand for such an addon API. cg-help and the cg\n> wrapper will pick up the newly installed commands automagically. The\n> only thing missing is updating cogito(7) to list the addon commands,\n> which would take a bit more work.\n\nCouldn't these just as easily have been written as git-bundle and\ngit-unbundle without needing any plugins or other cogito infrastructure?\n\n> Though it's an example, it's actually supposed to be useful, by doing\n> exactly what is outlined above - l - it lets you exchange commits over\n> mail by so-called \"bundles\", similar to e.g. Bazaar bundles - basically,\n> it is like push or fetch, but over email, and the commit ids are\n> preserved when transferred in bundles (if you just send patches, the\n> commit ids will end up different).\n\nNot sure if it would be useful, but it shouldn't be too hard to have\nsame commit ids regenerated at receiving end with git patches.\n\n> The provided cg-bundle and cg-unbundle commands are rather crude and\n> don't support many things - they don't actually include a diff, only a\n> diffstat, etc. The uuencoded bundle is inlined in the mail, which I\n> suspect isn't very useful; perhaps it would be more practical to just\n> attach it binarily. Feel free to send patches (or bundles ;).\n\nThink you're right about making it an attachment instead.\n\nSean\n"},{"id":"29144","messageId":"Pine.LNX.4.64.0610181302080.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061018185907.GV20017@pasky.or.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-18T20:08:58Z","receivedAt":"2006-10-18T20:08:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Petr Baudis wrote:\n> \n> By the way, originally I just wanted to index and save the pack, but\n> when trying to feed it to git-index-pack, I kept getting\n> \n> \tfatal: packfile '.git/objects/pack/pack-b2ab684daebea5b9c5a6492fa732e0d2e1799c8e.pack' has unresolved deltas\n> \n> while feeding it to git-unpack-objects works fine. Any idea what's wrong?\n\nSince you created a \"thin\" pack (that's what the \"--objects-edge\" means), \nthe pack actually contains deltas to objects that are _not_ in the pack. \n\nIn other words, it's not a valid stand-alone pack, it's only a valid thin \npack, useful to transfer data to the other end (and the other end had \nbetter have the objects that the deltas are against already).\n\nAs a result, index-file refuses to index it: it cannot be used as a \nstand-alone pack, it's _only_ useful as a transfer medium.\n\nSo don't even _try_ to use it as a standalone pack-file. It won't work.\n\n(If you want somethign that actually works as a stand-alone pack-file, \nchange the \"--objects-edge\" flag to just \"--objects\" - that makes the \npack-file self-sufficient, and doesn't try to delta against \"edge\" \nobjects).\n\n> (BTW, I got the id by sha1summing the pack file; is there an existing\n> way to name a pack properly if I have it lying around, unnamed? sha1sum\n> seems to be specific to a fairly new GNU coreutils version.)\n\nA properly named _standalone_ pack gets named not by its actual contents, \nbut by the SHA1-sum of the sorted list of objects it contains. That's so \nthat a pack-file will be named the same thing regardless of how the \ncontents are actually packed.\n\nA thin pack cannot be named that way at all, for the same reason you \ncannot index it: it has a set of objects it enumerates (so you could name \nit by them), but it _also_ has a set of objects outside of it that it \ndepends on. \n\nThat said, even a thin pack internally has a SHA1 checksum of its \ncontents: the last 20 bytes should be the SHA1-sum of all preceding bytes. \nSo if you just want _some_ kind of name, you can use the last 20 bytes of \na pack, which is just its internal integrity-checksum (but that is \n_different_ from the \"pack-xxxxxx.idx\"/\"pack-xxxxxx.pack\" naming).\n\n\t\t\tLinus\n"},{"id":"29146","messageId":"20061018204618.GW20017@pasky.or.cz","threadId":"5925","inReplyTo":"20061018155704.b94b441d.seanlkml@sympatico.ca","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T20:46:18Z","receivedAt":"2006-10-18T20:46:18Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Oct 18, 2006 at 09:57:04PM CEST, I got a letter\nwhere Sean said that...\n> Couldn't these just as easily have been written as git-bundle and\n> git-unbundle without needing any plugins or other cogito infrastructure?\n\nThey could be written, but certainly not \"just as easily\". I'm more used\nto coding Cogito, I find it much more convenient than hacking git's\nshell scripts (those two may be interconnected ;), and there's plenty of\ninfrastructure in Cogito missing in Git - Cogito has more flexible\narguments parsing, documentation bundled with code, I could just\ncut'n'paste the code to handle -m arguments and message editor (and most\nof it is libified anyway) so I got that basically for free, and I think\nCogito beats Git hands down in code readability.\n\n> Not sure if it would be useful, but it shouldn't be too hard to have\n> same commit ids regenerated at receiving end with git patches.\n\nIt would be of course technically possible, yes. But somewhat more work,\nthis is just a quick hack.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> If there are advantages to do so then maybe. That would be for another \n> day though, as I've been burned a bit with packs recently.\n\nI guess its my turn then to work in the mmap window code, huh? :-)\n\n-- \nShawn.\n"},{"id":"29147","messageId":"20061018204755.GB19194@spearce.org","threadId":"5925","inReplyTo":"7vr6x51ks3.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-18T20:47:55Z","receivedAt":"2006-10-18T20:47:55Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Nicolas Pitre writes:\n> \n> > Ah true. I missed the \"thin\" pack.\n> >\n> > Any idea why we should still prevent this? It is not like it was a \n> > technical limitation.\n> \n> It is a technical limitation. We have never assumed that the\n> virtual address space is big enough to hold more than one whole\n> pack mmapped at the same time.\n\nEven though its not big enough for some larger packs on a 32\nbit system.\n \n> Lifting this needs the piecemeal mmap() change somebody was\n> talking about.\n> \n> I might bite the bullet and do that myself but I've been hoping\n> to get an appliable patch from somewhere else ;-).\n\nI might be able to do it this weekend. I'll try to spend some time\non it. You'll either see a patch series, or you won't. ;-)\n\n-- \nShawn.\n"},{"id":"29148","messageId":"BAYC1-PASMTP0628ED9CBD2F53119374EEAE0F0@CEZ.ICE","threadId":"5925","inReplyTo":"20061018204618.GW20017@pasky.or.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-18T20:53:41Z","receivedAt":"2006-10-18T20:53:41Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 18 Oct 2006 22:46:18 +0200\nPetr Baudis wrote:\n\n> They could be written, but certainly not \"just as easily\". I'm more used\n> to coding Cogito, I find it much more convenient than hacking git's\n> shell scripts (those two may be interconnected ;), and there's plenty of\n> infrastructure in Cogito missing in Git - Cogito has more flexible\n> arguments parsing, documentation bundled with code, I could just\n> cut'n'paste the code to handle -m arguments and message editor (and most\n> of it is libified anyway) so I got that basically for free, and I think\n> Cogito beats Git hands down in code readability.\n\nHmmm, if I get some time over the weekend i'll take a look at porting\nthem to Git. But maybe some of the items you mentioned above deserve\nto become part of Git proper? It would definitely be nice to see\nsomething like what you just did put into the hands of more users than\njust those using Cogito, and its unfortunate that the current state\nof Git code kept you from going that route.\n\n> It would be of course technically possible, yes. But somewhat more work,\n> this is just a quick hack.\n\nNo doubt, there would be some slightly thorny issues to deal with. It\nmight even end up too fragile to be worthwhile.\n\nSean\n"},{"id":"29149","messageId":"eh64tk$rug$2@sea.gmane.org","threadId":"5925","inReplyTo":"BAYC1-PASMTP01369CD694D75CB61ACCC7AE0E0@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Charles Duffy","fromEmail":"cduffy@spamcop.net","sentAt":"2006-10-18T21:04:52Z","receivedAt":"2006-10-18T21:04:52Z","isPatch":false,"sender":{"key":"cduffy@spamcop.net","avatar":null},"body":"Sean wrote:\n> Hmm.. It's pretty easy to test out Git ideas too. People do it all\n> the time, and without plugins. Junio maintains several such trees\n> for instance. Dunno.. I just think plugs _sounds_ good to developers\n> without much real benefit to users over regular ole source code.\n\nExample time!\n\nThere's a plugin for Bzr which adds support for Cygwin-compatible \nsymlink support on Windows. (IIRC, this involves monkey-patching some of \nthe Python standard library bits).\n\nNow, this is something which is *proposed* as a feature to be merged \ninto upstream bzr, and it may happen at some point. That said, when I \nhave a Windows-using coworker who wants to check out a repository that \nhas symlinks in it (with his win32-native, no-cygwin-required bzr \nupstream binary), I don't need to tell him to go download and build bzr \nfrom a third party; instead, I just need to tell him to run a single \ncommand to check out the plugin in question into the bzr plugins folder.\n\n From an end-user convenience perspective, it's a pretty significant win.\n"},{"id":"29150","messageId":"Pine.LNX.4.64.0610181358200.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061018204626.GA19194@spearce.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-18T21:17:42Z","receivedAt":"2006-10-18T21:17:42Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Shawn Pearce wrote:\n>\n> I guess its my turn then to work in the mmap window code, huh? :-)\n\nThere are bigger reasons to _never_ allow packs to contain deltas to \noutside of themselves:\n\n - there's no point. \n\n If you have many small packs, you're doing something wrong. The whole \n _point_ of packs is to put things into the same file, so that you can \n avoid the filesystem overhead. And once packs are big and few, the \n advantage of having deltas to outside the pack is basically zero.\n\n - it's a bad design. \n\n Self-sufficient packs means that a pack is a \"safe\" thing. When the \n index says that it contains an object, then it damn well contains it.\n\n In contrast, if you had packs that only contained a delta, and the pack \n needed some _other_ pack (or loose object) to actually generate that \n object, then it's not safe any more. You could end up with a situation \n where you get two packs from two different sources, and they contain \n deltas to _each_other_, and you have no way of actually generating the \n object itself any more.\n\n (Or you end up having to have rules to figure out when you have a loop,\n and stop looking just in the packed files, and start looking for loose \n objects instead)\n\n In other words, it has potentially _serious_ downsides.\n\nSo DAMMIT! Stop looking to make the data structures worse. The fact is, \nthe git data structures are FINE. They are well-designed. They work well. \nThere's no _point_ in changing them, especially since changing them seems \nto be all about making things less reliable for dubious gain.\n\nOne of the advantages of git is that you can explain things with object \nrelationships, and that the file format is stable as _hell_. Thats a GOOD \nthing. Please realize that if you want to change the file formats, you'd \nhave a hell of a better reason for it that \"just because I can\".\n\nPlease. Really.\n\nSo next time somebody suggests a new pack-format, ask yourself:\n\n - does it save disk-space by 50% or more?\n\n - does it drop memory usage by 50% or more?\n\n - does it improve performance by 50% of more?\n\n - does it make something possible that really fundamentally isn't \n possible right now?\n\nAnd if the answer to those questions is \"no\", then JUST DON'T DO IT.\n\nIt really needs to be _damn_ spectacular to be worthy of a new format. \nReally. We've had a few of those, so it clearly does happen:\n\n - The \"compress _after_ SHA1\". The original object format was just \n broken, and the SHA1 name depended on how things compressed. I fixed \n it. It needed fixing. We couldn't have done a lot of the things we did \n without switching compression and SHA1-hashing around.\n\n - the pack-file in the first place: this saved orders of magnitude both \n in diskspace _and_ performance. Not \"10%\". More like \"factors of 100\".\n\n THAT was worthy of a major format change.\n\n - the \"make loose object contents look the same as packed objects\". This \n was not just a cleanup, it allows us to create pack-files much faster. \n\n That said, we're still defaulting to the legacy format, and maybe it \n wasn't really worth it. \n\nMy personal suspicion is that we'll want to have a 64-bit index file some \nday, and THAT is worthy of a format change. That day is not now, btw. It's \nprobably not even very close. Even the mozilla repo that was pushing the \nlimit was only doing so until it was optimized better, and now it's \napparently nowhere _near_ that limit.\n\nBut even then, we might well want to update _just_ the index file format.\n\nBecause in an SCM, stability and trustworthiness is more important than \njust about _anything_ else. \n\n\t\t\tLinus\n"},{"id":"29151","messageId":"20061018212028.GC24707@coredump.intra.peff.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610180739230.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-18T21:20:28Z","receivedAt":"2006-10-18T21:20:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 18, 2006 at 07:52:25AM -0700, Linus Torvalds wrote:\n\n> \tgit send origin..\n> \n> and that \"origin\" is what the other end is expected to already have.\n> \n> Of course, if you send an unconnected bundle (ie you give an origin that \n> the other end _doesn't_ have), you're screwed.\n\nOK, that was how I was envisioning it, as well, but I was concerned\nabout the \"screwed\" part. But I'm not sure how often that would be an\nissue in practice (after all, patches require some matchup of the base,\nthough not as strict as SHA1s).\n\nThanks for the explanation.\n\n-Peff\n"},{"id":"29153","messageId":"BAYC1-PASMTP069C473B2E79389E5BFC92AE0F0@CEZ.ICE","threadId":"5925","inReplyTo":"eh64tk$rug$2@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-18T21:29:45Z","receivedAt":"2006-10-18T21:29:45Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 18 Oct 2006 16:04:52 -0500\nCharles Duffy wrote:\n\n> Example time!\n> \n> There's a plugin for Bzr which adds support for Cygwin-compatible \n> symlink support on Windows. (IIRC, this involves monkey-patching some of \n> the Python standard library bits).\n> \n> Now, this is something which is *proposed* as a feature to be merged \n> into upstream bzr, and it may happen at some point. That said, when I \n> have a Windows-using coworker who wants to check out a repository that \n> has symlinks in it (with his win32-native, no-cygwin-required bzr \n> upstream binary), I don't need to tell him to go download and build bzr \n> from a third party; instead, I just need to tell him to run a single \n> command to check out the plugin in question into the bzr plugins folder.\n> \n> From an end-user convenience perspective, it's a pretty significant win.\n\nYou'll need a better example than that. Git has supported a version\nof Cygwin-compatible symlink support on Windows for quite some time.\nAnd no plugins were needed.\n\nSean\n"},{"id":"29303","messageId":"20061018172945.c0c58c38.seanlkml__5735.08153106577$1161333739$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"eh64tk$rug$2@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-18T21:29:45Z","receivedAt":"2006-10-18T21:29:45Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 18 Oct 2006 16:04:52 -0500\nCharles Duffy wrote:\n\n> Example time!\n> \n> There's a plugin for Bzr which adds support for Cygwin-compatible \n> symlink support on Windows. (IIRC, this involves monkey-patching some of \n> the Python standard library bits).\n> \n> Now, this is something which is *proposed* as a feature to be merged \n> into upstream bzr, and it may happen at some point. That said, when I \n> have a Windows-using coworker who wants to check out a repository that \n> has symlinks in it (with his win32-native, no-cygwin-required bzr \n> upstream binary), I don't need to tell him to go download and build bzr \n> from a third party; instead, I just need to tell him to run a single \n> command to check out the plugin in question into the bzr plugins folder.\n> \n> From an end-user convenience perspective, it's a pretty significant win.\n\nYou'll need a better example than that. Git has supported a version\nof Cygwin-compatible symlink support on Windows for quite some time.\nAnd no plugins were needed.\n\nSean\n"},{"id":"29154","messageId":"20061018213225.GD19194@spearce.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181358200.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-18T21:32:26Z","receivedAt":"2006-10-18T21:32:26Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Wed, 18 Oct 2006, Shawn Pearce wrote:\n> >\n> > I guess its my turn then to work in the mmap window code, huh? :-)\n> \n> There are bigger reasons to _never_ allow packs to contain deltas to \n> outside of themselves:\n> \n> - there's no point. \n> - it's a bad design. \n\nThat and all of the other reasons you cited in your message are\nwhy I haven't finished trying to use some sort of dictionary based\ncompression for packing objects.\n\nOn the other hand we've already seen how packs >1.5 GiB in size\n(certainly well within the 4 GiB limitation in the current index\nfile format) cannot be repacked by git-repack-objects on a 32\nbit address space as the entire pack file is mmap'd on one shot.\nAfter the kernel space of ~1 GiB and the pack file at ~1.5 GiB\nthere's very little address space left for the application code.\n\nMy comment that you quoted was about mmap'ing the pack files in\nlarge chunks (around 64-128 MiB at a time, but configurable from\n.git/config) rather than as an entire massive mapping. It had\nabsolutely nothing to do about changing the pack file format, the\nindex format, or any other on disk format. Although it would add\na new pair of configuration options to .git/config. Is that change\ntoo radical? :-)\n\nWith such a change the Git and Linux kernel repositories would both\nstill mmap in one chunk but much larger projects like Mozilla or\nvery large pack files coming out of git-fastimport would actually\nbe usable on 32 bit architectures without running into address space\nlimitations so quickly. Git would also be slightly more usable for\nsome people who have a lot of very uncompressable data stored in Git.\n\n\nUnless of course you are actively working on a fix for the Linux\nkernel so that we can actually have all 4 GiB of virtual address\nspace available for the userspace git-repack-objects process.\nOr have some sort of secret plan to upgrade everyone who uses Git\nto 64 bit processors which support 64 bit address spaces...\n\n-- \nShawn.\n"},{"id":"29155","messageId":"20061018213703.GE19194@spearce.org","threadId":"5925","inReplyTo":"20061018172945.c0c58c38.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-18T21:37:03Z","receivedAt":"2006-10-18T21:37:03Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sean wrote:\n> On Wed, 18 Oct 2006 16:04:52 -0500\n> Charles Duffy wrote:\n> \n> > Example time!\n> > \n> > There's a plugin for Bzr which adds support for Cygwin-compatible \n> > symlink support on Windows. (IIRC, this involves monkey-patching some of \n> > the Python standard library bits).\n> > \n> > Now, this is something which is *proposed* as a feature to be merged \n> > into upstream bzr, and it may happen at some point. That said, when I \n> > have a Windows-using coworker who wants to check out a repository that \n> > has symlinks in it (with his win32-native, no-cygwin-required bzr \n> > upstream binary), I don't need to tell him to go download and build bzr \n> > from a third party; instead, I just need to tell him to run a single \n> > command to check out the plugin in question into the bzr plugins folder.\n> > \n> > From an end-user convenience perspective, it's a pretty significant win.\n> \n> You'll need a better example than that. Git has supported a version\n> of Cygwin-compatible symlink support on Windows for quite some time.\n> And no plugins were needed.\n\nActually I think the only part of that example that was really\ninteresting was that Bzr runs natively on Windows and that Bzr's\nnative method of extending the tool with additional features doesn't\nrequire Cygwin.\n\n\nToday Git doesn't run natively on Windows. It runs slowly through\nCygwin, thanks to lots of various overheads in different places.\nAnd due to the crappy disk drive in my Windows box. :-)\n\nToday Git is typically extended (at least initially in prototyping\nmode) through Perl, Python, TCL or Bourne shell scripts. Although\nthe first three are available natively on Windows the last requires\nCygwin... and we've had some issues with ActiveState Perl on Windows\nin the past too.\n\n-- \nShawn.\n"},{"id":"29156","messageId":"20061018213935.GX20017@pasky.or.cz","threadId":"5925","inReplyTo":"20061018165341.bcece11f.seanlkml@sympatico.ca","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T21:39:35Z","receivedAt":"2006-10-18T21:39:35Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"(Trimmed Cc' list, this is offtopic for bazaar-ng.)\n\nDear diary, on Wed, Oct 18, 2006 at 10:53:41PM CEST, I got a letter\nwhere Sean said that...\n> On Wed, 18 Oct 2006 22:46:18 +0200\n> Petr Baudis wrote:\n> \n> > They could be written, but certainly not \"just as easily\". I'm more used\n> > to coding Cogito, I find it much more convenient than hacking git's\n> > shell scripts (those two may be interconnected ;), and there's plenty of\n> > infrastructure in Cogito missing in Git - Cogito has more flexible\n> > arguments parsing, documentation bundled with code, I could just\n> > cut'n'paste the code to handle -m arguments and message editor (and most\n> > of it is libified anyway) so I got that basically for free, and I think\n> > Cogito beats Git hands down in code readability.\n> \n> Hmmm, if I get some time over the weekend i'll take a look at porting\n> them to Git. But maybe some of the items you mentioned above deserve\n> to become part of Git proper? It would definitely be nice to see\n> something like what you just did put into the hands of more users than\n> just those using Cogito, and its unfortunate that the current state\n> of Git code kept you from going that route.\n\nYou can use just this single tool from Cogito. ;-)\n\nThe point is, I'll of course prefer doing this stuff in Cogito while I'm\nenhancing Cogito, and I'll work on Cogito while I and others will be\nusing it. I didn't move on to pure Git long time ago since I simply\nconsider its UI much inferior to Cogito's. Sure, given enough time and\nwork, it is fixable - but UI flaws are very hard to fix and I find it\nmore effective to work on Cogito for the time being, at least until I\nbring it to 1.0, then I'll see.\n\nBesides, I'm used to Cogito. :-)\n\nSo yes, current Git code definitely is a part of the reason, but it is\ncertainly not the main part of it.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i There are bigger reasons to _never_ allow packs to contain deltas to \n> outside of themselves:\n> \n> - there's no point. \n\nRemember what I said earlier: \"If there are advantages to do so then \nmaybe.\" So far there are none.\n\n> You could end up with a situation where you get two packs from two \n> different sources, and they contain deltas to _each_other_, and you \n> have no way of actually generating the object itself any more.\n\nTo me this is the real killer.\n\nShawn was talking about a different issue though.\n\n\nNicolas\n"},{"id":"29158","messageId":"20061018214143.GF19194@spearce.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181358200.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-18T21:41:43Z","receivedAt":"2006-10-18T21:41:43Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> There are bigger reasons to _never_ allow packs to contain deltas to \n> outside of themselves:\n> \n> - there's no point. \n\nActually there is a point to storing thin packs. When I pull from\na remote repo (or push to a remote repo) a huge number of objects\nand the target disk that is about to receive that huge number of\nloose objects is slooooooooow I would rather just store the thin\npack then store the loose objects.\n\nIdeally that thin pack would be repacked (along with the other\nexisting packs) as quickly as possible into a self-contained pack.\nBut that of course is unlikely to happen in practice; especially\non a push.\n \n> - it's a bad design. \n> \n> In other words, it has potentially _serious_ downsides.\n\nYes, it does.\n\nBut it could also be useful when you fetch 20k+ objects onto a\nWindows system or push 1k+ objects onto the slowest NFS system I\nhave ever seen... where writing file data (aka packs) is reasonable\nbut creating or deleting files takes nearly 1 second per file.\nI don't want to kill the better part of an hour waiting for a push\nto complete!\n\n-- \nShawn.\n"},{"id":"29159","messageId":"7vlkndz4fr.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"20061018213225.GD19194@spearce.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-18T21:42:32Z","receivedAt":"2006-10-18T21:42:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> ... Although it would add\n> a new pair of configuration options to .git/config. Is that change\n> too radical? :-)\n\nI wonder what you would need the configuration options for.\n\nIf mmap() pack works well, it works well, and if it is broken\nnobody has reason to enable it. The code should be able to\nadjust the mmap window to appropriate size itself and its\nautomatic adjustment does not even have to be the absolute\noptimum (since the user would not know what the optimum would be\nanyway), so maybe your configuration options would not be\n\"enable\" nor \"window-size\" -- and I am puzzled as to what they\nare.\n"},{"id":"29160","messageId":"BAYC1-PASMTP0154E291106F138403852FAE0F0@CEZ.ICE","threadId":"5925","inReplyTo":"20061018213703.GE19194@spearce.org","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-18T21:44:50Z","receivedAt":"2006-10-18T21:44:50Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 18 Oct 2006 17:37:03 -0400\nShawn Pearce wrote:\n\n> Today Git is typically extended (at least initially in prototyping\n> mode) through Perl, Python, TCL or Bourne shell scripts. Although\n> the first three are available natively on Windows the last requires\n> Cygwin... and we've had some issues with ActiveState Perl on Windows\n> in the past too.\n\nJust for kicks and giggles it would be nice if someone tried out\none of the native Windows bourne shell ports[1] just to see how much\nis missing. A bunch of command line utilities would have to be ported\nas well; maybe too many. But i've held out booting a Windows box\nfor a long time so.... not it!\n\nSean\n\n[1] For example, http://www.steve.org.uk/Software/bash/\n"},{"id":"29161","messageId":"20061018214623.GA32725@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"1161149200.3423.34.camel@localhost.localdomain","subject":"Alternate revno proposal (Was: Re: VCS comparison table)","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-18T21:46:23Z","receivedAt":"2006-10-18T21:46:23Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Oct 18, 2006 at 03:26:40PM +1000, Robert Collins wrote:\n> revnos visibly change as your work is merged into the mainline - we've\n> been doing this for years without trouble: ones own commits to a branch\n> get '3', '4', '5' etc as revnos, and when they are merged to the\n> mainline they used to stop having revnos at all, but now they will be\n> given this dotted decimal revno. If you pull from the mainline after the\n> merge, you see the new numbers, and when you look at mainline you can\n> see the difference. So while I agree that the surprise the user gets is\n> inversely related to the frequency with which they see the behaviour, I\n> think our users see it a lot, so are not surprised much.\n> \n> FWIW, we're not optimising for mostly straight histories as I understand\n> such things : our own history has 3 commits on branches to every one on\n> the mainline.\n\nReading this thread I came to think, that the revnos should be assigned\nto _all_ revisions _available_, in order of when they entered the\nrepository (there are some possible variations I will mention below)\n\n - Such revnos would be purely local, but:\n - Current revnos are not guaranteed to be the same in different\n branches either.\n - They could be done so that mirror has the same revnos as the\n master.\n - They would be easier to use than the dotted ones. What (at least as\n far as I understand) makes revnos easier to use than revids is, that\n you can remember few of them for short time while composing some\n operation. Ie. look up 2 or 3 revisions in the log and than do some\n command on them. And a 4 to 5-digit number like 10532 is easier to\n remember than something like 3250.2.45.86.\n - Their ordering would be an (arbitrary) superset of the partial\n ordering by descendance, ie. if revision A is ancestor of B, it would\n always have lower revno.\n - The intuition that lower revno means older revision would be always\n valid for related revisions and approximately valid for unrelated\n ones.\n - They would be *localy stable*. That is once assigned the revno would\n always mean the same revision in given branch (as determined by\n location, not tip).\n - This is more than the current scheme can give, since now pull can\n renumber revisions.\n - They wouldn't make any branch special, so the objections Linus raised\n does not apply.\n - They would be the same as subversion and svk, and IIRC mercurial as\n well, use, so:\n - They would already be familiar to users comming from those systems.\n - They are known to be useful that way. In fact for svk it's the only\n way to refer to revisions and seem to work satisfactorily (though\n note that svk is not really suitable to ad-hoc topologies).\n\nNow I said there are two options how to assign them. These are:\n\n - Repository-wide: Number would be assigned to each revision entering\n the repository, even when it is not in ancestry of any branch (ie.\n if one starts a merge, but than reverts it).\n - Advantages:\n - Simpler to implement (just log every written-out revision).\n - All branches in the same repository use the same revision\n numbers, so if you keep branches in a shared repo, it makes\n easier to look up one revision in log of one branch, other in log\n of other branch and run diff on them.\n - Disadvantages:\n - Mirror only has the same revnos if both master and the mirror are\n stand-alone branches.\n - Branch-wide: Nuber would be assigned to each revision that becomes\n ancestor of the current head revision.\n - Advantages:\n - Mirror (always updated by push from the same source) always have\n the same revision numbers.\n - The revno assignment list could be reused for refering to state\n at particular point in time (in fact, it would be exactly the\n same thing as git reflog).\n - Bound branches could be forced to have the same revnos.\n - Disadvantages:\n - More complex to implement.\n - More work at runtime and more space needed in a shared\n repository, since each branch has it's own mapping.\n\nBoth ways, it would be implemented the way revision-history currently\nis, just it would list all revisions, not just the path along the\nleftmost parent.\n\nComments?\n\n(Should I put it on the wiki?)\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29163","messageId":"20061018215106.GY20017@pasky.or.cz","threadId":"5925","inReplyTo":"20061017185622.30fbc6c0.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T21:51:06Z","receivedAt":"2006-10-18T21:51:06Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Oct 18, 2006 at 12:56:22AM CEST, I got a letter\nwhere Sean said that...\n> On Tue, 17 Oct 2006 18:44:11 -0400\n> Aaron Bentley wrote:\n> > Plugins also don't have a Bazaar's rigid release cycle, testing\n> > requirements and coding conventions, so they are a convenient way to try\n> > out an idea, before committing to the effort of getting it merged into\n> > the core.\n> \n> Hmm.. It's pretty easy to test out Git ideas too. People do it all\n> the time, and without plugins. Junio maintains several such trees\n> for instance. Dunno.. I just think plugs _sounds_ good to developers\n> without much real benefit to users over regular ole source code.\n\nI think this is just another cultural difference. Git comes from the\nkernel environment (although it is currently used in far more\nenvironments than just the kernel and kernel-related stuff) and the\n_kernel_'s development style is that you want to get as much stuff as\npossible inside the kernel, and on the other hand don't care at all\nabout breaking in-kernel APIs and such.\n\nThe Git \"plumbing\" is very much the \"kernel\". We aren't as much\ninterested in having support for external bits of code poking in the Git\ninnards, we would much rather have them integrated into Git as soon as\npossible rather than live around externally. OTOH, the \"kernel\" gives a\nvery flexible (\"UNIXy\") API to the writhing mass of porcelain scripts you\nmay call the \"userland\".\n\nI'm not saying it must be always sharply better approach than the\nplugin-encouraging approach. It's just as it is. (Also, another reason\nis probably a purely technical one, it is much easier to have pluggable\nfunctions in scripting languages that support \"monkey-patching\", than\nhave them in C, since you actually need to explicitly add all the hooks\netc. So in Python, from a large part you get the plugin support for\nfree.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> Shawn Pearce writes:\n> \n> > ... Although it would add\n> > a new pair of configuration options to .git/config. Is that change\n> > too radical? :-)\n> \n> I wonder what you would need the configuration options for.\n> \n> If mmap() pack works well, it works well, and if it is broken\n> nobody has reason to enable it. The code should be able to\n> adjust the mmap window to appropriate size itself and its\n> automatic adjustment does not even have to be the absolute\n> optimum (since the user would not know what the optimum would be\n> anyway), so maybe your configuration options would not be\n> \"enable\" nor \"window-size\" -- and I am puzzled as to what they\n\nAll very true.\n\nHowever what do we do about the case where we mmap over 1 GiB worth\nof pack data (because the mmap succeeds and we have at least that\nmuch in .pack and .idx files) and then the application starts to\ndemand a lot of memory via malloc? At some point malloc will return\nNULL, xmalloc will die(), and that's the end of the program.\n\nIf the user was able to set the maximum threshold of how much data\nwe mmap then they could initially prevent us from mmap'ing over 1 GiB;\ninstead using a smaller upper limit like 512 MiB.\n\nOf course as I write this I think the better solution to this\nproblem is to simply modify xmalloc (and friends) so that if the\nunderlying malloc returned NULL and we have a large amount of stuff\nmmap'd from packs we try releasing some of the unused pack windows\nand retry the malloc before die()'ing.\n\n\nThe other configuration option is the size of the mmap window.\nThis should by default be at least 32 MiB, probably closer to\n128 MiB. But its nice to be able to force it as low as a single\nsystem page to setup test cases in the t/ directory for the mmap\nwindow code.\n\nEarlier this summer we discussed this exact issue and said this\nvalue probably needs to be configurable if only to facilitate the\nunit tests.\n\n-- \nShawn.\n"},{"id":"29165","messageId":"20061018215255.GZ20017@pasky.or.cz","threadId":"5925","inReplyTo":"20061018174450.f2108a21.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T21:52:56Z","receivedAt":"2006-10-18T21:52:56Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Oct 18, 2006 at 11:44:50PM CEST, I got a letter\nwhere Sean said that...\n> On Wed, 18 Oct 2006 17:37:03 -0400\n> Shawn Pearce wrote:\n> \n> > Today Git is typically extended (at least initially in prototyping\n> > mode) through Perl, Python, TCL or Bourne shell scripts. Although\n> > the first three are available natively on Windows the last requires\n> > Cygwin... and we've had some issues with ActiveState Perl on Windows\n> > in the past too.\n> \n> Just for kicks and giggles it would be nice if someone tried out\n> one of the native Windows bourne shell ports[1] just to see how much\n> is missing. A bunch of command line utilities would have to be ported\n> as well; maybe too many. But i've held out booting a Windows box\n> for a long time so.... not it!\n\nI think that before starting to think about the porcelain scripts, you\nneed to port the plumbing. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n\n> You can use just this single tool from Cogito. ;-)\n\nI'd rather not have to keep two separate tools up to date, i just want\nto install Git and have all these features installed. Especially since\nthere is so much overlap in what these two packages do. That would seem\nlike the best thing to do for most users in fact, asking them to install\nand keep both up to date just doesn't make sense, to me at least.\n\n> The point is, I'll of course prefer doing this stuff in Cogito while I'm\n> enhancing Cogito, and I'll work on Cogito while I and others will be\n> using it. I didn't move on to pure Git long time ago since I simply\n> consider its UI much inferior to Cogito's. Sure, given enough time and\n> work, it is fixable - but UI flaws are very hard to fix and I find it\n> more effective to work on Cogito for the time being, at least until I\n> bring it to 1.0, then I'll see.\n> \n> Besides, I'm used to Cogito. :-)\n> \n> So yes, current Git code definitely is a part of the reason, but it is\n> certainly not the main part of it.\n\nIt's just a shame that your talents are split off from helping the main\nproject more. Git would be further along today in content and PR if it\nhad managed to attract you back from your Cogito adventure. Then all\nthe nice things you're able to say about Cogito might then be said\nabout Git proper, and maybe we'd attract even more users.\n\nWhile you've contributed more to Git than many others (including me\nobviously), it would sure be nice to see you back full time on Git.\nI want to type \"git bundle\" without having to install more\nsoftware damnit ;o) But of course you have to decide what's best\nfor yourself.\n\nSean\n"},{"id":"29167","messageId":"Pine.LNX.4.64.0610181449290.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061018213225.GD19194@spearce.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-18T21:55:47Z","receivedAt":"2006-10-18T21:55:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Shawn Pearce wrote:\n> \n> My comment that you quoted was about mmap'ing the pack files in\n> large chunks (around 64-128 MiB at a time, but configurable from\n> .git/config) rather than as an entire massive mapping.\n\nSure. I agree that we should do that, if only because it's clearly getting \nhard to handle large pack-files on a 32-bit architecture.\n\nYou just seemed to say that in the _context_ of wanting to support having \nmultiple pack-files open (in order to allow deltas to refer to things \noutside their own pack-file).\n\nI just wanted to head that particular idea off at the pass.\n\nI think thin packs have been a good idea, and they certainly cut the \namount of data sent over the network down by a large amount (much more \nthan 50%), so I think thin packs are a great idea. Just _not_ when \nindexed.\n\nSo I don't object to mmap windows at all. I object to them only in the \ncontext of \"they would allow us to use deltas between two different packs\"\ndiscussion ;)\n\n\t\tLinus\n"},{"id":"29168","messageId":"7vejt5z3rq.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181358200.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-18T21:56:57Z","receivedAt":"2006-10-18T21:56:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> My personal suspicion is that we'll want to have a 64-bit index file some \n> day, and THAT is worthy of a format change. That day is not now, btw. It's \n> probably not even very close. Even the mozilla repo that was pushing the \n> limit was only doing so until it was optimized better, and now it's \n> apparently nowhere _near_ that limit.\n>\n> But even then, we might well want to update _just_ the index file format.\n\nWe've tried this already, and I shelved the patch for 64-index\nfor now due to exactly the same reasoning as yours (and it would\nhave conflicted heavily with Shawn's windowed-mmap() patch). It\ninvolved updating just the index file format, so you are right\non both counts.\n\nBut you are always right anyway, so it may not be a news at all\n;-).\n"},{"id":"29169","messageId":"Pine.LNX.4.64.0610181455570.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061018214143.GF19194@spearce.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-18T22:00:56Z","receivedAt":"2006-10-18T22:00:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Shawn Pearce wrote:\n> \n> Actually there is a point to storing thin packs. When I pull from\n> a remote repo (or push to a remote repo) a huge number of objects\n> and the target disk that is about to receive that huge number of\n> loose objects is slooooooooow I would rather just store the thin\n> pack then store the loose objects.\n> \n> Ideally that thin pack would be repacked (along with the other\n> existing packs) as quickly as possible into a self-contained pack.\n> But that of course is unlikely to happen in practice; especially\n> on a push.\n\nI'm really nervous about keeping thin packs around. \n\nBut a possibly good (and fairly simple) alternative would be to just \ncreate a non-thin pack on the receiving side. Right now we unpack into a \nlot of loose objects, but it should be possible to instead \"unpack\" into a \nnon-thin pack.\n\nIn other words, we could easily still use the thin pack for communication, \nwe'd just \"fill it out\" on the receiving side.\n\n\t\tLinus\n"},{"id":"29170","messageId":"7vac3tz3iw.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"20061018215219.GG19194@spearce.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-18T22:02:15Z","receivedAt":"2006-10-18T22:02:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> However what do we do about the case where we mmap over 1 GiB worth\n> of pack data (because the mmap succeeds and we have at least that\n> much in .pack and .idx files) and then the application starts to\n> demand a lot of memory via malloc?...\n>\n> The other configuration option is the size of the mmap window.\n>...\n> Earlier this summer we discussed this exact issue and said this\n> value probably needs to be configurable if only to facilitate the\n> unit tests.\n\nI see. So you are allowing users to control individual window\nsize and total mmap memory. That makes sense.\n"},{"id":"29171","messageId":"20061018220509.GH19194@spearce.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181449290.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-18T22:05:10Z","receivedAt":"2006-10-18T22:05:10Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> So I don't object to mmap windows at all. I object to them only in the \n> context of \"they would allow us to use deltas between two different packs\"\n> discussion ;)\n\nHaving mmap windows or not has no impact on using deltas between\npacks. We already map multiple packs at once. We just don't do\ndelta resolution between them, for the reasons you have already\ngiven.\n\nThe two are totally unrelated. I apologize for somehow making\nyourself (and others) think they are.\n\n-- \nShawn.\n"},{"id":"29172","messageId":"7v4pu1z3ab.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181449290.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-18T22:07:24Z","receivedAt":"2006-10-18T22:07:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> I think thin packs have been a good idea, and they certainly cut the \n> amount of data sent over the network down by a large amount (much more \n> than 50%), so I think thin packs are a great idea. Just _not_ when \n> indexed.\n\nAh, I feel quite behind. I was about to say \"oh have you been\npushing with --thin option?\", and then realized that we made it\ndefault since late March this year.\n\nI need to run memtest86 on myself X-<.\n"},{"id":"29173","messageId":"20061018221110.GI19194@spearce.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181455570.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-18T22:11:10Z","receivedAt":"2006-10-18T22:11:10Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Wed, 18 Oct 2006, Shawn Pearce wrote:\n> > \n> > Actually there is a point to storing thin packs. When I pull from\n> > a remote repo (or push to a remote repo) a huge number of objects\n> > and the target disk that is about to receive that huge number of\n> > loose objects is slooooooooow I would rather just store the thin\n> > pack then store the loose objects.\n> > \n> > Ideally that thin pack would be repacked (along with the other\n> > existing packs) as quickly as possible into a self-contained pack.\n> > But that of course is unlikely to happen in practice; especially\n> > on a push.\n> \n> I'm really nervous about keeping thin packs around. \n> \n> But a possibly good (and fairly simple) alternative would be to just \n> create a non-thin pack on the receiving side. Right now we unpack into a \n> lot of loose objects, but it should be possible to instead \"unpack\" into a \n> non-thin pack.\n> \n> In other words, we could easily still use the thin pack for communication, \n> we'd just \"fill it out\" on the receiving side.\n\nFunny, I had the same thought. :-)\n\nWe already know how many objects are coming in on a thin pack;\nits right there in the header. We could just have some threshold\nat which we start writing a full pack rather than unpacking.\n\nWriting such a full pack would be a simple matter of copying the\ninput stream out to a temporary pack, but sticking any delta bases\ninto a table in memory. At the end of the data stream if we have any\ndelta bases which weren't actually in that pack then find them and\ncopy them onto the end, update the header and recompute the checksum.\ngit-fastimport does some of that already, though its trivial code...\n\nWorst case scenario would be the incoming thin pack is 100% deltas\nas we would need to copy in a base object for every object mentioned\nin the pack.\n\n-- \nShawn.\n"},{"id":"29174","messageId":"7vwt6xxofi.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"20061018214143.GF19194@spearce.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-18T22:13:37Z","receivedAt":"2006-10-18T22:13:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Ideally that thin pack would be repacked (along with the other\n> existing packs) as quickly as possible into a self-contained pack.\n\nIt should not be hard to write another program that generates a\npackfile like pack-object does but taking a thin pack as its\ninput. Then receive-pack can drive it instead of\nunpack-objects.\n"},{"id":"29175","messageId":"eh68va$7er$1@sea.gmane.org","threadId":"5925","inReplyTo":"20061018214623.GA32725@artax.karlin.mff.cuni.cz","subject":"Re: Alternate revno proposal (Was: Re: VCS comparison table)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-18T22:14:02Z","receivedAt":"2006-10-18T22:14:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jan Hudec wrote:\n\n> Comments?\n\nWhat about fetching from repository? For revnos you have to assign revno for\nall commit you have downloaded; now you need only to unpack received pack\n(or not, if you used --keep option). More work.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29177","messageId":"Pine.LNX.4.64.0610181542160.3962@g5.osdl.org","threadId":"5925","inReplyTo":"7vwt6xxofi.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-18T22:42:50Z","receivedAt":"2006-10-18T22:42:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Junio C Hamano wrote:\n> \n> It should not be hard to write another program that generates a\n> packfile like pack-object does but taking a thin pack as its\n> input. Then receive-pack can drive it instead of\n> unpack-objects.\n\nGive me half an hour. It should be trivial to make \"unpack-objects\" write \nthe \"unpacked\" objects into a pack-file instead.\n\n\t\tLinus\n"},{"id":"29178","messageId":"7vslhlxmt3.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181542160.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-18T22:48:40Z","receivedAt":"2006-10-18T22:48:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Wed, 18 Oct 2006, Junio C Hamano wrote:\n>> \n>> It should not be hard to write another program that generates a\n>> packfile like pack-object does but taking a thin pack as its\n>> input. Then receive-pack can drive it instead of\n>> unpack-objects.\n>\n> Give me half an hour. It should be trivial to make \"unpack-objects\" write \n> the \"unpacked\" objects into a pack-file instead.\n\nHeh, three people having the same idea that goes in the same\ndirection at the same time is not necessarily a good sign of\nefficient project management...\n\nI am currently fighting with FC5 so please go ahead.\n"},{"id":"29179","messageId":"Pine.LNX.4.64.0610181910440.1971@xanadu.home","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181542160.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-10-18T23:18:58Z","receivedAt":"2006-10-18T23:18:58Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 18 Oct 2006, Linus Torvalds wrote:\n\n> \n> \n> On Wed, 18 Oct 2006, Junio C Hamano wrote:\n> > \n> > It should not be hard to write another program that generates a\n> > packfile like pack-object does but taking a thin pack as its\n> > input. Then receive-pack can drive it instead of\n> > unpack-objects.\n> \n> Give me half an hour. It should be trivial to make \"unpack-objects\" write \n> the \"unpacked\" objects into a pack-file instead.\n\nIf you use builtin-unpack-objects.c from next, you'll be able to \ngenerate the pack index pretty easily as well, as all the needed info is \nstored in the obj_list array. Just need to append objects remaining on \nthe delta_list array to the end of the pack, sort the obj_list by sha1 \nand write the index.\n\nPretty trivial indeed.\n\n\nNicolas\n"},{"id":"29180","messageId":"20061018232214.GJ19194@spearce.org","threadId":"5925","inReplyTo":"7vslhlxmt3.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-18T23:22:14Z","receivedAt":"2006-10-18T23:22:14Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Linus Torvalds writes:\n> \n> > On Wed, 18 Oct 2006, Junio C Hamano wrote:\n> >> \n> >> It should not be hard to write another program that generates a\n> >> packfile like pack-object does but taking a thin pack as its\n> >> input. Then receive-pack can drive it instead of\n> >> unpack-objects.\n> >\n> > Give me half an hour. It should be trivial to make \"unpack-objects\" write \n> > the \"unpacked\" objects into a pack-file instead.\n> \n> Heh, three people having the same idea that goes in the same\n> direction at the same time is not necessarily a good sign of\n> efficient project management...\n\nOr maybe it is just a sign of a good way to resolve the issue I\nwas raising. :-)\n\n-- \nShawn.\n"},{"id":"29181","messageId":"eh6dgr$pu8$1@sea.gmane.org","threadId":"5925","inReplyTo":"BAYC1-PASMTP069C473B2E79389E5BFC92AE0F0@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Charles Duffy","fromEmail":"cduffy@spamcop.net","sentAt":"2006-10-18T23:31:32Z","receivedAt":"2006-10-18T23:31:32Z","isPatch":false,"sender":{"key":"cduffy@spamcop.net","avatar":null},"body":"Sean wrote:\n> You'll need a better example than that. Git has supported a version\n> of Cygwin-compatible symlink support on Windows for quite some time.\n> And no plugins were needed.\n\nThe win32-compatible symlink support is not, in and of itself, the point.\n\nThe point is that core, pervasive functionality can be modified at \nruntime, with no recompilation or installation of tools not included in \nthe bzr package itself, simply by dropping a directory into place. This \nmeans that folks who don't have the skillset to merge three branches \ntogether (say, upstream plus two different trees adding extra \nfunctionality) and run a build can still install a few plugins to \nenhance their copy of bzr (which was installed by their IT staff, or a \nshiny click-through idiot-friendly Windows installer, etc).\n\nAnd yes, there are people like that who are part of bzr's target \naudience. Think (of the lower end of the set of) DBAs, QA folk and such.\n\n\nGranted, I'm speaking with my IT hat on here rather than my developer \nhat -- but plugins are a pretty clear usability win.\n"},{"id":"29182","messageId":"Pine.LNX.4.63.0610190134040.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"20061018213703.GE19194@spearce.org","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-18T23:38:45Z","receivedAt":"2006-10-18T23:38:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 18 Oct 2006, Shawn Pearce wrote:\n\n> Today Git doesn't run natively on Windows.\n\nAs I mentioned some time ago, I started a branch on MinGW. It works quite \nwell for the moment, but it lacks fork() emulation, and glob() emulation. \nAnd I lack the time to continue working on it.\n\n> Today Git is typically extended (at least initially in prototyping\n> mode) through Perl, Python, TCL or Bourne shell scripts. Although\n> the first three are available natively on Windows the last requires\n> Cygwin... and we've had some issues with ActiveState Perl on Windows\n> in the past too.\n\nThose are not the only problems with scripting. Scripting is fine for \nprototyping, but _anything_ remotely serious should be implemented using a \nportable (!) and safe (!) API.\n\nCiao,\nDscho\n"},{"id":"29183","messageId":"Pine.LNX.4.63.0610190144450.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"eh6dgr$pu8$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-18T23:48:05Z","receivedAt":"2006-10-18T23:48:05Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 18 Oct 2006, Charles Duffy wrote:\n\n> The point is that core, pervasive functionality can be modified at \n> runtime, with no recompilation or installation of tools not included in \n> the bzr package itself, simply by dropping a directory into place.\n\nPlease note that this is not welcome here. I _need_ to trust my SCM. And \n_that_ means that no strange non-mainline beast can be allowed to change \ncore features.\n\nSo, the wonderful upside of plugins you described here are actually the \nreason I will never, _never_ use bzr with plugins.\n\nCiao,\nDscho\n\n--\n\nIt's not paranoia. It's called experience.\n"},{"id":"29184","messageId":"eh6eft$roe$1@sea.gmane.org","threadId":"5925","inReplyTo":"eh6dgr$pu8$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-18T23:48:13Z","receivedAt":"2006-10-18T23:48:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Charles Duffy wrote:\n\n> Sean wrote:\n>> You'll need a better example than that. Git has supported a version\n>> of Cygwin-compatible symlink support on Windows for quite some time.\n>> And no plugins were needed.\n> \n> The win32-compatible symlink support is not, in and of itself, the point.\n> \n> The point is that core, pervasive functionality can be modified at \n> runtime, with no recompilation or installation of tools not included in \n> the bzr package itself, simply by dropping a directory into place. This \n> means that folks who don't have the skillset to merge three branches \n> together (say, upstream plus two different trees adding extra \n> functionality) and run a build can still install a few plugins to \n> enhance their copy of bzr (which was installed by their IT staff, or a \n> shiny click-through idiot-friendly Windows installer, etc).\n\nYou don't need plugins for that. Take for example git-svn (perhaps not the\nbest example, as it is Perl script; but Python although has compiled form\nis script language at heart), which went AFAIK from external contribution,\nto being in contrib/, to being in mainline (and in git-svn package).\n\nAbout plugins modifying some core functionality: this is rather sign\nof not attracting developers to do it in-core...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29185","messageId":"BAYC1-PASMTP08C440ED4BB74AC380B959AE0F0@CEZ.ICE","threadId":"5925","inReplyTo":"eh6dgr$pu8$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-18T23:49:45Z","receivedAt":"2006-10-18T23:49:45Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 18 Oct 2006 18:31:32 -0500\nCharles Duffy wrote:\n\n> Granted, I'm speaking with my IT hat on here rather than my developer \n> hat -- but plugins are a pretty clear usability win.\n\nSure they can be. But their value I think is overstated, especially\nin an open source project where anyone can grab a copy of the source\nand update it with a trial feature. This updated copy can be wrapped\nin a nice GUI installer just as easily as any plugin.\n\nNow, I suppose plugins let end users mix and match trial features\nslightly easier, but hopefully your base package isn't so devoid of\nfeatures that this is honestly necessary.\n\nAs Petr pointed out, all this comes to Bzr essentially for free\nsince it's a part of python. So be it, but I've yet to hear an\nexample where plugins were anything more than a minor convenience\nrather than a fundamental win over the way Git is developing.\n\nFor an example, just look how few lines of git were needed to\nimplement the essential features of the bzr bundle feature.\nWith no plugins or monkey business needed ;o)\n\nSean\n"},{"id":"29463","messageId":"20061018194945.3e5105e7.seanlkml__29789.188996847$1161405144$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"eh6dgr$pu8$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-18T23:49:45Z","receivedAt":"2006-10-18T23:49:45Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 18 Oct 2006 18:31:32 -0500\nCharles Duffy wrote:\n\n> Granted, I'm speaking with my IT hat on here rather than my developer \n> hat -- but plugins are a pretty clear usability win.\n\nSure they can be. But their value I think is overstated, especially\nin an open source project where anyone can grab a copy of the source\nand update it with a trial feature. This updated copy can be wrapped\nin a nice GUI installer just as easily as any plugin.\n\nNow, I suppose plugins let end users mix and match trial features\nslightly easier, but hopefully your base package isn't so devoid of\nfeatures that this is honestly necessary.\n\nAs Petr pointed out, all this comes to Bzr essentially for free\nsince it's a part of python. So be it, but I've yet to hear an\nexample where plugins were anything more than a minor convenience\nrather than a fundamental win over the way Git is developing.\n\nFor an example, just look how few lines of git were needed to\nimplement the essential features of the bzr bundle feature.\nWith no plugins or monkey business needed ;o)\n\nSean\n"},{"id":"29186","messageId":"Pine.LNX.4.63.0610190149580.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181910440.1971@xanadu.home","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-18T23:50:48Z","receivedAt":"2006-10-18T23:50:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 18 Oct 2006, Nicolas Pitre wrote:\n\n> Pretty trivial indeed.\n\nEasy! You take all the fun out of it!\n\nCiao,\nDscho\n"},{"id":"29188","messageId":"20061018235415.GA20017@pasky.or.cz","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610190134040.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-18T23:54:15Z","receivedAt":"2006-10-18T23:54:15Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nDear diary, on Thu, Oct 19, 2006 at 01:38:45AM CEST, I got a letter\nwhere Johannes Schindelin said that...\n> On Wed, 18 Oct 2006, Shawn Pearce wrote:\n> \n> > Today Git doesn't run natively on Windows.\n> \n> As I mentioned some time ago, I started a branch on MinGW. It works quite \n> well for the moment, but it lacks fork() emulation, and glob() emulation. \n> And I lack the time to continue working on it.\n\n care to publish it somewhere, e.g. on repo.or.cz?\n\n (P.S., have fun in Prague! Too bad I won't be around over the weekend.\n:-( )\n\n Thanks,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i \n> If you use builtin-unpack-objects.c from next, you'll be able to \n> generate the pack index pretty easily as well, as all the needed info is \n> stored in the obj_list array. Just need to append objects remaining on \n> the delta_list array to the end of the pack, sort the obj_list by sha1 \n> and write the index.\n\nActually, I've hit an impasse.\n\nThe index isn't the problem. The problem is actually writing the resultant \npack-file itself in one go.\n\nThe silly thing is, the pack-file contains the number of entries in the \nheader. That's a silly problem, because the _natural_ way to turn a thin \npack into a normal pack would be to just add the missing objects from the \nlocal store into the resulting pack. But we don't _know_ how many such \nmissing objects there are, until we've gone through the whole source pack. \n\nSo you can't easily do a streaming \"write the result as you go along\" \nversion using that approach.\n\nSo there's _another_ way of fixing a thin pack: it's to expand the objects \nwithout a base into non-delta objects, and keeping the number of objects \nin the pack the same. But _again_, we don't actually know which ones to \nexpand until it's too late.\n\nThe end result? I can expand them all (I have a patch that does that). Or \nI could leave as deltas the ones I have already seen the base for in the \npack-file (I don't have that yet, but that should be a SMOP). But I'm not \nvery happy with even the latter choice, because it really potentially \nexpands things that didn't _need_ expansion, they just got expanded \nbecause we hadn't seen the base object yet.\n\nSo I'll happily send my patches to anybody who wants to try (I don't write \nthe index file yet, but it should be easy to add), but I'm getting the \nfeeling that \"builtin-unpack-objects.c\" is the wrong tool to use for this, \nbecause it's very much designed for streaming.\n\nIt would probably be better to start from \"index-pack.c\" instead, which is \nalready a multi-pass thing, and wouldn't have had any of the problems I \nhit. \n\nGaah.\n\n> Pretty trivial indeed.\n\nSo it's conceptually totally trivial to rewrite a pack-file as another \npack-file, but at least so far, it's turned out to be less trivial in \npractice (or at least in a single pass, without holding everything in \nmemory, which I definitely do _not_ want to do).\n\nSo I'm leaving this for today, and perhaps coming back to it tomorrow with \na fresh eye.\n\n\t\t\tLinus\n"},{"id":"29190","messageId":"Pine.LNX.4.64.0610181711110.3962@g5.osdl.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181655430.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-19T00:15:00Z","receivedAt":"2006-10-19T00:15:00Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Linus Torvalds wrote:\n> \n> So I'll happily send my patches to anybody who wants to try (I don't write \n> the index file yet, but it should be easy to add), but I'm getting the \n> feeling that \"builtin-unpack-objects.c\" is the wrong tool to use for this, \n> because it's very much designed for streaming.\n\nA potentially even simpler way would probably be to literally just use \n\"git-pack-objects\" directly, and just have a very special mode that allows \nmapping the thin pack as if it was a real pack (ie basically \npre-populating a fake pack entry, where the fake part comes from adding \nthe missing objects by hand to the mapping).\n\nSo many ways to do it, so little real motivation ;)\n\n\t\tLinus\n"},{"id":"29191","messageId":"Pine.LNX.4.63.0610190229270.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181655430.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-19T00:31:02Z","receivedAt":"2006-10-19T00:31:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 18 Oct 2006, Linus Torvalds wrote:\n\n> The silly thing is, the pack-file contains the number of entries in the \n> header.\n\nYou do not write this to stdout, right? Why not just come back and correct \nthe number of objects? Of course, the SHA1 has to be calculated _after_ \nthat.\n\nCiao,\nDscho\n"},{"id":"29192","messageId":"Pine.LNX.4.63.0610190231140.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"20061018235415.GA20017@pasky.or.cz","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-19T00:33:46Z","receivedAt":"2006-10-19T00:33:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Oct 2006, Petr Baudis wrote:\n\n> Dear diary, on Thu, Oct 19, 2006 at 01:38:45AM CEST, I got a letter\n> where Johannes Schindelin said that...\n> > On Wed, 18 Oct 2006, Shawn Pearce wrote:\n> > \n> > > Today Git doesn't run natively on Windows.\n> > \n> > As I mentioned some time ago, I started a branch on MinGW. It works quite \n> > well for the moment, but it lacks fork() emulation, and glob() emulation. \n> > And I lack the time to continue working on it.\n> \n> care to publish it somewhere, e.g. on repo.or.cz?\n\nIt is way to dirty for that. I would only dare give it somebody in return \nfor the promise to clean everything up.\n\nBTW I completely forgot that in the absence of poll() from MinGW, all the \nnetworking code is actually just wrapped into \"return -1;\" functions.\n\n> (P.S., have fun in Prague! Too bad I won't be around over the weekend.\n> :-( )\n\nPity. You seem to have good connections...\n\nCiao,\nDscho\n"},{"id":"29193","messageId":"Pine.LNX.4.64.0610181741590.3962@g5.osdl.org","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610190229270.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-19T00:46:38Z","receivedAt":"2006-10-19T00:46:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 19 Oct 2006, Johannes Schindelin wrote:\n> \n> You do not write this to stdout, right? Why not just come back and correct \n> the number of objects? Of course, the SHA1 has to be calculated _after_ \n> that.\n\nThat's the issue. I wanted the pack-file thing to look as similar to the \nold code as possible. And that means using the \"sha1write()\" interfaces, \nwhich calculate the SHA1 checksum _as_ we write.\n\nSo yes, I wanted to do it all in one phase.\n\nAnyway, if anybody is interested, here's a series of four patches that do \nsomething that _almost_ works. I save away the SHA1's and the offsets so \nthat I could write an index too, but I didn't actually do that part.\n\nBut with this, I can rewrite a pack-file \"in flight\", and the end result \ncan then have \"git index-pack\" run on it, and used as a pack. It's just \nthat there are no deltas left because of some of the silly problems I \noutlined (the code to write out deltas is actually there and just \nuncommented - it works, but it leaves the end result with unsatisfied \ndeltas again).\n\n\t\tLinus\n---\ncommit 4efd9b0f44635b3075c9aad6d1cc8830e3abded3\nAuthor: Linus Torvalds \nDate: Wed Oct 18 17:22:04 2006 -0700\n\n Fix up csum-file interfaces\n \n Add \"const\" where appropriate\n \n Signed-off-by: Linus Torvalds \n\ndiff --git a/csum-file.c b/csum-file.c\nindex b7174c6..3237228 100644\n--- a/csum-file.c\n+++ b/csum-file.c\n@@ -47,7 +47,7 @@ int sha1close(struct sha1file *f, unsign\n \treturn 0;\n }\n \n-int sha1write(struct sha1file *f, void *buf, unsigned int count)\n+int sha1write(struct sha1file *f, const void *buf, unsigned int count)\n {\n \twhile (count) {\n \t\tunsigned offset = f->offset;\n@@ -115,7 +115,7 @@ struct sha1file *sha1fd(int fd, const ch\n \treturn f;\n }\n \n-int sha1write_compressed(struct sha1file *f, void *in, unsigned int size)\n+int sha1write_compressed(struct sha1file *f, const void *in, unsigned int size)\n {\n \tz_stream stream;\n \tunsigned long maxsize;\n@@ -127,7 +127,7 @@ int sha1write_compressed(struct sha1file\n \tout = xmalloc(maxsize);\n \n \t/* Compress it */\n-\tstream.next_in = in;\n+\tstream.next_in = (void *) in;\n \tstream.avail_in = size;\n \n \tstream.next_out = out;\ndiff --git a/csum-file.h b/csum-file.h\nindex 3ad1a99..fee8589 100644\n--- a/csum-file.h\n+++ b/csum-file.h\n@@ -13,7 +13,7 @@ struct sha1file {\n extern struct sha1file *sha1fd(int fd, const char *name);\n extern struct sha1file *sha1create(const char *fmt, ...) __attribute__((format (printf, 1, 2)));\n extern int sha1close(struct sha1file *, unsigned char *, int);\n-extern int sha1write(struct sha1file *, void *, unsigned int);\n-extern int sha1write_compressed(struct sha1file *, void *, unsigned int);\n+extern int sha1write(struct sha1file *, const void *, unsigned int);\n+extern int sha1write_compressed(struct sha1file *, const void *, unsigned int);\n \n #endif\n\f\ncommit c2c8480b05a75d93f78a0ddd1cce18c6864738eb\nAuthor: Linus Torvalds \nDate: Wed Oct 18 17:20:53 2006 -0700\n\n Make some of the pack-writing helper functions available\n \n string_to_type() and encode_header() are useful in general.\n \n Signed-off-by: Linus Torvalds \n\ndiff --git a/builtin-pack-objects.c b/builtin-pack-objects.c\nindex 96c069a..ea39bf3 100644\n--- a/builtin-pack-objects.c\n+++ b/builtin-pack-objects.c\n@@ -220,6 +220,20 @@ static void *delta_against(void *buf, un\n \treturn delta_buf;\n }\n \n+enum object_type string_to_type(const char *type, const unsigned char *sha1)\n+{\n+\tif (!strcmp(type, commit_type))\n+\t\treturn OBJ_COMMIT;\n+\tif (!strcmp(type, tree_type))\n+\t\treturn OBJ_TREE;\n+\tif (!strcmp(type, blob_type))\n+\t\treturn OBJ_BLOB;\n+\tif (!strcmp(type, tag_type))\n+\t\treturn OBJ_TAG;\n+\tdie(\"strange object %s of unknown type %s\",\n+\t\t sha1_to_hex(sha1), type);\n+}\n+\n /*\n * The per-object header is a pretty dense thing, which is\n * - first byte: low four bits are \"size\", then three bits of \"type\",\n@@ -227,7 +241,7 @@ static void *delta_against(void *buf, un\n * - each byte afterwards: low seven bits are size continuation,\n * with the high bit being \"size continues\"\n */\n-static int encode_header(enum object_type type, unsigned long size, unsigned char *hdr)\n+int encode_header(enum object_type type, unsigned long size, unsigned char *hdr)\n {\n \tint n = 1;\n \tunsigned char c;\n@@ -943,17 +957,7 @@ static void check_object(struct object_e\n \t\tdie(\"unable to get type of object %s\",\n \t\t sha1_to_hex(entry->sha1));\n \n-\tif (!strcmp(type, commit_type)) {\n-\t\tentry->type = OBJ_COMMIT;\n-\t} else if (!strcmp(type, tree_type)) {\n-\t\tentry->type = OBJ_TREE;\n-\t} else if (!strcmp(type, blob_type)) {\n-\t\tentry->type = OBJ_BLOB;\n-\t} else if (!strcmp(type, tag_type)) {\n-\t\tentry->type = OBJ_TAG;\n-\t} else\n-\t\tdie(\"unable to pack object %s of type %s\",\n-\t\t sha1_to_hex(entry->sha1), type);\n+\tentry->type = string_to_type(type, entry->sha1);\n }\n \n static unsigned int check_delta_limit(struct object_entry *me, unsigned int n)\ndiff --git a/pack.h b/pack.h\nindex eb07b03..346a430 100644\n--- a/pack.h\n+++ b/pack.h\n@@ -15,6 +15,9 @@ struct pack_header {\n \tunsigned int hdr_entries;\n };\n \n+enum object_type string_to_type(const char *type, const unsigned char *sha1);\n+int encode_header(enum object_type type, unsigned long size, unsigned char *hdr);\n+\n extern int verify_pack(struct packed_git *, int);\n extern int check_reuse_pack_delta(struct packed_git *, unsigned long,\n \t\t\t\t unsigned char *, unsigned long *,\n\f\ncommit 94d620067b4a4179656c0ce347cb87be52a9d67f\nAuthor: Linus Torvalds \nDate: Wed Oct 18 15:44:40 2006 -0700\n\n git-unpack-objects: pass in the original delta data when writing the object\n \n This does nothing right now, but if we want to instead of loose objects\n write a new \"verified packfile\" with an index, this lets us do that instead.\n \n Signed-off-by: Linus Torvalds \n\ndiff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c\nindex 4f96bca..bbb6e21 100644\n--- a/builtin-unpack-objects.c\n+++ b/builtin-unpack-objects.c\n@@ -109,7 +109,8 @@ static void add_delta_to_list(unsigned c\n \n static void added_object(unsigned char *sha1, const char *type, void *data, unsigned long size);\n \n-static void write_object(void *buf, unsigned long size, const char *type)\n+static void write_object(void *buf, unsigned long size, const char *type,\n+\tunsigned char *base, void *delta, unsigned long delta_size)\n {\n \tunsigned char sha1[20];\n \tif (write_sha1_file(buf, size, type, sha1) < 0)\n@@ -117,7 +118,7 @@ static void write_object(void *buf, unsi\n \tadded_object(sha1, type, buf, size);\n }\n \n-static void resolve_delta(const char *type,\n+static void resolve_delta(const char *type, unsigned char *base_sha1,\n \t\t\t void *base, unsigned long base_size,\n \t\t\t void *delta, unsigned long delta_size)\n {\n@@ -129,8 +130,8 @@ static void resolve_delta(const char *ty\n \t\t\t &result_size);\n \tif (!result)\n \t\tdie(\"failed to apply delta\");\n+\twrite_object(result, result_size, type, base_sha1, delta, delta_size);\n \tfree(delta);\n-\twrite_object(result, result_size, type);\n \tfree(result);\n }\n \n@@ -143,7 +144,7 @@ static void added_object(unsigned char *\n \t\tif (!hashcmp(info->base_sha1, sha1)) {\n \t\t\t*p = info->next;\n \t\t\tp = &delta_list;\n-\t\t\tresolve_delta(type, data, size, info->delta, info->size);\n+\t\t\tresolve_delta(type, sha1, data, size, info->delta, info->size);\n \t\t\tfree(info);\n \t\t\tcontinue;\n \t\t}\n@@ -164,7 +165,7 @@ static void unpack_non_delta_entry(enum \n \tdefault: die(\"bad type %d\", kind);\n \t}\n \tif (!dry_run && buf)\n-\t\twrite_object(buf, size, type);\n+\t\twrite_object(buf, size, type, NULL, NULL, 0);\n \tfree(buf);\n }\n \n@@ -197,7 +198,7 @@ static void unpack_delta_entry(unsigned \n \t\thas_errors = 1;\n \t\treturn;\n \t}\n-\tresolve_delta(type, base, base_size, delta_data, delta_size);\n+\tresolve_delta(type, base_sha1, base, base_size, delta_data, delta_size);\n \tfree(base);\n }\n \ndiff --git a/date.c b/date.c\nindex 1825922..0b06994 100644\n--- a/date.c\n+++ b/date.c\n@@ -657,6 +657,7 @@ static const struct typelen {\n \t{ \"hours\", 60*60 },\n \t{ \"days\", 24*60*60 },\n \t{ \"weeks\", 7*24*60*60 },\n+\t{ \"fortnights\", 2*7*24*60*60 },\n \t{ NULL }\n };\t\n \n\f\ncommit 636210e7fcceb7297ccf0fc54291bb1c8356f0d3\nAuthor: Linus Torvalds \nDate: Wed Oct 18 17:23:06 2006 -0700\n\n Make \"unpack-objects\" able to write a single pack-file instead\n \n This is idiotic. It writes everything undeltified, which is\n horrid. I need a brain.\n \n Signed-off-by: Linus Torvalds \n\ndiff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c\nindex bbb6e21..f139308 100644\n--- a/builtin-unpack-objects.c\n+++ b/builtin-unpack-objects.c\n@@ -7,11 +7,12 @@ #include \"blob.h\"\n #include \"commit.h\"\n #include \"tag.h\"\n #include \"tree.h\"\n+#include \"csum-file.h\"\n \n #include \n \n static int dry_run, quiet, recover, has_errors;\n-static const char unpack_usage[] = \"git-unpack-objects [-n] [-q] [-r] < pack-file\";\n+static const char unpack_usage[] = \"git-unpack-objects [-n] [-q] [-r] [--repack=pack-name] < pack-file\";\n \n /* We always read in 4kB chunks. */\n static unsigned char buffer[4096];\n@@ -87,6 +88,56 @@ static void *get_data(unsigned long size\n \treturn buf;\n }\n \n+static struct sha1file *pack_file;\n+static unsigned long pack_file_offset;\n+\n+struct index_entry {\n+\tunsigned long offset;\n+\tunsigned char sha1[20];\n+};\n+\n+static unsigned int index_nr, index_alloc;\n+static struct index_entry **index_array;\n+\n+static void add_pack_index(unsigned char *sha1)\n+{\n+\tstruct index_entry *entry;\n+\tint nr = index_nr;\n+\tif (nr >= index_alloc) {\n+\t\tindex_alloc = (index_alloc + 64) * 3 / 2;\n+\t\tindex_array = xrealloc(index_array, index_alloc * sizeof(*index_array));\n+\t}\n+\tentry = xmalloc(sizeof(*entry));\n+\tentry->offset = pack_file_offset;\n+\thashcpy(entry->sha1, sha1);\n+\tindex_array[nr++] = entry;\n+}\n+\n+static void write_pack_delta(const unsigned char *base, const void *delta, unsigned long delta_size)\n+{\n+\tunsigned char header[10];\n+\tunsigned hdrlen, datalen;\n+\n+\thdrlen = encode_header(OBJ_DELTA, delta_size, header);\n+\tsha1write(pack_file, header, hdrlen);\n+\tsha1write(pack_file, base, 20);\n+\tdatalen = sha1write_compressed(pack_file, delta, delta_size);\n+\n+\tpack_file_offset += hdrlen + 20 + datalen;\n+}\n+\n+static void write_pack_object(const char *type, const unsigned char *sha1, const void *buf, unsigned long size)\n+{\n+\tunsigned char header[10];\n+\tunsigned hdrlen, datalen;\n+\n+\thdrlen = encode_header(string_to_type(type, sha1), size, header);\n+\tsha1write(pack_file, header, hdrlen);\n+\tdatalen = sha1write_compressed(pack_file, buf, size);\n+\n+\tpack_file_offset += hdrlen + datalen;\n+}\n+\n struct delta_info {\n \tunsigned char base_sha1[20];\n \tunsigned long size;\n@@ -113,7 +164,16 @@ static void write_object(void *buf, unsi\n \tunsigned char *base, void *delta, unsigned long delta_size)\n {\n \tunsigned char sha1[20];\n-\tif (write_sha1_file(buf, size, type, sha1) < 0)\n+\n+\tif (pack_file) {\n+\t\tif (hash_sha1_file(buf, size, type, sha1) < 0)\n+\t\t\tdie(\"failed to compute object hash\");\n+\t\tadd_pack_index(sha1);\n+\t\tif (0 && base)\n+\t\t\twrite_pack_delta(base, delta, delta_size);\n+\t\telse\n+\t\t\twrite_pack_object(type, sha1, buf, size);\n+\t} else if (write_sha1_file(buf, size, type, sha1) < 0)\n \t\tdie(\"failed to write object\");\n \tadded_object(sha1, type, buf, size);\n }\n@@ -254,7 +314,7 @@ static void unpack_one(unsigned nr, unsi\n \t}\n }\n \n-static void unpack_all(void)\n+static void unpack_all(const char *repack)\n {\n \tint i;\n \tstruct pack_header *hdr = fill(sizeof(struct pack_header));\n@@ -266,17 +326,32 @@ static void unpack_all(void)\n \t\tdie(\"unknown pack file version %d\", ntohl(hdr->hdr_version));\n \tfprintf(stderr, \"Unpacking %d objects\\n\", nr_objects);\n \n+\tif (repack) {\n+\t\tstruct pack_header newhdr;\n+\t\tnewhdr.hdr_signature = htonl(PACK_SIGNATURE);\n+\t\tnewhdr.hdr_version = htonl(PACK_VERSION);\n+\t\tnewhdr.hdr_entries = htonl(nr_objects);\n+\t\t\n+\t\tpack_file = sha1create(\"%s.pack\", repack);\n+\t\tsha1write(pack_file, &newhdr, sizeof(newhdr));\n+\t\tpack_file_offset = sizeof(newhdr);\n+\t}\n+\t\t\n+\n \tuse(sizeof(struct pack_header));\n \tfor (i = 0; i < nr_objects; i++)\n \t\tunpack_one(i+1, nr_objects);\n \tif (delta_list)\n \t\tdie(\"unresolved deltas left after unpacking\");\n+\tif (repack)\n+\t\tsha1close(pack_file, NULL, 1);\n }\n \n int cmd_unpack_objects(int argc, const char **argv, const char *prefix)\n {\n \tint i;\n \tunsigned char sha1[20];\n+\tconst char *repack = NULL;\n \n \tgit_config(git_default_config);\n \n@@ -298,6 +373,10 @@ int cmd_unpack_objects(int argc, const c\n \t\t\t\trecover = 1;\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strncmp(arg, \"--repack=\", 9)) {\n+\t\t\t\trepack = arg + 9;\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tusage(unpack_usage);\n \t\t}\n \n@@ -305,7 +384,7 @@ int cmd_unpack_objects(int argc, const c\n \t\tusage(unpack_usage);\n \t}\n \tSHA1_Init(&ctx);\n-\tunpack_all();\n+\tunpack_all(repack);\n \tSHA1_Update(&ctx, buffer, offset);\n \tSHA1_Final(sha1, &ctx);\n \tif (hashcmp(fill(20), sha1))\n"},{"id":"29196","messageId":"4536DBB1.6050701@spamcop.net","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610190144450.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Charles Duffy","fromEmail":"cduffy@spamcop.net","sentAt":"2006-10-19T01:58:09Z","receivedAt":"2006-10-19T01:58:09Z","isPatch":false,"sender":{"key":"cduffy@spamcop.net","avatar":null},"body":"Johannes Schindelin wrote:\n> So, the wonderful upside of plugins you described here are actually the \n> reason I will never, _never_ use bzr with plugins.\n> \n\nI presume that for this reason you will also never, _never_ use a \nnon-mainline branch of git -- even if its actual code only touches UI \nenhancements or something similarly non-core -- because third-party \nbranches have the ability, in theory, to make changes to the core of the \nrevision control system. And that you will never, _never_ use \nthird-party wrappers because they might play LD_PRELOAD tricks. Or run \nany software with root privileges you haven't personally written. Or...\n\nSean's point that plugins are a comparatively minor win made inexpensive \non account of bzr's use of Python is reasonable (though we may choose to \ndiffer on what level of value we attach to the utility). The claim that \nan extensibility mechanism should be rejected wholesale on account of \nbeing excessively powerful, on the other hand, is just silly.\n\n\n\n(If you couldn't write a plugin that *didn't* touch the core, this would \nbe a different story. This is, however, very much not the case).\n"},{"id":"29197","messageId":"Pine.LNX.4.64.0610182234070.1971@xanadu.home","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181655430.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-10-19T03:01:52Z","receivedAt":"2006-10-19T03:01:52Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 18 Oct 2006, Linus Torvalds wrote:\n\n> \n> \n> On Wed, 18 Oct 2006, Nicolas Pitre wrote:\n> > \n> > If you use builtin-unpack-objects.c from next, you'll be able to \n> > generate the pack index pretty easily as well, as all the needed info is \n> > stored in the obj_list array. Just need to append objects remaining on \n> > the delta_list array to the end of the pack, sort the obj_list by sha1 \n> > and write the index.\n> \n> Actually, I've hit an impasse.\n> \n> The index isn't the problem. The problem is actually writing the resultant \n> pack-file itself in one go.\n> \n> The silly thing is, the pack-file contains the number of entries in the \n> header. That's a silly problem, because the _natural_ way to turn a thin \n> pack into a normal pack would be to just add the missing objects from the \n> local store into the resulting pack. But we don't _know_ how many such \n> missing objects there are, until we've gone through the whole source pack. \n> \n> So you can't easily do a streaming \"write the result as you go along\" \n> version using that approach.\n\nHmmm.... unpack-objects receives a (possibly thin) pack over its stdin. \nThat part has to be streamed. But its output is currently always \nwritten to multiple files as separate objects. So, while the input \ncomes from a stream, the output doesn't have to.\n\nIn that case, why not just write the input directly to a temporary file, \nappend the missing objects, seek back to adjust the object number, and \nfinally run a SHA1_Update() on the whole thing? This forces you to \nwrite everything and then read everything back, but this should not be \ntoo bad especially that the written data is likely to still be cached. \nOnce its final sha1sum is written then it just need to be moved with the \nappropriate name.\n\n> So there's _another_ way of fixing a thin pack: it's to expand the objects \n> without a base into non-delta objects, and keeping the number of objects \n> in the pack the same. But _again_, we don't actually know which ones to \n> expand until it's too late.\n> \n> The end result? I can expand them all (I have a patch that does that). Or \n> I could leave as deltas the ones I have already seen the base for in the \n> pack-file (I don't have that yet, but that should be a SMOP). But I'm not \n> very happy with even the latter choice, because it really potentially \n> expands things that didn't _need_ expansion, they just got expanded \n> because we hadn't seen the base object yet.\n\nMost base objects, well all of them nowadays, are written before their \ndeltas. So in practice the only objects that will get expanded are the \ndeltas with missing base. Still it is unfortunate.\n\n> So I'll happily send my patches to anybody who wants to try (I don't write \n> the index file yet, but it should be easy to add), but I'm getting the \n> feeling that \"builtin-unpack-objects.c\" is the wrong tool to use for this, \n> because it's very much designed for streaming.\n> \n> It would probably be better to start from \"index-pack.c\" instead, which is \n> already a multi-pass thing, and wouldn't have had any of the problems I \n> hit. \n\nBut index-pack is totally incompatible with any streaming. It mmap() \nthe whole pack and happily perform random accesses. So you'd need to \nwrite the entire thin pack to disk anyway before it could work on it. \nThis is not really better than the unpack-objects option. At least \nunpack-objects is structured to perform work on the fly as data is \nreceived.\n\n> Gaah.\n> \n> > Pretty trivial indeed.\n> \n> So it's conceptually totally trivial to rewrite a pack-file as another \n> pack-file, but at least so far, it's turned out to be less trivial in \n> practice (or at least in a single pass, without holding everything in \n> memory, which I definitely do _not_ want to do).\n> \n> So I'm leaving this for today, and perhaps coming back to it tomorrow with \n> a fresh eye.\n\nI'll have a look at your patches tomorrow as well. I have many ideas \nbrewing, including randering index-pack obsolete since actually \nunpack-objects could do it all already (both tools have many concepts in \ncommon).\n\n\nNicolas\n"},{"id":"29199","messageId":"4536EC93.9050305@utoronto.ca","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610172014250.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-19T03:10:11Z","receivedAt":"2006-10-19T03:10:11Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nLinus Torvalds wrote:\n\n> For example, what happens is that:\n> - you like the simple revision numbers\n> - that in turn means that you can never allow a mainline-merge to be done \n> by anybody else than the main maintainer\n\nThat's not true of bzr development. The \"main maintainer\" that runs the\nbzr.dev is an email bot. It's not an integrator-- its work is purely\nmechanical. It can't resolve merge conflicts.\n\nMost of the merge work is done in integration branches run by the core\ndevelopers. Although Martin is our project leader, lays out ground\nrules, and makes design decisions, he doesn't have to be involved in any\nparticular merge.\n\n> The \"main trunk matters\" mentality (which has deep roots in CVS - don't \n> get me wrong, I don't think you're the first one to do this) is \n> fundamentally antithetical to truly distributed system, because it \n> basically assumes that some maintainer is \"more important\" than others. \n\nLinus, if you got hit by a bus, it would still be a shock, and it would\nstill take time for the Linux world to recover. Your insights and\ntalent, both technical and social, make you the most important kernel\ndeveloper. And it stays that way because you deserve it. Projects with\ngood leadership don't fork, or if they do, the fork withers and dies\npretty quickly.\n\nIt is fine to say all branches are equal from a technical perspective.\n- From a social perspective, it's just not true.\n\nThe scale of Bazaar development is much smaller than the scale of kernel\ndevelopment, so it doesn't make sense to maintain long-term divergent\nbranches like the mm tree. We do occasionally have long-lived feature\nbranches, though.\n\n> That special maintainer is the maintainer whose merge-trunk is followed, \n> and whose revision numbers don't change when they are merged back.\n\nIn bzr development, it's very rare for anyone's revision numbers to change.\n\n> That may even be _true_ in many cases. But please do realize that it's a \n> real issue, and that it has real impact - it does two things:\n> \n> - it impacts the technology and workflow directly itself: \"pull\" and \n> \"merge\" are different: a central maintainer would tend to do a \"merge\", \n> and one more in the outskirts would tend to do more of a \"pull\", \n> expecting his work to then be merged back to the \"trunk\" at some later \n> point)\n\nAFAIK, everyone who maintains long-lived branches in bzr uses \"merge\".\n\n> - it will result in _psychological_ damage, in the sense that there's \n> always one group that is the \"trunk\" group, and while you can pass the \n> baton around (like the perl people do), it's always clear who sits \n> centrally.\n\nAs I mentioned earlier, there are four people who each run their own\nintegration branches and make decisions about what gets merged. No baton.\n\n> \n> Maybe this is fine. It's certainly how most projects tend to work. \n> \n> I'll just point out that one of my design goals for git was to make every \n> single repository 100% equal. That means that there MUST NOT be a \"trunk\", \n> or a special line of development. There is no \"vendor branch\".\n\nI think you're implying that on a technical level, bzr doesn't support\nthis. But it does. Every published repository has unique identifiers\nfor every revision on its mainline, and it's exceedingly uncommon for\nthese to change. There are special procedures to maintain bzr.dev, but\nthere's nothing technically unique about it. People develop against\nbzr.dev rather than my integration branch, because they have\nnon-technical reasons for wanting their changes to be merged into\nbzr.dev, not my integration branch.\n\n> It's \n> something that a lot of people on the git lists understand now, but it \n> took a while for it to sink in - people used to believe that the \"first \n> parent\" of a merge was somehow special, and I had to point out several \n> times on the git list that no, that's not how it works - because the merge \n> might have been done by somebody _else_ than the person who you think of \n> as being \"on the trunk\".\n\nOn an actively-developed bzr branch, the first parent *is* special:\n- - it's a revision that you committed\n- - the diff between a revision and its first parent is the same as the\n diff that would be produced just before it was committed.\n\n> So when I say that your \"simple\" revision numbers are totally broken and \n> horrible, I say that not because I think a number like \"1.45.3.17\" is \n> ugly, but because I think that the deeper _implications_ of using a number \n> like that is ugly. It implies one of two things:\n> \n> - the numbers change all the time as things get merged both ways\n> \n> OR\n> \n> - people try to maintain a \"trunk\" mentality\n\nI don't think your analysis holds together completely, because all\nactively-maintained branches have very stable revnos that anyone can\nrefer to.\n\n> In git, the fact that everybody is on an equal footing is something that I \n> think is really good. For example, when I was away for effectively three \n> weeks during August, all the git-level merging for the kernel was done by \n> Greg KH.\n> \n> And realize that he didn't use \"my tree\". No baton was passed. I emailed \n> with him (and some others) before-hand, so that everybody knew that I \n> expected to be just pull from Greg when I came back, but it was _his_ tree \n> that he merged in, and he just worked the same way I did.\n>\n> And when I did come back, I did a \"pull\" from his tree.\n\nThat sounds to me like a baton was passed. You asked Greg to behave\nlike you, and told everyone else to expect that, too. Passing the baton\nwas a social, not technical event, but it did happen. And there would\ncertainly be no difficulty doing exactly that (right down to running\n\"pull\") in Bazaar land.\n\nIn fact, we are currently rotating release managers. The 0.10 and 0.11\nreleases were done by Robert, and the upcoming 0.12 is being managed by\nJohn. Neither of them is the project leader. They threaten that they\nwant me to manage a release, too. We shall see...\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFNuyT0F+nu1YWqI0RAjxSAJ9YulgRMmIuy9RS1xrrYnKl9x2arQCaAr5/\nu56sojZb6jhKl3fMQ/ZxLf4=\n=EYC+\n-----END PGP SIGNATURE-----\n"},{"id":"29200","messageId":"7vac3tx900.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610181655430.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-19T03:46:55Z","receivedAt":"2006-10-19T03:46:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Actually, I've hit an impasse.\n>\n> So there's _another_ way of fixing a thin pack: it's to expand the objects \n> without a base into non-delta objects, and keeping the number of objects \n> in the pack the same. But _again_, we don't actually know which ones to \n> expand until it's too late.\n\npack-objects.c::write_one() makes sure that we write out base\nimmediately after delta if we haven't written out its base yet,\nso I suspect if you buffer one delta you should be Ok, no?\n"},{"id":"29205","messageId":"87lkncev90.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"4536EC93.9050305@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-19T05:21:15Z","receivedAt":"2006-10-19T05:21:15Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 18 Oct 2006 23:10:11 -0400, Aaron Bentley wrote:\n> It is fine to say all branches are equal from a technical perspective.\n> - From a social perspective, it's just not true.\n\nThat's actually a very important insight, but supporting the wrong\nconclusion.\n\nIn a healthy situation, the only thing that makes a branch special are\nsocial issues, such as you describe. That's how it should be.\n\nBut think about your favorite example of an unhealthy social situation\naround a software project and a big, nasty fork. Every example I can\nthink of involves some technical distinction that makes one branch\nmore special than another.\n\nNow, those situations also involve social problems, and those are even\nmore significant. But the technical blessing of one branch does not\nhelp. And I think it contributes to the social problems in many cases.\n\nSo, I think the technical thing that is distributed version control is\nan extremely important thing for us to use to help maintain healthy\nsocial software projects. Reducing the technical hurdle of a fork, (to\nwhere continual forking is actually a totally expected part of the\nprocess), is a very healthy thing.\n\nNow, both bzr and git are distributed systems, and either one will\nhelp a great deal in the respects I'm talking about compared to\nsomething like cvs.\n\nAs far as the revision numbers, my impression is that the numbers\nwould be confusing or worthless if I were to use bzr the way I'm\ncurrently using git, as they certainly could not remain stable.\n\n> In bzr development, it's very rare for anyone's revision numbers to change.\n\nWhich just says to me that the bzr developers really are sticking to a\ncentralized model. That's fine, but it does have impacts, and the tool\nreally does seem to have some bias toward this.\n\n> I think you're implying that on a technical level, bzr doesn't support\n> this. But it does. Every published repository has unique identifiers\n> for every revision on its mainline, and it's exceedingly uncommon for\n> these to change.\n\nEvery argument you make for the number change being uncommon just\nstrengthens the argument that it will be all that more\nconfusing/frustrating when the numbers do change.\n\nIn cairo, for example, we've made a habit of including a revision\nidentifier in our bug tracking system for every commit that resolves a\nbug. I like having the assurance that those numbers will survive\nforever. And it doesn't matter if the repository moves, or the project\nis forked, or anything else. Those numbers cannot change.\n\nI understand that bzr also has unique identifiers, but it sounds like\nthe tools try to hide them, and people aren't in the habit of using\nthem for things like this. Do bzr developers put revision numbers in\ntheir bug trackers? Is there a guarantee they will always be valid?\n\n-Carl\n"},{"id":"29206","messageId":"20061019053355.GA9403@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"4536EC93.9050305@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-19T05:33:55Z","receivedAt":"2006-10-19T05:33:55Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Oct 18, 2006 at 11:10:11PM -0400, Aaron Bentley wrote:\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> Linus Torvalds wrote:\n> \n> > For example, what happens is that:\n> > - you like the simple revision numbers\n> > - that in turn means that you can never allow a mainline-merge to be done \n> > by anybody else than the main maintainer\n> \n> That's not true of bzr development. The \"main maintainer\" that runs the\n> bzr.dev is an email bot. It's not an integrator-- its work is purely\n> mechanical. It can't resolve merge conflicts.\n\nThe point here is, that because of using the bot, the revnos on bzr.dev\nare indeed stable (and many of the merges are in fact pointless merges\n(ie. merges of revision and it's ancestor)). But if you don't use the\nbot, than doing:\n\nbzr merge mainline\nbzr push mainline\n\nmakes your revision the leftmost parent is your revison, not the one\nfrom \"mainline\". The fact that bzr treats leftmost parent somewhat\nspecially makes people to replace the above with\n\nbzr branch mainline\ncd mainline\nbzr merge feature-branch\nbzr push\n\nwhich is, well, more complicated (but you see it's not about main\nmaintainer -- anybody with write access can push).\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29207","messageId":"20061019054556.GB9403@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"eh68va$7er$1@sea.gmane.org","subject":"Re: Alternate revno proposal (Was: Re: VCS comparison table)","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-19T05:45:56Z","receivedAt":"2006-10-19T05:45:56Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Thu, Oct 19, 2006 at 12:14:02AM +0200, Jakub Narebski wrote:\n> Jan Hudec wrote:\n> > Comments?\n> \n> What about fetching from repository? For revnos you have to assign revno for\n> all commit you have downloaded; now you need only to unpack received pack\n> (or not, if you used --keep option). More work.\n\nI don't know git internals, so I can't tell for git. For bzr:\n1) You have to add the data to the knits, since the knits are one for\n each versioned file plus one for inventory and one for revision\n metadata, so this is just a small addition to that work. In fact the\n revnos in repository-wide case would be just the indices into the\n revisions knit (while in the branch-wide there would have to be a\n special list).\n2) Bzr already generates a special list, revision-history, where it\n stores a list of mainline branches (in fact it used to store a list\n of local commits, but now lists the path over leftmost parents).\n So it already does the work.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29208","messageId":"20061019055626.GK18052@sourcefrog.net","threadId":"5925","inReplyTo":"87lkncev90.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Martin Pool","fromEmail":"mbp@sourcefrog.net","sentAt":"2006-10-19T05:56:35Z","receivedAt":"2006-10-19T05:56:35Z","isPatch":false,"sender":{"key":"mbp@sourcefrog.net","avatar":null},"body":"On 18 Oct 2006, Carl Worth wrote:\n\n> I understand that bzr also has unique identifiers, but it sounds like\n> the tools try to hide them, and people aren't in the habit of using\n> them for things like this. Do bzr developers put revision numbers in\n> their bug trackers? Is there a guarantee they will always be valid?\n\nThere is a mix of \n\n - Just giving the overall tarball version number, which is most \n meaningful to users (and not related to bzr versions)\n\n - Giving a mainline revision number, which will never revert because we\n never pull (fast-forward) that branch. That has the substantial\n (imo) benefit that you can immediately compare these numbers by eye,\n and they are easy to quote.\n\n - Giving a unique id, which is obviously most definitive and\n appropriate if you're talking about something which is not \n on the mainline or a well known branch. The launchpad.net \n bug tracker links branches to bugs and does this through \n revision ids.\n\n-- \nMartin\n"},{"id":"29211","messageId":"eh76np$trg$1@sea.gmane.org","threadId":"5925","inReplyTo":"20061018185225.GU20017@pasky.or.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Alexander Belchenko","fromEmail":"bialix@ukr.net","sentAt":"2006-10-19T06:46:32Z","receivedAt":"2006-10-19T06:46:32Z","isPatch":false,"sender":{"key":"bialix@ukr.net","avatar":null},"body":"Petr Baudis пишет:\n...\n> An example bundle is available at\n> \n> \thttp://pasky.or.cz/~pasky/cp/example-bundle.txt\n\nYou probably miss main idea of bzr bundles. It's not just the way to\nsend via e-mail or other appropriate transport the part of repository.\nIt primarily was designed to be human readable as usual diff (i.e.\npatch). It was designed to solve 2 thing simultaneously:\n\n- be informative for human as usual patch\n- be consistent for machine.\n\n--\nAlexander\n"},{"id":"29212","messageId":"845b6e870610190002u420118b8ud634bb9594572c48@mail.gmail.com","threadId":"5925","inReplyTo":"4536EC93.9050305@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-19T07:02:16Z","receivedAt":"2006-10-19T07:02:16Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"> > In git, the fact that everybody is on an equal footing is something that I\n> > think is really good. For example, when I was away for effectively three\n> > weeks during August, all the git-level merging for the kernel was done by\n> > Greg KH.\n> >\n> > And realize that he didn't use \"my tree\". No baton was passed. I emailed\n> > with him (and some others) before-hand, so that everybody knew that I\n> > expected to be just pull from Greg when I came back, but it was _his_ tree\n> > that he merged in, and he just worked the same way I did.\n> >\n> > And when I did come back, I did a \"pull\" from his tree.\n>\n> That sounds to me like a baton was passed. You asked Greg to behave\n> like you, and told everyone else to expect that, too. Passing the baton\n> was a social, not technical event, but it did happen. And there would\n> certainly be no difficulty doing exactly that (right down to running\n> \"pull\") in Bazaar land.\n\n\nI'd like to point out that the same thing has happened in bzr-land.\nBack in the \"pre-bot\" days, only Martin did put things in \"his branch\"\nwhere most people got bzr from (same as Linus' git branch), but he was\naway for a few weeks and during this time, there was 3 (or 4 perhaps)\nother branches, called integration branches, that was being used.\nThey were all maintained by different people.\n\nEveryone learned really quickly to use them instead of Martin's\nbranch. When Martin came back, he just pulled/merged these branches\nand everything was back to normal.\n\nI'd say in this case, bzr was even more \"without a trunk\" then in the\nexample Linus gives above.\n\nWhat seams to be one interesting thing in this discussion is that,\nbecause people use bzr and git in slightly different ways, they think\nthat one or the other cannot be used in another way.\n\nbzr's use of revision numbers, doesn't mean it hasn't got unique\nrevision identifiers, and I can't see any reason why it couldn't be\nused in the same way as git. Both are excellent tools, and since git\nis more specialized (built to support the exact workflow used in\nkernel development), it's more suited for that exact use.\n\nbzr tries to take a broader view, for example, it does support a\ncentralized workflow if you want one. Most people don't, but a few\nmight. Because of this, it probably fits the kernel development less\ngood than git. That's fine I think! I happens to fit my workflow\nbetter than git does :)\n\nRegards,\nErik\n"},{"id":"29213","messageId":"eh7c5t$gd1$1@sea.gmane.org","threadId":"5925","inReplyTo":"20061018214623.GA32725@artax.karlin.mff.cuni.cz","subject":"Re: Alternate revno proposal (Was: Re: VCS comparison table)","fromName":"Alexander Belchenko","fromEmail":"bialix@ukr.net","sentAt":"2006-10-19T08:19:30Z","receivedAt":"2006-10-19T08:19:30Z","isPatch":false,"sender":{"key":"bialix@ukr.net","avatar":null},"body":"Jan Hudec пишет:\n...\n> \n> Reading this thread I came to think, that the revnos should be assigned\n> to _all_ revisions _available_, in order of when they entered the\n> repository (there are some possible variations I will mention below)\n> \n...\n> - They would be the same as subversion and svk, and IIRC mercurial as\n> well, use, so:\n> - They would already be familiar to users comming from those systems.\n> - They are known to be useful that way. In fact for svk it's the only\n> way to refer to revisions and seem to work satisfactorily (though\n> note that svk is not really suitable to ad-hoc topologies).\n\nI think that SVN model of revision numbers is wrong. And apply it to bzr\nbreak many UI habits. Per example, when ones use svn and their repo has\nmany branches you never could say what revisions belongs to mainline. So\nthings like\nbzr diff -rM..N\n(where M and N absolute revisions numbers, and N = M+1(+2) etc.)\nwill more complicated, because in this case you first need to run log\ncommand, remember actual numbers of those revisions.\nAnd I each time frustrating to see that after mainline svn revision 1000\nmight be mainline revision 1020. It's very-very-very confusing. May be\nonly for me.\n\nThere is 2 things why I don't want to switch to svn (if I can do my own\nchoice): their strange tags implementation (their tags is the same as\nbranches, so what difference?) and their revisions numbers.\n\nI also think that dotted revisions is not answer in this case, but it\nlooks very logical and nice.\n\nI think bzr need to have a switch, a flag, probably in .bazaar.conf to\nshow revno to user or revid. And user can easily select what model is\nmore appropriate for him:\n\n* decentralized (with revno)\n* or distrubuted (with revid i.e. UUID)\n\n> Comments?\n\n-1 to make revno as in svn.\n\n--\nAlexander\n"},{"id":"29215","messageId":"46d6db660610190149x32442596we4112cdd044185a@mail.gmail.com","threadId":"5925","inReplyTo":"845b6e870610190002u420118b8ud634bb9594572c48@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2006-10-19T08:49:28Z","receivedAt":"2006-10-19T08:49:28Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"close to 200 post on bzr-git war!\nis this the right place (git mailing list) to discuss about future\nfeatures of bzr ?\n\n-- \nChristian\n"},{"id":"29216","messageId":"45373E27.3050209@op5.se","threadId":"5925","inReplyTo":"46d6db660610190149x32442596we4112cdd044185a@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-19T08:58:15Z","receivedAt":"2006-10-19T08:58:15Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Christian MICHON wrote:\n> close to 200 post on bzr-git war!\n> is this the right place (git mailing list) to discuss about future\n> features of bzr ?\n> \n\nPerhaps not, but the tone is friendly (mostly), the patience of the \nbazaar people seems infinite and lots of people seem to be having fun \nwhile at the same time learning a thing or two about a different SCM.\nBest case scenario, both git and bazaar come out of the discussion as \nbetter tools. If there would never be any cross-pollination, git \nwouldn't have half the features it has today.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"29218","messageId":"vpqwt6wsmb5.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"45373E27.3050209@op5.se","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-19T09:10:38Z","receivedAt":"2006-10-19T09:10:38Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Andreas Ericsson writes:\n\n> Perhaps not, but the tone is friendly (mostly), the patience of the\n> bazaar people seems infinite and lots of people seem to be having fun\n> while at the same time learning a thing or two about a different SCM.\n> Best case scenario, both git and bazaar come out of the discussion as\n> better tools. If there would never be any cross-pollination, git\n> wouldn't have half the features it has today.\n\nI second this.\n\nI'm bzr user and occasionnal developper, and I learnt a lot about git\nin the discussion. I hope I also could explain well some of the\nfeatures of bzr to some git guys, it's always interesting to\nunderstand why other people do things on a different way, or why they\ndo it in the same way.\n\n-- \nMatthieu\n"},{"id":"29217","messageId":"20061019091045.GV75501@over-yonder.net","threadId":"5925","inReplyTo":"87y7rdd47j.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-19T09:10:45Z","receivedAt":"2006-10-19T09:10:45Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Wed, Oct 18, 2006 at 08:38:24AM -0700 I heard the voice of\nCarl Worth, and lo! it spake thus:\n> \n> But as you already said, it's often avoided specifically because it\n> destroys locally-created revision numbers.\n\nI think this has the causality backward. It's avoided because it\nchanges the ancestry of the branch in question, by rearranging the\nleft parents; this ties into Linus' assertion that all parents ought\nto be treated equally, which I'm beginning to think is the base\nlynchpin of this whole dissension.\n\n\nWithout a differentiation of the parents, there's no such creature as\na \"mainline\" on a branch, so it's hard to find anything to base revnos\non from the get-go; the whole discussion becomes meaningless and\nincomprehensible then.\n\nWith the differentiation, numbering along the leftmost 'mainline'\nmakes sense, and fits the way people tend to work. \"I did this, then\nI did this, then I merged in Joe's stuff, then I did this\", and the\nnumbering follows along that. And as long as it's the same branch,\nthose revnos will always be the same; I can't go back and add\nsomething in between my first and second commits. THAT'S where revnos\nare useful; referring to a point on given branch.\n\n\nCertainly, they're of no (or extremely limited) use when referring to\n_different_ branches. And when you change the arrangement of parents\non a branch, you create a different branch. That's why bzr (the\nproject, not the program) tends toward trunks that are merged into,\nrather than ephemeral trunks that are merged from and then replaced\nwith the new trunk, and has its UI optimized by default for that case;\nbecause the ordering of the parents IS considered important and to be\npreserved. Ancestry changes aren't avoided because it would screw up\nthe revnos; the revnos don't get screwed up because the ancestry\nchanges are avoided for their OWN sake, and it's BECAUSE of that\npre-existing tendancy that the revnos could come into being in the\nfirst place.\n\n\nIf you need to refer to a specific revision in a vacuum, a revno is\nthe *WRONG* tool for the job. Revnos exist to refer to points along a\nbranch. And in cases where there's a meaningful persistent branch, as\nhappens in most projects which have a trunk in some sense or another,\nthey can be the right tool for referring to points along that.\n\n\n> So there are some aspects of the bzr design that rob from its\n> ability to function as a distributed version control system. It\n> really does bias itself toward centralization, (the so called \"star\n> topoloogy\" as opposed to something \"fully\" distributed).\n\nThat depends on what you mean by 'bias' (and for that matter, what you\nmean by 'centralization'; I think that's being used in very different\nways here). If you don't care about the ancestry changes, you can go\nahead and change it around by merging and pushing like there's no\ntomorrow, and it'll keep up just fine. Some attributes of it like the\nrevnos which assume you do care about the ancestry simply cease to be\nof any applicability. That doesn't make it a useless feature, any\nmore than diff being inapplicable in a branch I'm using to store\nbinary files makes diff useless; it's just not one that's meaningful\nin a given case.\n\nbzr (the project) does care about the ordering of the parents, so it\ndoesn't do that. bzr (the tool) assumes that the majority of its\nusers will care, which is why it has revnos; because in the case where\nyou don't disturb the ancestry of given branches, revnos are very\nuseful in reference to that branch.\n\n\n> So even a project that's very oriented around a single, central tree\n> can get a lot of benefit from being able to share things arbitrarily\n> between any two given repositories.\n\nI agree wholeheartedly. That's one of the reasons I'm using bzr, even\nthough 95% or better of what I do is very oriented around single,\ncentral trees, after all 8-}\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29219","messageId":"BAYC1-PASMTP061F10D0B5AF9F6608134CAE0C0@CEZ.ICE","threadId":"5925","inReplyTo":"eh76np$trg$1@sea.gmane.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-19T10:40:49Z","receivedAt":"2006-10-19T10:40:49Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 19 Oct 2006 09:46:32 +0300\nAlexander Belchenko wrote:\n\n> You probably miss main idea of bzr bundles. It's not just the way to\n> send via e-mail or other appropriate transport the part of repository.\n> It primarily was designed to be human readable as usual diff (i.e.\n> patch). It was designed to solve 2 thing simultaneously:\n> \n> - be informative for human as usual patch\n> - be consistent for machine.\n\nPetr already mentioned that the data currently shown in the email\ntext isn't really useful. But it's simple to make it an attachment\nand show a combined diff instead.\n\nAlthough that might just make the email bigger for not a lot of\ngain. It's easy to use the git command line and gui tools to inspect\nthe bundle after importing it into your repository. And just as\neasy to expunge the bundle afterward if it isn't up to grade.\n\nSean\n"},{"id":"29310","messageId":"20061019064049.bec89582.seanlkml__16460.7259365313$1161335321$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"eh76np$trg$1@sea.gmane.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-19T10:40:49Z","receivedAt":"2006-10-19T10:40:49Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 19 Oct 2006 09:46:32 +0300\nAlexander Belchenko wrote:\n\n> You probably miss main idea of bzr bundles. It's not just the way to\n> send via e-mail or other appropriate transport the part of repository.\n> It primarily was designed to be human readable as usual diff (i.e.\n> patch). It was designed to solve 2 thing simultaneously:\n> \n> - be informative for human as usual patch\n> - be consistent for machine.\n\nPetr already mentioned that the data currently shown in the email\ntext isn't really useful. But it's simple to make it an attachment\nand show a combined diff instead.\n\nAlthough that might just make the email bigger for not a lot of\ngain. It's easy to use the git command line and gui tools to inspect\nthe bundle after importing it into your repository. And just as\neasy to expunge the bundle afterward if it isn't up to grade.\n\nSean\n"},{"id":"29220","messageId":"Pine.LNX.4.63.0610191250400.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"4536DBB1.6050701@spamcop.net","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-19T11:01:49Z","receivedAt":"2006-10-19T11:01:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 18 Oct 2006, Charles Duffy wrote:\n\n> Johannes Schindelin wrote:\n\nyou neatly clipped the most important part of my email: I quoted you \nsaying that plugins can even change core behaviour!\n\n> > So, the wonderful upside of plugins you described here are actually the\n> > reason I will never, _never_ use bzr with plugins.\n> > \n> \n> I presume that for this reason you will also never, _never_ use a \n> non-mainline branch of git -- even if its actual code only touches UI \n> enhancements or something similarly non-core\n\nNO! The point was that I will not gladly run anything which could change \nthe core. If I know it touches only the UI, there is no problem.\n\nIf I get a shell script using git-core programs to do its job, I \n_know_ that my repository will not be fscked afterwards.\n\nAnd _that_ was the whole point of my email.\n\n> And that you will never, _never_ use third-party wrappers because they \n> might play LD_PRELOAD tricks. Or run any software with root privileges \n> you haven't personally written. Or...\n\nMost of it comes down to trust. And yes, you are correct, I will not run \ngit with some obscure module LD_PRELOADed that some guy from some planet \nsent me.\n\nYou might have missed my argument being about the SCM, and not the \nuniverse and all the rest.\n\n> The claim that an extensibility mechanism should be rejected wholesale \n> on account of being excessively powerful, on the other hand, is just \n> silly.\n\nOh, but NO! An extensibility mechanism which allows for a fragile system \n_is_ silly. Not my rejection of it.\n\nJust take an example (illustrating that once again, one should not \nattribute everything to malevolence...): I write a plugin for bzr. It does \nreally wonderful things, it even cooks you dinner.\n\nOnly that I happened to make a small mistake (if you followed some threads \non the git list, you'd know that small mistakes are a hobby of mine), and \nby this mistake, your repository is ... gone. Small mistake, big \nconsequence. That is wrong with such a powerful system which caters for \ndevelopers, which are human after all.\n\nNote that such a small mistake would be much more likely caught in git: if \nit touches the core, plenty of eyes look at it.\n\nCiao,\nDscho\n"},{"id":"29221","messageId":"45375D16.90204@spamcop.net","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610191250400.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Charles Duffy","fromEmail":"cduffy@spamcop.net","sentAt":"2006-10-19T11:10:14Z","receivedAt":"2006-10-19T11:10:14Z","isPatch":false,"sender":{"key":"cduffy@spamcop.net","avatar":null},"body":"Johannes Schindelin wrote:\n>> I presume that for this reason you will also never, _never_ use a \n>> non-mainline branch of git -- even if its actual code only touches UI \n>> enhancements or something similarly non-core\n>> \n>\n> NO! The point was that I will not gladly run anything which could change \n> the core. If I know it touches only the UI, there is no problem.\n> \n\nIf you're willing to look at the source of a branch to know that it \ntouches only the UI, why would you not be willing to look at the source \nof a plugin to do the same thing?\n\n> If I get a shell script using git-core programs to do its job, I \n> _know_ that my repository will not be fscked afterwards.\n>\n> And _that_ was the whole point of my email.\n> \n\nIt's a silly point. If you're willing to look at what your shell script \ndoes and validate that it doesn't do LD_PRELOAD tricks or swap out git \ncore pieces, why wouldn't you be willing to accept a plugin after a \nsimilar level of review, rather than stating outright that you would \n*never* use them?\n\n>> The claim that an extensibility mechanism should be rejected wholesale \n>> on account of being excessively powerful, on the other hand, is just \n>> silly.\n>> \n>\n> Oh, but NO! An extensibility mechanism which allows for a fragile system \n> _is_ silly. Not my rejection of it.\n> \n\nShell scripts allow for a fragile system because they could include C \ncode snippets which they then compile and LD_PRELOAD. Sure, they \"allow \nfor\" a fragile system -- but the author has to go out of their way to \nmake it so. Similarly, folks writing bzr plugins need to take explicit \nactions to monkeypatch existing code (as opposed to adding a new \ntransport/storage format/command/etc but leaving the old ones alone).\n\nIf you trust the author of your shell script not to build their own \nLD_PRELOAD at runtime, why don't you trust the author of your bzr plugin \nnot to monkeypatch in replacements to core code if they say they aren't?\n"},{"id":"29222","messageId":"45375E56.4090106@op5.se","threadId":"5925","inReplyTo":"20061019091045.GV75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-19T11:15:34Z","receivedAt":"2006-10-19T11:15:34Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthew D. Fuller wrote:\n> On Wed, Oct 18, 2006 at 08:38:24AM -0700 I heard the voice of\n> Carl Worth, and lo! it spake thus:\n>> But as you already said, it's often avoided specifically because it\n>> destroys locally-created revision numbers.\n> \n> I think this has the causality backward. It's avoided because it\n> changes the ancestry of the branch in question, by rearranging the\n> left parents; this ties into Linus' assertion that all parents ought\n> to be treated equally, which I'm beginning to think is the base\n> lynchpin of this whole dissension.\n> \n> \n> Without a differentiation of the parents, there's no such creature as\n> a \"mainline\" on a branch, so it's hard to find anything to base revnos\n> on from the get-go; the whole discussion becomes meaningless and\n> incomprehensible then.\n> \n> With the differentiation, numbering along the leftmost 'mainline'\n\n\nYou, and others, keep saying \"leftmost\". What on earth does left or \nright have to do with anything? Or rather, how do you determine which \nside anything at all is on?\n\n> makes sense, and fits the way people tend to work. \"I did this, then\n> I did this, then I merged in Joe's stuff, then I did this\", and the\n> numbering follows along that. And as long as it's the same branch,\n> those revnos will always be the same; I can't go back and add\n> something in between my first and second commits. THAT'S where revnos\n> are useful; referring to a point on given branch.\n> \n\nSo long as the given branch is, in git-speak, \"master\"? I think I'm \nstarting to see how this would work, but I still fail to see how you can \nthen come up with revnos such as 2343.1.14.7.19, since the only ones \nthat seem to actually make any sense are the ones that track the \nstrictly linear development.\n\nIn git, this can be accomplished by auto-tagging each update of any \nbranch with a tag named numerically and incrementally, although no-one \nreally bothers with it.\n\nLet's say you have the following graph, where A is the root commit, B \nintroduces the base for a couple of new features that three separate \ncoders start to work on in their own repositories. The feature started \non in D is logically coded as a two-stage change. F fixes a bug \nintroduced in D. I is the result of an octopus merge of all three \nbranches, where the three features are implemented and all bugs are \nfixed (this is btw by far the most common pattern we have in our repos \nhere at work).\n\n A\n |\n B\n /|\\\nC | D\n| | |\\\n| | E F\n| | |/\n| | G\n| H /\n \\|/\n I\n\nNow a couple of questions arise.\n- How do I do to get to C, D, E, F, G and H?\n- When these get merged, which one will be considered the \"left\" parent, \nand why?\n\n> \n>> So there are some aspects of the bzr design that rob from its\n>> ability to function as a distributed version control system. It\n>> really does bias itself toward centralization, (the so called \"star\n>> topoloogy\" as opposed to something \"fully\" distributed).\n> \n> That depends on what you mean by 'bias' (and for that matter, what you\n> mean by 'centralization'; I think that's being used in very different\n> ways here). If you don't care about the ancestry changes, you can go\n> ahead and change it around by merging and pushing like there's no\n> tomorrow, and it'll keep up just fine. Some attributes of it like the\n> revnos which assume you do care about the ancestry simply cease to be\n> of any applicability.\n\n\nHow deep will I have to dig to get the immutable revids instead?\n\n\n> That doesn't make it a useless feature, any\n> more than diff being inapplicable in a branch I'm using to store\n> binary files makes diff useless; it's just not one that's meaningful\n> in a given case.\n> \n\nBinary diffs work just fine, thank you very much ;-)\n\n> bzr (the project) does care about the ordering of the parents, so it\n> doesn't do that. bzr (the tool) assumes that the majority of its\n> users will care, which is why it has revnos; because in the case where\n> you don't disturb the ancestry of given branches, revnos are very\n> useful in reference to that branch.\n> \n> \n>> So even a project that's very oriented around a single, central tree\n>> can get a lot of benefit from being able to share things arbitrarily\n>> between any two given repositories.\n> \n> I agree wholeheartedly. That's one of the reasons I'm using bzr, even\n> though 95% or better of what I do is very oriented around single,\n> central trees, after all 8-}\n> \n\nI'm sure it's supported. The question is whether or not bazaar makes it \neasy for those developers to exchange valuable information (revids, \nsince their revnos will be mixed up) so they can communicate detailed \ninfo about \"commit X introduced a bug in foo_diddle(). I fixed it in \ncommit Y, so if you merge it we can release\". If revids are always \nprinted anyways, I see even less need for revnos. If it's hard to get \nthe revids I wouldn't consider the truly distributed workflow supported \nany more than I consider CVS file rename support á la \"just hand-edit \nthe ,v-files\" to actually work.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"29223","messageId":"Pine.LNX.4.63.0610191321090.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"45375D16.90204@spamcop.net","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-19T11:24:55Z","receivedAt":"2006-10-19T11:24:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Oct 2006, Charles Duffy wrote:\n\n> Johannes Schindelin wrote:\n> > > I presume that for this reason you will also never, _never_ use a\n> > > non-mainline branch of git -- even if its actual code only touches UI\n> > > enhancements or something similarly non-core\n> > > \n> > \n> > NO! The point was that I will not gladly run anything which could change the\n> > core. If I know it touches only the UI, there is no problem.\n> > \n> \n> If you're willing to look at the source of a branch to know that it \n> touches only the UI, why would you not be willing to look at the source \n> of a plugin to do the same thing?\n\nThat is why I said I'd be gladly using a shell-script using git-core \nprograms. It is typically no more than 20 lines, and I can review that \nquite easily.\n\n> Shell scripts allow for a fragile system because they could include C code\n> snippets which they then compile and LD_PRELOAD.\n\nWell, I do not expect people to misbehave. You do not compile a nasty \nC-program from a shell script _by mistake_.\n\nI also expect people not to constantly miss my point. It could be that I \nam not as proficient in the English language as I thought. In that case, \nI'll better shut up.\n\nCiao,\nDscho\n"},{"id":"29224","messageId":"20061019112759.GA31066@diana.vm.bytemark.co.uk","threadId":"5925","inReplyTo":"20061019091045.GV75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-10-19T11:27:59Z","receivedAt":"2006-10-19T11:27:59Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-10-19 04:10:45 -0500, Matthew D. Fuller wrote:\n\n> I think this has the causality backward. It's avoided because it\n> changes the ancestry of the branch in question, by rearranging the\n> left parents; this ties into Linus' assertion that all parents ought\n> to be treated equally, which I'm beginning to think is the base\n> lynchpin of this whole dissension.\n\nYes, it seems you have found the needle. :-) In git, history is a DAG;\na commit has a _set_ of parents, so by definition they are not\nordered. This has a number of consequences. For example, you can't\nreally answer the question \"Which branch was this commit on?\". All you\ncan say is that \"This commit is reachable from (and therefore part of)\nbranches X, Y, and Z.\"\n\nIn all other SCMs I have seen, a \"branch\" is conceptually an ordered\nseries of commits (some of which may be merges). In git, a \"branch\" is\na pointer to a commit, period. The commit knows its set of parents, so\nall its history is there, but there is fundamentally no way to tell\nwhich branch a commit was \"on\" when it was created.\n\nThis is an important point; it means there is no concept of \"my\" or\n\"your\" branch. Every participant is adding commits to the same DAG,\nand may at any point decide to share her additions with someone else,\nor keep them private forever. And because \"branches\" don't really\nexist, every commit really is created equal.\n\nReally, every commit. Not even the initial commit of a project is\nspecial -- it's just a commit with an empty parent set. And, it's\nperfectly possible to make a (merge) commit whose parents belong to\npreviously disconnected parts of the DAG. This of course means that\nit's not even possible to differentiate commits based on which project\nthey're part of, since one can create a commit whose parents belong to\ndifferent projects. All commits are _really_ born equal! There's just\none great DAG of all git commits that could possibly exist. (This has\nbeen done in git's own history; the graphical viewer gitk was\noriginally a separate project, with its own initial commit, but that\ninitial commit is now reachable from all commits currently being made\nto git -- that is, it has been merged.)\n\nThis structure of things may seem complex, since it's different, but\nmathematically it's quite simple, and that's what counts in the end if\nyou want to do nontrivial things.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"29225","messageId":"453761D5.80306@spamcop.net","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610191321090.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Charles Duffy","fromEmail":"cduffy@spamcop.net","sentAt":"2006-10-19T11:30:29Z","receivedAt":"2006-10-19T11:30:29Z","isPatch":false,"sender":{"key":"cduffy@spamcop.net","avatar":null},"body":"Johannes Schindelin wrote:\n>> Shell scripts allow for a fragile system because they could include C code\n>> snippets which they then compile and LD_PRELOAD.\n>> \n>\n> Well, I do not expect people to misbehave. You do not compile a nasty \n> C-program from a shell script _by mistake_.\n> \n\nYou also don't replace bzrlib functionality (in your terms, plumbing) in \na plugin by mistake.\n\n> I also expect people not to constantly miss my point.\n\nI think your point is predicated on a misunderstanding of how plugins work.\n"},{"id":"29226","messageId":"20061019113731.GC20017@pasky.or.cz","threadId":"5925","inReplyTo":"845b6e870610190002u420118b8ud634bb9594572c48@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-19T11:37:31Z","receivedAt":"2006-10-19T11:37:31Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Oct 19, 2006 at 09:02:16AM CEST, I got a letter\nwhere Erik B?gfors said that...\n> bzr's use of revision numbers, doesn't mean it hasn't got unique\n> revision identifiers, and I can't see any reason why it couldn't be\n> used in the same way as git.\n\nThere is perhaps no \"technical\" reason, but it's also what the user\ninterface is designed around - most probably, using UUIDs instead of\nrevnos would be a lot less convenient for bzr people because you\nprobably primarily show revnos everywhere and UUIDs only in few special\nplaces and/or when asked specifically through a command (correct me if\nI'm wrong). Also, do you support \"UUID autocompletion\" so that you can\ntype just the unique UUID prefix instead of the whole thing?\n\n> Both are excellent tools, and since git\n> is more specialized (built to support the exact workflow used in\n> kernel development), it's more suited for that exact use.\n> \n> bzr tries to take a broader view, for example, it does support a\n> centralized workflow if you want one. Most people don't, but a few\n> might. Because of this, it probably fits the kernel development less\n> good than git. That's fine I think! I happens to fit my workflow\n> better than git does :)\n\nI think they are in fact just as flexible (+-epsilon). Git can support\ncentralized workflow as well - you have some central repository\nsomewhere and all the developers clone it, then pull from it and push to\nit in basically the same way they would use CVS. And it is perhaps\ncurrently even more used in practice than the \"single-man\" workflow\nnowadays, as more project are using Git.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i said that...\n> Really, every commit. Not even the initial commit of a project is\n> special -- it's just a commit with an empty parent set. And, it's\n> perfectly possible to make a (merge) commit whose parents belong to\n> previously disconnected parts of the DAG. This of course means that\n> it's not even possible to differentiate commits based on which project\n> they're part of, since one can create a commit whose parents belong to\n> different projects.\n\nFWIW, IIRC the Git project has about 6 initial commits. :-)\n\nBTW, a popular source of horrification in other VCSes are Git's octopus\nmerges. (A popular source of horrification in Git are kernel developers\ndoing octopus merges of 40 branches at once.) Does Bazaar support those?\n(I can't really say it's a defect if it doesn't...)\n\n(An octopus merge is a merge of more than two branches at once, in a\nsingle commit.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i writes:\n\n> You, and others, keep saying \"leftmost\". What on earth does left or\n> right have to do with anything? Or rather, how do you determine which\n> side anything at all is on?\n\nNot sure it's the same in git, but in bzr, a new revision is always\ncreated by a commit (it can be \"fetched\" by other commands though). If\nyou \"merge\", then you have to commit after.\n\nWhat people call \"leftmost ancestor\" is the revision which used to be\nthe tip at the time you commited. For example, if you do \"bzr diff;\nbzr commit\" the diff shown before is the same as the one got with\n\"bzr diff -r last:1\" right after the commit.\n\nI believe this doesn't make a difference for merge algorithms, but in\nthe UI, it's here when you say, e.g.:\n\nbzr diff -r last:12..before:revid:foo@bar-auents987aue\n\n(once in \"last:\", and once in \"before:\")\n\n-- \nMatthieu\n"},{"id":"29229","messageId":"20061019123349.GE20017@pasky.or.cz","threadId":"5925","inReplyTo":"vpqirigqzpd.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-19T12:33:49Z","receivedAt":"2006-10-19T12:33:49Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Oct 19, 2006 at 02:04:14PM CEST, I got a letter\nwhere Matthieu Moy said that...\n> What people call \"leftmost ancestor\" is the revision which used to be\n> the tip at the time you commited. For example, if you do \"bzr diff;\n> bzr commit\" the diff shown before is the same as the one got with\n> \"bzr diff -r last:1\" right after the commit.\n\nThe lack of parents ordering in Git is directly connected with\nfast-forwarding.\n\nConsider\n\n repo1 repo2\n\n a a\n / /\n b c\n\nNow repo2 merges with repo1:\n\n repo1 repo2\n\n a a\n / / \\\n b c b\n \\ /\n m\n\nrepo1 tip ('b') is not ancestor of repo2 tip ('c') so a three-way merge\nis done and a new 'm' merge commit is created.\n\nAnd now repo1 merges with repo2:\n\n repo1 repo2\n\n a a\n / \\ / \\\n c b c b\n \\ / \\ /\n m m\n\nBecause previous repo1 tip ('b') was ancestor of repo2 tip ('m'), a\nfast-forward happenned and repo1 tip simply moved to 'm'. But this\n\"flipped\" the development from repo1 POV - you cannot assume anymore\nthat the first (\"leftmost\") parent is special.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i writes:\n\n> The lack of parents ordering in Git is directly connected with\n> fast-forwarding.\n\n[...]\n\n> repo1 repo2\n>\n> a a\n> / \\ / \\\n> c b c b\n> \\ / \\ /\n> m m\n\nYes, bzr has similar thing too. AIUI, the difference is that git does\nit automatically, while bzr has two commands in its UI, \"merge\" and\n\"pull\".\n\nIn your case, the \"leftmost ancestor\" of m is b, because at the time\nit was created, it was commited from b.\n\nOne problem with that approach is that from revision m and looking\nbackward in history (say, running \"bzr log\"), you have two ways to go\nbackward:\n\n1) Take the history of _your_ commits, and your pull till the point\n where you've branched.\n\n2) Follow the history taking the leftmost ancestor at each step.\n\nIn bzr, the notion of \"branch\" corresponds to a succession of\nrevisions, which are explicitely stored in a file (ls\n.bzr/branch/revision-history), which is what commands like \"log\"\nfollow, and what is used for revision numbering. And this sucession of\nrevision must obey (at most) one of the above. In the past, it was 1),\nwhich means that \"pull\" (i.e. fast-forward) was only adding revisions\nto a branch. In your scenario, repo1 would get a revision history of\n\"a c m\" while repo2 would have had \"a b m\" with the same tip.\n\nToday, the revision history follows leftmost ancestor. One good\nproperty of this is that revision history is unique for a given\nrevision. But the terrible drawback is that \"pull\" and \"push\" do not\n/add/ revisions to your revision history, they rewrite the target one\nwith the source one. That means I can have\n\n$ bzr log --line\n1: some upstream stuff\n2: started my work\n3: continued my work\n\n# upstream merges.\n\n$ bzr pull\n$ bzr log --line\n1: some upstream stuff\n2: some other upstream stuff ...\n3: ... commited while I was working\n4: merged from Matthieu this terrible feature\n\n-- \nMatthieu -- definitely curious to give a real try to git ;-)\n"},{"id":"29235","messageId":"Pine.LNX.4.64.0610191025340.1971@xanadu.home","threadId":"5925","inReplyTo":"7vac3tx900.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-10-19T14:27:40Z","receivedAt":"2006-10-19T14:27:40Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 18 Oct 2006, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > Actually, I've hit an impasse.\n> >\n> > So there's _another_ way of fixing a thin pack: it's to expand the objects \n> > without a base into non-delta objects, and keeping the number of objects \n> > in the pack the same. But _again_, we don't actually know which ones to \n> > expand until it's too late.\n> \n> pack-objects.c::write_one() makes sure that we write out base\n> immediately after delta if we haven't written out its base yet,\n> so I suspect if you buffer one delta you should be Ok, no?\n\nIf we create full packs out of thin packs the base objects will end up \nat the end of the pack so this assumption is a bad one to rely upon if \nwe want to make things robust (like being able to feed such a pack \nback).\n\n\nNicolas\n"},{"id":"29236","messageId":"Pine.LNX.4.64.0610190747060.3962@g5.osdl.org","threadId":"5925","inReplyTo":"7vac3tx900.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-19T14:55:18Z","receivedAt":"2006-10-19T14:55:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Junio C Hamano wrote:\n>\n> Linus Torvalds writes:\n> >\n> > Actually, I've hit an impasse.\n> >\n> > So there's _another_ way of fixing a thin pack: it's to expand the objects \n> > without a base into non-delta objects, and keeping the number of objects \n> > in the pack the same. But _again_, we don't actually know which ones to \n> > expand until it's too late.\n> \n> pack-objects.c::write_one() makes sure that we write out base\n> immediately after delta if we haven't written out its base yet,\n> so I suspect if you buffer one delta you should be Ok, no?\n\nIt doesn't matter. I realized that my bogus patch to unpack-objects was \nmore seriously broken anyway: even the \"un-deltify every single object\" \nwas broken. And that's despite the fact that I _tested_ it, and verified \nthe end result by hand.\n\nWhy? Because I tested it within one repo, by just piping the output of \ngit-pack-objects --stdout directly to the repacker. That seemed to be a \ngood way to test it without setting up anything bigger. But it turns out \nthat it misses one of the big problems: if you don't unpack the objects in \na way that later phases can read, none of the streaming code works at all, \nand you have to buffer up _everything_ in memory just to be able to read \nany previous _non_delta objects too.\n\nSo my patch-series works - but it only works in a repo that already has \nall the objects in question, because then it can look up the objects in \nthe original database. Which makes it useless. Duh.\n\nSo forget about unpack-objects. It's designed to be streaming (and it's a \n_good_ design for what it does), but repacking really cannot be done that \nway. Repacking needs to be done by saving the thin pack to disk, and then \ndoing a multi-pass over it (like git-index-pack does, for example).\n\nJust throw my patch away. It's not even useful as a basis for anything \nelse, unless you want to use it as a way to keep all the objects in memory \nand use the \"unpack-objects\" logic to just _parse_ the incoming pack.\n\nI suspect using \"index-pack\" is saner (since it already has the multi-pass \nlogic), or just doing somethign that maps all the objects in memory, and \nthen calls builtin-pack-objects once it has set up the new thin pack so \nthat others can see/use the new objects without realizing that they aren't \nin the canonical pack-format.\n\n\t\tLinus\n"},{"id":"29237","messageId":"72877ab10610190757u3d2b4df0o204c6ffd73af69b4@mail.gmail.com","threadId":"5925","inReplyTo":"vpqwt6wsmb5.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Tim Webster","fromEmail":"tdwebste@gmail.com","sentAt":"2006-10-19T14:57:24Z","receivedAt":"2006-10-19T14:57:24Z","isPatch":false,"sender":{"key":"tdwebste@gmail.com","avatar":null},"body":"On 10/19/06, Matthieu Moy wrote:\n> Andreas Ericsson writes:\n>\n> > Perhaps not, but the tone is friendly (mostly), the patience of the\n> > bazaar people seems infinite and lots of people seem to be having fun\n> > while at the same time learning a thing or two about a different SCM.\n> > Best case scenario, both git and bazaar come out of the discussion as\n> > better tools. If there would never be any cross-pollination, git\n> > wouldn't have half the features it has today.\n>\n>\n\n\nThanks everyone for taking time to explain details.\n\nHowever, I don't use SCM for code development. I use it for collaborative\ndocumentation, white boarding and tracking configurations.\nIn fact in my company no one uses SCM for code development.\nEveryone here uses it for collaborative documentation and white boarding.\nOnly I use SCM for tracking configurations.\n\nI think of SCMs in terms of an SCM core and SCM tools.\n\nFirst I want to say every SCM I know of sucks when it comes to tracking\nconfigurations, simply because they don't record or restore file metadata,\nlike perms, ownership, and acl. I don't see recording or restoring\nfile metadata as part of the SCM core. I do however feel an SCM core needs to\nhave provisions for extended file inventory information. The problem\nwith extended file inventory information, it is fs specific. For this reason I\nfeel it is essential that the SCM core allow multiple sets of extended file\ninventory information. The SCM tools are responsible, based on the local\nconfig, for recording metadata and creating extended file inventory,\ntranslating file metadata of one file system. When tracking configurations\noctopus merges are surprisingly common. If a configuration changed is\nnot signed off by a responsible person, it can not be accepted. Doing\notherwise is simply an invitation to attackers and makes trouble shooting\nfar too difficult. Also configuration file in one directory will most often not\nbe members of the same repo. For example each file etc in directory would\nmembers of different repos according to its associated application/pkg.\n\nSomethings I like the SCM tools to handle. Personally I would like the\nSCM tools to be platform independent. This would ensure that correct\nthings happening on ext3 mounted on windows.\nI don't think execute bit belongs in the basic file inventory information.\nInstead I would like to use this replace by a filter in the extended\nfile inventory\nindicating what file metadata if any should be recorded or restored.\nWhen the local SCM tools config has use metadata enable, the filter is used.\nA filter lets the user select file metadata to record/restore such as;\nrecord ownership, record permissions, record acl.\n\nFor SCM configuration tracking to function reliably, pulls, pushes and merges\nneed to be atomic. Personally I like my servers to pull change updates. And\nI like to push changes I make on local servers to branches. On configuration\nmaster merge the branches into groups. When the server pulls changes\nfor a particular application/pkg, the following is a list of steps that need to\noccur.\nThe SCM tools, perform a pre update step, such as optionally stopping a service\npull updates and build changes files in a scratch space, than apply\nfile metadata,\nunchanged files would be links from the scratch space to the original files,\nverify all files are correct by checking their sha1 or md5,\natomically move configuration files and scripts to install them,\nperform a post update step, such as starting or reloading a service.\nThe pre update step and the post update are very much like pkg pre and post\ninstall scripts. The pre update and post update scripts are in fact part of the\napplication/pkg configurations files.\n\n\nCollaborative document editing and white boarding are other requirements.\nodf and svg are xml file formats. I would like to see an efficient\nxml diff as part of the SCM core. Using mime types SCM tools can unzip\nfiles, bundles, and use mime type information to the SCM core xml\ndiff, plain diff\nas required. I think it is essential that the SCM core include\nprevisions for multiple\nrepo partners. For example this can be used to create fail over star\nscm architecture.\nIn collaborative document editing it is often the case where you want to\ncompress / summarize some of the change history.\n\nWe currently use our scm based collaborative document editing as an ad\nhock white\nboard, coordinating our commits and updates via IM. :)\nIt would be nice if the SCM tools included rss feeds for communicating zip\npatch bundles.\n"},{"id":"29238","messageId":"453792A8.1010700@utoronto.ca","threadId":"5925","inReplyTo":"87lkncev90.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-19T14:58:48Z","receivedAt":"2006-10-19T14:58:48Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nCarl Worth wrote:\n> On Wed, 18 Oct 2006 23:10:11 -0400, Aaron Bentley wrote:\n> But think about your favorite example of an unhealthy social situation\n> around a software project and a big, nasty fork. Every example I can\n> think of involves some technical distinction that makes one branch\n> more special than another.\n>\n> Now, those situations also involve social problems, and those are even\n> more significant. But the technical blessing of one branch does not\n> help. And I think it contributes to the social problems in many cases.\n\nI'm not as familiar with those details. The one fork that I know a lot\nabout, when Baz (the old Bazaar architecture) forked off from Arch,\nshowed me that for each developer branch, one branch must be special.\n\nThis is just because it is hard to maintain a branch that applies\ncleanly to two diverging codebases. So each developer must develop\nagainst the fork that they want to merge their code into. If they want\ntheir code to be applied to the other fork, someone must port it.\n\nSo I really do feel that special branches are inescapable.\n\nWith bzr, you have the freedom to choose which branch you consider\nspecial, and change your mind at any time. There are no technical\nlimitations in that regard.\n\n> As far as the revision numbers, my impression is that the numbers\n> would be confusing or worthless if I were to use bzr the way I'm\n> currently using git, as they certainly could not remain stable.\n\nThey would remain stable if you only used pull to update your origin\nbranch, and used merge+commit to update your development branch.\n\n>> In bzr development, it's very rare for anyone's revision numbers to change.\n> \n> Which just says to me that the bzr developers really are sticking to a\n> centralized model.\n\nI don't see why you're reaching that conclusion. I'd like to understand\nthat better, because Linus seems to be concluding the same thing, and it\ndoesn't make sense to me.\n\n>> I think you're implying that on a technical level, bzr doesn't support\n>> this. But it does. Every published repository has unique identifiers\n>> for every revision on its mainline, and it's exceedingly uncommon for\n>> these to change.\n> \n> Every argument you make for the number change being uncommon just\n> strengthens the argument that it will be all that more\n> confusing/frustrating when the numbers do change.\n\nThat doesn't follow. Just because something is arguably true doesn't\nmake it bad. And in this case, I'm not arguing that it's true, I'm\nsaying that it's true, because that is what my experience tells me is true.\n\n> In cairo, for example, we've made a habit of including a revision\n> identifier in our bug tracking system for every commit that resolves a\n> bug.\n\nWe do it the other way around: we put a bug number in the commit\nmessage. And I personally have been developing a bugtracker that is\ndistributed in the same way bzr is; it stores bug data in the source\ntree of a project, so that bug activities follow branches around.\n\n> I like having the assurance that those numbers will survive\n> forever. And it doesn't matter if the repository moves, or the project\n> is forked, or anything else. Those numbers cannot change.\n> \n> I understand that bzr also has unique identifiers, but it sounds like\n> the tools try to hide them, and people aren't in the habit of using\n> them for things like this. Do bzr developers put revision numbers in\n> their bug trackers? Is there a guarantee they will always be valid?\n\nYes, we put revnos in our bug trackers. No, we can't prove that they\nwill always be valid. But there are significant disincentives to\nchanging them, so I am quite comfortable assuming they will not change.\n And the older a revno gets, the less likely it is to change.\n\nOn the other hand, I think your revision identifiers are not as\npermanent as you think.\n\nIn the first place, it seems fairly common in the Git community to\nrebase. This process throws away old revisions and creates new\nrevisions that are morally equivalent[1]. I don't know whether Git\nfetches unreferenced revisions, but bzr's policy is to fetch only\nrevisions referenced in the ancestry DAG of the branch.\n\nIn the second place, one must consider the \"nuclear launch codes\"\nscenario. In this scenario, someone has committed the codes necessary\nto begin a nuclear attack into their branch. This is an unlikely event,\nof course, but nuclear launch codes are an extreme example of data that\nabsolutely, positively must be completely expunged from the branch.\nOther examples include proprietary code (e.g. if SCO wasn't a bunch of\ncharlatans), passwords and obscene or libelous statements.\n\nIn a nuclear codes scenario, the revision that introduced the nuclear\nlaunch codes and all its descendants must be expunged from the\nrepository. You may, perhaps, rebase in order to retain the shape of\nthe history, but the revision-ids that you have recorded will be gone.\n\nAaron\n\n[1] This is a process that I find discomforting, because I consider the\noriginal revisions to be real, historical data, and I don't like the\nidea of throwing it away.\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFN5F70F+nu1YWqI0RAhrsAJ9rcqNGv28134eTvbGoxxteOxif3wCfTbaq\nfpD0HNeGgdlMwuJldyzUxRM=\n=9k8r\n-----END PGP SIGNATURE-----\n"},{"id":"29239","messageId":"20061019151736.GY75501@over-yonder.net","threadId":"5925","inReplyTo":"20061019113731.GC20017@pasky.or.cz","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-19T15:17:36Z","receivedAt":"2006-10-19T15:17:36Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"[ trim back CC a bit ]\n\nOn Thu, Oct 19, 2006 at 01:37:31PM +0200 I heard the voice of\nPetr Baudis, and lo! it spake thus:\n> \n> [...] you probably primarily show revnos everywhere and UUIDs only\n> in few special places and/or when asked specifically through a\n> command (correct me if I'm wrong).\n\nThe primary place you'd see either is in 'log'. To show the UUID,\nyou'd add a \"--show-ids\" arg to it (and via per-user config aliasing,\nyou could just alias 'log' to 'log --show-ids' if you always wanted to\nsee them, so you wouldn't have to type it. The output looks something\nlike:\n\nrevno: 1\nrevision-id: fullermd@over-yonder.net-20061019151437-5b99dff6ed1d76cd\ncommitter: Matthew Fuller \nbranch nick: a\ntimestamp: Thu 2006-10-19 10:14:37 -0500\nmessage:\n Foo\n\n(without --show-ids, it's the same, except not showing the\nrevision-id: line)\n\n\n> Also, do you support \"UUID autocompletion\" so that you can type just\n> the unique UUID prefix instead of the whole thing?\n\nWith the form of bzr UUID's, that's not particularly useful, since\nyou're probably into the minutes/seconds of the timestamp before it\nbecomes unique, at which points you're close to 2/3 of the way through\nthe whole string.\n\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29240","messageId":"Pine.LNX.4.64.0610190757100.3962@g5.osdl.org","threadId":"5925","inReplyTo":"87lkncev90.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-19T15:25:26Z","receivedAt":"2006-10-19T15:25:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Oct 2006, Carl Worth wrote:\n> \n> I understand that bzr also has unique identifiers, but it sounds like\n> the tools try to hide them, and people aren't in the habit of using\n> them for things like this. Do bzr developers put revision numbers in\n> their bug trackers? Is there a guarantee they will always be valid?\n\nbzr seems to use the classic UUID format, and it's funny how much it looks \nlike a real BK ChangeSet revision number (\"key\").\n\nHere's the quoted bzr \"true\" revision ID:\n\n\tMatthieu.Moy@imag.fr-20061017152029-4c5a2861bcf23b7d\n\nand here's a BK \"ChangeSet Key\":\n\n\tadi@zaphod.bitmover.com|ChangeSet|20031031183805|57296\n\n(I don't have BK installed anywhere, so I had to google for changeset \nkeys, and this was just some random key in the BK bugzilla ;)\n\nLooks very similar, don't they? And yes, the true revision ID is stable \nover time (at least it was in BK, and I assume it is in bzr too).\n\nThe biggest difference seems to be that in bzr, the final checksum is \n64-bit, while for BK, it was just a 16-bit checksum/unique number (the \nrest is just user-name/machine-name and date: I assume that the bzr commit \nwas done at 10/17/2006 3:20:29PM, and the example BK ChangeSet was created \n10/31/2003 6:38:50PM - it looks like _exactly_ the same date format).\n\nWith BK, you can also use a \"md5 key\", and I don't actually know how they \nwork. They may just be the md5 hash of the ChangeSet key, I think that may \nbe how those things are indexed. So in bkcvs, you'll see a line like this:\n\n\tBKrev: 42516681VmgTWL0bkLcltPGiI6Yk5Q\n\nwhich is the BK md5 key for my last kernel revision in BK (2.6.12-rc2). \nAgain, these numbers are stable, unlike the simple revisions.\n\nNote that from a usability standpoint, the UUID's look more readable to a \nhuman, but are actually much worse than the md5 keys (or the SHA1's that \ngit uses). At least with a hash, the first few digits are likely to be \nunique, so you can do things like auto-completion (or just short names). \nWith the email+date+random number kind of UUID, you don't have that.\n\n(Pure hashes obviously also tend to just all have the same length, and are \neasier to parse automatically, so from a programmatic standpoint they are \na lot easier too - but the surprising thing is how they are actually \neasier on humans too, even if the UUID's look more readable).\n\n\t\t\tLinus\n"},{"id":"29241","messageId":"45379A02.1010105@utoronto.ca","threadId":"5925","inReplyTo":"72877ab10610190757u3d2b4df0o204c6ffd73af69b4@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-19T15:30:10Z","receivedAt":"2006-10-19T15:30:10Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nTim Webster wrote:\n> First I want to say every SCM I know of sucks when it comes to tracking\n> configurations, simply because they don't record or restore file metadata,\n> like perms, ownership, and acl.\n\nArch supports that kind of metadata.\n\nI believe SVN supports recording arbitrary file properties, so it's just\na matter of applying those properties to the tree.\n\n> Somethings I like the SCM tools to handle. Personally I would like the\n> SCM tools to be platform independent. This would ensure that correct\n> things happening on ext3 mounted on windows.\n> I don't think execute bit belongs in the basic file inventory information.\n\nOur choices have been predicated on producing the best SCM we can for\nthe purpose of developing software. We find that the execute bit is\nvery useful for build scripts and other incidental scripts.\n\nThe other attributes didn't seem useful for software development, so\nthey're not part of the baseline.\n\n> Collaborative document editing and white boarding are other requirements.\n> odf and svg are xml file formats. I would like to see an efficient\n> xml diff as part of the SCM core. Using mime types SCM tools can unzip\n> files, bundles, and use mime type information to the SCM core xml\n> diff, plain diff\n> as required.\n\nAn XML diff/patch or merge will not handle ODF properly. There's too\nmuch extra semantic information.\n\n> I think it is essential that the SCM core include\n> previsions for multiple\n> repo partners.\n\nYou mean multiple merge sources?\n\n> It would be nice if the SCM tools included rss feeds for communicating zip\n> patch bundles.\n\nThe bzr \"webserve\" plugin provides rss feeds.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFN5oB0F+nu1YWqI0RAjSoAJ9xrZtSrZpVVoz6qAf/sZnd/StsUACfenqX\n6bemNgMSbhtL0JjIlvulrb4=\n=bSpK\n-----END PGP SIGNATURE-----\n"},{"id":"29242","messageId":"624934630610190845ocf2818fhd0a9d19bfacf53a0@mail.gmail.com","threadId":"5925","inReplyTo":"45373E27.3050209@op5.se","subject":"Re: VCS comparison table","fromName":"Ramon Diaz-Uriarte","fromEmail":"rdiaz02@gmail.com","sentAt":"2006-10-19T15:45:02Z","receivedAt":"2006-10-19T15:45:02Z","isPatch":false,"sender":{"key":"rdiaz02@gmail.com","avatar":null},"body":"On 10/19/06, Andreas Ericsson wrote:\n> Christian MICHON wrote:\n> > close to 200 post on bzr-git war!\n> > is this the right place (git mailing list) to discuss about future\n> > features of bzr ?\n> >\n>\n> Perhaps not, but the tone is friendly (mostly), the patience of the\n> bazaar people seems infinite and lots of people seem to be having fun\n> while at the same time learning a thing or two about a different SCM.\n> Best case scenario, both git and bazaar come out of the discussion as\n> better tools. If there would never be any cross-pollination, git\n> wouldn't have half the features it has today.\n>\n\nI fully agree with Andreas: I am just a bzr user (not even a bzr\ndeveloper) and when looking for a decentralized VCS I also looked at\ngit and a few others. I think I am learning quite a bit about bzr,\ngit, and VCS in general.\n\nR.\n\n> --\n> Andreas Ericsson andreas.ericsson@op5.se\n> OP5 AB www.op5.se\n> Tel: +46 8-230225 Fax: +46 8-230231\n>\n>\n\n\n-- \nRamon Diaz-Uriarte\nStatistical Computing Team\nStructural Biology and Biocomputing Programme\nSpanish National Cancer Centre (CNIO)\nhttp://ligarto.org/rdiaz\n"},{"id":"29246","messageId":"20061019160103.GZ75501@over-yonder.net","threadId":"5925","inReplyTo":"20061019114639.GD20017@pasky.or.cz","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-19T16:01:03Z","receivedAt":"2006-10-19T16:01:03Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Thu, Oct 19, 2006 at 01:46:39PM +0200 I heard the voice of\nPetr Baudis, and lo! it spake thus:\n> \n> Does Bazaar support those? (I can't really say it's a defect if it\n> doesn't...)\n\nBy default, merge will refuse to do its thing if there are uncommitted\nchanges in the working tree, whether those changes are something\nyou've done, or the pending results of a previous merge. A '--force'\narg to merge will make it go forward though, so yes, you can merge\nmultiple other branches in one merge if you want to.\n\nActually, I can kill 2 birds here. Quick little bictopus merge:\n\n% bzr log --show-ids\n------------------------------------------------------------\nrevno: 2\nrevision-id: fullermd@over-yonder.net-20061019151856-c3b406b8bcdfb537\nparent: fullermd@over-yonder.net-20061019151437-5b99dff6ed1d76cd\nparent: fullermd@over-yonder.net-20061019151800-2fe41e4949f5e237\nparent: fullermd@over-yonder.net-20061019151807-3d7047e387edcad9\ncommitter: Matthew Fuller \nbranch nick: a\ntimestamp: Thu 2006-10-19 10:18:56 -0500\nmessage:\n merge\n ------------------------------------------------------------\n revno: 1.2.1\n merged: fullermd@over-yonder.net-20061019151800-2fe41e4949f5e237\n parent: fullermd@over-yonder.net-20061019151437-5b99dff6ed1d76cd\n committer: Matthew Fuller \n branch nick: b\n timestamp: Thu 2006-10-19 10:18:00 -0500\n message:\n bar\n ------------------------------------------------------------\n revno: 1.1.1\n merged: fullermd@over-yonder.net-20061019151807-3d7047e387edcad9\n parent: fullermd@over-yonder.net-20061019151437-5b99dff6ed1d76cd\n committer: Matthew Fuller \n committer: Matthew Fuller \n branch nick: c\n timestamp: Thu 2006-10-19 10:18:07 -0500\n message:\n baz\n------------------------------------------------------------\nrevno: 1\nrevision-id: fullermd@over-yonder.net-20061019151437-5b99dff6ed1d76cd\ncommitter: Matthew Fuller \nbranch nick: a\ntimestamp: Thu 2006-10-19 10:14:37 -0500\nmessage:\n Foo\n\n\n(I'll refer to revids by the last segment)\n\nNote that this also shows the \"left-most\" parent distinction. The\n\"left-most\" parent of revno 2 (c3b406b8bcdfb537) is revno 1\n(5b99dff6ed1d76cd), because that's the last thing I did in THIS\nbranch. That's my 'mainline'; the commits from branch b\n(2fe41e4949f5e237) and c (3d7047e387edcad9) are then additional\nparents of the merge at revno 2.\n\nThe graph for branch a now looks something like (calling the 3\noriginal commits 'a', 'b', and 'c' and the merge rev 'D'):\n\n a-.\n |\\ \\\n | b c\n |/ /\n D-'\n\n\nThe 2fe41e4949f5e237 rev is on branch b's mainline forever, and it has\na single-digit revno (2 in this case) on branch b, but it's not on\nmine in a. Now, let's pretend we're branch b, and we want to pick up\nfrom a. Because a is a superset of b, we could pull ('fast-forward')\na. If we do that, the graph in b will be identical to a (and so 'log'\nwill be too). That, AIUI, is what you'd do in git.\n\nIn the bzr methodology we've been discussing, where you want to\nmaintain your branch's identity, you'd instead merge from a into b.\nYou've got two new revisions to pick up in doing so; the\n3d7047e387edcad9 from branch c, and the merge rev c3b406b8bcdfb537;\nyou already have 2fe41e4949f5e237 on your mainline. So, post-merge,\nthe log for b will look like (somewhat trimmed for space):\n\n\n------------------------------------------------------------\nrevno: 3\nrevision-id: fullermd@over-yonder.net-20061019153827-78d6209cd0f5f2f7\nparent: fullermd@over-yonder.net-20061019151800-2fe41e4949f5e237\nparent: fullermd@over-yonder.net-20061019151856-c3b406b8bcdfb537\nbranch nick: b\n ------------------------------------------------------------\n revno: 1.1.1\n merged: fullermd@over-yonder.net-20061019151856-c3b406b8bcdfb537\n parent: fullermd@over-yonder.net-20061019151437-5b99dff6ed1d76cd\n parent: fullermd@over-yonder.net-20061019151800-2fe41e4949f5e237\n parent: fullermd@over-yonder.net-20061019151807-3d7047e387edcad9\n branch nick: a\n ------------------------------------------------------------\n revno: 1.2.1\n merged: fullermd@over-yonder.net-20061019151807-3d7047e387edcad9\n parent: fullermd@over-yonder.net-20061019151437-5b99dff6ed1d76cd\n branch nick: c\n------------------------------------------------------------\nrevno: 2\nrevision-id: fullermd@over-yonder.net-20061019151800-2fe41e4949f5e237\nparent: fullermd@over-yonder.net-20061019151437-5b99dff6ed1d76cd\nbranch nick: b\n------------------------------------------------------------\nrevno: 1\nrevision-id: fullermd@over-yonder.net-20061019151437-5b99dff6ed1d76cd\nbranch nick: a\n\n\nThe 2fe41e4949f5e237 which was originally on b's mainline is still on\nthe mainline at revno 2. The graph in b now looks like (adding the\nnew 'E' merge commit)[0]:\n\n a-.\n |\\ \\\n b c |\n |\\|/\n | D\n |/ \n E\n\n\nNow, the question of \"is that merge commit E really necessary, when\nyou could just attach D to the end of the graph and create something\nlike:\n\n a-.\n |\\ \\\n b c |\n |/ /\n D-'\n\nis perhaps a useful question (and one that there's obviously\ndisagreement on). And it may be a fruitful one to discuss, if we're\nnot way off in the weeds already. But, it's also not QUITE the same\nquestion as \"Is the left-vs-other path distinction meaningful and to\nbe preserved?\"\n\n\n\n[0] For reference at this point:\n a: 5b99dff6ed1d76cd\n b: 2fe41e4949f5e237\n c: 3d7047e387edcad9\n D: c3b406b8bcdfb537\n E: 78d6209cd0f5f2f7\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29247","messageId":"87ac3s2syi.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"vpqr6x4pghp.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-19T16:03:49Z","receivedAt":"2006-10-19T16:03:49Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 19 Oct 2006 15:44:34 +0200, Matthieu Moy wrote:\n> > The lack of parents ordering in Git is directly connected with\n> > fast-forwarding.\n\nYes. We're identifying the core underlying technical difference behind\nthe recent discussion. Namely bzr treats one parent as special, (the\nparent that was the branch tip previously). And this special treatment\neliminates the ability to fast-forward, adds merge commits that\nwouldn't exist with fast forwarding, and is able to make its revision\nnumbers a bit more stable as a consequence.\n\n> > a a\n> > / \\ / \\\n> > c b c b\n> > \\ / \\ /\n> > m m\n>\n> Yes, bzr has similar thing too. AIUI, the difference is that git does\n> it automatically, while bzr has two commands in its UI, \"merge\" and\n> \"pull\".\n\nThere's a bit more to it than that though. The git command named\n\"pull\" will perform a fast-forward if possible, but will create a\nmerge commit if necessary. For example:\n\n\ta a a\n\t| pulls | and fast-forwards to |\n\tb b b\n\t | |\n\t c c\n\nwhereas:\n\n\ta a a\n\t| pulls | and creates a merge / \\\n\tb c b c\n \\ /\n m\n\nSo I'm curious. What does bzr pull do in the case of divergence like\nthis? (And this is the \"numbers will be changed\" case, by the way).\n\n> In your case, the \"leftmost ancestor\" of m is b, because at the time\n> it was created, it was commited from b.\n\nIt should be mentioned that git can, (annoyingly not by default), save\na file detailing the history of a branch, (time a revision ID for\nevery time the branch tip moved). This is the \"reflog\" support and\nprovides the same information that bzr is encoding in its \"leftmost\nancestor\" branches.\n\nImportantly, though, git's reflog is entirely local and is not\npropagated by push/pull etc.\n\n> One problem with that approach is that from revision m and looking\n> backward in history (say, running \"bzr log\"), you have two ways to go\n> backward:\n>\n> 1) Take the history of _your_ commits, and your pull till the point\n> where you've branched.\n>\n> 2) Follow the history taking the leftmost ancestor at each step.\n\nUhm, don't you really have to follow both? And the only ambiguity is\nwhich one you see first?\n\n> In your scenario, repo1 would get a revision history of\n> \"a c m\" while repo2 would have had \"a b m\" with the same tip.\n\nOK. With git the two reflogs on the two machines would also have \"a c\nm\" and \"a b m\". But is this the only kind of log that exists? If I\nhad code history as above and wanted to ask questions about what led\nto commit m, then I would want to know about both b and c which\ncontribute to it.\n\nAnd that's what \"git log\" provides. It lists all the commits that are\nreachable from a given commit by following parent links. Surely bzr\nhas a way to view the complete history that way?\n\nMeanwhile, I suggest that there really is no significance to which\nparent of a commit used to have the branch head pointing at it. Saving\nthat information as part of the history is saving it in the wrong\nplace. It forces the user to have to be careful about which direction\nmerges happen, leading to awkward command sequences as demonstrated\nabove, (or daemons to hide them). And in the end, it's just not\nimportant information to have saved in the permanent history.\n\nIt is useful in a transient sense to be able to say, (as git reflog\nallows), what was my \"master\" branch pointing at yesterday, (because I\nknow the code was working before I merged in some bad code this\nmorning, for instance). But that's a local-only question and will\nnever have historical significance. \"What was cworth's master branch\npointing at on 2006-10-18\" is a question that nobody will ever need\nthe answer to in any historical sense.\n\n-Carl\n\nPS. Here are the commands the show the divergent pull example I gave\nabove with git:\n\n# Start a new empty repository\n$ mkdir git-example; cd git-example\n$ git init-db\ndefaulting to local storage area\n\n# Create initial commit 'a'\n$ touch a; git add a; git commit -m \"Initial commit of a\"\nCommitting initial tree 496d6428b9cf92981dc9495211e6e1120fb6f2ba\n\n# Create the 'b' commit on a new 'b' branch from 'a'\n$ git checkout -b b; touch b; git add b; git commit -m \"Add b on branch b\"\n\n# Create the 'c' commit on a new 'c' branch from 'a'\n$ git checkout -b c master; touch c; git add c; git commit -m \"Add c on branch c\"\n\n# Checkout the 'master' branch, (which is pointing at 'a')\n$ git git checkout master\n\n# Merge the 'b' branch, (notice that this is a fast forward)\n$ git pull . b\nUpdating from faf5f2f7363ef5de740193afd89bedee095ef966 to 141811d050aa7008f19867280c41405e05b3dbf7\nFast forward\n 0 files changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 b\n\n# Now merge the 'c' branch (notice that this is not a fast\n# forward, but instead creates a new merge commit)\n$ git pull . c\nTrying really trivial in-index merge...\nWonderful.\nIn-index merge\n 0 files changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 c\n\n# Show the log of commits reachable from 'master', (all 4 commits)\n$ git log\ncommit 59b3cdaf930824d4c0def4ba7ef9b913fcf05d96\nMerge: 141811d... dfc35d5...\nAuthor: Carl Worth \nDate: Thu Oct 19 08:15:23 2006 -0700\n\n Merge branch 'c'\n\ncommit dfc35d5bd88b22f836bd6f46991169d3c3960b69\nAuthor: Carl Worth \nDate: Thu Oct 19 08:14:30 2006 -0700\n\n Add c on branch c\n\ncommit 141811d050aa7008f19867280c41405e05b3dbf7\nAuthor: Carl Worth \nDate: Thu Oct 19 08:14:10 2006 -0700\n\n Add b on branch b\n\ncommit faf5f2f7363ef5de740193afd89bedee095ef966\nAuthor: Carl Worth \nDate: Thu Oct 19 08:13:53 2006 -0700\n\n Initial commit of a\n"},{"id":"29248","messageId":"20061019160750.GS17794@delft.aura.cs.cmu.edu","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610190747060.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2006-10-19T16:07:50Z","receivedAt":"2006-10-19T16:07:50Z","isPatch":false,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Thu, Oct 19, 2006 at 07:55:18AM -0700, Linus Torvalds wrote:\n> On Wed, 18 Oct 2006, Junio C Hamano wrote:\n> >\n> > Linus Torvalds writes:\n> > >\n> > > Actually, I've hit an impasse.\n> > >\n> > > So there's _another_ way of fixing a thin pack: it's to expand the objects \n> > > without a base into non-delta objects, and keeping the number of objects \n> > > in the pack the same. But _again_, we don't actually know which ones to \n> > > expand until it's too late.\n> > \n> > pack-objects.c::write_one() makes sure that we write out base\n> > immediately after delta if we haven't written out its base yet,\n> > so I suspect if you buffer one delta you should be Ok, no?\n> \n> It doesn't matter. I realized that my bogus patch to unpack-objects was \n> more seriously broken anyway: even the \"un-deltify every single object\" \n> was broken. And that's despite the fact that I _tested_ it, and verified \n> the end result by hand.\n> \n> Why? Because I tested it within one repo, by just piping the output of \n> git-pack-objects --stdout directly to the repacker. That seemed to be a \n> good way to test it without setting up anything bigger. But it turns out \n> that it misses one of the big problems: if you don't unpack the objects in \n> a way that later phases can read, none of the streaming code works at all, \n> and you have to buffer up _everything_ in memory just to be able to read \n> any previous _non_delta objects too.\n\nYou are correct that it is not possible to create a pack with all\nobjects expanded in a single pass. But that doesn't mean that a single\npass conversion to a full pack is impossible.\n\nIf we find a delta against a base that is not found in our repository we\ncan keep it as a delta, the base should show up later on in the\nthin-pack. Whenever we find a delta against a base that we haven't seen\nin the received part of the thin pack, but is available from the\nrepository we should expand it because there is a chance we may not see\nthis base in the remainder of the thin-pack.\n\n> So my patch-series works - but it only works in a repo that already has \n> all the objects in question, because then it can look up the objects in \n> the original database. Which makes it useless. Duh.\n\nAbout that patch series, is there a simple way to import the series into\na local repository? git-am doesn't like it, even after splitting it into\nseparate files on the linebreaks. I guess git-mailinfo could be taught\nto recognise the git-log headers. Or have I missed some useful git apply\ntrick.\n\nJan\n"},{"id":"29249","messageId":"20061019161319.GA75501@over-yonder.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610190757100.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-19T16:13:19Z","receivedAt":"2006-10-19T16:13:19Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Thu, Oct 19, 2006 at 08:25:26AM -0700 I heard the voice of\nLinus Torvalds, and lo! it spake thus:\n> \n> The biggest difference seems to be that in bzr, the final checksum\n> is 64-bit,\n\nActually, as best I know, it's not a checksum, just random bits (a\nquick glance at the code seems to agree with me).\n\n\n> Note that from a usability standpoint, the UUID's look more readable\n> to a human, but are actually much worse [...]\n\nThis I agree with, at least in part.\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29250","messageId":"vpq7iyw2sg9.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"72877ab10610190757u3d2b4df0o204c6ffd73af69b4@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-19T16:14:46Z","receivedAt":"2006-10-19T16:14:46Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Tim Webster\" writes:\n\n> First I want to say every SCM I know of sucks when it comes to tracking\n> configurations, simply because they don't record or restore file metadata,\n> like perms, ownership, and acl.\n\nThat's not a simple matter.\n\nTracking ownership hardly makes sense as soon as you have two\ndevelopers on the same project. What does it mean to checkout a file\nbelonging to user foo and group bar on a system not having such user\nand group?\n\nJust restoring the complete user/group/other rwx permission is already\na mess. In my experience (GNU Arch did this):\n\n1) It sucks ;-). Me working with umask 022 so that my collegues can\n \"cp -r\" from me, working on a project with people having umask 077,\n I got some files not readable, some yes, well, a mess. *I* have set\n my umask, and *I* want my tools to obey.\n\n2) It's a security hole. If you work with people having umask=002 (not\n indecent if your default group contains just you), you end-up with\n world-writable files in your ${HOME}.\n\nThat said, it can be interesting to have it, but disabled by default.\n\nThe 'x' bit, OTOH, is definitely useful.\n"},{"id":"29252","messageId":"vpq1wp42rd4.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"87ac3s2syi.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-19T16:38:15Z","receivedAt":"2006-10-19T16:38:15Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Carl Worth writes:\n\n> Yes. We're identifying the core underlying technical difference behind\n> the recent discussion. Namely bzr treats one parent as special, (the\n> parent that was the branch tip previously). And this special treatment\n> eliminates the ability to fast-forward, \n\nNo.\n\nbzr could trivially do fast-forward too. It's an explicit design\ndecision to have two separate commands.\n\n> adds merge commits that wouldn't exist with fast forwarding,\n\nThey don't exist either with \"pull\".\n\nThe difference between bzr and git is smaller than you think on this\npoint I believe.\n\n> There's a bit more to it than that though. The git command named\n> \"pull\" will perform a fast-forward if possible, but will create a\n> merge commit if necessary. For example:\n\nThe bzr command \"pull\" will do a fast-forward if possible, but will\nrefuse to continue and ask you to create the merge commit with other\ncommands if necessary.\n\n> \ta a a\n> \t| pulls | and fast-forwards to |\n> \tb b b\n> \t | |\n> \t c c\n\nSame as bzr.\n\n> whereas:\n>\n> a a a\n> | pulls | and creates a merge / \\\n> b c b c\n> \\ /\n> m\n\nHere, bzr will refuse to pull. It will say \"branches have diverged\"\nand tell you to use merge.\n\nThen, you'll do\n\n$ bzr merge\n\n# optionally \"bzr status\"\n\n$ bzr commit -m \"merged such or such thing\"\n\n\nSo, \"git pull\" seems roughly equivalent to something like\n\n$ bzr pull || (bzr merge; bzr commit -m merge)\n\n> So I'm curious. What does bzr pull do in the case of divergence like\n> this? (And this is the \"numbers will be changed\" case, by the way).\n\nNot yet. The \"numbers will be changed\" is if b pulls, right after.\n\n\nThen, one other difference is in the UI. bzr shows you commits in a\nkind of hierarchical maner, like (fictive example, that's not the real\nexact format).\n\n$ bzr log\ncommiter: upstream@maintainer.com\nmessage:\n merged the work on a feature\n ------\n commiter: contributor@site.com\n message:\n prepared for feature X\n ------\n commiter: contributor@site.com\n message:\n implemented feature X\n ------\n commiter: contributor@site.com\n message:\n added testcase for feature X\n------\ncommiter: upstream@maintainer.com\nmessage:\n something else\n\nNo big difference in the model either, but it probably reveals a\ndifferent vision of what \"history\" means.\n\n-- \nMatthieu\n"},{"id":"29253","messageId":"Pine.LNX.4.64.0610190936440.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061019160750.GS17794@delft.aura.cs.cmu.edu","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-19T16:48:29Z","receivedAt":"2006-10-19T16:48:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 19 Oct 2006, Jan Harkes wrote:\n> \n> If we find a delta against a base that is not found in our repository we\n> can keep it as a delta, the base should show up later on in the\n> thin-pack. Whenever we find a delta against a base that we haven't seen\n> in the received part of the thin pack, but is available from the\n> repository we should expand it because there is a chance we may not see\n> this base in the remainder of the thin-pack.\n\nYes, indeed. We can also have another heuristic: if we find a delta, and \nwe haven't seen the object it deltas against, we can still keep it as a \ndelta IF WE ALSO DON'T ALREADY HAVE THE BASE OBJECT. Because then we know \nthat the base object has to be there later in the pack (or we have a \ndangling delta, which we'll just consider an error).\n\nSo yeah, maybe my patch-series is something we can still save.\n\nHowever, the thing that makes me suspect that it is _not_ saveable, is \nthis:\n\n - let's assume we have a nice thin pack, with object A B C D (in that \n order), which is actually a good pack in itself (ie it _might_ be thin, \n but it's actually self-sufficient)\n\n - let A be a full object, and B be packed as a delta off A, C as a delta \n off B, and D as a delta off C.\n\n - Try to repack it as a streaming thing (the end result _should_ \n obviously be exactly the same as the input, since it turns out to be \n self-sufficient)\n\nLooks trivial, no?\n\nThe answer is: no. It's not trivial. Or rather, it _is_ trivial, but you \nhave to _remember_ all of the actual data for A, B, C and D all the way to \nthe end, because only if you have that data in memory can you actually \n_recreate_ B, C and D even enough to get their SHA1's (which you need, \njust in order to know that the pack is complete, must less to be able to \ncreate a non-delta version in case it hadn't been).\n\nSo we can definitely do the one-pass creation, but it requires that we \nkeep track of everything we've expanded so far in memory (because we won't \nhave the data available any other way - we don't have them as objects in \nour object database, and we don't have a good new pack yet).\n\nBut if you do that, then yes, it's salvageable.\n\n> About that patch series, is there a simple way to import the series into\n> a local repository? git-am doesn't like it, even after splitting it into\n> separate files on the linebreaks. I guess git-mailinfo could be taught\n> to recognise the git-log headers. Or have I missed some useful git apply\n> trick.\n\nNo, you've not missed anything. I didn't really expect anybody to want to \nseriously play with it, so I didn't bother to do things properly. \n\nEspecially since I hadn't even written very good commit messages.\n\nAnyway, I just pushed the \"rewrite-pack\" branch to my git repo on \nkernel.org, so once it mirrors out, if you really want to try to fix up \nthe mess I left behind, there it is:\n\n\tgit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git rewrite-pack\n\nMaybe it's recoverable. \n\n\t\tLinus\n"},{"id":"29254","messageId":"Pine.LNX.4.64.0610190948540.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061019161319.GA75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-19T16:49:46Z","receivedAt":"2006-10-19T16:49:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 19 Oct 2006, Matthew D. Fuller wrote:\n\n> On Thu, Oct 19, 2006 at 08:25:26AM -0700 I heard the voice of\n> Linus Torvalds, and lo! it spake thus:\n> > \n> > The biggest difference seems to be that in bzr, the final checksum\n> > is 64-bit,\n> \n> Actually, as best I know, it's not a checksum, just random bits (a\n> quick glance at the code seems to agree with me).\n\nAhh. They may be that even in BK. I know BK had various 16-bit CRC \nchecksums, but they were probably on the actual _file_ contents, not in \nthe key itself.\n\n\t\tLinus\n"},{"id":"29255","messageId":"878xjc2qeb.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"453792A8.1010700@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-19T16:59:08Z","receivedAt":"2006-10-19T16:59:08Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 19 Oct 2006 10:58:48 -0400, Aaron Bentley wrote:\n> >> In bzr development, it's very rare for anyone's revision numbers to change.\n> >\n> > Which just says to me that the bzr developers really are sticking to a\n> > centralized model.\n>\n> I don't see why you're reaching that conclusion. I'd like to understand\n> that better, because Linus seems to be concluding the same thing, and it\n> doesn't make sense to me.\n\nFirst, I want to point out that I think we're having a delightfully\nenlightening conversation here, and I'm glad for that.\n\nLet me provide a couple of hypothetical situations to try to\ndemonstrate my thinking here. The first is far-fetched but perhaps\neasier to understand the implications. But the second is the real,\neveryday situation that is much more important.\n\nFar-fetched\n-----------\nLet's imagine there's a complete fork in the bzr codebase tomorrow. We\nneed not suppose any acrimony, just an amiable split as two subsets of\nthe team start taking the code in different directions.\n\nNow, at the time of the fork, all published revision numbers apply\nequally well to either team's codebase, (obviously, since they are\nidentical). But as the projects diverge they each start publishing\nrevision numbers with respect to their own repositories in their own\nbug trackers, etc. Obviously, each project has its own \"mainline\" so\nthese new revision numbers are only unique within each project and not\nbetween the two.\n\nTime passes...\n\nFinally the two teams (who had remained good friends after the\nbreakup) find a unifying theory that will let them work on a single\ntool that will meet the needs of both user bases. So they want to\nmerge their code together.\n\nAfter the merge, there can be only one mainline, so one team or the\nother will have to concede to give up the numbers they had generated\nand published during the fork. That is, the numbers will not be usable\nwithin the new, merged repository.\n\nEveryday\n--------\nNow, the above scenario is just silly. It's not likely to ever happen,\nso it's really not worth considering as a motivating case.\n\nBut, what does (and should) happen everyday is exactly the same. So\nhere's a realistic situation that is worth considering:\n\nAn individual takes the bzr codebase and starts working on it. It's\nexperimental stuff, so it's not pushed back into the central\nrepository yet. But our coder isn't a total recluse, so his friends\nhelp him with the code he's working on. They communicate about their\nwork, (perhaps on the main bzr mailing list), and make statements such\nas \"feature F is working perfectly as of version V\".\n\nBut for these communications, revision numbers will not provide\nhistorically stable values that can be used. It's impossible for our\ncoder to predict the numbers that will be assigned to his code when\nthey get merged back into the mainline---since some other unknown\nprogrammer may have branched at exactly the same point and is trying\nto make the same determination. Neither programmer can know which code\nwill land first, so neither can know what numbers will get assigned,\nright?\n\nNow, the programmers could get stable numbers by keeping the branch in\nthe main tree, or by at least pushing out the branching point to\n\"reserve\" a number in the main tree.\n\nSo, the only way to get stable numbers is to rely on this central\ntree.\n\nDoes that make sense?\n\n> That doesn't follow. Just because something is arguably true doesn't\n> make it bad. And in this case, I'm not arguing that it's true, I'm\n> saying that it's true, because that is what my experience tells me is true.\n\n[I'm sorry, but I didn't grasp this sentence. I think I lost the\nantecedent of \"it\" somewhere.]\n\n> > In cairo, for example, we've made a habit of including a revision\n> > identifier in our bug tracking system for every commit that resolves a\n> > bug.\n>\n> We do it the other way around: we put a bug number in the commit\n> message.\n\nOh, we do that too. That number is important, (for \"what the heck is\nthis commit trying to do, and why\", since (sadly) much of the why ends\nup getting stuck off in external bug tracking tools). But the reverse\ndirection is also important, (\"Hey, this bug got fixed in the\ndevelopment version, but I want to backport it to my distribution\npackage. Where can I find it?\").\n\n> And I personally have been developing a bugtracker that is\n> distributed in the same way bzr is; it stores bug data in the source\n> tree of a project, so that bug activities follow branches around.\n\nThat kind of thing sounds very useful. As I've been talking about\n\"numbers\" here in bug trackers and mailing lists, it should be obvious\nthat I consider the information stored in such systems an important\npart of the history of a code project. So it would be nice if all of\nthat history were stored in an equally reliable system in some way.\n\n> On the other hand, I think your revision identifiers are not as\n> permanent as you think.\n>\n> In the first place, it seems fairly common in the Git community to\n> rebase. This process throws away old revisions and creates new\n> revisions that are morally equivalent[1].\n\nYes, rebasing does \"destroy history\" in one sense, (in actual fact, it\ncreates new commits and leaves the old ones around, which may or may\nnot have references to them anymore). But i's definitely not common\nfor git users to use rebase in a situation where it would change any\npublished number.\n\nFor example, I regularly use git-rebase, (and similar \"git-commit\n --amend\"), as I'm putting together a new branch that exists only\nin a repository on my laptop with nobody having external visibility to\nit.\n\nSo, if I see a typo in a commit and I've never pushed it anywhere,\nI'll just \"git commit --amend\" to fix it. But if I see that typo only\nafter I push out the change, then I just make a new commit to fix it,\n(and suck up the fact that my mistake will be a permanent part of the\nhistory).\n\nAnd git helps with this as well. If I ever forget that I've already\npushed a change and then I rebase, then the next time I try to push,\ngit will complain that I'm attempting to throw away history on the\nremote end, and will refuse to cooperate, (unless I force it).\n\nThere's a similar safety mechanism on the pull side. If I did force a\nhistory-rewriting push, then users who tried to pull it would also\nhave to force git's hand before it would rewrite their history.\n\n[By the way, it is sometimes useful to make chaotic, regularly-rebased\nbranches visible to others, so they can watch what's going on. (Junio\ndoes this with his \"proposed updates (pu)\" branch in hit repository\nfor git itself, for example). It's just that such branches should\nnever be used to start new development if they expect to pull from the\nbranch again later, nor should the revision numbers of such a branch\never be considered permanent, nor published anywhere.]\n\n> In the second place, one must consider the \"nuclear launch codes\"\n> scenario.\n\nSure. And git does provide tools that can do this. Of course, the\n\"normal\" tools strictly add new commits and move branches (which are\nno more than references to commits) around. But moving branches can\nleave commits unreferenced. And a \"prune\" command does exist, (which\nisn't needed in \"normal\" use), which will delete unreferenced objects.\n\n-Carl\n\n> [1] This is a process that I find discomforting, because I consider the\n> original revisions to be real, historical data, and I don't like the\n> idea of throwing it away.\n\nAs I mentioned above. They aren't thrown away. I often use rebase when\nre-building an ugly series of patches into a nice clean set of\npatches. And in that situation, I might rebase from the old to the\nnew, but still with a reference to the old branch until I'm done with\nthe entire process. And it's perfectly possible, and legitimate that\nsuch a reference has been published and the old branch will live\n\"forever\" even if I rebased it. So rebase isn't necessarily\ndestructive.\n"},{"id":"29256","messageId":"8764eg2qaa.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"453792A8.1010700@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-19T17:01:33Z","receivedAt":"2006-10-19T17:01:33Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 19 Oct 2006 10:58:48 -0400, Aaron Bentley wrote:\n> >> In bzr development, it's very rare for anyone's revision numbers to change.\n> >\n> > Which just says to me that the bzr developers really are sticking to a\n> > centralized model.\n>\n> I don't see why you're reaching that conclusion. I'd like to understand\n> that better, because Linus seems to be concluding the same thing, and it\n> doesn't make sense to me.\n\nFirst, I want to point out that I think we're having a delightfully\nenlightening conversation here, and I'm glad for that.\n\nLet me provide a couple of hypothetical situations to try to\ndemonstrate my thinking here. The first is far-fetched but perhaps\neasier to understand the implications. But the second is the real,\neveryday situation that is much more important.\n\nFar-fetched\n-----------\nLet's imagine there's a complete fork in the bzr codebase tomorrow. We\nneed not suppose any acrimony, just an amiable split as two subsets of\nthe team start taking the code in different directions.\n\nNow, at the time of the fork, all published revision numbers apply\nequally well to either team's codebase, (obviously, since they are\nidentical). But as the projects diverge they each start publishing\nrevision numbers with respect to their own repositories in their own\nbug trackers, etc. Obviously, each project has its own \"mainline\" so\nthese new revision numbers are only unique within each project and not\nbetween the two.\n\nTime passes...\n\nFinally the two teams (who had remained good friends after the\nbreakup) find a unifying theory that will let them work on a single\ntool that will meet the needs of both user bases. So they want to\nmerge their code together.\n\nAfter the merge, there can be only one mainline, so one team or the\nother will have to concede to give up the numbers they had generated\nand published during the fork. That is, the numbers will not be usable\nwithin the new, merged repository.\n\nEveryday\n--------\nNow, the above scenario is just silly. It's not likely to ever happen,\nso it's really not worth considering as a motivating case.\n\nBut, what does (and should) happen everyday is exactly the same. So\nhere's a realistic situation that is worth considering:\n\nAn individual takes the bzr codebase and starts working on it. It's\nexperimental stuff, so it's not pushed back into the central\nrepository yet. But our coder isn't a total recluse, so his friends\nhelp him with the code he's working on. They communicate about their\nwork, (perhaps on the main bzr mailing list), and make statements such\nas \"feature F is working perfectly as of version V\".\n\nBut for these communications, revision numbers will not provide\nhistorically stable values that can be used. It's impossible for our\ncoder to predict the numbers that will be assigned to his code when\nthey get merged back into the mainline---since some other unknown\nprogrammer may have branched at exactly the same point and is trying\nto make the same determination. Neither programmer can know which code\nwill land first, so neither can know what numbers will get assigned,\nright?\n\nNow, the programmers could get stable numbers by keeping the branch in\nthe main tree, or by at least pushing out the branching point to\n\"reserve\" a number in the main tree.\n\nSo, the only way to get stable numbers is to rely on this central\ntree.\n\nDoes that make sense?\n\n> That doesn't follow. Just because something is arguably true doesn't\n> make it bad. And in this case, I'm not arguing that it's true, I'm\n> saying that it's true, because that is what my experience tells me is true.\n\n[I'm sorry, but I didn't grasp this sentence. I think I lost the\nantecedent of \"it\" somewhere.]\n\n> > In cairo, for example, we've made a habit of including a revision\n> > identifier in our bug tracking system for every commit that resolves a\n> > bug.\n>\n> We do it the other way around: we put a bug number in the commit\n> message.\n\nOh, we do that too. That number is important, (for \"what the heck is\nthis commit trying to do, and why\", since (sadly) much of the why ends\nup getting stuck off in external bug tracking tools). But the reverse\ndirection is also important, (\"Hey, this bug got fixed in the\ndevelopment version, but I want to backport it to my distribution\npackage. Where can I find it?\").\n\n> And I personally have been developing a bugtracker that is\n> distributed in the same way bzr is; it stores bug data in the source\n> tree of a project, so that bug activities follow branches around.\n\nThat kind of thing sounds very useful. As I've been talking about\n\"numbers\" here in bug trackers and mailing lists, it should be obvious\nthat I consider the information stored in such systems an important\npart of the history of a code project. So it would be nice if all of\nthat history were stored in an equally reliable system in some way.\n\n> On the other hand, I think your revision identifiers are not as\n> permanent as you think.\n>\n> In the first place, it seems fairly common in the Git community to\n> rebase. This process throws away old revisions and creates new\n> revisions that are morally equivalent[1].\n\nYes, rebasing does \"destroy history\" in one sense, (in actual fact, it\ncreates new commits and leaves the old ones around, which may or may\nnot have references to them anymore). But i's definitely not common\nfor git users to use rebase in a situation where it would change any\npublished number.\n\nFor example, I regularly use git-rebase, (and similar \"git-commit\n --amend\"), as I'm putting together a new branch that exists only\nin a repository on my laptop with nobody having external visibility to\nit.\n\nSo, if I see a typo in a commit and I've never pushed it anywhere,\nI'll just \"git commit --amend\" to fix it. But if I see that typo only\nafter I push out the change, then I just make a new commit to fix it,\n(and suck up the fact that my mistake will be a permanent part of the\nhistory).\n\nAnd git helps with this as well. If I ever forget that I've already\npushed a change and then I rebase, then the next time I try to push,\ngit will complain that I'm attempting to throw away history on the\nremote end, and will refuse to cooperate, (unless I force it).\n\nThere's a similar safety mechanism on the pull side. If I did force a\nhistory-rewriting push, then users who tried to pull it would also\nhave to force git's hand before it would rewrite their history.\n\n[By the way, it is sometimes useful to make chaotic, regularly-rebased\nbranches visible to others, so they can watch what's going on. (Junio\ndoes this with his \"proposed updates (pu)\" branch in hit repository\nfor git itself, for example). It's just that such branches should\nnever be used to start new development if they expect to pull from the\nbranch again later, nor should the revision numbers of such a branch\never be considered permanent, nor published anywhere.]\n\n> In the second place, one must consider the \"nuclear launch codes\"\n> scenario.\n\nSure. And git does provide tools that can do this. Of course, the\n\"normal\" tools strictly add new commits and move branches (which are\nno more than references to commits) around. But moving branches can\nleave commits unreferenced. And a \"prune\" command does exist, (which\nisn't needed in \"normal\" use), which will delete unreferenced objects.\n\n-Carl\n\n> [1] This is a process that I find discomforting, because I consider the\n> original revisions to be real, historical data, and I don't like the\n> idea of throwing it away.\n\nAs I mentioned above. They aren't thrown away. I often use rebase when\nre-building an ugly series of patches into a nice clean set of\npatches. And in that situation, I might rebase from the old to the\nnew, but still with a reference to the old branch until I'm done with\nthe entire process. And it's perfectly possible, and legitimate that\nsuch a reference has been published and the old branch will live\n\"forever\" even if I rebased it. So rebase isn't necessarily\ndestructive.\n"},{"id":"29257","messageId":"20061019170638.GB75501@over-yonder.net","threadId":"5925","inReplyTo":"20061019160103.GZ75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-19T17:06:38Z","receivedAt":"2006-10-19T17:06:38Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Thu, Oct 19, 2006 at 11:01:03AM -0500 I heard the voice of\nMatthew D. Fuller, and lo! it spake thus:\n>\n> Now, the question of \"is that merge commit E really necessary, when\n> you could just attach D to the end of the graph and create something\n> like [...] is perhaps a useful question (and one that there's\n> obviously disagreement on). And it may be a fruitful one to\n> discuss, if we're not way off in the weeds already.\n>\n> But, it's also not QUITE the same question as \"Is the left-vs-other\n> path distinction meaningful and to be preserved?\"\n\nLet me elaborate a little on this.\n\nbzr COULD create\n\n> a-.\n> |\\ \\\n> b c |\n> |/ /\n> D-'\n\ninstead of\n\n> a-.\n> |\\ \\\n> b c |\n> |\\|/\n> | D\n> |/ \n> E\n\nfor the previously discussed merge, basically duplicating\n'fast-forward' behavior. It doesn't currently, but it could just as\nwell without disturbing the attributes it gains from assigning meaning\nto the left-most parent. The choice to create E is the result of an\nindependent decision from the choice to treat the left path as\nspecial.\n\n\nWhat the leftmost discussion impacts is the case of \n\n a-.\n |\\ \\\n | b c\n |/ /\n D-'\n\nvs\n\n a-.-.\n \\ \\ \\\n b c |\n / / /\n D-'-'\n\nNow, the branches are distinct to bzr, but they're not different. If\nyou try to merge one from the other, merge will quite rightly tell you\nthere's nothing to do, since you both have all the same revs. git\ndoesn't recognize the distinction at all, of course. The difference\nis mostly cosmetic. But, it's a cosmetic difference that bzr devs\n(and users, I venture) find _useful_, which is why it's fought for.\nAnd everything else seems to follow from that.\n\nIf you don't think the distinction is meaningful or useful, you can\nignore it, and the tool should work just fine. The main place the\ndistinction would show up is in the cosmetics of how \"log\" looks (and\nprobably similarly in any tool that graphically describes ancestry),\nand a custom log output formatter could probably be very easily\nwritten to obviate even that.\n"},{"id":"29258","messageId":"20061019171409.GA31671@fieldses.org","threadId":"5925","inReplyTo":"8764eg2qaa.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-10-19T17:14:09Z","receivedAt":"2006-10-19T17:14:09Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Oct 19, 2006 at 10:01:33AM -0700, Carl Worth wrote:\n> On Thu, 19 Oct 2006 10:58:48 -0400, Aaron Bentley wrote:\n> > On the other hand, I think your revision identifiers are not as\n> > permanent as you think.\n> >\n> > In the first place, it seems fairly common in the Git community to\n> > rebase. This process throws away old revisions and creates new\n> > revisions that are morally equivalent[1].\n> \n> Yes, rebasing does \"destroy history\" in one sense, (in actual fact, it\n> creates new commits and leaves the old ones around, which may or may\n> not have references to them anymore).\n\nNote that the id's are still permanent in this case; they will never\n(module some assumptions about the crypto) be reused. So a given id\npoints at one and only one object, for all time; it's just that we may\nforget what that one object is....\n\n> > In the second place, one must consider the \"nuclear launch codes\"\n> > scenario.\n> \n> Sure. And git does provide tools that can do this.\n\nSo in this case you can certainly lose the launch codes. But you have\nforever granted everyone a way to determine whether a given guess at the\nlaunch codes is correct. (Again, assuming some stuff about SHA1).\n\n--b.\n"},{"id":"29260","messageId":"Pine.LNX.4.64.0610191110290.3962@g5.osdl.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610190948540.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-19T18:30:15Z","receivedAt":"2006-10-19T18:30:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 19 Oct 2006, Linus Torvalds wrote:\n> \n> Ahh. They may be that even in BK. I know BK had various 16-bit CRC \n> checksums, but they were probably on the actual _file_ contents, not in \n> the key itself.\n\nBtw, I do believe that bzr seems to be acting a lot like BK, at least when \nit comes to versioning. I suspect that is not entirely random either, and \nI suspect it's been a conscious effort to some degree.\n\nWhich is fine, in the sense that there are certainly much worse things to \ntry to copy.\n\nThat said, at least BK was up-front about the versions changing, and \ndidn't try to do anything to hinder it. It still confused some people, and \nit wasn't a great naming system, but it did work.\n\nIn the big picture, the version naming between BK and git hasn't been an \nissue for anybody in practice, I suspect.\n\nSo if you want to look at features that actually matter more, try out \nsomething like\n\n\tgitk drivers/scsi include/scsi\n\non the kernel archive (I assume that somebody has tried importing the \nkernel git tree into bzr - quite frankly, if bzr cannot handle that size \ntree without problems, you have much bigger issues!).\n\nIn other words, being able to look at history of more than a single file \nhas been a _huge_ bonus. \n\nThe other big difference is being able to do merges in seconds. The \nbiggest cost of doing a big merge these days seems to literally be \ngenerating the diffstat of the changes at the end (which is purely a UI \nissue, but one that I find so important that I'll happily take the extra \nfew seconds for that, even if it sometimes effectively doubles the \noverhead).\n\nLooking at the dates of the merges yesterday, they're literally half a \nminute apart, and that's not me _scripting_ them - that's me actually \nlooking up the emails, typing in the \"git pull \" and pasting the source \nrepository, and git fetching the data over the network and merging it, and \nchecking out the result (and me verifying that the resulting diffstat \nmatches what the email says). Doing four of those in a row in less than \ntwo minutes is actually a really big deal.\n\nAt some point, \"performance\" is just more than a question of how fast \nthings are, it becomes a big part of usability.\n\n\t\t\tLinus\n"},{"id":"29261","messageId":"vpqlknc3zmn.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610191110290.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-19T18:54:24Z","receivedAt":"2006-10-19T18:54:24Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Linus Torvalds writes:\n\n> Btw, I do believe that bzr seems to be acting a lot like BK, at least when \n> it comes to versioning. I suspect that is not entirely random either, and \n> I suspect it's been a conscious effort to some degree.\n>\n> Which is fine, in the sense that there are certainly much worse things to \n> try to copy.\n\nBy curiosity, how would you compare git and Bitkeeper, on a purely\ntechnical basis? (not asking for a detailed comparison, but an \"X is\nglobaly/much/terribly/not better than Y\" kind of statement ;-) )\n"},{"id":"29264","messageId":"loom.20061019T205327-196@post.gmane.org","threadId":"5925","inReplyTo":"45345CBE.8020209@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Nathaniel Smith","fromEmail":"njs@pobox.com","sentAt":"2006-10-19T19:01:50Z","receivedAt":"2006-10-19T19:01:50Z","isPatch":false,"sender":{"key":"njs@pobox.com","avatar":null},"body":"Aaron Bentley utoronto.ca> writes:\n> Bazaar also supports multiple unrelated branches in a repository, as\n> does CVS, SVN (depending how you squint), Arch, and probably Monotone.\n\nIt's quite common in Monotone. You could probably do it in Mercurial as well,\nthough I don't know that anyone does. SVK definitely does it (since each user\nhas a single repo that's shared by all the projects they work on).\n\nTrivia-ly yours,\n-- Nathaniel\n"},{"id":"29263","messageId":"7vac3sru9a.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610191110290.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-19T19:16:33Z","receivedAt":"2006-10-19T19:16:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> The other big difference is being able to do merges in seconds. The \n> biggest cost of doing a big merge these days seems to literally be \n> generating the diffstat of the changes at the end (which is purely a UI \n> issue, but one that I find so important that I'll happily take the extra \n> few seconds for that, even if it sometimes effectively doubles the \n> overhead).\n\nAn interesting effect on this is when people have a column for\nmerge performance in a SCM comparison table, they would include\ntime to run the diffstat as part of the time spent for merging\nwhen they fill in the number for git, but not for any other SCM.\n\nI know you won't misunderstand me but for the sake of others, I\nshould add this: I am not saying diffstat should be optional.\n"},{"id":"29265","messageId":"Pine.LNX.4.64.0610191258290.3962@g5.osdl.org","threadId":"5925","inReplyTo":"vpqlknc3zmn.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-19T20:47:53Z","receivedAt":"2006-10-19T20:47:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 19 Oct 2006, Matthieu Moy wrote:\n> \n> By curiosity, how would you compare git and Bitkeeper, on a purely\n> technical basis? (not asking for a detailed comparison, but an \"X is\n> globaly/much/terribly/not better than Y\" kind of statement ;-) )\n\nI think git is better for kernel work these days, but a large portion of \nthat is that a lot of the features have literally been tweaked for us (for \nvery obvious reasons).\n\nFor example, the whole \"rebase\" thing (or explicitly making cherry-picking \neasy) is something that a number of kernel people do, and even if I have \nto admit to not liking the practice very much (it kind of hides the \"true\" \ndevelopment history), it does have huge advantages, and it makes history a \nlot easier to read.\n\nSimilarly, I often used the single-file graphical history viewing in BK \n(\"revtool\"), but being able to follow the history of multiple files as one \n\"entity\" really is something that once you get used to, it's really really \nhard going back, and \"gitk\" does generate a much more readable graph.\n\nAnd I think the git way of doing branches is just simply superior. Git \nalways did branches in the sense that the way merges happened you _always_ \nhad several heads, but actually making them available and switching \nbetween them was something that wasn't my idea, and that I even was a bit \napprehensive about. I was wrong. Git branches are branches done right. I \njust don't see how you _could_ do them better.\n\nThat said, a lot of the features I like and _I_ consider really important \nare possibly not that important to others. For example, maybe nobody else \nreally cares about viewing the history of a particular subsystem, the way \nI do. For a lot of people, single-file is probably ok. \n\nFor example, while git now does \"annotate\" (or \"blame\"), it's not \nlightning fast, and I simply don't care. Doing a\n\n\tgit blame kernel/sched.c\n\ntakes about three seconds for me, and that's on a pretty good machine (and \non the kernel tree, which for me is always in the cache ;). Quite frankly, \nif I cared deeply about that kind of annotation, I'd probably be upset \nabout it. There are basically _no_ other git operations that take that \nlong. I can get the _full_ log of the last 18 months of the kernel much \nfaster than that.\n\nAnd the slowness of annotate comes directly from the design of git, and \nfrom the fact that it's not how I tend to look at changes. Rather than \ndoing \"git blame kernel/sched.c\", I'm _much_ more likely to just do\n\n\tgit log -p kernel/sched.c\n\nand see the changes as individual patches instead (and perhaps search for \nsome pattern that I'm looking for by just literally using a regex in the \npager).\n\nAlso, the fact that you need to repack the archive every once in a while \ndoesn't disturb me. I probably end up repacking the kernel almost daily, \nwhich is _waay_ excessive, but it's just become habit of mine. I've seen \npeople who really don't like it, and I've also seen people who apparently \nnever even realized that they should do an occasional \"git repack -a -d\", \nand then they have hundreds of thousands of loose objects and wonder why \nthe performance is so bad ;)\n\nBK never had these issues. BK always kept things \"packed\", which made a \nlot of operations much slower (\"bk undo\" was painfully slow). BK could \nannotate quickly, since it was really a file-based history, in a way that \ngit fundamentally isn't, and can never be (and I don't _want_ it to be, \nbut it means that \"annotate\" is slow).\n\nAnd BK had some great tools. The merge tool was superior (\"bk resolve\"? I \nforget). The patch-application tool was great.\n\nBut both of those tools are things that git doesn't have, for _another_ \nreason: the way git works, you don't really need them. For example, the \npatch application tool was great, but the biggest reason it was needed in \nthe first place was tracking renames explicitly.\n\nIn that kind of environment, you have serious problems with patches, and \nyou actually _need_ a tool to let the user explain when something is a \nrename and when it isn't. With git not tracking renames, the patch \napplication tool simply isn't needed.\n\nThe same goes to some degree to \"bk resolve\". Because git has the index, \nand you can _leave_ things unresolved in the index, you don't need a \ngraphical tool to resolve things - git knows very fundamentally about \nincomplete merges _and_ about multiple branches (which you need in order \nto keep track of both the branch you merge from and the branch you merge \ninto), and it's fine to resolve any conflicts in the normal working tree.\n\nSo for at least _my_ usage, git does everything very well, but that's \nbecause if it didn't fit me, I fixed it until it did. \n\nAnd \"git bisect\" really does rock. I still cannot believe that apparently \nnobody did it before us. It's such a useful thing, and it works so well in \nunambiguous cases (and not all cases are that unambiguous, but an \nappreciably large subset is).\n\nSo that said, git does work very well for us, but I do want to end on a \nnote on thigns that BitKeeper did and nobody else has:\n\n - Larry was first. The undeniable fact is, that before BK (and for \n several years _after_ BK), the open-source alternatives were just CRAP.\n\n You can say anything you like about his personality, but dammit, \n compared to Larry, most people I know are idiots. People don't give BK \n the credit it deserves. When Tridge \"reverse-engineered\" it, people \n were making jokes about how trivial some of the protocols were. That \n misses the point ENTIRELY. The point is, compared to BK, everything \n else absolutely _sucked_, and BK really was a watershed program.\n\n Never EVER underestimate how important BK was. Quite frankly, I think \n most open-source SCM's _still_ suck. I'm constantly amazed that anybody \n would touch SVN with a ten-foot pole. Talk about crap. And SVN is at \n least usable, unlike a lot of other projects.\n\n - When I did git, one of the things that actually _helped_ me was that I \n was consciously trying to not do a BK clone. I wanted to do the same \n things that BK did, but I very much did _not_ want to do them the _way_ \n BK did them. I respect Larry too much, and I didn't want there to be \n any question about git being just a \"clone\".\n\n So a lot of the git design ended up very much trying to avoid old \n designs on purpose, and I think that really helped. The fact that I \n didn't have a background in SCM's, and that I thought all the weaves \n etc were confusing, meant that I instead went for a radically different \n way of doing things.\n\n And I'm 100% convinced that \"radically different\" was the right thing \n to do. That was what allowed git to really soar. A lot of the good \n things in git come exactly from the fact that git does _not_ do things \n like most traditional SCM's do. But BK should still get a lot of \n credit, because it was what taught me (and a lot of other people) what \n being \"distributed\" really meant.\n\n - On a more personal note: people say that BK showed the \"failure\" of \n using a commercial closed-source program. I would disagree. Not only \n did the kernel get a whole lot of useful work out of BK, we learnt how \n distributed systems _should_ work, and quite frankly, I'd do ít all \n over again in a heartbeat.\n\n If there was a \"failure\" in the BK saga, it was in how horrendously \n _bad_ all open-source SCM's were, even with BK showing how it should \n have been done for several years. THAT is the failure. The fact that \n there were hundreds of people who whined about BK, and nobody really \n did anything productive. \n\nNow, I'm obviously biased, but I really do believe that git is the best \nopen-source SCM there is, by a _mile_. I don't know how many people \nrealize this, but we literally haven't changed our data formats in over a \nyear. I was looking at my old git import of the BKCVS tree today, because \nI wanted to look up the \"BKrev\" format for the email earlier in this tree, \nand I realized that the pack-file was from July of last year. That's \nwithin a few _weeks_ of the pack-file being introduced at all, and guess \nwhat? It all still worked. No \"on-the-fly format conversion\", no \n_nothing_. It just worked.\n\nThat should tell people something. It's pretty much the fastest SCM out \nthere (and yeah, that's on almost any operation you can name), it still \nhas the smallest disk footprint I've ever heard of, and it hasn't had the \n\"format of the week\" disease that every other project seems to go through.\n\nAnd it's used in production settings on some of the biggest projects out \nthere. SVN has more users, but let's face it, SVN really isn't even in the \nrunning. Technology-wise, the thing is just not worth bothering with, but \nit's a good crutch for people who are used to CVS and never want to use \nanything lse.\n\nAm I happy with git? I'm happy as a clam. It turned out even better than I \never thought it would. And BK was what taught me what to aim for.\n\n\t\t\tLinus"},{"id":"29268","messageId":"453803E6.2060309@utoronto.ca","threadId":"5925","inReplyTo":"878xjc2qeb.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-19T23:01:58Z","receivedAt":"2006-10-19T23:01:58Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nCarl Worth wrote:\n> On Thu, 19 Oct 2006 10:58:48 -0400, Aaron Bentley wrote:\n\n> Let's imagine there's a complete fork in the bzr codebase tomorrow. We\n> need not suppose any acrimony, just an amiable split as two subsets of\n> the team start taking the code in different directions.\n\n...\n\n> Finally the two teams ... want to\n> merge their code together.\n> \n> After the merge, there can be only one mainline, so one team or the\n> other will have to concede to give up the numbers they had generated\n> and published during the fork.\n\nI don't think this is true. The abandoned mainline does not need to be\ndestroyed. It can be kept at the same location that it always was, with\nthe numbers that it always had. So the number + URL combo stays\nmeaningful. Additionally, the new mainline can keep a mirror of the\nabandoned mainline in its repository, because there are virtually no\nadditional storage requirements to doing so.\n\n> An individual takes the bzr codebase and starts working on it. It's\n> experimental stuff, so it's not pushed back into the central\n> repository yet. But our coder isn't a total recluse, so his friends\n> help him with the code he's working on. They communicate about their\n> work, (perhaps on the main bzr mailing list), and make statements such\n> as \"feature F is working perfectly as of version V\".\n> \n> But for these communications, revision numbers will not provide\n> historically stable values that can be used.\n\nThey certainly can.\n\nThe coder says \"I've put up a branch at http://example.com/bzr/feature.\n In revision 5, I started work on feature A. I finished work in\nrevision 6. But then I had to fix a related bug in revision 7.\"\n\nAs long as that coder is active, they'll keep their repository at the\nsame location. And because branches are cheap (even cheaper than\ndelta-compressed revisions), there's no reason to delete old branches.\nIt's better to keep them around for reference purposes.\n\n> It's impossible for our\n> coder to predict the numbers that will be assigned to his code when\n> they get merged back into the mainline---since some other unknown\n> programmer may have branched at exactly the same point and is trying\n> to make the same determination.\n\nThis is true, but his code is likely to all land in the mainline at\nonce. Since his own revnos are more fine-grained, he's not likely want\nto use the mainline revnos.\n\n> Now, the programmers could get stable numbers by keeping the branch in\n> the main tree, or by at least pushing out the branching point to\n> \"reserve\" a number in the main tree.\n\nI don't know what you mean by pushing out the branching point.\n\n>> That doesn't follow. Just because something is arguably true doesn't\n>> make it bad. And in this case, I'm not arguing that it's true, I'm\n>> saying that it's true, because that is what my experience tells me is true.\n> \n> [I'm sorry, but I didn't grasp this sentence. I think I lost the\n> antecedent of \"it\" somewhere.]\n\nI felt that you were mischaracterizing my _statement_ that \"it's\nexceedingly uncommon for [revnos] to change\" as an _argument_ \"it's\nexceedingly uncommon for [revnos] to change\". The reality is that we\nkeep saying revnos don't change because git users keep saying \"but what\nif the revnos change?\".\n\n\n>> And I personally have been developing a bugtracker that is\n>> distributed in the same way bzr is; it stores bug data in the source\n>> tree of a project, so that bug activities follow branches around.\n> \n> That kind of thing sounds very useful. As I've been talking about\n> \"numbers\" here in bug trackers and mailing lists, it should be obvious\n> that I consider the information stored in such systems an important\n> part of the history of a code project. So it would be nice if all of\n> that history were stored in an equally reliable system in some way.\n\nIf you're interested, it's called \"Bugs Everywhere\" and it's available here:\nhttp://panoramicfeedback.com/opensource/\n\nNew VCS backends are welcome :-D\n\n>> In the first place, it seems fairly common in the Git community to\n>> rebase. This process throws away old revisions and creates new\n>> revisions that are morally equivalent[1].\n> \n> Yes, rebasing does \"destroy history\" in one sense, (in actual fact, it\n> creates new commits and leaves the old ones around, which may or may\n> not have references to them anymore). But i's definitely not common\n> for git users to use rebase in a situation where it would change any\n> published number.\n\nSo actually, not all branches are treated equally by Git users. Public\nbranches are treated as append-only, but private branches are treated as\nmutable. (It's the same with bzr users, of course.)\n\n> And git helps with this as well. If I ever forget that I've already\n> pushed a change and then I rebase, then the next time I try to push,\n> git will complain that I'm attempting to throw away history on the\n> remote end, and will refuse to cooperate, (unless I force it).\n\nSame here.\n\n> There's a similar safety mechanism on the pull side. If I did force a\n> history-rewriting push, then users who tried to pull it would also\n> have to force git's hand before it would rewrite their history.\n\nSame here.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFOAPm0F+nu1YWqI0RAhkdAJ9InxuEjbToGQU2AOJmfZw124Lb2wCeMmDC\n9w08eZbmL19FfVQmtpPcYkQ=\n=AmGo\n-----END PGP SIGNATURE-----\n"},{"id":"29270","messageId":"87dcb0bd0610191628h2bbb5a3o8f445718312ac44c@mail.gmail.com","threadId":"5925","inReplyTo":"vpqlknc3zmn.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Ryan Anderson","fromEmail":"rda@google.com","sentAt":"2006-10-19T23:28:24Z","receivedAt":"2006-10-19T23:28:24Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On 10/19/06, Matthieu Moy wrote:\n> Linus Torvalds writes:\n>\n> > Btw, I do believe that bzr seems to be acting a lot like BK, at least when\n> > it comes to versioning. I suspect that is not entirely random either, and\n> > I suspect it's been a conscious effort to some degree.\n> >\n> > Which is fine, in the sense that there are certainly much worse things to\n> > try to copy.\n>\n> By curiosity, how would you compare git and Bitkeeper, on a purely\n> technical basis? (not asking for a detailed comparison, but an \"X is\n> globaly/much/terribly/not better than Y\" kind of statement ;-) )\n\nHaving used both in a past job setting (simultaneously even),\nBitKeeper was a huge win over CVS, but after a while, some of its\ntools were just very frustrating in comparison with comparable Git\ninterfaces, and I had actually written a terribly slow BK -> Git\nconverter just so I could incrementally import our BK tree, then use\nGit's history-viewing because it was so much more pleasant to work\nwith.\n\nFor small projects (~5 people), they weren't hugely different, but Git\njust felt more comfortable after a while. (It was actually possible\nto do a commit from the command line in a single command, without\ngetting annoyed by the interface, for a trivial example.)\n"},{"id":"29271","messageId":"87ods727pn.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"453803E6.2060309@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-19T23:42:44Z","receivedAt":"2006-10-19T23:42:44Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 19 Oct 2006 19:01:58 -0400, Aaron Bentley wrote:\n> I don't think this is true. The abandoned mainline does not need to be\n> destroyed. It can be kept at the same location that it always was, with\n> the numbers that it always had. So the number + URL combo stays\n> meaningful.\n\nSure that's possible, but it gets rather unwieldy the more\nrepositories you have involved. I've been arguing that bzr really does\nencourage centralized, not distributed development, and you were having\ntrouble seeing how I came to that conclusion. Do you see how \"maintain\nan independent URL namespace for every distributed branch\" doesn't\nencourage much distributed development?\n\n> Additionally, the new mainline can keep a mirror of the\n> abandoned mainline in its repository, because there are virtually no\n> additional storage requirements to doing so.\n\nAnd this part I don't understand. I can understand the mainline\nstoring the revisions, but I don't understand how it could make them\naccessible by the published revision numbers of the \"abandoned\"\nline. And that's the problem.\n\n> > But for these communications, revision numbers will not provide\n> > historically stable values that can be used.\n>\n> They certainly can.\n>\n> The coder says \"I've put up a branch at http://example.com/bzr/feature.\n> In revision 5, I started work on feature A. I finished work in\n> revision 6. But then I had to fix a related bug in revision 7.\"\n\n\"I've put this branch up\" isn't historically stable...\n\n> As long as that coder is active\n\n...which is what you just said there yourself.\n\nOn the other hand, git names really do live forever, regardless of\nwhere the code is hosted or how it moves around. When I'm talking\nabout historical stability, I'm talking about being able to publish\nnumbers that live forever.\n\nIt sounds like bzr has numbers like this inside it, (but not nearly as\nsimple as the ones that git has), but that users aren't in the\npractice of communicating with them. Instead, users communicate with\nthe unstable numbers. And that's a shame from an historical\nperspective.\n\n> This is true, but his code is likely to all land in the mainline at\n> once. Since his own revnos are more fine-grained, he's not likely want\n> to use the mainline revnos.\n\nWhat I'd like to be able to do, is advertise a temporary repository,\nand while using it, publish names for revisions that will still be\nvalid when the code gets pushed out to the mainline. That is\nsupporting distributed development, and everything I'm hearing says\nthat the bzr revision numbers don't support that.\n\n> I felt that you were mischaracterizing my _statement_ that \"it's\n> exceedingly uncommon for [revnos] to change\" as an _argument_ \"it's\n> exceedingly uncommon for [revnos] to change\". The reality is that we\n> keep saying revnos don't change because git users keep saying \"but what\n> if the revnos change?\".\n\nOK.\n\nThe original claim that sparked the discussion was that bzr has a\n\"simple namespace\" while git does not. We've been talking for quite a\nwhile here, and I still don't fully understand how these numbers are\ngenerated or what I can expect to happen to the numbers associated\nwith a given revision as that revision moves from one repository to\nanother. It's really not a simple scheme.\n\nMeanwhile, I have been arguing that the \"simple\" revision numbers that\nbzr advertises have restrictions on their utility, (they can only be\nused with reference to a specific repository, or with reference to\nanother that treats it as canonical). I _think_ I understand the\nnumbers well enough to say that still.\n\nCompare that with the git names. The scheme really is easy to\nunderstand, (either the new user already understands cryptographic\nhashes, or else it's as easy as \"a long string of digits that git\nassigns as the name\"). The names have universal utility in time and\nspace, (for definitions of the the universe larger than I will ever be\nable to observe anyway). And the natural inclination to abbreviate the\na name when repeating it, (note the recent post with bzr UUIDs\nexhibiting the same inclination), doesn't make the names any less\nuseful since the abbreviation alone will work most always.\n\nThe naming in git really is beautiful and beautifully simple.\n\nIt's not monotonically increasing from one revision to the next, but\nI've never found that to be an issue. Of course, we do still use our\nown \"simple\" names for versioning the releases and snapshots of\nsoftware we manage with git, and that's where being able to easily\ndetermine \"newer\" or \"older\" by simple numerical examination is\nimportant. I've honestly never encountered a situation where I was\nhanded two git sha1 sums and wished that I could do the same thing.\n\n> If you're interested, it's called \"Bugs Everywhere\" and it's available here:\n> http://panoramicfeedback.com/opensource/\n>\n> New VCS backends are welcome :-D\n\nThanks, I hope to take a look at that at some point.\n\n> So actually, not all branches are treated equally by Git users. Public\n> branches are treated as append-only, but private branches are treated as\n> mutable. (It's the same with bzr users, of course.)\n\nWell, some users treat all branches as append only and shun rebase.\n\n[snip of remaining agreement of similarity between the tools]\n\n-Carl\n"},{"id":"29274","messageId":"20061020002032.GA7162@delft.aura.cs.cmu.edu","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610190936440.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2006-10-20T00:20:32Z","receivedAt":"2006-10-20T00:20:32Z","isPatch":false,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Thu, Oct 19, 2006 at 09:48:29AM -0700, Linus Torvalds wrote:\n> On Thu, 19 Oct 2006, Jan Harkes wrote:\n> > \n> > If we find a delta against a base that is not found in our repository we\n> > can keep it as a delta, the base should show up later on in the\n> > thin-pack. Whenever we find a delta against a base that we haven't seen\n> > in the received part of the thin pack, but is available from the\n> > repository we should expand it because there is a chance we may not see\n> > this base in the remainder of the thin-pack.\n> \n> Yes, indeed. We can also have another heuristic: if we find a delta, and \n> we haven't seen the object it deltas against, we can still keep it as a \n> delta IF WE ALSO DON'T ALREADY HAVE THE BASE OBJECT. Because then we know \n> that the base object has to be there later in the pack (or we have a \n> dangling delta, which we'll just consider an error).\n> \n> So yeah, maybe my patch-series is something we can still save.\n\nIt looks like you were really close. When we cannot resolve a delta, we\njust write it to the packfile and we don't queue it. If it can be\nresolved we write it as a full object.\n\nThe only thing that cannot be reliably tracked is the pack index\ninformation. The offsets are trivial, but we cannot calculate the SHA1\nfor a delta without applying it to it's base, if the base comes later\nthe existing code could do it, but if it has already been written to the\npack we can't easily track back.\n\nAnd why add all the extra complexity. Running git-index-pack after\ngit-update-objects --repack not only generates the correct index without\na problem, it also serves as an extra consistency check and we keep this\ncode isolated from any possible future changes to the index file format.\n\nI'll try to follow this up with 2 patches, one is an almost trivial\nchange to your code that makes it write out a pack with all full objects\nand resolvable deltas converted to full objects, any unresolved deltas\nare expected to be relative to some other object in the same pack.\n\nThe rewritten pack is indexed correctly even when I run git-update-index\nin a repository that does not contain any of the objects in the thin-pack.\nOfcourse it also works when the objects are available, but the resulting\nfull pack is considerably bigger since we can find a suitable base for\nevery delta.\n\n> However, the thing that makes me suspect that it is _not_ saveable, is \n> this:\n...\n> The answer is: no. It's not trivial. Or rather, it _is_ trivial, but you \n> have to _remember_ all of the actual data for A, B, C and D all the way to \n> the end, because only if you have that data in memory can you actually \n> _recreate_ B, C and D even enough to get their SHA1's (which you need, \n> just in order to know that the pack is complete, must less to be able to \n> create a non-delta version in case it hadn't been).\n\nOnly if you want to build the index at the same time, we don't need to\nknow the SHA1 values for unresolved deltas.\n\n> Anyway, I just pushed the \"rewrite-pack\" branch to my git repo on \n> kernel.org, so once it mirrors out, if you really want to try to fix up \n> the mess I left behind, there it is:\n\nI think I still left quite a bit of the mess unfixed.\n\nJan\n"},{"id":"29276","messageId":"20061020002040.GB7162@delft.aura.cs.cmu.edu","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610190936440.3962@g5.osdl.org","subject":"[PATCH 1/2] Pass through unresolved deltas when writing a pack","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2006-10-20T00:20:40Z","receivedAt":"2006-10-20T00:20:40Z","isPatch":true,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"The resulting pack should be correct if we have the base somewhere else in\nthe received pack, if we didn't have the base the received pack would be\nfaulty and can't be unpacked as loose objects either.\n\nThe internal pack index information is not updated correctly anymore.\n\nSigned-off-by: Jan Harkes \n\n---\n builtin-unpack-objects.c | 5 ++++-\n 1 files changed, 4 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c\nindex f139308..b95c93c 100644\n--- a/builtin-unpack-objects.c\n+++ b/builtin-unpack-objects.c\n@@ -246,7 +246,10 @@ static void unpack_delta_entry(unsigned \n \t}\n \n \tif (!has_sha1_file(base_sha1)) {\n-\t\tadd_delta_to_list(base_sha1, delta_data, delta_size);\n+\t\tif (pack_file)\n+\t\t\twrite_pack_delta(base_sha1, delta_data, delta_size);\n+\t\telse\n+\t\t\tadd_delta_to_list(base_sha1, delta_data, delta_size);\n \t\treturn;\n \t}\n \tbase = read_sha1_file(base_sha1, type, &base_size);\n-- \n1.4.2.1\n"},{"id":"29275","messageId":"20061020002048.GC7162@delft.aura.cs.cmu.edu","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610190936440.3962@g5.osdl.org","subject":"[PATCH 2/2] Remove unused index tracking code.","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2006-10-20T00:20:48Z","receivedAt":"2006-10-20T00:20:48Z","isPatch":true,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"Tracking the offsets is not that hard, but calculating the sha1 for the\ndeltas is tricky, we may have already seen and written out the base we\nneed. So it is actually easier to avoid the complexity altogether and\nrely on git-index-pack to rebuild the index. The indexing step is also a\nuseful validation whether the final pack contains a base for every delta.\n\nSigned-off-by: Jan Harkes \n\n---\n builtin-unpack-objects.c | 57 +++++++++++-----------------------------------\n 1 files changed, 14 insertions(+), 43 deletions(-)\n\ndiff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c\nindex b95c93c..3df7938 100644\n--- a/builtin-unpack-objects.c\n+++ b/builtin-unpack-objects.c\n@@ -89,29 +89,6 @@ static void *get_data(unsigned long size\n }\n \n static struct sha1file *pack_file;\n-static unsigned long pack_file_offset;\n-\n-struct index_entry {\n-\tunsigned long offset;\n-\tunsigned char sha1[20];\n-};\n-\n-static unsigned int index_nr, index_alloc;\n-static struct index_entry **index_array;\n-\n-static void add_pack_index(unsigned char *sha1)\n-{\n-\tstruct index_entry *entry;\n-\tint nr = index_nr;\n-\tif (nr >= index_alloc) {\n-\t\tindex_alloc = (index_alloc + 64) * 3 / 2;\n-\t\tindex_array = xrealloc(index_array, index_alloc * sizeof(*index_array));\n-\t}\n-\tentry = xmalloc(sizeof(*entry));\n-\tentry->offset = pack_file_offset;\n-\thashcpy(entry->sha1, sha1);\n-\tindex_array[nr++] = entry;\n-}\n \n static void write_pack_delta(const unsigned char *base, const void *delta, unsigned long delta_size)\n {\n@@ -122,11 +99,9 @@ static void write_pack_delta(const unsig\n \tsha1write(pack_file, header, hdrlen);\n \tsha1write(pack_file, base, 20);\n \tdatalen = sha1write_compressed(pack_file, delta, delta_size);\n-\n-\tpack_file_offset += hdrlen + 20 + datalen;\n }\n \n-static void write_pack_object(const char *type, const unsigned char *sha1, const void *buf, unsigned long size)\n+static void write_pack_object(const void *buf, unsigned long size, const char *type, const unsigned char *sha1)\n {\n \tunsigned char header[10];\n \tunsigned hdrlen, datalen;\n@@ -134,8 +109,6 @@ static void write_pack_object(const char\n \thdrlen = encode_header(string_to_type(type, sha1), size, header);\n \tsha1write(pack_file, header, hdrlen);\n \tdatalen = sha1write_compressed(pack_file, buf, size);\n-\n-\tpack_file_offset += hdrlen + datalen;\n }\n \n struct delta_info {\n@@ -160,22 +133,21 @@ static void add_delta_to_list(unsigned c\n \n static void added_object(unsigned char *sha1, const char *type, void *data, unsigned long size);\n \n-static void write_object(void *buf, unsigned long size, const char *type,\n-\tunsigned char *base, void *delta, unsigned long delta_size)\n+static void write_object(void *buf, unsigned long size, const char *type)\n {\n \tunsigned char sha1[20];\n \n \tif (pack_file) {\n \t\tif (hash_sha1_file(buf, size, type, sha1) < 0)\n \t\t\tdie(\"failed to compute object hash\");\n-\t\tadd_pack_index(sha1);\n-\t\tif (0 && base)\n-\t\t\twrite_pack_delta(base, delta, delta_size);\n-\t\telse\n-\t\t\twrite_pack_object(type, sha1, buf, size);\n-\t} else if (write_sha1_file(buf, size, type, sha1) < 0)\n-\t\tdie(\"failed to write object\");\n-\tadded_object(sha1, type, buf, size);\n+\n+\t\twrite_pack_object(buf, size, type, sha1);\n+\t} else {\n+\t\tif (write_sha1_file(buf, size, type, sha1) < 0)\n+\t\t die(\"failed to write object\");\n+\n+\t\tadded_object(sha1, type, buf, size);\n+\t}\n }\n \n static void resolve_delta(const char *type, unsigned char *base_sha1,\n@@ -190,7 +162,7 @@ static void resolve_delta(const char *ty\n \t\t\t &result_size);\n \tif (!result)\n \t\tdie(\"failed to apply delta\");\n-\twrite_object(result, result_size, type, base_sha1, delta, delta_size);\n+\twrite_object(result, result_size, type);\n \tfree(delta);\n \tfree(result);\n }\n@@ -225,7 +197,7 @@ static void unpack_non_delta_entry(enum \n \tdefault: die(\"bad type %d\", kind);\n \t}\n \tif (!dry_run && buf)\n-\t\twrite_object(buf, size, type, NULL, NULL, 0);\n+\t\twrite_object(buf, size, type);\n \tfree(buf);\n }\n \n@@ -334,12 +306,11 @@ static void unpack_all(const char *repac\n \t\tnewhdr.hdr_signature = htonl(PACK_SIGNATURE);\n \t\tnewhdr.hdr_version = htonl(PACK_VERSION);\n \t\tnewhdr.hdr_entries = htonl(nr_objects);\n-\t\t\n+\n \t\tpack_file = sha1create(\"%s.pack\", repack);\n \t\tsha1write(pack_file, &newhdr, sizeof(newhdr));\n-\t\tpack_file_offset = sizeof(newhdr);\n \t}\n-\t\t\n+\n \n \tuse(sizeof(struct pack_header));\n \tfor (i = 0; i < nr_objects; i++)\n-- \n1.4.2.1\n"},{"id":"29280","messageId":"45382120.9060702@utoronto.ca","threadId":"5925","inReplyTo":"87ods727pn.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-20T01:06:40Z","receivedAt":"2006-10-20T01:06:40Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nCarl Worth wrote:\n> On Thu, 19 Oct 2006 19:01:58 -0400, Aaron Bentley wrote:\n\n> Do you see how \"maintain\n> an independent URL namespace for every distributed branch\" doesn't\n> encourage much distributed development?\n\nI understand your argument now. It's nothing to do with numbers per se,\nand all about per-branch namespaces. Correct?\n\n>> Additionally, the new mainline can keep a mirror of the\n>> abandoned mainline in its repository, because there are virtually no\n>> additional storage requirements to doing so.\n> \n> And this part I don't understand. I can understand the mainline\n> storing the revisions, but I don't understand how it could make them\n> accessible by the published revision numbers of the \"abandoned\"\n> line. And that's the problem.\n\nI meant that the active branch and a mirror of the abandoned branch\ncould be stored in the same repository, for ease of access.\n\nBazaar encourages you to stick lots and lots of branches in your\nrepository. They don't even have to be related. For example, my repo\ncontains branches of bzr, bzrtools, Meld, and BazaarInspect.\n\n> It sounds like bzr has numbers like this inside it, (but not nearly as\n> simple as the ones that git has), but that users aren't in the\n> practice of communicating with them. Instead, users communicate with\n> the unstable numbers. And that's a shame from an historical\n> perspective.\n\nI can see where you're coming from, but to me, the trade-off seems\nworthwhile. Because historical data gets less and less valuable the\nolder it gets. By the time the URL for a branch goes dark, there's\nunlikely to be any reason to refer to one of its revisions at all.\n\n> The original claim that sparked the discussion was that bzr has a\n> \"simple namespace\" while git does not. We've been talking for quite a\n> while here, and I still don't fully understand how these numbers are\n> generated or what I can expect to happen to the numbers associated\n> with a given revision as that revision moves from one repository to\n> another. It's really not a simple scheme.\n\nWhen you create a new branch from scratch, the number starts at zero.\nIf you copy a branch, you copy its number, too.\n\nEvery time you commit, the number is incremented. If you pull, your\nnumbers are adjusted to be identical to those of the branch you pulled from.\n\nIs that really complicated?\n\n> Meanwhile, I have been arguing that the \"simple\" revision numbers that\n> bzr advertises have restrictions on their utility, (they can only be\n> used with reference to a specific repository, or with reference to\n> another that treats it as canonical). I _think_ I understand the\n> numbers well enough to say that still.\n\nSure. It's the \"favors centralization\" thing that I don't agree with,\nbut I now understand your argument.\n\n> Compare that with the git names. The scheme really is easy to\n> understand, (either the new user already understands cryptographic\n> hashes, or else it's as easy as \"a long string of digits that git\n> assigns as the name\").\n\nIn my experience, users who don't understand distributed systems don't\nunderstand why UUIDS must be used as identifiers.\n\n> The naming in git really is beautiful and beautifully simple.\n\nWell, you've got to admit that those names are at least superficially ugly.\n\n> It's not monotonically increasing from one revision to the next, but\n> I've never found that to be an issue. Of course, we do still use our\n> own \"simple\" names for versioning the releases and snapshots of\n> software we manage with git, and that's where being able to easily\n> determine \"newer\" or \"older\" by simple numerical examination is\n> important. I've honestly never encountered a situation where I was\n> handed two git sha1 sums and wished that I could do the same thing.\n\nWhat's nice is being able see the revno 753 and knowing that \"diff -r\n752..753\" will show the changes it introduced. Checking the revo on a\nbranch mirror and knowing how out-of-date it is.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFOCEf0F+nu1YWqI0RAhgtAJwK4jkWFjjF2iHJb1VyXqgszsHElACff2U7\nolZJiAED80tIS6kgkqFsJps=\n=BkRZ\n-----END PGP SIGNATURE-----\n"},{"id":"29281","messageId":"Pine.LNX.4.64.0610192058130.1971@xanadu.home","threadId":"5925","inReplyTo":"20061020002048.GC7162@delft.aura.cs.cmu.edu","subject":"Re: [PATCH 2/2] Remove unused index tracking code.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-10-20T01:11:10Z","receivedAt":"2006-10-20T01:11:10Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 19 Oct 2006, Jan Harkes wrote:\n\n> Tracking the offsets is not that hard, but calculating the sha1 for the\n> deltas is tricky, we may have already seen and written out the base we\n> need. So it is actually easier to avoid the complexity altogether and\n> rely on git-index-pack to rebuild the index. The indexing step is also a\n> useful validation whether the final pack contains a base for every delta.\n> \n> Signed-off-by: Jan Harkes \n\nI don't think it is a good idea.\n\nAfter looking at the problem for a while I should side with Linus. \nunpack-objects is not the proper tool for the job. The way to go is to \nmake input to index-pack streamable.\n\nThis patch in particular creates additional restrictions on pack \nfiles that were not present before. And I don't think this is a good \nthing.\n\nThis patch impose an ordering on REF_DELTA objects that doesn't need to \nexist. Say for example that an OFS_DELTA depends on an object which is \na REF_DELTA object. With this patch any pack with the base for that \nREF_DELTA stored after the OFS_DELTA object will be broken.\n\nAnd to really do thin pack fixing properly we really want to just append \nmissing base objects at the end of the pack which falls in the broken \ncase above.\n\nSo this is a NAK from me.\n\n> ---\n> builtin-unpack-objects.c | 57 +++++++++++-----------------------------------\n> 1 files changed, 14 insertions(+), 43 deletions(-)\n> \n> diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c\n> index b95c93c..3df7938 100644\n> --- a/builtin-unpack-objects.c\n> +++ b/builtin-unpack-objects.c\n> @@ -89,29 +89,6 @@ static void *get_data(unsigned long size\n> }\n> \n> static struct sha1file *pack_file;\n> -static unsigned long pack_file_offset;\n> -\n> -struct index_entry {\n> -\tunsigned long offset;\n> -\tunsigned char sha1[20];\n> -};\n> -\n> -static unsigned int index_nr, index_alloc;\n> -static struct index_entry **index_array;\n> -\n> -static void add_pack_index(unsigned char *sha1)\n> -{\n> -\tstruct index_entry *entry;\n> -\tint nr = index_nr;\n> -\tif (nr >= index_alloc) {\n> -\t\tindex_alloc = (index_alloc + 64) * 3 / 2;\n> -\t\tindex_array = xrealloc(index_array, index_alloc * sizeof(*index_array));\n> -\t}\n> -\tentry = xmalloc(sizeof(*entry));\n> -\tentry->offset = pack_file_offset;\n> -\thashcpy(entry->sha1, sha1);\n> -\tindex_array[nr++] = entry;\n> -}\n> \n> static void write_pack_delta(const unsigned char *base, const void *delta, unsigned long delta_size)\n> {\n> @@ -122,11 +99,9 @@ static void write_pack_delta(const unsig\n> \tsha1write(pack_file, header, hdrlen);\n> \tsha1write(pack_file, base, 20);\n> \tdatalen = sha1write_compressed(pack_file, delta, delta_size);\n> -\n> -\tpack_file_offset += hdrlen + 20 + datalen;\n> }\n> \n> -static void write_pack_object(const char *type, const unsigned char *sha1, const void *buf, unsigned long size)\n> +static void write_pack_object(const void *buf, unsigned long size, const char *type, const unsigned char *sha1)\n> {\n> \tunsigned char header[10];\n> \tunsigned hdrlen, datalen;\n> @@ -134,8 +109,6 @@ static void write_pack_object(const char\n> \thdrlen = encode_header(string_to_type(type, sha1), size, header);\n> \tsha1write(pack_file, header, hdrlen);\n> \tdatalen = sha1write_compressed(pack_file, buf, size);\n> -\n> -\tpack_file_offset += hdrlen + datalen;\n> }\n> \n> struct delta_info {\n> @@ -160,22 +133,21 @@ static void add_delta_to_list(unsigned c\n> \n> static void added_object(unsigned char *sha1, const char *type, void *data, unsigned long size);\n> \n> -static void write_object(void *buf, unsigned long size, const char *type,\n> -\tunsigned char *base, void *delta, unsigned long delta_size)\n> +static void write_object(void *buf, unsigned long size, const char *type)\n> {\n> \tunsigned char sha1[20];\n> \n> \tif (pack_file) {\n> \t\tif (hash_sha1_file(buf, size, type, sha1) < 0)\n> \t\t\tdie(\"failed to compute object hash\");\n> -\t\tadd_pack_index(sha1);\n> -\t\tif (0 && base)\n> -\t\t\twrite_pack_delta(base, delta, delta_size);\n> -\t\telse\n> -\t\t\twrite_pack_object(type, sha1, buf, size);\n> -\t} else if (write_sha1_file(buf, size, type, sha1) < 0)\n> -\t\tdie(\"failed to write object\");\n> -\tadded_object(sha1, type, buf, size);\n> +\n> +\t\twrite_pack_object(buf, size, type, sha1);\n> +\t} else {\n> +\t\tif (write_sha1_file(buf, size, type, sha1) < 0)\n> +\t\t die(\"failed to write object\");\n> +\n> +\t\tadded_object(sha1, type, buf, size);\n> +\t}\n> }\n> \n> static void resolve_delta(const char *type, unsigned char *base_sha1,\n> @@ -190,7 +162,7 @@ static void resolve_delta(const char *ty\n> \t\t\t &result_size);\n> \tif (!result)\n> \t\tdie(\"failed to apply delta\");\n> -\twrite_object(result, result_size, type, base_sha1, delta, delta_size);\n> +\twrite_object(result, result_size, type);\n> \tfree(delta);\n> \tfree(result);\n> }\n> @@ -225,7 +197,7 @@ static void unpack_non_delta_entry(enum \n> \tdefault: die(\"bad type %d\", kind);\n> \t}\n> \tif (!dry_run && buf)\n> -\t\twrite_object(buf, size, type, NULL, NULL, 0);\n> +\t\twrite_object(buf, size, type);\n> \tfree(buf);\n> }\n> \n> @@ -334,12 +306,11 @@ static void unpack_all(const char *repac\n> \t\tnewhdr.hdr_signature = htonl(PACK_SIGNATURE);\n> \t\tnewhdr.hdr_version = htonl(PACK_VERSION);\n> \t\tnewhdr.hdr_entries = htonl(nr_objects);\n> -\t\t\n> +\n> \t\tpack_file = sha1create(\"%s.pack\", repack);\n> \t\tsha1write(pack_file, &newhdr, sizeof(newhdr));\n> -\t\tpack_file_offset = sizeof(newhdr);\n> \t}\n> -\t\t\n> +\n> \n> \tuse(sizeof(struct pack_header));\n> \tfor (i = 0; i < nr_objects; i++)\n> -- \n> 1.4.2.1\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n\n\nNicolas\n"},{"id":"29282","messageId":"7vhcxzrcq6.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610192058130.1971@xanadu.home","subject":"Re: [PATCH 2/2] Remove unused index tracking code.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-20T01:35:13Z","receivedAt":"2006-10-20T01:35:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> This patch in particular creates additional restrictions on pack \n> files that were not present before. And I don't think this is a good \n> thing.\n>\n> This patch impose an ordering on REF_DELTA objects that doesn't need to \n> exist. Say for example that an OFS_DELTA depends on an object which is \n> a REF_DELTA object. With this patch any pack with the base for that \n> REF_DELTA stored after the OFS_DELTA object will be broken.\n>\n> And to really do thin pack fixing properly we really want to just append \n> missing base objects at the end of the pack which falls in the broken \n> case above.\n>\n> So this is a NAK from me.\n\nI agree.\n\nBy the way, it is rather rare for us to see a NAK on this list.\nI'd welcome to see more of them ;-).\n"},{"id":"29284","messageId":"20061020022723.GE7162@delft.aura.cs.cmu.edu","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610192058130.1971@xanadu.home","subject":"Re: [PATCH 2/2] Remove unused index tracking code.","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2006-10-20T02:27:23Z","receivedAt":"2006-10-20T02:27:23Z","isPatch":true,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Thu, Oct 19, 2006 at 09:11:10PM -0400, Nicolas Pitre wrote:\n> This patch impose an ordering on REF_DELTA objects that doesn't need to \n> exist. Say for example that an OFS_DELTA depends on an object which is \n> a REF_DELTA object. With this patch any pack with the base for that \n> REF_DELTA stored after the OFS_DELTA object will be broken.\n\nI don't see where it imposes any ordering.\n\nIf we see a complete object it will remain complete. If we find a delta,\nand we have the base in the current repository it will be expanded to a\ncomplete object. When we get a delta that doesn't have a base in the\ncurrent repository it will remain unresolved and is written out as a\ndelta.\n\nSo the output pack will always contain fewer deltas as the input.\n\nbtw. I don't really know what OFS_DELTA and REF_DELTA objects are, I\ngrepped the source and found no references to either. I can only find\nan OBJ_DELTA.\n\nBut if any of the deltas depend on an object that is not in the thin\npack, the base has to be available in the current repository and as such\nit will be expanded to a full object, replacing the possibly external\ndelta reference with an internal base object. If the base is not found\nin the current repository the base has to be another object in the\noriginal thin pack so we can write out the delta as is.\n\nThere is no before or after decision here. We don't look back in the\nthin pack, and we don't have to look forward either. So I don't\nunderstand why your example would break or not depending on if the base\nobject happens to be before or after the OFS_DELTA.\n\n> And to really do thin pack fixing properly we really want to just append \n> missing base objects at the end of the pack which falls in the broken \n> case above.\n\nI guess I'll grep through the mailinglists to try to figure out what\nthese OFS and REF deltas are and why they behave so differently\ndepending on their order in the pack.\n\nJan\n"},{"id":"29285","messageId":"7vd58nra64.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"20061020022723.GE7162@delft.aura.cs.cmu.edu","subject":"Re: [PATCH 2/2] Remove unused index tracking code.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-20T02:30:27Z","receivedAt":"2006-10-20T02:30:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jan Harkes writes:\n\n> I guess I'll grep through the mailinglists to try to figure out what\n> these OFS and REF deltas are and why they behave so differently\n> depending on their order in the pack.\n\nIt's been cooking in \"next\" branch for quite a while.\n"},{"id":"29286","messageId":"20061020024602.GF7162@delft.aura.cs.cmu.edu","threadId":"5925","inReplyTo":"7vd58nra64.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 2/2] Remove unused index tracking code.","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2006-10-20T02:46:02Z","receivedAt":"2006-10-20T02:46:02Z","isPatch":true,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Thu, Oct 19, 2006 at 07:30:27PM -0700, Junio C Hamano wrote:\n> Jan Harkes writes:\n> \n> > I guess I'll grep through the mailinglists to try to figure out what\n> > these OFS and REF deltas are and why they behave so differently\n> > depending on their order in the pack.\n> \n> It's been cooking in \"next\" branch for quite a while.\n\nAh yes, just went through the thread about the git-index-pack breaking on\n64-bit systems and the back and forth about the possible complexity of\nthe new code.\n\n> It is really simple:\n>\n> - if the found union content matches with a reference union initialized\n> through the sha1 member then deltas[j].obj->type == OBJ_REF_DELTA\n> must be true.\n>\n> - if the found union content matches with a reference union initialized\n> through the sha1 member then deltas[j].obj->type == OBJ_OFS_DELTA\n> must be true.\n...\n\nI guess one of these must be false.\n\nBut clearly this patch breaks those offset based delta's when we expand\nrandom deltas in place.\n\nJan\n"},{"id":"29287","messageId":"a7e835d40610191953i467ce853k4b4740bbfdd92936@mail.gmail.com","threadId":"5925","inReplyTo":"87ods727pn.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"James Henstridge","fromEmail":"james@jamesh.id.au","sentAt":"2006-10-20T02:53:52Z","receivedAt":"2006-10-20T02:53:52Z","isPatch":false,"sender":{"key":"james@jamesh.id.au","avatar":"https://gravatar.com/avatar/3007d1d261c8d1edc4e388f53ea5e53ab40fd5f8334748472ba0e2037b76e4aa?d=mp&s=160"},"body":"On 20/10/06, Carl Worth wrote:\n> On Thu, 19 Oct 2006 19:01:58 -0400, Aaron Bentley wrote:\n> > I don't think this is true. The abandoned mainline does not need to be\n> > destroyed. It can be kept at the same location that it always was, with\n> > the numbers that it always had. So the number + URL combo stays\n> > meaningful.\n>\n> Sure that's possible, but it gets rather unwieldy the more\n> repositories you have involved. I've been arguing that bzr really does\n> encourage centralized, not distributed development, and you were having\n> trouble seeing how I came to that conclusion. Do you see how \"maintain\n> an independent URL namespace for every distributed branch\" doesn't\n> encourage much distributed development?\n>\n> > Additionally, the new mainline can keep a mirror of the\n> > abandoned mainline in its repository, because there are virtually no\n> > additional storage requirements to doing so.\n>\n> And this part I don't understand. I can understand the mainline\n> storing the revisions, but I don't understand how it could make them\n> accessible by the published revision numbers of the \"abandoned\"\n> line. And that's the problem.\n\nWith this sort of setup, I would publish my branches in a directory\ntree like this:\n\n /repo\n /branch1\n /branch2\n\nI make \"/repo\" a Bazaar repository so that it stores the revision data\nfor all branches contained in the directory (the tree contents,\nrevision meta data, etc).\n\nThe \"/repo/branch1\" essentially just contains a list of mainline\nrevision IDs that identify the branch. This could probably be just\nstore the head revision ID, but there are some optimisations that make\nuse of the linear history here.\n\nIf the ancestry of \"/repo/branch2\" is a subset of branch1 (as it might\nbe if the in the case of forked then merged projects), then all its\nrevision data will already be in the repository when branch1 was\nimported. The only cost of keeping the branch around (and publishing\nit) is the list of revision IDs in its mainline history.\n\nFor similar reasons, the cost of publishing 20 related Bazaar branches\non my web server is generally not 20 times the cost of publishing a\nsingle branch.\n\nI understand that you get similar benefits by a GIT repository with\nmultiple head revisions.\n\n\n> > > But for these communications, revision numbers will not provide\n> > > historically stable values that can be used.\n> >\n> > They certainly can.\n> >\n> > The coder says \"I've put up a branch at http://example.com/bzr/feature.\n> > In revision 5, I started work on feature A. I finished work in\n> > revision 6. But then I had to fix a related bug in revision 7.\"\n>\n> \"I've put this branch up\" isn't historically stable...\n\nWith the repository structure mentioned above, the cost of publishing\nmultiple branches is quite low. If I continue to work on the project,\nthen there is no particular bandwidth or disk space reasons for me to\ncut off access to my old branches.\n\nFor similar reasons, it doesn't cost me much to mirror other people's\nrelated branches if I really care about them.\n\n> > As long as that coder is active\n>\n> ...which is what you just said there yourself.\n>\n> On the other hand, git names really do live forever, regardless of\n> where the code is hosted or how it moves around. When I'm talking\n> about historical stability, I'm talking about being able to publish\n> numbers that live forever.\n>\n> It sounds like bzr has numbers like this inside it, (but not nearly as\n> simple as the ones that git has), but that users aren't in the\n> practice of communicating with them. Instead, users communicate with\n> the unstable numbers. And that's a shame from an historical\n> perspective.\n\nIf you need that level of stability then you want the revision\nidentifier in both the GIT and Bazaar cases.\n\nAs for simplicity, note that Bazaar doesn't extract any special\nmeaning from the \"$email-$date-$random\" format of the revision\nidentifiers. The only property it cares about is that they are\nglobally unique. For example, revision identifiers generated by the\nArch -> Bazaar importer have a different format and are handled the\nsame.\n\n\n> > This is true, but his code is likely to all land in the mainline at\n> > once. Since his own revnos are more fine-grained, he's not likely want\n> > to use the mainline revnos.\n>\n> What I'd like to be able to do, is advertise a temporary repository,\n> and while using it, publish names for revisions that will still be\n> valid when the code gets pushed out to the mainline. That is\n> supporting distributed development, and everything I'm hearing says\n> that the bzr revision numbers don't support that.\n\nThat is correct. The revision numbers assigned to particular\nrevisions in the context of one branch won't necessarily be the same\nas the numbers in another branch.\n\n\n> > I felt that you were mischaracterizing my _statement_ that \"it's\n> > exceedingly uncommon for [revnos] to change\" as an _argument_ \"it's\n> > exceedingly uncommon for [revnos] to change\". The reality is that we\n> > keep saying revnos don't change because git users keep saying \"but what\n> > if the revnos change?\".\n>\n> OK.\n>\n> The original claim that sparked the discussion was that bzr has a\n> \"simple namespace\" while git does not. We've been talking for quite a\n> while here, and I still don't fully understand how these numbers are\n> generated or what I can expect to happen to the numbers associated\n> with a given revision as that revision moves from one repository to\n> another. It's really not a simple scheme.\n\nI can't say anything about the dotted revision numbers that have been\nrecently introduced to Bazaar, but I have definitely found the simple\nnumeric revision numbers for mainline revisions useful when using\nBazaar. The revisions with these short revision numbers are generally\nthe ones I am most interested in when working on that branch.\n\nIt hasn't ever seemed a problem those revisions no longer had short\nrevision numbers assigned to them when someone else merged my branch.\n\n\n> Meanwhile, I have been arguing that the \"simple\" revision numbers that\n> bzr advertises have restrictions on their utility, (they can only be\n> used with reference to a specific repository, or with reference to\n> another that treats it as canonical). I _think_ I understand the\n> numbers well enough to say that still.\n\nUsing Bazaar terminology, the revision numbers are specific to a\nparticular _branch_. If I copy a branch from one repository to\nanother, its revision numbers will stay the same. And conversely, two\nbranches in the same repository can have different revision numbers.\n\n\n> Compare that with the git names. The scheme really is easy to\n> understand, (either the new user already understands cryptographic\n> hashes, or else it's as easy as \"a long string of digits that git\n> assigns as the name\"). The names have universal utility in time and\n> space, (for definitions of the the universe larger than I will ever be\n> able to observe anyway). And the natural inclination to abbreviate the\n> a name when repeating it, (note the recent post with bzr UUIDs\n> exhibiting the same inclination), doesn't make the names any less\n> useful since the abbreviation alone will work most always.\n>\n> The naming in git really is beautiful and beautifully simple.\n\nI don't think anyone is saying that universally unique names are bad.\nBut I also don't see a problem with using shorter names that only have\nmeaning in a local scope.\n\nI've noticed some people using abbreviated SHA1 sums with GIT. Isn't\nthat also a case of trading potential global uniqueness for\nconvenience when working in a local scope?\n\n\nJames.\n"},{"id":"29288","messageId":"72877ab10610192014o3a7f66c6v79f94f48615e08f4@mail.gmail.com","threadId":"5925","inReplyTo":"45379A02.1010105@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Tim Webster","fromEmail":"tdwebste@gmail.com","sentAt":"2006-10-20T03:14:04Z","receivedAt":"2006-10-20T03:14:04Z","isPatch":false,"sender":{"key":"tdwebste@gmail.com","avatar":null},"body":"On 10/19/06, Aaron Bentley wrote:\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n>\n> Tim Webster wrote:\n> > First I want to say every SCM I know of sucks when it comes to tracking\n> > configurations, simply because they don't record or restore file metadata,\n> > like perms, ownership, and acl.\n>\n> Arch supports that kind of metadata.\n>\n> I believe SVN supports recording arbitrary file properties, so it's just\n> a matter of applying those properties to the tree.\n\nyes svn has arbitrary properties which can be manipulated.\nThey are not really intended for permissions, ownership, and acl.\nTo use the svn properties for this requires adding scm tools.\nAlso svn does not allow files in the same directory to live in\nmultiple repos\n\n>\n> > Somethings I like the SCM tools to handle. Personally I would like the\n\n> > Collaborative document editing and white boarding are other requirements.\n> > odf and svg are xml file formats. I would like to see an efficient\n> > xml diff as part of the SCM core. Using mime types SCM tools can unzip\n> > files, bundles, and use mime type information to the SCM core xml\n> > diff, plain diff\n> > as required.\n>\n> An XML diff/patch or merge will not handle ODF properly. There's too\n> much extra semantic information.\n\nI have only experiment with xml diffs on odf files.\nFrom my experience xml diffs work fine on svg files.\nFor more information, please refer to\nhttp://www.unibw.de/inf2/OO_VCS/oo_rcs_api.html\n\n\n> > I think it is essential that the SCM core include\n> > previsions for multiple\n> > repo partners.\n>\n> You mean multiple merge sources?\n\nyes, Multiple merge sources is handy for collaborative document editing\n"},{"id":"29289","messageId":"Pine.LNX.4.64.0610192324420.1971@xanadu.home","threadId":"5925","inReplyTo":"20061020022723.GE7162@delft.aura.cs.cmu.edu","subject":"Re: [PATCH 2/2] Remove unused index tracking code.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-10-20T03:36:19Z","receivedAt":"2006-10-20T03:36:19Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 19 Oct 2006, Jan Harkes wrote:\n\n> If we see a complete object it will remain complete. If we find a delta,\n> and we have the base in the current repository it will be expanded to a\n> complete object.\n> When we get a delta that doesn't have a base in the\n> current repository it will remain unresolved and is written out as a\n> delta.\n\nBut the point of the whole exercice is actually to avoid unresolved \ndeltas. And you know if you have unresolved deltas only when the whole \npack has been processed.\n\nIf the base object is not in the repository but it is in the pack \n_after_ the delta that needs it, you won't have resolved it. If this is \na thin pack with missing base objects for whatever reason you're \nscrewed.\n\nIf the delta has its base object in both the repository _and_ in the \npack but after the delta then you will have expanded the delta \nneedlessly.\n\nSo your solution is suboptimal.\n\nThe optimal solution really consists of appending missing base objects \nto a thin pack in order to make it complete, or error out if those \ncannot be found.\n\n\nNicolas\n"},{"id":"29290","messageId":"72877ab10610192040u1e531f9dh3462a934b60cbad9@mail.gmail.com","threadId":"5925","inReplyTo":"vpq7iyw2sg9.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Tim Webster","fromEmail":"tdwebste@gmail.com","sentAt":"2006-10-20T03:40:20Z","receivedAt":"2006-10-20T03:40:20Z","isPatch":false,"sender":{"key":"tdwebste@gmail.com","avatar":null},"body":"On 10/20/06, Matthieu Moy wrote:\n> \"Tim Webster\" writes:\n>\n> > First I want to say every SCM I know of sucks when it comes to tracking\n> > configurations, simply because they don't record or restore file metadata,\n> > like perms, ownership, and acl.\n>\n> That's not a simple matter.\n>\n> Tracking ownership hardly makes sense as soon as you have two\n> developers on the same project. What does it mean to checkout a file\n> belonging to user foo and group bar on a system not having such user\n> and group?\n.\n> That said, it can be interesting to have it, but disabled by default.\n\nYes I agree it should be disabled by default. And enabled based on the\nlocal settings.\n"},{"id":"29291","messageId":"45384B0F.4040901@utoronto.ca","threadId":"5925","inReplyTo":"72877ab10610192014o3a7f66c6v79f94f48615e08f4@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-20T04:05:35Z","receivedAt":"2006-10-20T04:05:35Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nTim Webster wrote:\n> On 10/19/06, Aaron Bentley wrote:\n>> I believe SVN supports recording arbitrary file properties, so it's just\n>> a matter of applying those properties to the tree.\n> \n> yes svn has arbitrary properties which can be manipulated.\n> They are not really intended for permissions, ownership, and acl.\n> To use the svn properties for this requires adding scm tools.\n\nAgreed. I think it's okay to require extra work to set the scm up to\nhandle configurations.\n\n> Also svn does not allow files in the same directory to live in\n> multiple repos\n\nIt would surprise me if many SCMs that support atomic commit also\nsupport intermixing files from multiple repos in the same directory.\n\n>> You mean multiple merge sources?\n> \n> yes, Multiple merge sources is handy for collaborative document editing\n\nThat's something I'd like for software development, too.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFOEsO0F+nu1YWqI0RAo+6AJ9lzF0+O1I8rgkyCOdhsir1gjo0NQCfXEVV\nEIsDmS+eR/7cHKQfmnPJRA4=\n=g5jk\n-----END PGP SIGNATURE-----\n"},{"id":"29292","messageId":"Pine.LNX.4.64.0610192202340.3962@g5.osdl.org","threadId":"5925","inReplyTo":"45382120.9060702@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-20T05:05:00Z","receivedAt":"2006-10-20T05:05:00Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 19 Oct 2006, Aaron Bentley wrote:\n> \n> I understand your argument now. It's nothing to do with numbers per se,\n> and all about per-branch namespaces. Correct?\n\nI don't know if that is what Carl's problem is, but yes, to somebody from \nthe git world, it's totally insane to have the _same_ commit have ten \ndifferent names just depending on which branch is was in.\n\nIn git-land, the name of a commit is the same in every branch.\n\nDo you have something like\n\n\tgitk --all\n\nin your graphical viewers? That one shows _all_ the branches of a \nrepository, and how they relate to each other in git. How do you name your \ncommits in such a viewer, since every branch has a _different_ name for \nthe same commit?\n\n\t\t\tLinus\n"},{"id":"29295","messageId":"45387F04.5010101@research.canon.com.au","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610192202340.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Lachlan Patrick","fromEmail":"loki@research.canon.com.au","sentAt":"2006-10-20T07:47:16Z","receivedAt":"2006-10-20T07:47:16Z","isPatch":false,"sender":{"key":"loki@research.canon.com.au","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Thu, 19 Oct 2006, Aaron Bentley wrote:\n>> I understand your argument now. It's nothing to do with numbers per se,\n>> and all about per-branch namespaces. Correct?\n> \n> I don't know if that is what Carl's problem is, but yes, to somebody from \n> the git world, it's totally insane to have the _same_ commit have ten \n> different names just depending on which branch is was in.\n> \n> In git-land, the name of a commit is the same in every branch.\n\nI've been following the git-vs-bzr discussion, and I'd like to ask a\nquestion (being new to both bzr and git). How does git disambiguate SHA1\nhash collisions? I think git has an alternative way to name revisions\n(can someone please explain it in more detail, I've seen ~\nmentioned only in passing in this thread). It seems to me collisions are\na good argument in favour of having two independent naming schemes, so\nthat you're not solely relying on hashes being unique.\n\nA strong argument is that a global namespace based on hashes of data is\nideal because the names are generated from the data being named, and\ntherefore are immutable. Same data => same name for that data, always\nand forever, which is desirable when merging named data from many\nsources. But the converse isn't true: one name does not necessarily map\nto only that data. Have I misunderstood? Is this a problem?\n\nTa,\nLoki\n"},{"id":"29301","messageId":"a7e835d40610200126y5edc2ad0v8ca0a95655b2e029@mail.gmail.com","threadId":"5925","inReplyTo":"BAYC1-PASMTP08A746E5FA6B87BC65BD37AE0E0@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"James Henstridge","fromEmail":"james@jamesh.id.au","sentAt":"2006-10-20T08:26:39Z","receivedAt":"2006-10-20T08:26:39Z","isPatch":false,"sender":{"key":"james@jamesh.id.au","avatar":"https://gravatar.com/avatar/3007d1d261c8d1edc4e388f53ea5e53ab40fd5f8334748472ba0e2037b76e4aa?d=mp&s=160"},"body":"On 17/10/06, Sean wrote:\n> > - - you can use a checkout to maintain a local mirror of a read-only\n> > branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n>\n> I'm not sure what you mean here. A bzr checkout doesn't have any history\n> does it? So it's not a mirror of a branch, but just a checkout of the\n> branch head?\n\nThere are two forms of checkout: a normal checkout which contains the\ncomplete history of the branch, and a lightweight checkout, which just\nhas a pointer back to the original location of the history.\n\nIn both cases, a \"bzr commit\" invocation will commit changes to the\nremote location. In general, you only want to use a lightweight\ncheckout when there is a fast reliably connection to the branch (e.g.\nif it is on the local file system, or local network).\n\nAaron would be talking about a normal (heavyweight) checkout here.\nWith a heavyweight checkout, you can do pretty much anything without\naccess to the branch. In contrast, almost all operations on a\nlightweight checkout need access to the branch.\n\nJames.\n"},{"id":"29302","messageId":"Pine.LNX.4.63.0610201034170.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"45387F04.5010101@research.canon.com.au","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-20T08:38:48Z","receivedAt":"2006-10-20T08:38:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Oct 2006, Lachlan Patrick wrote:\n\n> How does git disambiguate SHA1 hash collisions?\n\nIt does not. You can fully expect the universe to go down before that \nhappens.\n\nThe only reasonable worry is about SHA-1 being broken some time in future, \ni.e. being able to construct a malign version of some source code _which \nhas the same hash_. There were plenty of discussions about that; Please \nsearch the mailing list. (The consent was that those do not matter, \nbecause an existing object will _never_ be overwritten by a fetch, so you \nwould not get that invalid object anyway.)\n\nHth,\nDscho\n"},{"id":"29312","messageId":"845b6e870610200156w7a676ae5lfcb531fd30139757@mail.gmail.com","threadId":"5925","inReplyTo":"BAYC1-PASMTP08A746E5FA6B87BC65BD37AE0E0@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-20T08:56:53Z","receivedAt":"2006-10-20T08:56:53Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"> > - - you can use a checkout to maintain a local mirror of a read-only\n> > branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n>\n> I'm not sure what you mean here. A bzr checkout doesn't have any history\n> does it? So it's not a mirror of a branch, but just a checkout of the\n> branch head?\n\nIn bzr there are two different kind of checkouts. One is a called a\nlightweight checkout and that's really a \"normal\" checkout in the way\nsvn for example does it. In this mode, you have the branch remotely\nand only the working tree locally. So it's just a checkout of the\nbranch head (of any other revision if using -r when doing the\ncheckout).\n\nThen there are none lightweight checkouts, heavyweight checkouts.\nThese are the default type. A heavyweight checkout is in fact a full\nbranch locally, but it is \"bound\" to the remote branch. What this\nmeans is that all commands such as diff/status/log/etc can be done\nlocally. So it's really quick.\n\nIt acts the same as a lightweight checkout in most regards, so when I\nrun \"bzr update\" it actually pulls from the remove branch, and when I\nrun \"bzr commit\" it commits the same revision in both the remote\nbranch and the local branch. It does this in one transaction so one\ncan't work and the other fail (they would both fail in that case).\n\nWhat this also gives you is that when you want to clone the branch,\nyou don't need to go the the remote branch to get the revisions and\nalso, when being offline, you can commit locally.\n\nCommitting locally is a very cool feature in my mind. If you work in\na centralized manner with checkouts, you normally commit directly to\nthe central branch, but when you are offline, that will fail (of\ncourse :) ). So what you can do then is to run \"bzr commit --local\"\nto commit only to your local checkout branch, then when you get online\nagain you can run \"bzr update\". In this case the update will take any\nnew commits that has been done while you were away, pull them into\nyour local branch, and make your local commits into something that has\nbeen merged into the \"checkout\".\n\nI find this REALLY useful.\n\nDon't know if that made sense, here it is in commands.\n\n$ bzr checkout t p\n$ cd p\n$ echo hej >> hosts\n$ bzr commit --local -m 'offline'\n$ echo hej >> hosts\n$ bzr commit --local -m 'offline 2'\n\nNow I get back, someone has committed new stuff... I run bzr update\n$ bzr update\nAll changes applied successfully.\nUpdated to revision 2.\nYour local commits will now show as pending merges with 'bzr status',\nand can be committed with 'bzr commit'.\n$ bzr status\nmodified:\n hosts\npending merges:\n Erik Bågfors 2006-10-20 offline 2\n Erik Bågfors 2006-10-20 offline\n$ bzr commit -m 'my offline stuff'\nmodified hosts\nCommitted revision 3.\n\n$ bzr log -r-1\n------------------------------------------------------------\nrevno: 3\ncommitter: Erik Bågfors \nbranch nick: p\ntimestamp: Fri 2006-10-20 10:51:08 +0200\nmessage:\n my offline stuff\n ------------------------------------------------------------\n merged: erik@bagfors.nu-20061020084949-8bc43db8f5cd449b\n committer: Erik Bågfors \n branch nick: p\n timestamp: Fri 2006-10-20 10:49:49 +0200\n message:\n offline 2\n ------------------------------------------------------------\n merged: erik@bagfors.nu-20061020084945-13e5093f98c0c380\n committer: Erik Bågfors \n branch nick: p\n timestamp: Fri 2006-10-20 10:49:45 +0200\n message:\n offline\n\nI think that bzr really allows you to work well in a centralized\nenvironment as well as a distrubuted, which is one of the things I\nlike best about bzr.\n\nRegards,\nErik\n-- \ngoogle talk/jabber. zindar@gmail.com\nSIP-phones: sip:erik_bagfors@gizmoproject.com\nsip:17476714687@proxy01.sipphone.com\n"},{"id":"29315","messageId":"vpq4ptz2uh8.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"BAYC1-PASMTP07AB11A64250AAF683424DAE0E0@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-20T09:43:15Z","receivedAt":"2006-10-20T09:43:15Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Sean writes:\n\n> On Tue, 17 Oct 2006 17:27:44 -0400\n> Aaron Bentley wrote:\n>\n>> Bzr has plugin autoloading, Protocol plugins, Repository format plugins,\n>> and more. Because Python supports monkey-patching, a plugin can change\n>> absolutely anything.\n>\n> But really why does any of that matter? This is the open source world.\n> We don't need plugins to extend features, we just add the feature to\n> the source. The example I asked about earlier is a case in point. \n> Apparently in bzr \"bisect\" was implemented as a plugin, yet in Git it\n> was implemented as a command without any issue at all,\n\nThe plugin Vs core feature is not a technical problem. The code for a\nplugin and for a core functionality will roughly be the same, but in a\ndifferent file.\n\nThere can be many reasons why you want to implement something as a\nplugin:\n\n* This is project-specific, upstream is not interested (for example,\n bzr has a plugin to submit a merge request to a robot, it will\n probably never come in the core).\n\n* The feature is not matured enough, so you don't want to merge it in\n upstream, but you want to make it available to people without\n patching (for example, \"bzr uncommit\" was once in the bzrtools\n plugin, and finally landed in upstream).\n\n* The feature you're adding are only of use to a small subset of\n users. You don't want to pollute, in particular \"bzr help commands\"\n with it, especially not to disturb beginners. I've been arguing in\n favor of a configuration option to hide commands from \"bzr help\n commands\" instead, but nobody seemed interested.\n\n* Explicit divergent points of view between the implementor of the\n plugin and upstream. That avoids a fork. I don't remember any such\n case with bzr.\n\nI'd compare bzr's plugins to Firefox extensions. Geeks used to like\nthe big Mozilla-with-tons-of-config-options, but\nFirefox-with-only-the-most-relevant-features is the one which allowed\na wide adoption by non-geeks. Still, geeks can customize their\nbrowser, and add features without having to wait for Mozilla Fundation\nto incorporate it in upstream.\n\nNow, I don't know git enough to know whether the way it is extensible\nallow all of the above, but bzr's plugin system it quite good at that.\nAt the time git was almost exclusively used by the kernel, you didn't\nhave all those problems since you targeted only one community, but I\nguess you already had some needs for flexibility.\n"},{"id":"29316","messageId":"200610201151.13199.jnareb@gmail.com","threadId":"5925","inReplyTo":"a7e835d40610191953i467ce853k4b4740bbfdd92936@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T09:51:12Z","receivedAt":"2006-10-20T09:51:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"James Henstridge wrote:\n> On 20/10/06, Carl Worth wrote:\n>> On Thu, 19 Oct 2006 19:01:58 -0400, Aaron Bentley wrote:\n\n>>> Additionally, the new mainline can keep a mirror of the\n>>> abandoned mainline in its repository, because there are virtually no\n>>> additional storage requirements to doing so.\n>>\n>> And this part I don't understand. I can understand the mainline\n>> storing the revisions, but I don't understand how it could make them\n>> accessible by the published revision numbers of the \"abandoned\"\n>> line. And that's the problem.\n> \n> With this sort of setup, I would publish my branches in a directory\n> tree like this:\n> \n> /repo\n> /branch1\n> /branch2\n> \n> I make \"/repo\" a Bazaar repository so that it stores the revision data\n> for all branches contained in the directory (the tree contents,\n> revision meta data, etc).\n\nAnd here we have a feature which is as far as I see unique to git,\nnamely to have persistent branches with _separate namespace_. It means\nthat we can have hierarchical branch names (including names like\n\"remotes//\", or \"jc/diff\"), and we don't\nhave to guess where repository name ends and branch name begins.\n\nThe idea of \"branches (and tags) as directories\" was if I understand\nit correctly introduced by Subversion, and from what can be seen from\ntroubles with git-svn (stemming from the fact that division between\nproject name and branch name is the matter of _convention_) at least\nslightly brain-damaged.\n \n> The \"/repo/branch1\" essentially just contains a list of mainline\n> revision IDs that identify the branch. This could probably be just\n> store the head revision ID, but there are some optimisations that make\n> use of the linear history here.\n> \n> If the ancestry of \"/repo/branch2\" is a subset of branch1 (as it might\n> be if the in the case of forked then merged projects), then all its\n> revision data will already be in the repository when branch1 was\n> imported. The only cost of keeping the branch around (and publishing\n> it) is the list of revision IDs in its mainline history.\n> \n> For similar reasons, the cost of publishing 20 related Bazaar branches\n> on my web server is generally not 20 times the cost of publishing a\n> single branch.\n> \n> I understand that you get similar benefits by a GIT repository with\n> multiple head revisions.\n\nYou can get similar benefits by a GIT repository with shared object\ndatabase using alternates mechanism. And that is usually preferred\nover storing unrelated branches, i.e. branches pointing to disconnected\nDAG (separate trees in BK terminology) of revision, if that you mean by\nmultiple head revisions (because in GIT there is no notion of \"mainline\"\nbranch, only of current (HEAD) branch).\n\n\n>>>> But for these communications, revision numbers will not provide\n>>>> historically stable values that can be used.\n>>>\n>>> They certainly can.\n>>>\n>>> The coder says \"I've put up a branch at http://example.com/bzr/feature.\n>>> In revision 5, I started work on feature A. I finished work in\n>>> revision 6. But then I had to fix a related bug in revision 7.\"\n>>\n>> \"I've put this branch up\" isn't historically stable...\n> \n> With the repository structure mentioned above, the cost of publishing\n> multiple branches is quite low. If I continue to work on the project,\n> then there is no particular bandwidth or disk space reasons for me to\n> cut off access to my old branches.\n> \n> For similar reasons, it doesn't cost me much to mirror other people's\n> related branches if I really care about them.\n\nBut the revision number in this case _changes_. It is from 7 to\nbranch:7 but still it changes somewhat.\n\n[...]\n>> The naming in git really is beautiful and beautifully simple.\n> \n> I don't think anyone is saying that universally unique names are bad.\n> But I also don't see a problem with using shorter names that only have\n> meaning in a local scope.\n> \n> I've noticed some people using abbreviated SHA1 sums with GIT. Isn't\n> that also a case of trading potential global uniqueness for\n> convenience when working in a local scope?\n\nEmphasisis on _potential_. SHA1 id abbreviated to 6 characters might\nbe not unique in larger project, but for example the chance that\nSHA1 id abbreviated to 7 or 8 characters is not unique is really low.\n\n\nYet another analogy:\n\nSHA1 identifiers of commits (and not only commits) can be compared\nto Message-Ids of Usenet messages, while revision numbers can be compared\nto Xref number of Usenet message which if I understand correctly is unique\nonly for given news server. But Message-Ids cannot be shortened\nmeaningfully like SHA1 ids can; newertheless they are used in communication\nwithout any problems. Even if namespace is not simple ;-)\n"},{"id":"29317","messageId":"200610201157.22348.jnareb@gmail.com","threadId":"5925","inReplyTo":"45382120.9060702@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T09:57:21Z","receivedAt":"2006-10-20T09:57:21Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n>> The naming in git really is beautiful and beautifully simple.\n> \n> Well, you've got to admit that those names are at least superficially\n> ugly. \n\nIf you want pretty name, you tag it. Tags are exchanged during \nfetch/push operation. And you can have pretty names of revisions\nlike v1.4.3\n \n>> It's not monotonically increasing from one revision to the next, but\n>> I've never found that to be an issue. Of course, we do still use our\n>> own \"simple\" names for versioning the releases and snapshots of\n>> software we manage with git, and that's where being able to easily\n>> determine \"newer\" or \"older\" by simple numerical examination is\n>> important. I've honestly never encountered a situation where I was\n>> handed two git sha1 sums and wished that I could do the same thing.\n> \n> What's nice is being able see the revno 753 and knowing that \"diff -r\n> 752..753\" will show the changes it introduced.  Checking the revo on a\n> branch mirror and knowing how out-of-date it is.\n\nHuh? If you want what changes have been introduced by commit \nc3424aebbf722c1f204931bf1c843e8a103ee143, you just do\n\n# git diff c3424aebbf722c1f204931bf1c843e8a103ee143\n\n(or better \"git show\" instead of \"git diff\" or \"git diff-tree\").\nIf you give only one commit (only one revision) git automatically\ngives diff to its parent(s).\n\n\nBy the way, is referring to revision by it's revno _fast_?\n-- \nJakub Narebski\nPoland\n"},{"id":"29318","messageId":"vpqwt6v1f11.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"200610201157.22348.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-20T10:02:18Z","receivedAt":"2006-10-20T10:02:18Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n> Huh? If you want what changes have been introduced by commit \n> c3424aebbf722c1f204931bf1c843e8a103ee143, you just do\n>\n> # git diff c3424aebbf722c1f204931bf1c843e8a103ee143\n\nHow does git chose which ancestor to use if this revision has more\nthan one in this case?\n"},{"id":"29319","messageId":"20061020101350.GF20017@pasky.or.cz","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610201034170.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-20T10:13:50Z","receivedAt":"2006-10-20T10:13:50Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nDear diary, on Fri, Oct 20, 2006 at 10:38:48AM CEST, I got a letter\nwhere Johannes Schindelin said that...\n> On Fri, 20 Oct 2006, Lachlan Patrick wrote:\n> \n> > How does git disambiguate SHA1 hash collisions?\n> \n> It does not. You can fully expect the universe to go down before that \n> happens.\n> \n> The only reasonable worry is about SHA-1 being broken some time in future, \n> i.e. being able to construct a malign version of some source code _which \n> has the same hash_. There were plenty of discussions about that; Please \n> search the mailing list. (The consent was that those do not matter, \n> because an existing object will _never_ be overwritten by a fetch, so you \n> would not get that invalid object anyway.)\n\n well, that's somewhat a bold statement, since when you have a way to\nfabricate malicious objects, you probably can socially engineer to have\nit distributed to a large portion of repositories if you try hard\nenough. Or you hack kernel.org and replace the object. Who knows.\n\n But the thing is that noone has come any closer to this kind of attack\nat all. Currently known attacks are that you can relatively fast (which\ndoesn't mean \"5 minutes\"; I think that in case of SHA1 the complexity is\nstill huge, just smaller than intended, but I may remember wrong; you\ncan get a MD5 collision of this kind within one minute on a standard\nnotebook) create a _pair_ of objects sharing the same hash, where both\nobjects contain a big binary blob. So you would first have to engineer\nto have one of those objects accepted officially, then engineer the\nmalicious one getting in. Generating an object that hashes to a\npredetermined value is much harder problem and AFAIK there's no much\nprogress in breaking this.\n"},{"id":"29320","messageId":"20061020101601.GG20017@pasky.or.cz","threadId":"5925","inReplyTo":"45387F04.5010101@research.canon.com.au","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-20T10:16:01Z","receivedAt":"2006-10-20T10:16:01Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Oct 20, 2006 at 09:47:16AM CEST, I got a letter\nwhere Lachlan Patrick said that...\n> I think git has an alternative way to name revisions\n> (can someone please explain it in more detail, I've seen ~\n> mentioned only in passing in this thread).\n\nThis is just a notion that lets you point to revisions relative to a\ngiven id. ~ means n-th ancestor of the given commit.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i On 17/10/06, Sean wrote:\n> > > - - you can use a checkout to maintain a local mirror of a read-only\n> > > branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n> >\n> > I'm not sure what you mean here. A bzr checkout doesn't have any history\n> > does it? So it's not a mirror of a branch, but just a checkout of the\n> > branch head?\n> \n> There are two forms of checkout: a normal checkout which contains the\n> complete history of the branch, and a lightweight checkout, which just\n> has a pointer back to the original location of the history.\n> \n> In both cases, a \"bzr commit\" invocation will commit changes to the\n> remote location. In general, you only want to use a lightweight\n> checkout when there is a fast reliably connection to the branch (e.g.\n> if it is on the local file system, or local network).\n\nSo the \"lightweight checkout\" is equivalent of \"lazy clone\" we have\nmuch discussed on git mailing list about (without any resulting code,\nunfortunately). The point of problem was how to do this fast, without\nneed for fast reliable connection to the repository it was cloned from.\nFor example if to leave fetched objects in some kind of cache, or even\nin \"lightweight checkout\"/\"lazy clone\" repository database.\n\nIf repository we do \"lightweight checkout\"/\"lazy clone\" from is on\nlocal file system (perhaps network file system), then we can use\nalternates mechanism (git clone -l -s). That's why \"lazy clone\" was\nsometimes named \"remote alternates\".\n \n> Aaron would be talking about a normal (heavyweight) checkout here.\n> With a heavyweight checkout, you can do pretty much anything without\n> access to the branch. In contrast, almost all operations on a\n> lightweight checkout need access to the branch.\n\nWe have terminology conflict here. Bazaar-NG \"pull\" and \"merge\" vs.\nGIT \"fetch\", \"pull\" and \"merge\"; Bazaar-NG \"checkout\" vs. GIT \"clone\"\nand \"checkout\".\n\nIn GIT \"clone\" is what is used to copy whole repository, \"checkout\"\nis what is used to extract given/current branch to [given] working area.\n-- \nJakub Narebski\nPoland\n"},{"id":"29322","messageId":"eha8k6$uc$1@sea.gmane.org","threadId":"5925","inReplyTo":"loom.20061019T205327-196@post.gmane.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T10:32:43Z","receivedAt":"2006-10-20T10:32:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nathaniel Smith wrote:\n\n> Aaron Bentley utoronto.ca> writes:\n>\n>> Bazaar also supports multiple unrelated branches in a repository, as\n>> does CVS, SVN (depending how you squint), Arch, and probably Monotone.\n> \n> It's quite common in Monotone. You could probably do it in Mercurial as well,\n> though I don't know that anyone does. SVK definitely does it (since each user\n> has a single repo that's shared by all the projects they work on).\n\nI think that GIT separation of root, repository, and branches\nnamespaces is why there are so many calls for adding subproject\nsupport to GIT; people want to change to GIT literally, for example\nputting everything in one large repository.\n\nIn GIT there is no concept of root, like in CVS or SVN. You can\nput repository anywhere. By default GIT looks for repository \nin current directory or one of its parents; otherwise you have to\nprovide location of repository either by using GIT_DIR environment\nvariable, or by using --git-dir option to git wrapper.\n\nAnd the branch namespace is totally separate. There are some\nrestrictions on branch names (caused by notation GIT uses, for\nexample ^ means [first] parent of commit given by ),\nbut really few. Branch names can be hierarchical, like \"jc/diff\".\n\nSo there is no \"store everything in URL/path\" of\n /root/repo/branch\nnotation in GIT.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29323","messageId":"eha926$uc$2@sea.gmane.org","threadId":"5925","inReplyTo":"45373E27.3050209@op5.se","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T10:40:11Z","receivedAt":"2006-10-20T10:40:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson wrote:\n\n> Christian MICHON wrote:\n>\n>> close to 200 post on bzr-git war!\n>> is this the right place (git mailing list) to discuss about future\n>> features of bzr ?\n>> \n> \n> Perhaps not, but the tone is friendly (mostly), the patience of the \n> bazaar people seems infinite and lots of people seem to be having fun \n> while at the same time learning a thing or two about a different SCM.\n> Best case scenario, both git and bazaar come out of the discussion as \n> better tools. If there would never be any cross-pollination, git \n> wouldn't have half the features it has today.\n\nAnd it certainly helps to explain user-visible differences between\nBazaar-NG and GIT; I'd like to put ComparisonWithBazaarNG page on\nGitWiki (http://git.or.cz/gitwiki/) some time soon, in addition\nto ComparisonWithMercurial I meant to add from some time (stemming\nfrom discussion on #revctrl list on FreeNode), and in addition\nto existing GitSvnComparison page on GitWiki).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29324","messageId":"a7e835d40610200342ibc56fd9t542a60230ebe0020@mail.gmail.com","threadId":"5925","inReplyTo":"200610201151.13199.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"James Henstridge","fromEmail":"james@jamesh.id.au","sentAt":"2006-10-20T10:42:50Z","receivedAt":"2006-10-20T10:42:50Z","isPatch":false,"sender":{"key":"james@jamesh.id.au","avatar":"https://gravatar.com/avatar/3007d1d261c8d1edc4e388f53ea5e53ab40fd5f8334748472ba0e2037b76e4aa?d=mp&s=160"},"body":"On 20/10/06, Jakub Narebski wrote:\n> James Henstridge wrote:\n> > On 20/10/06, Carl Worth wrote:\n> >> On Thu, 19 Oct 2006 19:01:58 -0400, Aaron Bentley wrote:\n>\n> >>> Additionally, the new mainline can keep a mirror of the\n> >>> abandoned mainline in its repository, because there are virtually no\n> >>> additional storage requirements to doing so.\n> >>\n> >> And this part I don't understand. I can understand the mainline\n> >> storing the revisions, but I don't understand how it could make them\n> >> accessible by the published revision numbers of the \"abandoned\"\n> >> line. And that's the problem.\n> >\n> > With this sort of setup, I would publish my branches in a directory\n> > tree like this:\n> >\n> > /repo\n> > /branch1\n> > /branch2\n> >\n> > I make \"/repo\" a Bazaar repository so that it stores the revision data\n> > for all branches contained in the directory (the tree contents,\n> > revision meta data, etc).\n>\n> And here we have a feature which is as far as I see unique to git,\n> namely to have persistent branches with _separate namespace_. It means\n> that we can have hierarchical branch names (including names like\n> \"remotes//\", or \"jc/diff\"), and we don't\n> have to guess where repository name ends and branch name begins.\n\nWith the above layout, I would just type:\n bzr branch http://server/repo/branch1\n\nThis command behaves identically whether the repository data is in\n/repo or in /repo/branch1. Someone pulling from the branch doesn't\nhave to care what the repository structure is. Having a separate\nnamespace for branch names only really makes sense if the user needs\nto care about it.\n\nAs for heirarchical names, there is nothing stopping you from using\ndeaper directory structures with Bazaar too. Bazaar just checks each\nsuccessive parent directory til it finds a repository for the branch.\n\n\n> The idea of \"branches (and tags) as directories\" was if I understand\n> it correctly introduced by Subversion, and from what can be seen from\n> troubles with git-svn (stemming from the fact that division between\n> project name and branch name is the matter of _convention_) at least\n> slightly brain-damaged.\n\nI think you are a bit confused about how Bazaar works here. A Bazaar\nrepository is a store of trees and revision metadata. A Bazaar branch\nis just a pointer to a head revision in the repository. As you can\nprobably guess, the data for the branch is a lot smaller than the data\nfor the repository.\n\nYou can store the repository and branch in the same directory to get a\nstandalone branch. The layout I described above has a repository in a\nparent directory, shared by multiple branches.\n\nIf you are comparing Subversion and Bazaar, a Bazaar branch shares\nmore properties with a full Subversion repository rather than a\nSubversion branch.\n\n\n> > The \"/repo/branch1\" essentially just contains a list of mainline\n> > revision IDs that identify the branch. This could probably be just\n> > store the head revision ID, but there are some optimisations that make\n> > use of the linear history here.\n> >\n> > If the ancestry of \"/repo/branch2\" is a subset of branch1 (as it might\n> > be if the in the case of forked then merged projects), then all its\n> > revision data will already be in the repository when branch1 was\n> > imported. The only cost of keeping the branch around (and publishing\n> > it) is the list of revision IDs in its mainline history.\n> >\n> > For similar reasons, the cost of publishing 20 related Bazaar branches\n> > on my web server is generally not 20 times the cost of publishing a\n> > single branch.\n> >\n> > I understand that you get similar benefits by a GIT repository with\n> > multiple head revisions.\n>\n> You can get similar benefits by a GIT repository with shared object\n> database using alternates mechanism. And that is usually preferred\n> over storing unrelated branches, i.e. branches pointing to disconnected\n> DAG (separate trees in BK terminology) of revision, if that you mean by\n> multiple head revisions (because in GIT there is no notion of \"mainline\"\n> branch, only of current (HEAD) branch).\n\nI may have got the git terminology wrong. I was trying to draw\nparallels between the .git/refs/... files in a git repository and the\nway multiple branches can be stored in a Bazaar repository.\n\nI am not claiming that you'll get bandwidth or disk space benefits for\nstoring unrelated branches in a single Bazaar repository. But if the\nbranches are related, then there will be space savings (which is what\nthe great-grandparent post was asking about).\n\n\n> >>>> But for these communications, revision numbers will not provide\n> >>>> historically stable values that can be used.\n> >>>\n> >>> They certainly can.\n> >>>\n> >>> The coder says \"I've put up a branch at http://example.com/bzr/feature.\n> >>> In revision 5, I started work on feature A. I finished work in\n> >>> revision 6. But then I had to fix a related bug in revision 7.\"\n> >>\n> >> \"I've put this branch up\" isn't historically stable...\n> >\n> > With the repository structure mentioned above, the cost of publishing\n> > multiple branches is quite low. If I continue to work on the project,\n> > then there is no particular bandwidth or disk space reasons for me to\n> > cut off access to my old branches.\n> >\n> > For similar reasons, it doesn't cost me much to mirror other people's\n> > related branches if I really care about them.\n>\n> But the revision number in this case _changes_. It is from 7 to\n> branch:7 but still it changes somewhat.\n\nA revision number is only has meaning in the context of a branch. If\nI mirror a branch, the revision numbers in the context of each will\nrefer to the same revision IDs.\n\nI am not sure what sort of distinction you are trying to draw.\n\n\n> >> The naming in git really is beautiful and beautifully simple.\n> >\n> > I don't think anyone is saying that universally unique names are bad.\n> > But I also don't see a problem with using shorter names that only have\n> > meaning in a local scope.\n> >\n> > I've noticed some people using abbreviated SHA1 sums with GIT. Isn't\n> > that also a case of trading potential global uniqueness for\n> > convenience when working in a local scope?\n>\n> Emphasisis on _potential_. SHA1 id abbreviated to 6 characters might\n> be not unique in larger project, but for example the chance that\n> SHA1 id abbreviated to 7 or 8 characters is not unique is really low.\n\nMy point was that by shortening the IDs with GIT, you are trading\nglobal uniqueness (i.e. the identifier may clash with one found in a\ndifferent context) for the convenience of shorter identifiers.\n\nProvided you know that the tradeoff is being made, it isn't generally\nmuch of a problem. I agree that the ability to pick how much of a\ntradeoff is made by altering the length of the identifier is a nice\nproperty of GIT.\n\n\n> Yet another analogy:\n>\n> SHA1 identifiers of commits (and not only commits) can be compared\n> to Message-Ids of Usenet messages, while revision numbers can be compared\n> to Xref number of Usenet message which if I understand correctly is unique\n> only for given news server. But Message-Ids cannot be shortened\n> meaningfully like SHA1 ids can; newertheless they are used in communication\n> without any problems. Even if namespace is not simple ;-)\n\nI can't say I ever used usenet much, so can't comment too much. But\nfrom your description, a (server, xref) tuple could be used to look up\nthe unique identifier in a similar way to how you can do so in Bazaar\nwith a (branch_url, revno) tuple.\n\nJames.\n"},{"id":"29327","messageId":"eha99t$uc$3@sea.gmane.org","threadId":"5925","inReplyTo":"45379A02.1010105@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T10:44:18Z","receivedAt":"2006-10-20T10:44:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n\n>> It would be nice if the SCM tools included rss feeds for communicating zip\n>> patch bundles.\n> \n> The bzr \"webserve\" plugin provides rss feeds.\n\nGit \"gitweb\" (in git.git repo from some time) web interface provides OPML\nand RSS feeds.\n"},{"id":"29326","messageId":"4538A8B0.3080003@shadowen.org","threadId":"5925","inReplyTo":"vpqwt6v1f11.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-10-20T10:45:04Z","receivedAt":"2006-10-20T10:45:04Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Matthieu Moy wrote:\n> Jakub Narebski writes:\n> \n>> Huh? If you want what changes have been introduced by commit \n>> c3424aebbf722c1f204931bf1c843e8a103ee143, you just do\n>>\n>> # git diff c3424aebbf722c1f204931bf1c843e8a103ee143\n> \n> How does git chose which ancestor to use if this revision has more\n> than one in this case?\n\nWell if there is more than one parent, then there are more than one\ndiff. For instance this is a merge commit which I asked to 'see'.\n\nThis gets shown in the combined diff format, showing the results of the\nconflict resolution.\n\ndiff --cc this\nindex fbbafbf,10c8337..43b7af0\n--- a/this\n+++ b/this\n@@@ -1,3 -1,3 +1,4 @@@\n 1\n+ 2a\n +2b\n 3\n\nIf you want to know each individual diff in a more 'standard' form you\ncan ask about the parents specifically.\n\napw@pinky$ git diff HEAD^1..\ndiff --git a/this b/this\nindex fbbafbf..43b7af0 100644\n--- a/this\n+++ b/this\n@@ -1,3 +1,4 @@\n 1\n+2a\n 2b\n 3\n\napw@pinky$ git diff HEAD^2..\ndiff --git a/bar b/bar\nnew file mode 100644\nindex 0000000..8dc5f23\n--- /dev/null\n+++ b/bar\n@@ -0,0 +1 @@\n+this that other\ndiff --git a/this b/this\nindex 10c8337..43b7af0 100644\n--- a/this\n+++ b/this\n@@ -1,3 +1,4 @@\n 1\n 2a\n+2b\n 3\n"},{"id":"29325","messageId":"a7e835d40610200345o2ad83bb7k6dfc29867498971c@mail.gmail.com","threadId":"5925","inReplyTo":"200610201157.22348.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"James Henstridge","fromEmail":"james@jamesh.id.au","sentAt":"2006-10-20T10:45:50Z","receivedAt":"2006-10-20T10:45:50Z","isPatch":false,"sender":{"key":"james@jamesh.id.au","avatar":"https://gravatar.com/avatar/3007d1d261c8d1edc4e388f53ea5e53ab40fd5f8334748472ba0e2037b76e4aa?d=mp&s=160"},"body":"On 20/10/06, Jakub Narebski wrote:\n> > What's nice is being able see the revno 753 and knowing that \"diff -r\n> > 752..753\" will show the changes it introduced. Checking the revo on a\n> > branch mirror and knowing how out-of-date it is.\n>\n> Huh? If you want what changes have been introduced by commit\n> c3424aebbf722c1f204931bf1c843e8a103ee143, you just do\n>\n> # git diff c3424aebbf722c1f204931bf1c843e8a103ee143\n>\n> (or better \"git show\" instead of \"git diff\" or \"git diff-tree\").\n> If you give only one commit (only one revision) git automatically\n> gives diff to its parent(s).\n\nIf a revision has multiple parents, what does it diff against in this\ncase? Do you get one diff against each parent revision?\n\nJames.\n"},{"id":"29328","messageId":"eha9no$5t7$1@sea.gmane.org","threadId":"5925","inReplyTo":"7vac3sru9a.fsf@assigned-by-dhcp.cox.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T10:51:40Z","receivedAt":"2006-10-20T10:51:40Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n>> The other big difference is being able to do merges in seconds. The \n>> biggest cost of doing a big merge these days seems to literally be \n>> generating the diffstat of the changes at the end (which is purely a UI \n>> issue, but one that I find so important that I'll happily take the extra \n>> few seconds for that, even if it sometimes effectively doubles the \n>> overhead).\n> \n> An interesting effect on this is when people have a column for\n> merge performance in a SCM comparison table, they would include\n> time to run the diffstat as part of the time spent for merging\n> when they fill in the number for git, but not for any other SCM.\n\nSo if you want to compare merge performance with other SCM, you should\neither add time to run diffstat for other SCM, or substract time to\nrun \"git diff-tree --stat\".\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29330","messageId":"eha9rq$5t7$2@sea.gmane.org","threadId":"5925","inReplyTo":"453803E6.2060309@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T10:53:51Z","receivedAt":"2006-10-20T10:53:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n\n>>>          And I personally have been developing a bugtracker that is\n>>> distributed in the same way bzr is; it stores bug data in the source\n>>> tree of a project, so that bug activities follow branches around.\n>>\n>> That kind of thing sounds very useful. As I've been talking about\n>> \"numbers\" here in bug trackers and mailing lists, it should be obvious\n>> that I consider the information stored in such systems an important\n>> part of the history of a code project. So it would be nice if all of\n>> that history were stored in an equally reliable system in some way.\n> \n> If you're interested, it's called \"Bugs Everywhere\" and it's available here:\n> http://panoramicfeedback.com/opensource/\n> \n> New VCS backends are welcome :-D\n\nWhile SCM can (and should be usually) distributed, I think that bugtracker\nhas to be centralized.\n"},{"id":"29329","messageId":"200610201300.46361.jnareb@gmail.com","threadId":"5925","inReplyTo":"45382120.9060702@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T11:00:45Z","receivedAt":"2006-10-20T11:00:45Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n\n> Bazaar encourages you to stick lots and lots of branches in your\n> repository.  They don't even have to be related.  For example, my repo\n> contains branches of bzr, bzrtools, Meld, and BazaarInspect.\n\nGIT encourages you to use separate repositories for unrelated projects.\nAnd alternates mechanism for related projects (like different Linux\nkernel repositories: Linus, stable, etc.).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29331","messageId":"ehaapb$5t7$3@sea.gmane.org","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610201034170.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T11:09:36Z","receivedAt":"2006-10-20T11:09:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Fri, 20 Oct 2006, Lachlan Patrick wrote:\n> \n>> How does git disambiguate SHA1 hash collisions?\n> \n> It does not. You can fully expect the universe to go down before that \n> happens.\n \nOr you can compile git with COLLISION_CHECK\n\n>From Makefile:\n# Define COLLISION_CHECK below if you believe that SHA1's\n# 1461501637330902918203684832716283019655932542976 hashes do not give you\n# sufficient guarantee that no collisions between objects will ever happen.\n"},{"id":"29332","messageId":"ehablj$bm4$1@sea.gmane.org","threadId":"5925","inReplyTo":"vpq1wp42rd4.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T11:24:40Z","receivedAt":"2006-10-20T11:24:40Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthieu Moy wrote:\n\n> Then, one other difference is in the UI. bzr shows you commits in a\n> kind of hierarchical maner, like (fictive example, that's not the real\n> exact format).\n> \n> $ bzr log\n> commiter: upstream@maintainer.com\n> message:\n>   merged the work on a feature\n>   ------\n>   commiter: contributor@site.com\n>   message:\n>     prepared for feature X\n>   ------\n>   commiter: contributor@site.com\n>   message:\n>     implemented feature X\n>   ------\n>   commiter: contributor@site.com\n>   message:\n>     added testcase for feature X\n> ------\n> commiter: upstream@maintainer.com\n> message:\n>   something else\n> \n> No big difference in the model either, but it probably reveals a\n> different vision of what \"history\" means.\n\nWe have in GIT git-show-branch command for that (although it\nhas quite strange UI, and shows only title of commit), we\ncan do \"git log | git name-rev --stdin\", or better use graphical\nhistory viewers like gitk (Tcl/Tk) or qgit (Qt). Graphical history\nviewers are a must with more complicated history. \n\nBazaar-NG has bzr-gtk.\n"},{"id":"29333","messageId":"Pine.LNX.4.63.0610201335420.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"ehaapb$5t7$3@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-20T11:37:02Z","receivedAt":"2006-10-20T11:37:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Oct 2006, Jakub Narebski wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Fri, 20 Oct 2006, Lachlan Patrick wrote:\n> > \n> >> How does git disambiguate SHA1 hash collisions?\n> > \n> > It does not. You can fully expect the universe to go down before that \n> > happens.\n> \n> Or you can compile git with COLLISION_CHECK\n> \n> >From Makefile:\n> # Define COLLISION_CHECK below if you believe that SHA1's\n> # 1461501637330902918203684832716283019655932542976 hashes do not give you\n> # sufficient guarantee that no collisions between objects will ever happen.\n\nYou can document your disbelief.\n\nBut it does not change a thing. Since v0.99~653, we do not have any \ncollision check, even if compiled with COLLISION_CHECK.\n\nCiao,\nDscho\n"},{"id":"29334","messageId":"ehaceq$he7$1@sea.gmane.org","threadId":"5925","inReplyTo":"453761D5.80306@spamcop.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T11:38:06Z","receivedAt":"2006-10-20T11:38:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Charles Duffy wrote:\n\n> Johannes Schindelin wrote:\n>>> Shell scripts allow for a fragile system because they could include C\ncode\n>>> snippets which they then compile and LD_PRELOAD.\n>>> \n>>\n>> Well, I do not expect people to misbehave. You do not compile a nasty \n>> C-program from a shell script _by mistake_.\n> \n> You also don't replace bzrlib functionality (in your terms, plumbing) in \n> a plugin by mistake.\n\nPerhaps the cause for not having plugins in GIT (besides the fact that\nit follows OSS + Unix guidelines) is that git is not libified, yet. It\nis \"scriptified\", i.e. it has many helper programs, and has options for\npipelining that it is really easy to use in scripts (Cogito, pg, StGit),\nbut the libification effort is [only] ongoing.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29336","messageId":"200610201350.12273.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061019123349.GE20017@pasky.or.cz","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T11:50:11Z","receivedAt":"2006-10-20T11:50:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"I have lost somewhere among many emails in this thread the email I \nwanted to reply to, the one mentioning for the first time the lack of \nparents ordering in GIT, but this one should do.\n\n\nPetr Baudis wrote:\n\n> The lack of parents ordering in Git is directly connected with\n> fast-forwarding.\n\nThere are exactly _two_ places where Git treats first parent specially \n(correct me if I'm wrong).\n\nFirst, ^ is shortcut for ^1, i.e. for first \nparent of commit. ~ is shortcut for ^^...^ \n(n-times '^'), which means that ~ is n-th parent in \n1st-parent lineage of . But you can always use names\nlike for example next~12^2^^2~2.\n\nSecond, git-diff with only one generates diff to first\nparent. But you can always use '-c' or '-cc' combined diff format\nor '-m' with default diff format to compare to _all_ parents.\n-- \nJakub Narebski\nPoland\n"},{"id":"29337","messageId":"200610201401.33676.jnareb@gmail.com","threadId":"5925","inReplyTo":"a7e835d40610200345o2ad83bb7k6dfc29867498971c@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T12:01:33Z","receivedAt":"2006-10-20T12:01:33Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"James Henstridge wrote:\n> On 20/10/06, Jakub Narebski wrote:\n> > > What's nice is being able see the revno 753 and knowing that \"diff -r\n> > > 752..753\" will show the changes it introduced. Checking the revo on a\n> > > branch mirror and knowing how out-of-date it is.\n> >\n> > Huh? If you want what changes have been introduced by commit\n> > c3424aebbf722c1f204931bf1c843e8a103ee143, you just do\n> >\n> > # git diff c3424aebbf722c1f204931bf1c843e8a103ee143\n> >\n> > (or better \"git show\" instead of \"git diff\" or \"git diff-tree\").\n> > If you give only one commit (only one revision) git automatically\n> > gives diff to its parent(s).\n> \n> If a revision has multiple parents, what does it diff against in this\n> case? Do you get one diff against each parent revision?\n\nIf revision has multiple parents (is merge commit), git-diff\n(which is used by git-show) does not show differences (unless you\ngive two revisions in git-diff case).\n\nYou can either use '-m' option to show differences from all its\nparents, or '-c'/'--cc' to show combined diff ('--cc' shows more\ncompact diff).\n-- \nJakub Narebski\nPoland\n"},{"id":"29338","messageId":"200610201403.53664.jnareb@gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610201335420.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T12:03:53Z","receivedAt":"2006-10-20T12:03:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> On Fri, 20 Oct 2006, Jakub Narebski wrote:\n> \n>> Johannes Schindelin wrote:\n>> \n>>> On Fri, 20 Oct 2006, Lachlan Patrick wrote:\n>>> \n>>>> How does git disambiguate SHA1 hash collisions?\n>>> \n>>> It does not. You can fully expect the universe to go down before that \n>>> happens.\n>> \n>> Or you can compile git with COLLISION_CHECK\n>> \n>> From Makefile:\n>> # Define COLLISION_CHECK below if you believe that SHA1's\n>> # 1461501637330902918203684832716283019655932542976 hashes do not give you\n>> # sufficient guarantee that no collisions between objects will ever happen.\n> \n> You can document your disbelief.\n> \n> But it does not change a thing. Since v0.99~653, we do not have any \n> collision check, even if compiled with COLLISION_CHECK.\n\nSo why it is left in Makefile? Does defining this change a thing\nor not (in which case this section should be removed)?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29341","messageId":"vpqslhjyxlz.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"eha9rq$5t7$2@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-20T12:34:32Z","receivedAt":"2006-10-20T12:34:32Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n>> If you're interested, it's called \"Bugs Everywhere\" and it's available here:\n>> http://panoramicfeedback.com/opensource/\n>> \n>> New VCS backends are welcome :-D\n>\n> While SCM can (and should be usually) distributed, I think that bugtracker\n> has to be centralized.\n\nWell, indeed, I think bug _reporting_ should be somehow centralized,\nwhile bug _fixing_ can be decentralized: You fix a bug, you mark it as\nfixed, and then the main branch gets the information that the bug is\nfixed when the bugfix is merged.\n\n-- \nMatthieu\n"},{"id":"29342","messageId":"Pine.LNX.4.63.0610201444030.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"200610201403.53664.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-20T12:48:25Z","receivedAt":"2006-10-20T12:48:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Oct 2006, Jakub Narebski wrote:\n\n> > But it does not change a thing. Since v0.99~653, we do not have any \n> > collision check, even if compiled with COLLISION_CHECK.\n> \n> So why it is left in Makefile? Does defining this change a thing\n> or not (in which case this section should be removed)?\n\nIt does not. The relevant parts in the code read like this:\n\nsha1_filc.c:1442\n /* FIXME!!! Collision check here ? */\n\nsha1_file.c:1541\n /*\n * FIXME!!! We might do collision checking here, but we'd\n * need to uncompress the old file and check it. Later.\n */\n\nIt was hoped that the people who actually care would implement that \nfunctionality. (Note that in an earlier version, the check was \nimplemented, but would have to be different these days: pack files did not \nexist then).\n\nCiao,\nDscho\n"},{"id":"29343","messageId":"200610201517.26702.jnareb@gmail.com","threadId":"5925","inReplyTo":"a7e835d40610200342ibc56fd9t542a60230ebe0020@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T13:17:26Z","receivedAt":"2006-10-20T13:17:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"James Henstridge wrote:\n> On 20/10/06, Jakub Narebski wrote:\n>> James Henstridge wrote:\n>>> On 20/10/06, Carl Worth wrote:\n>>>> On Thu, 19 Oct 2006 19:01:58 -0400, Aaron Bentley wrote:\n\n>>> With this sort of setup, I would publish my branches in a directory\n>>> tree like this:\n>>>\n>>> /repo\n>>> /branch1\n>>> /branch2\n>>>\n>>> I make \"/repo\" a Bazaar repository so that it stores the revision data\n>>> for all branches contained in the directory (the tree contents,\n>>> revision meta data, etc).\n>>\n>> And here we have a feature which is as far as I see unique to git,\n>> namely to have persistent branches with _separate namespace_. It means\n>> that we can have hierarchical branch names (including names like\n>> \"remotes//\", or \"jc/diff\"), and we don't\n>> have to guess where repository name ends and branch name begins.\n> \n> With the above layout, I would just type:\n> bzr branch http://server/repo/branch1\n\nWith Cogito (you can think of it either as alternate Git UI, or as SCM\nbuilt on top of Git) you would use\n\n $ cg clone http://server/repo#branch\n\nfor example\n\n $ cg clone git://git.kernel.org/pub/scm/git/git.git#next\n\nto clone _single_ branch (in bzr terminology, \"heavy checkout\" of branch).\nBut you can also clone _whole_ repository, _all_ published branches with\n\n $ cg clone git://git.kernel.org/pub/scm/git/git.git\n\nWith core Git it is the same, but we don't have the above shortcut\nfor checking only one branch; branches to checkout are in separate\narguments to git-clone.\n\nIn bzr it seems that you cannot distinguish (at least not only\nfrom URL) where repository ends and branch begins.\n\n*Sidenote:* In current version of gitweb you can get file\nin given repository in given branch using the following\nnotation:\n\n http://path/to/gitweb.cgi/repo/sitory/branch/name:file/name\n\ngitweb can detect where branch name ends and repository name\nbegins; usually (by convention) \"bare\" git repositories uses\n.git name, \"clothed\" git repositories uses\n/.git\n\n\nSee also below.\n\n> This command behaves identically whether the repository data is in\n> /repo or in /repo/branch1. Someone pulling from the branch doesn't\n> have to care what the repository structure is. Having a separate\n> namespace for branch names only really makes sense if the user needs\n> to care about it.\n> \n> As for hierarchical names, there is nothing stopping you from using\n> deaper directory structures with Bazaar too. Bazaar just checks each\n> successive parent directory til it finds a repository for the branch.\n> \n>> The idea of \"branches (and tags) as directories\" was if I understand\n>> it correctly introduced by Subversion, and from what can be seen from\n>> troubles with git-svn (stemming from the fact that division between\n>> project name and branch name is the matter of _convention_) at least\n>> slightly brain-damaged.\n> \n> I think you are a bit confused about how Bazaar works here. A Bazaar\n> repository is a store of trees and revision metadata. A Bazaar branch\n> is just a pointer to a head revision in the repository. As you can\n> probably guess, the data for the branch is a lot smaller than the data\n> for the repository.\n> \n> You can store the repository and branch in the same directory to get a\n> standalone branch. The layout I described above has a repository in a\n> parent directory, shared by multiple branches.\n> \n> If you are comparing Subversion and Bazaar, a Bazaar branch shares\n> more properties with a full Subversion repository rather than a\n> Subversion branch.\n\nOh, that explained yet another difference between Bazaar-NG (and other\nSCM which uses similar model) and Git.\n\nIn Git branch is just a pointer to head (top) commit (hence they are stored\nunder .git/refs/heads/) in given line of development. Git also stores\ninformation (in .git/HEAD) about which branch we are currently on, which\nmeans on which branch git puts new commits. Nothing more (well, there\ncan be log of changes to head in .git/logs/refs/heads/ but that is optional\nand purely local information). In Bazaar-NG you have to store (if I\nunderstand it correctly) mapping from revnos to revisions.\n \nBy default (it means for example default behavior of git-clone, if we don't\nuse --bare option) git repository is _embedded_ in working area. We have\n\n .git/\n .git/HEAD\n ...\n .git/refs/heads/\n ...\n \n\nSo repo/branch wouldn't work, because 'branch' would conflict with working\narea files. GIT doesn't follow the CVS model of separate storage area\n(CVSROOT) and having only pointer to said area (files in CVS/ \nsubdirectories) in working directory.\n\nIn GIT to work on some repository you don't (like from what I understand\nin Bazaar-NG) \"checkout\" some branch (which would automatically copy some\ndata in case of \"heavy checkout\" or just save some pointer to repository\nin \"lightweight checkout\" case). You clone whole repository; well you can\nselect which branches to clone. \"Checkout\" in GIT terminology means to\npopulate working area with given version (and change in repository which\nbranch is current, usually).\n\nHow checked out working area looks like in Bazaar-NG?\n\n[...]\n>>> For similar reasons, the cost of publishing 20 related Bazaar branches\n>>> on my web server is generally not 20 times the cost of publishing a\n>>> single branch.\n>>>\n>>> I understand that you get similar benefits by a GIT repository with\n>>> multiple head revisions.\n>>\n>> You can get similar benefits by a GIT repository with shared object\n>> database using alternates mechanism. And that is usually preferred\n>> over storing unrelated branches, i.e. branches pointing to disconnected\n>> DAG (separate trees in BK terminology) of revision, if that you mean by\n>> multiple head revisions (because in GIT there is no notion of \"mainline\"\n>> branch, only of current (HEAD) branch).\n> \n> I may have got the git terminology wrong. I was trying to draw\n> parallels between the .git/refs/... files in a git repository and the\n> way multiple branches can be stored in a Bazaar repository.\n\nYes, but using Git that way has serious disadvantages. For example\nthere is only one current branch pointer and only one index (dircache)\nper git repository.\n\n> I am not claiming that you'll get bandwidth or disk space benefits for\n> storing unrelated branches in a single Bazaar repository. But if the\n> branches are related, then there will be space savings (which is what\n> the great-grandparent post was asking about).\n\nSo it is way better to use one repository per project, and use alternates\nmechanism to save space.\n\nBut I agree that saving \"old fork\" info as separate branch doesn't lead\nto that much inefficiency as might be thought.\n\nBut after saving \"old fork\" as a branch revno based revision identifiers\nchange from http://old.host/old/repo:127 to http://host/repo/old.fork:127\nThat is maybe minimal change, but this is change!\n\n\nP.S. In two separate git repositories, even if they exchange information\nwith each other, the branch names can be different.\n-- \nJakub Narebski\nPoland\n"},{"id":"29344","messageId":"200610201520.42799.jnareb@gmail.com","threadId":"5925","inReplyTo":"vpqslhjyxlz.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T13:20:42Z","receivedAt":"2006-10-20T13:20:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthieu Moy wrote:\n> Jakub Narebski writes:\n> \n> >> If you're interested, it's called \"Bugs Everywhere\" and it's available here:\n> >> http://panoramicfeedback.com/opensource/\n> >> \n> >> New VCS backends are welcome :-D\n> >\n> > While SCM can (and should be usually) distributed, I think that bugtracker\n> > has to be centralized.\n> \n> Well, indeed, I think bug _reporting_ should be somehow centralized,\n> while bug _fixing_ can be decentralized: You fix a bug, you mark it as\n> fixed, and then the main branch gets the information that the bug is\n> fixed when the bugfix is merged.\n\nBut you don't need much infrastructure for branch fixing. Fix it in\nrepository, and write bug number (you have to have centralized bugtracker\nfor numbers) or bug identifier in commit message. You write (or post-commit\nhook writes) in bugtracker that bug was fixed in commit .\nYou tell mainline to pull from you. That's all.\n"},{"id":"29347","messageId":"200610201526.42811.jnareb@gmail.com","threadId":"5925","inReplyTo":"200610201350.12273.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T13:26:42Z","receivedAt":"2006-10-20T13:26:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n> Second, git-diff with only one generates diff to first\n> parent. But you can always use '-c' or '-cc' combined diff format\n> or '-m' with default diff format to compare to _all_ parents.\n\nI stand corrected: git-diff refuses to show anything if provided\nwith only one commit, and commit has more than one parent. So it\ndoes not reat first parent specially.\n-- \nJakub Narebski\nPoland\n"},{"id":"29349","messageId":"20061020133630.GH20017@pasky.or.cz","threadId":"5925","inReplyTo":"200610201517.26702.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-20T13:36:30Z","receivedAt":"2006-10-20T13:36:30Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Oct 20, 2006 at 03:17:26PM CEST, I got a letter\nwhere Jakub Narebski said that...\n> But you can also clone _whole_ repository, _all_ published branches with\n> \n> $ cg clone git://git.kernel.org/pub/scm/git/git.git\n\nNope, cg clone will in this case clone the master branch (or whatever\nthe remote HEAD points at). cg clone -a is planned but not implemented\nyet. Very soon now, hopefully. :-)\n\n> In GIT to work on some repository you don't (like from what I understand\n> in Bazaar-NG) \"checkout\" some branch (which would automatically copy some\n> data in case of \"heavy checkout\" or just save some pointer to repository\n> in \"lightweight checkout\" case). You clone whole repository; well you can\n> select which branches to clone. \"Checkout\" in GIT terminology means to\n> populate working area with given version (and change in repository which\n> branch is current, usually).\n\nYou don't need to, you can switch your working tree between various\nbranches. I think Linus said he does that (or was it Junio?), and I do that\nas well, as well as many others.\n\nA good question would be \"when to create another branch and when to\nclone the repository\". And I don't think there's any good answer, except\n\"when you are comfortable with it\". :-) Both approaches have pros/cons.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> from discussion on #revctrl list on FreeNode), and in addition\n> to existing GitSvnComparison page on GitWiki).\n\nOh, you mean that document that I orphaned when I got sidetracked\nand forgot I hadn't quite finished it? :-)\n\n-- \nShawn.\n"},{"id":"29352","messageId":"20061020134740.GI20017@pasky.or.cz","threadId":"5925","inReplyTo":"200610201520.42799.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-20T13:47:40Z","receivedAt":"2006-10-20T13:47:40Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Oct 20, 2006 at 03:20:42PM CEST, I got a letter\nwhere Jakub Narebski said that...\n> Matthieu Moy wrote:\n> > Jakub Narebski writes:\n> > \n> > >> If you're interested, it's called \"Bugs Everywhere\" and it's available here:\n> > >> http://panoramicfeedback.com/opensource/\n> > >> \n> > >> New VCS backends are welcome :-D\n> > >\n> > > While SCM can (and should be usually) distributed, I think that bugtracker\n> > > has to be centralized.\n> > \n> > Well, indeed, I think bug _reporting_ should be somehow centralized,\n> > while bug _fixing_ can be decentralized: You fix a bug, you mark it as\n> > fixed, and then the main branch gets the information that the bug is\n> > fixed when the bugfix is merged.\n> \n> But you don't need much infrastructure for branch fixing. Fix it in\n> repository, and write bug number (you have to have centralized bugtracker\n> for numbers) or bug identifier in commit message. You write (or post-commit\n> hook writes) in bugtracker that bug was fixed in commit .\n> You tell mainline to pull from you. That's all.\n\nYes but noone did the infrastructure yet. :-) Also, we need a way to\nmake it worth smooth, e.g. so that you don't have to download any\nspecial stuff after cloning a branch - thus the post-commit hook needs\nto be cloned too, but you also need to deal with the security\nimplications reasonably. (We would very much like to have \"hooks\ncloning\" in Git in our in-SUSE usage as well; I didn't get to it yet.)\n\nOn a somewhat related note, I was on Microsoft's presentation at my\nuniversity about their Team Foundation Server. And Microsoft's clearly\naware that SourceSafe was a horrible crap and the version control in TFS\nis much more advanced and even shows some signs of distributiveness (but\nI don't know how much, the presenter did not know details about how it\nworks).\n\nBut their selling point really is the tight integration with bug\ntracking and autobuild system. And it indeed does look pretty nice (when\nyou watch it, you might get quite a different perspective when actually\n*using* it ;).\n\nYou can read my brief notes from the presentation at\n\n\thttp://pasky.or.cz/~pasky/cp/tfs-lecture-notes.txt\n\nIt's a bit of bureaucracy for developers but managers will absolutely\n*adore* it.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Petr already mentioned that the data currently shown in the email\n> text isn't really useful.\n\nIn Bazaar bundles, the text of the diff is an integral part of the data.\n It is used to generate the text of all the files in the revision.\n\nBazaar bundles were designed to be used on mailing lists. So you can\nreview the changes from the diff, comment on them, and if it seems\nsuitable, merge them.\n\n> Although that might just make the email bigger for not a lot of\n> gain.\n\nIt's my understanding that most changes discussed on lkml are provided\nas a series of patches. Bazaar bundles are intended as a direct\nreplacement for patches in that use case.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFONck0F+nu1YWqI0RAgrHAJ0flmF1wCGYYUSk8f2iy8LuZnkaKQCdFSIo\nJIaKi9S8TzUkhvaWpYYP5AA=\n=MgZo\n-----END PGP SIGNATURE-----\n"},{"id":"29354","messageId":"200610201612.14417.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061020133630.GH20017@pasky.or.cz","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T14:12:13Z","receivedAt":"2006-10-20T14:12:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis wrote:\n> Dear diary, on Fri, Oct 20, 2006 at 03:17:26PM CEST, I got a letter\n> where Jakub Narebski said that...\n\n>> But you can also clone _whole_ repository, _all_ published branches with\n>> \n>> $ cg clone git://git.kernel.org/pub/scm/git/git.git\n> \n> Nope, cg clone will in this case clone the master branch (or whatever\n> the remote HEAD points at). cg clone -a is planned but not implemented\n> yet. Very soon now, hopefully. :-)\n\nThat's probably because Cogito still uses obsolete branches/\n\n\n$ git clone git://git.kernel.org/pub/scm/git/git.git\n\nclones _whole_ repository, all the branches and tags, and saves information\nabout the branches it cloned, and URL to repository in remotes/ file.\n \n>> In GIT to work on some repository you don't (like from what I understand\n>> in Bazaar-NG) \"checkout\" some branch (which would automatically copy some\n>> data in case of \"heavy checkout\" or just save some pointer to repository\n>> in \"lightweight checkout\" case). You clone whole repository; well you can\n>> select which branches to clone. \"Checkout\" in GIT terminology means to\n>> populate working area with given version (and change in repository which\n>> branch is current, usually).\n> \n> You don't need to, you can switch your working tree between various\n> branches. I think Linus said he does that (or was it Junio?), and I do that\n> as well, as well as many others.\n\nI should have said: bring working area to state given by some revision\n(instead of \"populate working area\").\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29356","messageId":"20061020141222.GA17497@coredump.intra.peff.net","threadId":"5925","inReplyTo":"45382120.9060702@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-20T14:12:22Z","receivedAt":"2006-10-20T14:12:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 19, 2006 at 09:06:40PM -0400, Aaron Bentley wrote:\n\n> What's nice is being able see the revno 753 and knowing that \"diff -r\n> 752..753\" will show the changes it introduced. Checking the revo on a\n> branch mirror and knowing how out-of-date it is.\n\nI was accustomed to doing such things in CVS, but I find the git way\nmuch more pleasant, since I don't have to do any arithmetic:\n diff d8a60^..d8a60\n(Yes, I am capable of performing subtraction in my head, but I find that\na \"parent-of\" operator matches my cognitive model better, especially\nwhen you get into things like d8a60^2~3).\n\nDoes bzr have a similar shorthand for mentioning relative commits?\n\n-Peff\n"},{"id":"29360","messageId":"20061020143111.GB17497@coredump.intra.peff.net","threadId":"5925","inReplyTo":"20061019171409.GA31671@fieldses.org","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-20T14:31:11Z","receivedAt":"2006-10-20T14:31:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 19, 2006 at 01:14:09PM -0400, J. Bruce Fields wrote:\n\n> > > In the second place, one must consider the \"nuclear launch codes\"\n> > > scenario.\n> > Sure. And git does provide tools that can do this.\n> \n> So in this case you can certainly lose the launch codes. But you have\n> forever granted everyone a way to determine whether a given guess at the\n> launch codes is correct. (Again, assuming some stuff about SHA1).\n\nIn what sense? Yes, you can make a guess if you have stored the SHA1\nthat contained the launch codes. But the point is that that particular\nSHA1 is no longer part of the repository. Keeping that SHA1 is no easier\nthan just keeping the launch codes in the first place.\n\n-Peff\n"},{"id":"29361","messageId":"200610201640.36640.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061020141222.GA17497@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T14:40:36Z","receivedAt":"2006-10-20T14:40:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King wrote:\n> On Thu, Oct 19, 2006 at 09:06:40PM -0400, Aaron Bentley wrote:\n> \n>> What's nice is being able see the revno 753 and knowing that \"diff -r\n>> 752..753\" will show the changes it introduced. Checking the revo on a\n>> branch mirror and knowing how out-of-date it is.\n> \n> I was accustomed to doing such things in CVS, but I find the git way\n> much more pleasant, since I don't have to do any arithmetic:\n> diff d8a60^..d8a60\n\nBy the way \"diff d8a60\" also works (unless d8a60 is merge commit, in\nwhich case you would need \"diff -c d8a60\" or \"diff -m d8a60\").\n\n> (Yes, I am capable of performing subtraction in my head, but I find that\n> a \"parent-of\" operator matches my cognitive model better, especially\n> when you get into things like d8a60^2~3).\n> \n> Does bzr have a similar shorthand for mentioning relative commits?\n\nBy the way, git has the following extended SHA1 syntax for \n(documented in git-rev-parse(1)):\n * full SHA1 (40-chars hexadecimal string) or abbreviation unique for\n repository\n * symbolic ref name. E.g. 'master' typically means commit object referenced\n by $GIT_DIR/refs/heads/master; 'v1.4.1' means commit object referenced\n [indirectly] by $GIT_DIR/refs/tags/v1.4.1. You can say 'heads/master'\n and 'tags/master' if you have both head (branch) and tag named 'master',\n but don't do that. HEAD means current branch (and is usually default).\n * @{} or @{} to specify value of (usually branch)\n at given point of time, or n changes to ref back. Available only if you\n have reflog for given ref.\n * ^ means n-th parent of given revision. ^0\n means commit itself. ^ is a shortcut for ^1.\n ~ is shortcut for ^^..^ with n*'^', for\n example rev~3 is equivalent to rev^^^, which in turn is equivalent\n to rev^1^1^1\n\nAdditionally it has following undocumented extended SHA1 syntax to refer\nto trees (directories) and blobs (file contents)\n * : gives SHA1 of tree or blob at given revision\n * :: (I think for blobs only) gives SHA1 for different\n versions of file during unresolved merge conflict.\n\nI'm not enumerating here all the ways to specify part of DAG of history,\nexcept that it includes \"A ^B\" meaning \"all from A\", \"exclude all from B\",\n\"B..A\" meaning \"^B A\", \"A...B\" meaning \"A B --not $(git merge-base A B)\",\nand of course \"A -- path\" meaning \"all from A\", \"limit to changes in path\".\n\nWhat about _your_ SMC? ;-)\n-- \nJakub Narebski\nPoland\n"},{"id":"29362","messageId":"20061020144108.GC17497@coredump.intra.peff.net","threadId":"5925","inReplyTo":"20061020002032.GA7162@delft.aura.cs.cmu.edu","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-20T14:41:08Z","receivedAt":"2006-10-20T14:41:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 19, 2006 at 08:20:32PM -0400, Jan Harkes wrote:\n\n> It looks like you were really close. When we cannot resolve a delta, we\n> just write it to the packfile and we don't queue it. If it can be\n> resolved we write it as a full object.\n\nIf I understand correctly, if we see an unresolvable delta, we are just\nmaking the assumption that its base has arrived (or will arrive) in the\nsame pack (without checking). This means that we could end up with a\ncorrupted repository if the sender gives us a bad pack. I believe that\ngit's network interaction has been designed specifically to avoid such\npossibilities (e.g., verifying completeness and integrity of downloaded\nobjects).\n\n-Peff\n"},{"id":"29365","messageId":"Pine.LNX.4.63.0610201647420.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"200610201640.36640.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-20T14:52:09Z","receivedAt":"2006-10-20T14:52:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Oct 2006, Jakub Narebski wrote:\n\n> Jeff King wrote:\n> > \n> > I was accustomed to doing such things in CVS, but I find the git way\n> > much more pleasant, since I don't have to do any arithmetic:\n> > diff d8a60^..d8a60\n> \n> By the way \"diff d8a60\" also works (unless d8a60 is merge commit, in\n> which case you would need \"diff -c d8a60\" or \"diff -m d8a60\").\n\nI could be wrong, but I have the impression (even after actually testing \nit) that \"git diff d8a60\" is equivalent to \"git diff d8a60..HEAD\", _not_ \n\"git diff d8a60^..d8a60\".\n\nIIRC we had a \"-p\" flag to denote \"parent\" once upon a time, but that no \nlonger works...\n\n\"git-show\" is definitely what you want.\n\nCiao,\nDscho\n"},{"id":"29367","messageId":"ehao3e$2qv$1@sea.gmane.org","threadId":"5925","inReplyTo":"4538D724.5040508@utoronto.ca","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T14:56:47Z","receivedAt":"2006-10-20T14:56:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n\n> Sean wrote:\n> \n>> Petr already mentioned that the data currently shown in the email\n>> text isn't really useful.\n> \n> In Bazaar bundles, the text of the diff is an integral part of the data.\n> It is used to generate the text of all the files in the revision.\n\nI thought that the diff was combined diff of changes.\n \n> Bazaar bundles were designed to be used on mailing lists. So you can\n> review the changes from the diff, comment on them, and if it seems\n> suitable, merge them.\n\nIf you have only mega-diff, you can comment only on this mega-diff.\nIt is more usefull for changes which have natural mult-commit history,\nto review and comment on each of commits/patches in series _separately_.\n\n>> Although that might just make the email bigger for not a lot of\n>> gain.\n> \n> It's my understanding that most changes discussed on lkml are provided\n> as a series of patches. Bazaar bundles are intended as a direct\n> replacement for patches in that use case.\n\nAs _series_ of patches. You have git-format-patch + git-send-email\nto format and send them, git-am to apply them (as patches, not as branch).\n\nI was under an impression that user sees only mega-patch of all the\nrevisions in bundle together, and rest is for machine consumption only.\n\ncg-bundle doesn't have this \"mega-diff\", but has shortlog (does bzr\nbundle has shortlog/log of changes contained therein?) and diffstat\nwas planned.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29368","messageId":"a7e835d40610200759h49859a20k8a409fe34f68630a@mail.gmail.com","threadId":"5925","inReplyTo":"200610201517.26702.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"James Henstridge","fromEmail":"james@jamesh.id.au","sentAt":"2006-10-20T14:59:00Z","receivedAt":"2006-10-20T14:59:00Z","isPatch":false,"sender":{"key":"james@jamesh.id.au","avatar":"https://gravatar.com/avatar/3007d1d261c8d1edc4e388f53ea5e53ab40fd5f8334748472ba0e2037b76e4aa?d=mp&s=160"},"body":"On 20/10/06, Jakub Narebski wrote:\n> James Henstridge wrote:\n> > With the above layout, I would just type:\n> > bzr branch http://server/repo/branch1\n>\n> With Cogito (you can think of it either as alternate Git UI, or as SCM\n> built on top of Git) you would use\n>\n> $ cg clone http://server/repo#branch\n>\n> for example\n>\n> $ cg clone git://git.kernel.org/pub/scm/git/git.git#next\n>\n> to clone _single_ branch (in bzr terminology, \"heavy checkout\" of branch).\n\nMy understanding of git is that this would be equivalent to the \"bzr\nbranch\" command. A checkout (heavy or lightweight) has the property\nthat commits are made to the original branch.\n\n> But you can also clone _whole_ repository, _all_ published branches with\n>\n> $ cg clone git://git.kernel.org/pub/scm/git/git.git\n\nI suppose that'd be useful if you want a copy of all the branches at\nonce. There is no builtin command in Bazaar to do that at present.\n\n\n> With core Git it is the same, but we don't have the above shortcut\n> for checking only one branch; branches to checkout are in separate\n> arguments to git-clone.\n>\n> In bzr it seems that you cannot distinguish (at least not only\n> from URL) where repository ends and branch begins.\n\nI guess this highlights that the two tools optimise for different workflows.\n> > This command behaves identically whether the repository data is in\n> > /repo or in /repo/branch1. Someone pulling from the branch doesn't\n> > have to care what the repository structure is. Having a separate\n> > namespace for branch names only really makes sense if the user needs\n> > to care about it.\n> >\n> > As for hierarchical names, there is nothing stopping you from using\n> > deaper directory structures with Bazaar too. Bazaar just checks each\n> > successive parent directory til it finds a repository for the branch.\n> >\n> >> The idea of \"branches (and tags) as directories\" was if I understand\n> >> it correctly introduced by Subversion, and from what can be seen from\n> >> troubles with git-svn (stemming from the fact that division between\n> >> project name and branch name is the matter of _convention_) at least\n> >> slightly brain-damaged.\n> >\n> > I think you are a bit confused about how Bazaar works here. A Bazaar\n> > repository is a store of trees and revision metadata. A Bazaar branch\n> > is just a pointer to a head revision in the repository. As you can\n> > probably guess, the data for the branch is a lot smaller than the data\n> > for the repository.\n> >\n> > You can store the repository and branch in the same directory to get a\n> > standalone branch. The layout I described above has a repository in a\n> > parent directory, shared by multiple branches.\n> >\n> > If you are comparing Subversion and Bazaar, a Bazaar branch shares\n> > more properties with a full Subversion repository rather than a\n> > Subversion branch.\n>\n> Oh, that explained yet another difference between Bazaar-NG (and other\n> SCM which uses similar model) and Git.\n>\n> In Git branch is just a pointer to head (top) commit (hence they are stored\n> under .git/refs/heads/) in given line of development. Git also stores\n> information (in .git/HEAD) about which branch we are currently on, which\n> means on which branch git puts new commits. Nothing more (well, there\n> can be log of changes to head in .git/logs/refs/heads/ but that is optional\n> and purely local information). In Bazaar-NG you have to store (if I\n> understand it correctly) mapping from revnos to revisions.\n>\n> By default (it means for example default behavior of git-clone, if we don't\n> use --bare option) git repository is _embedded_ in working area. We have\n\nTwo points:\n(1) if we are publishing branches, we wouldn't include working trees\n-- they are not needed to pull or merge from such a branch.\n(2) if we did have working trees, they'd be rooted at /repo/branch1\nand /repo/branch2 -- not at /repo (since /repo is not a branch).\n\nIn case (2) there is a potential for conflicts if you nest branches,\nbut people don't generally trigger this problem with the way they use\nBazaar.\n\n> So repo/branch wouldn't work, because 'branch' would conflict with working\n> area files. GIT doesn't follow the CVS model of separate storage area\n> (CVSROOT) and having only pointer to said area (files in CVS/\n> subdirectories) in working directory.\n\nThat is fairly similar to the default mode of operation with Bazaar:\nyou have a repository, branch and working tree all rooted in the same\ndirectory. If you have separated working trees and branches, then\nthat is because you specifically asked for it.\n\n\n> In GIT to work on some repository you don't (like from what I understand\n> in Bazaar-NG) \"checkout\" some branch (which would automatically copy some\n> data in case of \"heavy checkout\" or just save some pointer to repository\n> in \"lightweight checkout\" case). You clone whole repository; well you can\n> select which branches to clone. \"Checkout\" in GIT terminology means to\n> populate working area with given version (and change in repository which\n> branch is current, usually).\n\nI think you have a slight misunderstanding of what a Bazaar checkout is.\n\n>\n> How checked out working area looks like in Bazaar-NG?\n\nThe layout of a standalone branch would be:\n .bzr/repository/ -- storage of trees and metadata\n .bzr/branch/ -- branch metadagta (e.g. pointer to the head revision)\n .bzr/checkout/ -- working tree book-keeping files\n source code\n\nIf we use a shared repository, the contained branches would lack the\n.bzr/repository/ directory. The parent directory would instead have a\n.bzr/repository/, but usually wouldn't have .bzr/branch/ (unless there\nis a branch rooted at the base of the repository).\n\nif we are publishing a branch to a web server, we'd skip the working\ntree, so the source code and .bzr/checkout/ directory would be\nmissing.\n\nIn the case of a checkout, the .bzr/branch/ directory has a special\nformat and acts as a pointer to the original branch. If the checkout\nis lightweight, the .bzr/repository/ directory would be missing, and\nbzr would need to contact the original branch for the data.\n\n\n> >>> For similar reasons, the cost of publishing 20 related Bazaar branches\n> >>> on my web server is generally not 20 times the cost of publishing a\n> >>> single branch.\n> >>>\n> >>> I understand that you get similar benefits by a GIT repository with\n> >>> multiple head revisions.\n> >>\n> >> You can get similar benefits by a GIT repository with shared object\n> >> database using alternates mechanism. And that is usually preferred\n> >> over storing unrelated branches, i.e. branches pointing to disconnected\n> >> DAG (separate trees in BK terminology) of revision, if that you mean by\n> >> multiple head revisions (because in GIT there is no notion of \"mainline\"\n> >> branch, only of current (HEAD) branch).\n> >\n> > I may have got the git terminology wrong. I was trying to draw\n> > parallels between the .git/refs/... files in a git repository and the\n> > way multiple branches can be stored in a Bazaar repository.\n>\n> Yes, but using Git that way has serious disadvantages. For example\n> there is only one current branch pointer and only one index (dircache)\n> per git repository.\n\nOkay. So using Bazaar terminology, this seems to be an issue of the\nworking tree being associated with the repository rather than the\nbranch?\n\n\n[...]\n> But I agree that saving \"old fork\" info as separate branch doesn't lead\n> to that much inefficiency as might be thought.\n>\n> But after saving \"old fork\" as a branch revno based revision identifiers\n> change from http://old.host/old/repo:127 to http://host/repo/old.fork:127\n> That is maybe minimal change, but this is change!\n\nWell, a branch can easily have multiple URLs even if there is only one\ncopy of it. I might write to it via local file access or sftp (which\nwould be a file: or sftp: URL).\n\nMirrors of branches don't usually confuse users (and remember that the\nrevision numbers are primarily intended for users -- if I am writing a\nBazaar plugin, I'd work in terms of revision IDs).\n\n\nJames.\n"},{"id":"29372","messageId":"20061020153323.GA12886@fieldses.org","threadId":"5925","inReplyTo":"20061020143111.GB17497@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-10-20T15:33:23Z","receivedAt":"2006-10-20T15:33:23Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Fri, Oct 20, 2006 at 10:31:11AM -0400, Jeff King wrote:\n> On Thu, Oct 19, 2006 at 01:14:09PM -0400, J. Bruce Fields wrote:\n> > So in this case you can certainly lose the launch codes. But you have\n> > forever granted everyone a way to determine whether a given guess at the\n> > launch codes is correct. (Again, assuming some stuff about SHA1).\n> \n> In what sense? Yes, you can make a guess if you have stored the SHA1\n> that contained the launch codes. But the point is that that particular\n> SHA1 is no longer part of the repository.\n\nWell, I thought the discussion was about what meaning references have\nafter branches were modified or removed. In which case the interesting\nsituation is one where an object is gone but someone somewhere still\nholds a reference (because the SHA1 was mentioned in a bug report or an\nemail or whatever).\n\n> Keeping that SHA1 is no easier than just keeping the launch codes in\n> the first place.\n\nCould be.\n\nAnyway, the important difference between the SHA1 references and small\nintegers is that there's no aliasing in the former case. Which is\nimportant--I'd rather have a reference to nothing than a reference to\nthe wrong thing....\n\n--b.\n"},{"id":"29374","messageId":"4538EC8F.7020502@utoronto.ca","threadId":"5925","inReplyTo":"ehao3e$2qv$1@sea.gmane.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-20T15:34:39Z","receivedAt":"2006-10-20T15:34:39Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJakub Narebski wrote:\n> Aaron Bentley wrote:\n>>In Bazaar bundles, the text of the diff is an integral part of the data.\n>> It is used to generate the text of all the files in the revision.\n> \n> \n> I thought that the diff was combined diff of changes.\n\nIt is. It's a description of how to produce revision X given revision\nY, where Y is the last-merged mainline revision.\n\n>>Bazaar bundles were designed to be used on mailing lists. So you can\n>>review the changes from the diff, comment on them, and if it seems\n>>suitable, merge them.\n> \n> \n> If you have only mega-diff, you can comment only on this mega-diff.\n\nThat is what we prefer to review.\n\n>>>Although that might just make the email bigger for not a lot of\n>>>gain.\n>>\n>>It's my understanding that most changes discussed on lkml are provided\n>>as a series of patches. Bazaar bundles are intended as a direct\n>>replacement for patches in that use case.\n> \n> \n> As _series_ of patches. You have git-format-patch + git-send-email\n> to format and send them, git-am to apply them (as patches, not as branch).\n\nIf you want to do it exactly the same way, you send a series of bundles.\n\nThe bundle format can also support sending a single bundles that\ndisplays the series of patches, though there's currently no UI to select\nthis.\n\n> I was under an impression that user sees only mega-patch of all the\n> revisions in bundle together, and rest is for machine consumption only.\n\nAll of it is for machine consumption. The MIME-encoded sections are a\nseries of patches. They're usually MIME-encoded to avoid confusion with\nthe overview patch, but this is optional.\n\nI've attached an example of what a combined patch-by-patch bundle looks\nlike.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFOOyB0F+nu1YWqI0RAtU6AKCJndTNlTTPNnzxZX53lkBUUHTYkwCfePlG\n7x3cjpYwh8LXEb5ZWXXmu6s=\n=6Lgv\n-----END PGP SIGNATURE-----\n\n\n# Bazaar revision bundle v0.8\n#\n# message:\n# Added 'world'\n# committer: Aaron Bentley \n# date: Fri 2006-10-20 11:30:21.903000116 -0400\n\n=== modified file world\n--- world\n+++ world\n@@ -1,1 +1,1 @@\n-Hello\n+Hello, world\n\n=== modified directory // last-changed:abentley@panoramicfeedback.com-20061020\n... 153021-b5fcea14e9cd2b34\n# revision id: abentley@panoramicfeedback.com-20061020153021-b5fcea14e9cd2b34\n# sha1: 6d553e72158aaa76c258d98c15cd24922d171cd9\n# inventory sha1: 64af82c4d81d9d6ad4f33fc734d32c2a1eaa0df5\n# parent ids:\n# abentley@panoramicfeedback.com-20061020152951-10cff5ff5a51e9a2\n# properties:\n# branch-nick: bar\n\n# message:\n# Capitalized\n# committer: Aaron Bentley \n# date: Fri 2006-10-20 11:29:51.953999996 -0400\n\n=== modified file world\n--- world\n+++ world\n@@ -1,1 +1,1 @@\n-hello\n+Hello\n\n=== modified directory // last-changed:abentley@panoramicfeedback.com-20061020\n... 152951-10cff5ff5a51e9a2\n# revision id: abentley@panoramicfeedback.com-20061020152951-10cff5ff5a51e9a2\n# sha1: f7b79934bc3b0a944e35168b5df6b106c5b29ebf\n# inventory sha1: 1400d56451752300cc31c9c94ff7ee2188e8ef8c\n# parent ids:\n# abentley@panoramicfeedback.com-20061020152935-64bde004f622131f\n# properties:\n# branch-nick: bar\n\n# message:\n# initial commit\n# committer: Aaron Bentley \n# date: Fri 2006-10-20 11:29:35.536999941 -0400\n\n=== added directory // file-id:TREE_ROOT\n=== added file world // file-id:world-20061020152929-12bknd8mm9mx48as-1\n--- /dev/null\n+++ world\n@@ -0,0 +1,1 @@\n+hello\n\n# revision id: abentley@panoramicfeedback.com-20061020152935-64bde004f622131f\n# sha1: 0728f761b891b257f0a71e2e360799eec080cd21\n# inventory sha1: e52e030ea40f6bf5da78f4e8eb8efcd072b0930a\n# properties:\n# branch-nick: bar\n\n"},{"id":"29373","messageId":"200610201734.59005.jnareb@gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610201647420.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T15:34:58Z","receivedAt":"2006-10-20T15:34:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> On Fri, 20 Oct 2006, Jakub Narebski wrote:\n> \n>> Jeff King wrote:\n>>> \n>>> I was accustomed to doing such things in CVS, but I find the git way\n>>> much more pleasant, since I don't have to do any arithmetic:\n>>> diff d8a60^..d8a60\n>> \n>> By the way \"diff d8a60\" also works (unless d8a60 is merge commit, in\n>> which case you would need \"diff -c d8a60\" or \"diff -m d8a60\").\n> \n> I could be wrong, but I have the impression (even after actually testing \n> it) that \"git diff d8a60\" is equivalent to \"git diff d8a60..HEAD\", _not_ \n> \"git diff d8a60^..d8a60\".\n\nOoops, I mixed git-diff-tree (which behaves as mentioned above) with\ngit-diff, which according to documentation compares with working tree\n(and not HEAD) if only one is given.\n\ngit-diff(1):\n ? When one is given, the working tree and the named tree are\n compared, using git-diff-index. The option --cached can be given to com-\n pare the index file and the named tree.\n\ngit-diff-tree(1):\n If there is only one given, the commit is compared with its par-\n ents (see --stdin below).\n-- \nJakub Narebski\nPoland\n"},{"id":"29375","messageId":"BAYC1-PASMTP03623861D4BBE8BD868117AE0D0@CEZ.ICE","threadId":"5925","inReplyTo":"4538D724.5040508@utoronto.ca","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-20T15:37:12Z","receivedAt":"2006-10-20T15:37:12Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Fri, 20 Oct 2006 10:03:16 -0400\nAaron Bentley wrote:\n\n> In Bazaar bundles, the text of the diff is an integral part of the data.\n> It is used to generate the text of all the files in the revision.\n> \n> Bazaar bundles were designed to be used on mailing lists. So you can\n> review the changes from the diff, comment on them, and if it seems\n> suitable, merge them.\n\nPerhaps I missed something in the earlier mails about this feature.\nAs I understood it, the email sent has a combined diff that shows\nthe net effect of all the commits included in the bundle. (Whereas\nthe current Cogito version only shows a diffstat)\n\nIf the recipient of such a bundle is unable to extract the diff of\neach separate commit included in the bundle then I can't see any\nvalue in the feature at all. But showing a combined diff in the\nemail may have marginal value, so long as when the bundle is \nimported into the recipient repository the individual commits\nare available.\n\n> It's my understanding that most changes discussed on lkml are provided\n> as a series of patches. Bazaar bundles are intended as a direct\n> replacement for patches in that use case.\n\nA combined diff of a bunch of changes would usually be most _unwelcome_\nfor review on lkml. The constant refrain is to ask people to split their\nchanges up into smallish individual patches for review.\n\nSean\n"},{"id":"29376","messageId":"20061020113712.d192580a.seanlkml__22452.8721104891$1161358693$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"4538D724.5040508@utoronto.ca","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-20T15:37:12Z","receivedAt":"2006-10-20T15:37:12Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Fri, 20 Oct 2006 10:03:16 -0400\nAaron Bentley wrote:\n\n> In Bazaar bundles, the text of the diff is an integral part of the data.\n> It is used to generate the text of all the files in the revision.\n> \n> Bazaar bundles were designed to be used on mailing lists. So you can\n> review the changes from the diff, comment on them, and if it seems\n> suitable, merge them.\n\nPerhaps I missed something in the earlier mails about this feature.\nAs I understood it, the email sent has a combined diff that shows\nthe net effect of all the commits included in the bundle. (Whereas\nthe current Cogito version only shows a diffstat)\n\nIf the recipient of such a bundle is unable to extract the diff of\neach separate commit included in the bundle then I can't see any\nvalue in the feature at all. But showing a combined diff in the\nemail may have marginal value, so long as when the bundle is \nimported into the recipient repository the individual commits\nare available.\n\n> It's my understanding that most changes discussed on lkml are provided\n> as a series of patches. Bazaar bundles are intended as a direct\n> replacement for patches in that use case.\n\nA combined diff of a bunch of changes would usually be most _unwelcome_\nfor review on lkml. The constant refrain is to ask people to split their\nchanges up into smallish individual patches for review.\n\nSean\n"},{"id":"29378","messageId":"20061020154305.GA29966@coredump.intra.peff.net","threadId":"5925","inReplyTo":"20061020153323.GA12886@fieldses.org","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-20T15:43:05Z","receivedAt":"2006-10-20T15:43:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 20, 2006 at 11:33:23AM -0400, J. Bruce Fields wrote:\n\n> Well, I thought the discussion was about what meaning references have\n> after branches were modified or removed. In which case the interesting\n> situation is one where an object is gone but someone somewhere still\n> holds a reference (because the SHA1 was mentioned in a bug report or an\n> email or whatever).\n\nGit tries very hard to make sure you don't have a reference to something\nthat doesn't exist. But yes, you could have a reference to the SHA1 in\nanother, non-git source, and try to guess the data from it. However,\nthere's a bit of a two-step procedure, since the SHA1 will likely be of\nthe commit. You have to guess the commit author, date, message, and\nthe contents of the rest of the tree to make a correct guess.\n\nIn practice I think most \"launch code\" scenarios are less about\nguessable confidentiality, and more about ceasing to publish things you\nshouldn't be (like copyright or patent encumbered code).\n\n-Peff\n"},{"id":"29380","messageId":"Pine.LNX.4.64.0610200857250.3962@g5.osdl.org","threadId":"5925","inReplyTo":"eha9no$5t7$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-20T15:58:43Z","receivedAt":"2006-10-20T15:58:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Jakub Narebski wrote:\n> Junio C Hamano wrote:\n> > \n> > An interesting effect on this is when people have a column for\n> > merge performance in a SCM comparison table, they would include\n> > time to run the diffstat as part of the time spent for merging\n> > when they fill in the number for git, but not for any other SCM.\n> \n> So if you want to compare merge performance with other SCM, you should\n> either add time to run diffstat for other SCM, or substract time to\n> run \"git diff-tree --stat\".\n\nNaah. Just run \"git pull -n\". It's even documented:\n\n\tOPTIONS\n\t -n, --no-summary\n\t Do not show diffstat at the end of the merge.\n\nso while the _default_ is to always show the diffstat, you certainly can \neasily do without it.\n\n\t\tLinus\n"},{"id":"29384","messageId":"200610201821.34712.jnareb@gmail.com","threadId":"5925","inReplyTo":"4538EC8F.7020502@utoronto.ca","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T16:21:34Z","receivedAt":"2006-10-20T16:21:34Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n\n> === added directory  // file-id:TREE_ROOT\n\nGaaah, so rename detection in bzr is done using file-ids?\nLinus will tell you the inherent problems with that \"solution\".\n-- \nJakub Narebski\nPoland\n"},{"id":"29388","messageId":"45390168.6020502@utoronto.ca","threadId":"5925","inReplyTo":"200610201821.34712.jnareb@gmail.com","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-20T17:03:36Z","receivedAt":"2006-10-20T17:03:36Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJakub Narebski wrote:\n> Aaron Bentley wrote:\n> \n> \n>>=== added directory // file-id:TREE_ROOT\n> \n> \n> Gaaah, so rename detection in bzr is done using file-ids?\n> Linus will tell you the inherent problems with that \"solution\".\n\nAll solutions have disadvantages. We prefer the disadvantages that come\nfrom using file-ids over the disadvantages that come from using\ncontent-based rename detection.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFOQFo0F+nu1YWqI0RAlCnAJwIqwuPG/IPBBQWaGyEImTm4GMP6QCfTV89\nQZaMQsTqXBH8wrt7VKAHpII=\n=Qx2i\n-----END PGP SIGNATURE-----\n"},{"id":"29389","messageId":"Pine.LNX.4.64.0610201016490.3962@g5.osdl.org","threadId":"5925","inReplyTo":"45390168.6020502@utoronto.ca","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-20T17:18:44Z","receivedAt":"2006-10-20T17:18:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Aaron Bentley wrote:\n> \n> All solutions have disadvantages. We prefer the disadvantages that come\n> from using file-ids over the disadvantages that come from using\n> content-based rename detection.\n\nThat's fine, but please don't call the git rename handling \"maybe\" or \n\"partial\", like a lot of people seem to do. \n\nGit _definitely_ handles renames, both in everyday life and when merging. \nSome people may not like how it's done, but other (I'll say \"equally \ninformed\", even though obviously I know better ;) people really don't like \nthe way bzr or others do their rename handling.\n\n\t\t\tLinus\n"},{"id":"29390","messageId":"20061020172125.GF18019@spearce.org","threadId":"5925","inReplyTo":"45390168.6020502@utoronto.ca","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-20T17:21:25Z","receivedAt":"2006-10-20T17:21:25Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Aaron Bentley wrote:\n> Jakub Narebski wrote:\n> > Gaaah, so rename detection in bzr is done using file-ids?\n> > Linus will tell you the inherent problems with that \"solution\".\n> \n> All solutions have disadvantages. We prefer the disadvantages that come\n> from using file-ids over the disadvantages that come from using\n> content-based rename detection.\n\nAs good as the content based rename detection is I got burned\nrecently by it.\n\nI renamed hundreds of small files in one shot and also did a few\nhundered adds and deletes of other small XML files. Git generated\na lot of those unrelated adds/deletes as rename/modifies, as their\ncontent was very similiar. Some people involved in the project\nfreaked as the files actually had nothing in common with one\nanother... except for a lot of XML elements (as they shared the\nsame DTD).\n"},{"id":"29391","messageId":"Pine.LNX.4.63.0610201012550.5248@qynat.qvtvafvgr.pbz","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610201335420.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: VCS comparison table","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-10-20T17:23:51Z","receivedAt":"2006-10-20T17:23:51Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Fri, 20 Oct 2006, Johannes Schindelin wrote:\n\n> On Fri, 20 Oct 2006, Jakub Narebski wrote:\n>\n>> Johannes Schindelin wrote:\n>>\n>>> On Fri, 20 Oct 2006, Lachlan Patrick wrote:\n>>>\n>>>> How does git disambiguate SHA1 hash collisions?\n>>>\n>>> It does not. You can fully expect the universe to go down before that\n>>> happens.\n>>\n>> Or you can compile git with COLLISION_CHECK\n>>\n>>> From Makefile:\n>> # Define COLLISION_CHECK below if you believe that SHA1's\n>> # 1461501637330902918203684832716283019655932542976 hashes do not give you\n>> # sufficient guarantee that no collisions between objects will ever happen.\n>\n> You can document your disbelief.\n>\n> But it does not change a thing. Since v0.99~653, we do not have any\n> collision check, even if compiled with COLLISION_CHECK.\n\nI had the same disbelief as you about this, however the last time this came up \nLinus pointed out something that satisfied me.\n\nany action in git that could create or or recreate an object will not overwrite \nan object that it thinks that it already has.\n\nso\n\nif you create a new local file that would conflict and save it, git will accept \nyour save and throw away the new file.\n\nif you pull from a remote repository and there is a file there that conflicts \nwith a file you already have it will throw away the new file.\n\nif you pull from a remote repository and someone has hacked it to replace a file \nwith a bad one, if you already have the good one git will throw away the bad \none.\n\nas a result the worst case is that a new file being checked in doesn't really \nget in and when someone checks it out and trys to use it they get the old \ncontents. In the case of code, it's extremely unlikly that the wrong code will \neven compile, let alone do anything remotely close to working correctly. At this \npoint the fix is to go back to the origional developer to get the correct \nversion while additional changes are made to git (and remember, that unless this \nis a brand new file the prior version is readily available so only the latest \ndiff needs to be recovered)\n\nso the odds are extremely low and the concequeces of a collision are fairly \nminor.\n\ngit has (or had) an option to actually check the full contents before throwing \naway the new copy instead of just checking the hash (and throwing an error if \nthe contents don't match), but the performance cost of this is pretty high.\n\nDavid Lang\n"},{"id":"29392","messageId":"200610201945.43957.jnareb@gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201016490.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T17:45:43Z","receivedAt":"2006-10-20T17:45:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n> \n> On Fri, 20 Oct 2006, Aaron Bentley wrote:\n>> \n>> All solutions have disadvantages. We prefer the disadvantages that come\n>> from using file-ids over the disadvantages that come from using\n>> content-based rename detection.\n\nIf I remember correctly, git decided on contents (plus filename)\nsimilarity based renames detection because 1), it is more generic\nas it covers (or can cover) contents moving not only wholesome rename\nof a file, and 2) because file-id based renames handling works only\nif you explicitely use SCM command to rename file, which is not the\ncase of non-SCM-aware channel like for example patches (and accepting\nordinary patches is important for Linux kernel, the project git was\ncreated for).\n\nAnother problem with file-id based rename handling is not handling\nfile copying (correct me if I'm wrong), and troubles with removing\nor renaming a file, then having new file with old name.\n \n> That's fine, but please don't call the git rename handling \"maybe\" or \n> \"partial\", like a lot of people seem to do. \n> \n> Git _definitely_ handles renames, both in everyday life and when merging. \n> Some people may not like how it's done, but other (I'll say \"equally \n> informed\", even though obviously I know better ;) people really don't like \n> the way bzr or others do their rename handling.\n\nI think that \"partial\" refers to not complete handling of renames\nfor file history; pathspec doesn't follow history. Although the\ninformation is there in SCM, it's the tools that need extension\n(the --follow of rename following single file pathspec limit\nproposal).\n\nThere was also suggestion of rr2-cache, which would record corrections\nto automatic rename detection (rename/copy conflict resolving) \nif I remember correctly.\n-- \nJakub Narebski\nPoland\n"},{"id":"29393","messageId":"45390BAF.5040405@utoronto.ca","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201016490.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-20T17:47:27Z","receivedAt":"2006-10-20T17:47:27Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nLinus Torvalds wrote:\n> \n> On Fri, 20 Oct 2006, Aaron Bentley wrote:\n> \n>>All solutions have disadvantages. We prefer the disadvantages that come\n>>from using file-ids over the disadvantages that come from using\n>>content-based rename detection.\n> \n> \n> That's fine, but please don't call the git rename handling \"maybe\" or \n> \"partial\", like a lot of people seem to do. \n> \n> Git _definitely_ handles renames, both in everyday life and when merging.\n\nHmm. Could you say more here? The only examples I can think of for\nhandling renames are situations that can be expressed as a merge.\n\nFor example, populating a working tree can be expressed as:\nBASE: nothing\nTHIS: nothing\nOTHER: aabbccddee\n\nOr revert can be expressed as\n\nBASE: current\nTHIS: current\nOTHER: aabbccddee\n\nOr fast-forward pull\n\nBASE: last-commit\nTHIS: current\nOTHER: aabbccddee\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFOQuv0F+nu1YWqI0RAotBAKCEEzvh1Cc2jJH4NIEBwoYrDJlbUQCgiPBF\nDZ4+hSbkjbvgOwbT4+oLzFA=\n=wSgK\n-----END PGP SIGNATURE-----\n"},{"id":"29394","messageId":"Pine.LNX.4.64.0610201045550.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061020172125.GF18019@spearce.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-20T17:48:58Z","receivedAt":"2006-10-20T17:48:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Shawn Pearce wrote:\n> \n> I renamed hundreds of small files in one shot and also did a few\n> hundered adds and deletes of other small XML files. Git generated\n> a lot of those unrelated adds/deletes as rename/modifies, as their\n> content was very similiar. Some people involved in the project\n> freaked as the files actually had nothing in common with one\n> another... except for a lot of XML elements (as they shared the\n> same DTD).\n\nHeh. We can probably tweak the heuristics (one of the _great_ things about \ncontent detection is that you can fix it after the fact, unlike the \nalternative).\n\nThat said, I've personally actually found the content-based similarity \nanalysis to often be quite informative, even when (and perhaps \n_especially_ when) it ended up showing something that the actual author of \nthe thing didn't intend.\n\nSo yeah, I've seen a few strange cases myself, but they've actually been \ninteresting. Like seeing how much of a file was just a copyright license, \nand then a file being considered a \"copy\" just because it didn't actually \nintroduce any real new code.\n\n\t\t\tLinus\n"},{"id":"29395","messageId":"Pine.LNX.4.63.0610201057070.5248@qynat.qvtvafvgr.pbz","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201045550.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-10-20T17:58:09Z","receivedAt":"2006-10-20T17:58:09Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Fri, 20 Oct 2006, Linus Torvalds wrote:\n\n> On Fri, 20 Oct 2006, Shawn Pearce wrote:\n>>\n>> I renamed hundreds of small files in one shot and also did a few\n>> hundered adds and deletes of other small XML files. Git generated\n>> a lot of those unrelated adds/deletes as rename/modifies, as their\n>> content was very similiar. Some people involved in the project\n>> freaked as the files actually had nothing in common with one\n>> another... except for a lot of XML elements (as they shared the\n>> same DTD).\n>\n> Heh. We can probably tweak the heuristics (one of the _great_ things about\n> content detection is that you can fix it after the fact, unlike the\n> alternative).\n>\n> That said, I've personally actually found the content-based similarity\n> analysis to often be quite informative, even when (and perhaps\n> _especially_ when) it ended up showing something that the actual author of\n> the thing didn't intend.\n>\n> So yeah, I've seen a few strange cases myself, but they've actually been\n> interesting. Like seeing how much of a file was just a copyright license,\n> and then a file being considered a \"copy\" just because it didn't actually\n> introduce any real new code.\n>\n\nisn't the default to consider them a copy if they are 80% the same, with a \ncommand line option to tweak this (IIRC -m, but I could easily be wrong)\n\nDavid Lang\n"},{"id":"29396","messageId":"Pine.LNX.4.64.0610201049250.3962@g5.osdl.org","threadId":"5925","inReplyTo":"200610201945.43957.jnareb@gmail.com","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-20T17:59:09Z","receivedAt":"2006-10-20T17:59:09Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Jakub Narebski wrote:\n> \n> If I remember correctly, git decided on contents (plus filename)\n> similarity based renames detection because 1), it is more generic\n> as it covers (or can cover) contents moving not only wholesome rename\n> of a file, and 2) because file-id based renames handling works only\n> if you explicitely use SCM command to rename file, which is not the\n> case of non-SCM-aware channel like for example patches (and accepting\n> ordinary patches is important for Linux kernel, the project git was\n> created for).\n\nThere are lots of problems with file ID's. One of the more obvious ones is \nindeed that if you arrive at the same state two different ways (eg patches \nvs \"native SCM\"), you end up with two fundmanetally different trees. Even \nthough clearly there was no real difference.\n\nThere are other serious problems. For example, file-ID based systems \ninvariably have _huge_ problems with handling two branches deleting and \nrenaming things differently, and we had several issues with that during \nthe BK days (ie two people would move files differently, and ending up \nwith different file ID's for the same path, and merging that inevitably \ncauses problems not just during the merge, but ever after, since one of \nthe file ID's will then have to be \"deleted\" even though it might be \nactive in one of the branches).\n\nFinally, file-ID based systems fundamentally cannot handle some simple and \ninteresting cases, like partial content movement. We're starting to see \ngit actually being able to track file content moving between files: even \nwhen the files themselves didn't move (ie Junio's \"git pickaxe\" work could \ndo things like that).\n\nAnd there really aren't as many advantages to tracking renames as people \nclaim. The biggest advantage of tracking renames is to avoid the trap that \nCVS fell into: being file-ID based _and_ not being able to track the file \nID moving is clearly the worst of all worlds.\n\nSo for anybody coming from a CVS background, tracking renames explicitly \nis a _huge_ advantage, which is, I think, why some SCM people have gotten \nso hung up about them. It's just that if you don't have the file-ID \nproblem in the first place (and git doesn't), then rename tracking doesn't \nactually make any sense, and only makes things much worse.\n\n\t\t\tLinus\n"},{"id":"29397","messageId":"Pine.LNX.4.64.0610201100070.3962@g5.osdl.org","threadId":"5925","inReplyTo":"45390BAF.5040405@utoronto.ca","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-20T18:06:09Z","receivedAt":"2006-10-20T18:06:09Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Aaron Bentley wrote:\n> > \n> > Git _definitely_ handles renames, both in everyday life and when merging.\n> \n> Hmm. Could you say more here? The only examples I can think of for\n> handling renames are situations that can be expressed as a merge.\n\nSo yes, merges are the situation where renames are normally considered a \n\"problem\", but it's actually not nearly the most every-day situation at \nall.\n\nThe most common one is actually just showing things as a diff.\n\nIf you are looking at a code-change, there's an absolutely _huge_ \ndifference if you look at the result as a \"delete this huge file\" and \n\"create this other huge file\" and seeing it as a \"move this huge file from \nhere to here, and change a few lines in the process\".\n\nSo the most _important_ part of rename tracking from a user perspective is \nfor the person who walks through somebody elses code history, and wants to \nknow how a certain state came to be. The merges are usually not as big of \na deal for the user (although they are clearly the most hairy case for the \nSCM - which is why SCM people concentrate on merges).\n\n\t\t\tLinus\n"},{"id":"29398","messageId":"20061020181210.GA29843@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"200610201821.34712.jnareb@gmail.com","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-20T18:12:10Z","receivedAt":"2006-10-20T18:12:10Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Fri, Oct 20, 2006 at 06:21:34PM +0200, Jakub Narebski wrote:\n> Aaron Bentley wrote:\n> \n> > === added directory  // file-id:TREE_ROOT\n> \n> Gaaah, so rename detection in bzr is done using file-ids?\n> Linus will tell you the inherent problems with that \"solution\".\n\nOk, I tried to read\nhttp://permalink.gmane.org/gmane.comp.version-control.git/217\n\nIt's all nice and well, but my question is whether the below cases work\nin git. Yes, they are particular cases, but they are particularly\nimportant. If they don't, I'd rather have file-id scheme, that is\nlimited to just them, but handles them, than something with big plans,\nbut nothing working.\n\nLet's consider following scenario:\n\n(where A$ means working in branch A, B$ means working in branch B and\n VCT stands for version control tool of choice)\n\nA$ echo Hello Warld! > hello.txt\nA$ VCT add hello.txt\nA$ VCT commit -m \"Created greeting\"\n$ VCT branch A B\nA$ VCT mkdir data\nA$ VCT mv hello.txt data/\nA$ VCT commit -m \"Moved hello.txt to data dir\"\nB$ ed hello.txt\n? 1s/Warld/World/\n? wq\nB$ VCT commit -m \"Fixed typo in greeting\"\nA$ VCT merge B\n\nAt this point, I expect the tree to look like this:\nA$ ls -R\n.:\ndata/\ndata:\nhello.txt\nA$ cat data/hello.txt\nHello World!\n\nThe file-id algorithm is not exceptionaly clever, is a bit of\nspecial-case and all that, but it handles the above case right. And\nwhile that scenario is just a special case of general moving contents,\nit is:\n1) Very common\n2) Possible to handle in an obviously correct way\n\nIt is very important for me that a version control tool I use handles\nthis case. If it handles the more general cases, that's nice, but this\nis a must.\n\nOh, and there is one more complicated case, that I also require to work\nand that works in Bzr, but did not work in Arch:\n\n...let's start with the tree at the end of previous example...\n\nA$ VCT mv data greetings\nA$ VCT commit -m \"Renamed the data directory to greetings\"\nB$ echo \"Goodbye World!\" > data/goodbye.txt\nB$ VCT add data/goodbye.txt\nB$ VCT commit -m \"Added goodbye message.\"\nA$ VCT merge B\n\nAnd now I expect to have tree looking like this:\n\nA$ ls -R\n.:\ngreetings/\ngreetings:\nhello.txt\ngoodbye.txt\n\nAnd note, that it is /not/ required to use file-ids to handle this.\nDarcs handles this just as well with it's patch algebra\n(http://darcs.net/DarcsWiki/PatchTheory) without need of any IDs.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29399","messageId":"9e4733910610201115g1790b5am55105bf0c662a0da@mail.gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201045550.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-10-20T18:15:15Z","receivedAt":"2006-10-20T18:15:15Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 10/20/06, Linus Torvalds wrote:\n> So yeah, I've seen a few strange cases myself, but they've actually been\n> interesting. Like seeing how much of a file was just a copyright license,\n> and then a file being considered a \"copy\" just because it didn't actually\n> introduce any real new code.\n\nIt may be worth doing something special for licenses. Logs of small\nMozilla files are also getting tripped up by the large copyright\nnotices. The notices take up a lot of space too. The Mozilla license\nhas been changed five times. That is 110,000 files times one to five\nlicenses at 800-1500 characters each. 500MB+ of junk before\ncompression.\n\nYou could have a file of macro substitutions that is applied/expanded\nwhen files go in/out of git. The macros would replace the copyright\nnotices improving the move/rename tracking and the reducing repository\nsize. The macros could be recorded out of band to eliminate the need\nfor escaping the file contents. Even simpler, the only valid place for\nthe macro could be the beginning of the file.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"29400","messageId":"Pine.LNX.4.64.0610201110320.3962@g5.osdl.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201100070.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-20T18:30:15Z","receivedAt":"2006-10-20T18:30:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Linus Torvalds wrote:\n> \n> So yes, merges are the situation where renames are normally considered a \n> \"problem\", but it's actually not nearly the most every-day situation at \n> all.\n\nBtw, this is a pet peeve of mine, and it is not at all restricted to \nthe SCM world.\n\nIn CompSci in general, you see a _lot_ of papers about things that almost \ndon't matter - not because the issues are that important in practice, but \nbecause the issues are something small enough to be something you can \ndiscuss and explain without having to delve into tons of ugly detail, and \nbecause it's something that has a lot of \"mental masturbation\" associated \nwith it - ie you can discuss it endlessly.\n\nIn the OS world, it's things like schedulers. You find an _inordinate_ \nnumber of papers on scheduling, considering that the actual algorithm then \ntends to be something that can be expressed in a hundred lines of code or \nso, but it's got quite high \"mental masturbatory value\" (hereafter called \nMMV).\n\nOther high-MMV areas are page-out algorithms (never mind that almost all \n_real_ VM problems are elsewhere) and some zero-copy schemes (never mind \nthat if you actually need to _work_ with the data, zero-copy DMA may \nactually be much worse because it ends up having bad cache behaviour).\n\nIn the SCM world, file renames and merging seem to be the high-MMV things. \nNever mind that the real issues tend to be elsewhere (like _performance_ \nwhen you have a few thousand commits that you want to merge).\n\nFor example, in the kernel, I think about half of all merges are what git \ncalls \"trivial in-index merges\". That's HALF. Being a trivial in-index \nmerge means that there was not a single file-level conflict that even \nneeded a three-way merge, much less any study of the history AT ALL (other \nthan finding the common ancestor, of course).\n\nOf the rest, most by far need some trivial 3-way merging. And the ones \nthat have trouble? In practice, that trivial and maligned 3-way does \n_better_ than anything more complicated.\n\nYet, if you actually bother to follow all the discussion on #revctrl and \nother places, what do you find discussed? Right: various high-MMV issues \nlike \"staircase merge\" etc crap.\n\nGo to revctrl.org for prime example of this. I think half the stuff is \nabout merge algorithms, some of it is about glossary, and almost none of \nit is about something as pedestrian and simple as performance and \nscalability.\n\n(Actually, to be honest, I think some of the #revctrl noise has become \nbetter lately. I'm not seeing quite as much theoretical discussion, it may \nbe that as open-source distributed SCM's are getting to be more \"real\", \npeople start to slowly realize that the masturbatory crap isn't actually \nwhat it's all about. So maybe at least this area is getting more about \nreal every-day problems, and less about the theoretical-but-not-very- \nimportant issues).\n\n\t\tLinus\n"},{"id":"29401","messageId":"200610202035.26227.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061020181210.GA29843@artax.karlin.mff.cuni.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T18:35:25Z","receivedAt":"2006-10-20T18:35:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jan Hudec wrote:\n> On Fri, Oct 20, 2006 at 06:21:34PM +0200, Jakub Narebski wrote:\n> > Aaron Bentley wrote:\n> > \n> > > === added directory  // file-id:TREE_ROOT\n> > \n> > Gaaah, so rename detection in bzr is done using file-ids?\n> > Linus will tell you the inherent problems with that \"solution\".\n> \n> Ok, I tried to read\n> http://permalink.gmane.org/gmane.comp.version-control.git/217\n> \n> It's all nice and well, but my question is whether the below cases work\n> in git. Yes, they are particular cases, but they are particularly\n> important. If they don't, I'd rather have file-id scheme, that is\n> limited to just them, but handles them, than something with big plans,\n> but nothing working.\n> \n> Let's consider following scenario:\n> \n> (where A$ means working in branch A, B$ means working in branch B and\n> VCT stands for version control tool of choice)\n\n1077:jnareb@roke:/tmp/jnareb> mkdir tmp\n1078:jnareb@roke:/tmp/jnareb> cd tmp/\n1079:jnareb@roke:/tmp/jnareb/tmp> git init-db\ndefaulting to local storage area\n\n> A$ echo Hello Warld! > hello.txt\n1081:jnareb@roke:/tmp/jnareb/tmp> echo 'Hello Warld!' > hello.txt\n\n> A$ VCT add hello.txt\n1082:jnareb@roke:/tmp/jnareb/tmp> git add hello.txt\n\n> A$ VCT commit -m \"Created greeting\"\n1083:jnareb@roke:/tmp/jnareb/tmp> git commit -a -m \"Created greeting\"\n\n(we use here still default branch 'master'. Let us change it to A)\n1084:jnareb@roke:/tmp/jnareb/tmp> git branch A\n1088:jnareb@roke:/tmp/jnareb/tmp> git checkout A\n\n> $ VCT branch A B\n1085:jnareb@roke:/tmp/jnareb/tmp> git branch B A\n(create branch B based on A)\n\n> A$ VCT mkdir data\n1089:jnareb@roke:/tmp/jnareb/tmp> mkdir data\n\n> A$ VCT mv hello.txt data/\n1090:jnareb@roke:/tmp/jnareb/tmp> git mv hello.txt data/\n\n> A$ VCT commit -m \"Moved hello.txt to data dir\"\n1092:jnareb@roke:/tmp/jnareb/tmp> git commit -a -m \"Moved hello.txt to data dir\"\n\n> B$ ed hello.txt\n> ? 1s/Warld/World/\n> ? wq\n1094:jnareb@roke:/tmp/jnareb/tmp> ed hello.txt \n13\n1s/Warld/World/\nwq\n13\n\n> B$ VCT commit -m \"Fixed typo in greeting\"\n1096:jnareb@roke:/tmp/jnareb/tmp> git commit -a -m \"Fixed typo in greeting\"\n\n> A$ VCT merge B\n1097:jnareb@roke:/tmp/jnareb/tmp> git checkout A\n1098:jnareb@roke:/tmp/jnareb/tmp> git pull . B\nTrying really trivial in-index merge...\nfatal: Merge requires file-level merging\nNope.\nMerging HEAD with 9de7290d385ec2b0c2ade9b888f6c3a6633ac926\nMerging: \n5f0eb04467538f0f1414af85ec6481150107c0b2 Moved hello.txt to data dir \n9de7290d385ec2b0c2ade9b888f6c3a6633ac926 Fixed typo in greeting \nfound 1 common ancestor(s): \nf49a520e40143cb9d84b00e9728c5742897c0a22 Created greeting \n\nMerge made by recursive.\n data/hello.txt | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\n> At this point, I expect the tree to look like this:\n> A$ ls -R\n1099:jnareb@roke:/tmp/jnareb/tmp> ls -R\n.:\ndata\n\n./data:\nhello.txt\n\n> A$ cat data/hello.txt\n1100:jnareb@roke:/tmp/jnareb/tmp> cat data/hello.txt \nHello World!\n\n\n\n> A$ VCT mv data greetings\n1102:jnareb@roke:/tmp/jnareb/tmp> git mv data greetings\n\n> A$ VCT commit -m \"Renamed the data directory to greetings\"\n1105:jnareb@roke:/tmp/jnareb/tmp> git commit -a -m \"Renamed the data directory to greetings\"\n\n> B$ echo \"Goodbye World!\" > data/goodbye.txt\n1106:jnareb@roke:/tmp/jnareb/tmp> git checkout B\n1109:jnareb@roke:/tmp/jnareb/tmp> echo 'Goodbye World!' > data/goodbye.txt\nbash: data/goodbye.txt: There is no such file or directory\n1110:jnareb@roke:/tmp/jnareb/tmp> ls -R\n.:\nhello.txt\n\nYou need to revise your example.\n-- \nJakub Narebski\nPoland\n"},{"id":"29403","messageId":"200610202046.23202.jnareb@gmail.com","threadId":"5925","inReplyTo":"200610202035.26227.jnareb@gmail.com","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T18:46:22Z","receivedAt":"2006-10-20T18:46:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n>> A$ VCT commit -m \"Moved hello.txt to data dir\"\n> 1092:jnareb@roke:/tmp/jnareb/tmp> git commit -a -m \"Moved hello.txt to data dir\"\n> \n>> B$ ed hello.txt\n>> ? 1s/Warld/World/\n>> ? wq\nSorry, I have forgot to put in email \"git checkout B\"\nto actually switch to branch B.\n\n> 1094:jnareb@roke:/tmp/jnareb/tmp> ed hello.txt \n> 13\n> 1s/Warld/World/\n> wq\n> 13\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29404","messageId":"200610202047.11291.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061020181210.GA29843@artax.karlin.mff.cuni.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T18:47:10Z","receivedAt":"2006-10-20T18:47:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jan Hudec wrote:\n\n> And note, that it is /not/ required to use file-ids to handle this.\n> Darcs handles this just as well with it's patch algebra\n> (http://darcs.net/DarcsWiki/PatchTheory) without need of any IDs.\n\nAnd Darcs is, from opinions I've read, dog-slow.\n"},{"id":"29405","messageId":"Pine.LNX.4.64.0610201133260.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061020181210.GA29843@artax.karlin.mff.cuni.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-20T18:48:09Z","receivedAt":"2006-10-20T18:48:09Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Jan Hudec wrote:\n>\n> Let's consider following scenario:\n\nHere's a real-life schenario that we hit several times with BK over the \nyears:\n\n - take a real repository, and a patch that gets discussed that adds a new \n file.\n - take two different people applying that patch to their trees (or, do \n the equivalent thing, which is to just create the same filename\n independently, because the solution is obvious - and the same - to \n both developers).\n - now, have somebody merge both of those two peoples trees (eg me)\n - have the two people continue to use their trees, modifying it, and \n getting merged.\n\nTrust me, this isn't even _unlikely_. It happens. And it's a serious \nproblem for a file-ID case. Why? Because you have two different file ID's \nfor the same pathname. \n\n(It happily only happened a handful of times, so it was never a big enough \nproblem to cause me to think that BK was crap. But it definitely was a \nreal issue).\n\nWhat BK did (and what is likely the only reasonable thing to do) is to \nmove one of the file-ID's to an \"Attic\" kind of place, and just go with \nthe other. The nasty part is that now the developer whose file was \n\"dropped\" (and anybody who got the work from him) may still be continuing \nto work with _his_ copy of the same file, never even realizing that when \nhis work gets merged, all his fixes GET THROWN AWAY!\n\nAnd trust me, this isn't a theoretical thing. This actually happens. So \nyou have problems at many levels: you have the problems that happen during \nthe merge (where somebody needs to decide how to resolve the file-ID \nclash), but what a lot of SCM people seem to not have understood is that \nthe problem actually _remains_ after the merge, and causes problems even \ndown the line.\n\nSo yeah, content-based merging has its own problems (especially if you do \nthings like re-indent a file as you move it, or if you have files that \njust look the same because they share 99% of their content through a \ncopyright message), but at least so far, we've not really ever hit that \nissue in the kernel.\n\nAnd we are actually approaching the old kernel BK tree in size with the \ncurrent git tree (we're about 2/3rds of the way if you count number of \ncommits). That's despite the fact that we actually have been moving things \naround. So from a purely _practical_ standpoint, I really do have \nanecdotal evidence that I'm right.\n\nI didn't have that evidence when I started, but I knew I was right anyway ;)\n\n\t\tLinus\n\nPS. It's undoubtedly true that the SCM you use impacts _how_ you do \ndevelopment, so any project will almost automatically align itself with \nwhatever SCM rules there are in place.\n\nSo \"anecdotal evidence\" in that sense isn't really wonderful, since it \nobviously is always a matter of a certain project/SCM combination - but \nthe above example is about as neutral as you can get, since it's the \n_same_ project, with the _same_ maintainer, and roughtly the _same_ rules, \njust two different approaches wrt renames of the SCM's in question.\n"},{"id":"29406","messageId":"Pine.LNX.4.64.0610201151130.3962@g5.osdl.org","threadId":"5925","inReplyTo":"200610202047.11291.jnareb@gmail.com","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-20T19:00:04Z","receivedAt":"2006-10-20T19:00:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Jakub Narebski wrote:\n\n> Jan Hudec wrote:\n> \n> > And note, that it is /not/ required to use file-ids to handle this.\n> > Darcs handles this just as well with it's patch algebra\n> > (http://darcs.net/DarcsWiki/PatchTheory) without need of any IDs.\n> \n> And Darcs is, from opinions I've read, dog-slow.\n\nYou really cannot expect to get any kind of performance at all unless you:\n\n - are able to ignore 99.9% of all files on merging (ie you have to be \n able to totally ignore the files that are identical in both sides, and \n you really shouldn't even _care_ about why they ended up being \n identical)\n\n - are able to ignore 99% of what the commits _did_ in between the merges \n (ie if you need to look at them at all, only look at the part that \n matters for the 0.1% of files that you couldn't ignore)\n\nIf you have to parse all the commit details all the way down to the common \nparent, you're basically already screwed. There's no _way_ you can make it \nfast. \n\nGit goes one step further: it _really_ doesn't matter about how you got to \na certain state. Absolutely _none_ of what the commits in between the \nfinal stages and the common ancestor matter in the least. The only thing \nthat matters is what the states at the end-point are.\n\n(Of course, you _could_ plug in a merge algorithm that cares, since there \nis more data there. I'm just talking about the standard \"recursive\" \nalgorithm here.)\n\nThat's why git can be so fast, but it's actually more important than that: \nthe fact that it doesn't matter _how_ you got to a certain state is \nactually a huge and important feature. In other words, you should see it \nas a guarantee, not as a \"lack of knowledge\".\n\nDarcs thinks it matters how you got somewhere. Git consciously says: none \nof the individual patches matter, the only thing that matters is the end \nresult, because you could have gotten the same result in a lot of \ndifferent ways, and nobody _cares_.\n\n\t\t\tLinus\n"},{"id":"29407","messageId":"45391DC3.7060002@utoronto.ca","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201110320.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-20T19:04:35Z","receivedAt":"2006-10-20T19:04:35Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nLinus Torvalds wrote:\n> \n> On Fri, 20 Oct 2006, Linus Torvalds wrote:\n> \n>>So yes, merges are the situation where renames are normally considered a \n>>\"problem\", but it's actually not nearly the most every-day situation at \n>>all.\n> \n> \n> Btw, this is a pet peeve of mine, and it is not at all restricted to \n> the SCM world.\n\nI guess I don't mind a bit of high-mmv discussion, so long as it doesn't\nget in the way of real work. Polishing these kinds of things seems to\nfall in the category of 10% of functionality that takes 90% of effort.\n\n> Of the rest, most by far need some trivial 3-way merging. And the ones \n> that have trouble? In practice, that trivial and maligned 3-way does \n> _better_ than anything more complicated.\n\nI think the great motivator for exploring other merge algorithms has\nbeen criss-cross merge. There are some workflows (e.g. the Launchpad\nworkflow) in which heavy mesh-merging takes place, leading to frequent\ncriss-crosses.\n\nBog-standard three-way doesn't handle that criss-cross very well. I\nunderstand git uses recursive three-way in that situation.\n\nThe other motivator has been cherry-picking.\n\nSo I'm happy that people are trying to devise merge algorithms that are\nbetter than three-way. When someone gets it right, we'll implement it.\n\nAnd then there are other more incremental tweaks, like\nmerge-across-indent and merge-across-line-ending-change that I'd like to\nsee.\n\n> Go to revctrl.org for prime example of this. I think half the stuff is \n> about merge algorithms, some of it is about glossary, and almost none of \n> it is about something as pedestrian and simple as performance and \n> scalability.\n\nPartly this is because of Bram's interests. AIUI, he started with a\nmerge algorithm and built a VCS around it.\n\n> (Actually, to be honest, I think some of the #revctrl noise has become \n> better lately.\n\nI used to spend time on #revctrl, but I think that was before you\nstarted visiting. Too bad I missed ya.\n\n So maybe at least this area is getting more about\n> real every-day problems, and less about the theoretical-but-not-very- \n> important issues).\n\nIt wouldn't surprise me if the early phases of VCS development tended\ntoward more theoretical discussion, just because so many questions are open.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFOR3D0F+nu1YWqI0RAo5lAJ99+5ShvLXaVIRG1A8XN7HRicoPngCeLO+y\nmeMZVcjdX7AX9JCfhSN5uK4=\n=AI8p\n-----END PGP SIGNATURE-----\n"},{"id":"29408","messageId":"45391F1C.80100@utoronto.ca","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201151130.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-20T19:10:20Z","receivedAt":"2006-10-20T19:10:20Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nLinus Torvalds wrote:\n> Git goes one step further: it _really_ doesn't matter about how you got to \n> a certain state. Absolutely _none_ of what the commits in between the \n> final stages and the common ancestor matter in the least. The only thing \n> that matters is what the states at the end-point are.\n\nThat's interesting, because I've always thought one of the strengths of\nfile-ids was that you only had to worry about end-points, not how you\ngot there.\n\nHow do you handle renames without looking at the history?\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFOR8c0F+nu1YWqI0RAkhJAJ9QJ3nyP/437/bNPI3VEVHZP0dEZACfZyEg\nSWAp+673iTDEZfH00M4RG4k=\n=1XO+\n-----END PGP SIGNATURE-----\n"},{"id":"29409","messageId":"200610202114.39223.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061020181210.GA29843@artax.karlin.mff.cuni.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T19:14:38Z","receivedAt":"2006-10-20T19:14:38Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jan Hudec wrote:\n\n> Let's consider following scenario:\n> \n> (where A$ means working in branch A, B$ means working in branch B and\n> VCT stands for version control tool of choice)\n[...]\n> At this point, I expect the tree to look like this:\n> A$ ls -R\n> .:\n> data/\n> data:\n> hello.txt\n> A$ cat data/hello.txt\n> Hello World!\n[...]\n> Oh, and there is one more complicated case, that I also require to work\n> and that works in Bzr, but did not work in Arch:\n> \n> ...let's start with the tree at the end of previous example...\n> \n> A$ VCT mv data greetings\n> A$ VCT commit -m \"Renamed the data directory to greetings\"\n> B$ echo \"Goodbye World!\" > data/goodbye.txt\n> B$ VCT add data/goodbye.txt\n> B$ VCT commit -m \"Added goodbye message.\"\n> A$ VCT merge B\n\n(slightly corrected example).\n\nA$ git branch B\nA$ git mv data greetings\nA$ git commit -a -m \"Renamed the data directory to greetings\"\nA$ git checkout B\nB$ echo 'Goodbye World!' > data/goodbye.txt\nB$ git add data/goodbye.txt\nB$ git commit -a -m \"Added goodbye message.\"\nB$ git checkout A\nA$ git pull . B\nTrying really trivial in-index merge...\nfatal: Merge requires file-level merging\nNope.\nMerging HEAD with 4a8a1a7941f214c6173786b583830b4f74a67c1f\nMerging: \n96738390ba0b4de5b234059081701badc1c86693 Renamed the data directory to greetings \n4a8a1a7941f214c6173786b583830b4f74a67c1f Added goodbye message. \nfound 1 common ancestor(s): \n7cfd8edd06b7cb016856737d8fd98d5d096955b5 Merge branch 'B' into A \n\nMerge made by recursive.\n data/goodbye.txt | 1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 data/goodbye.txt\n\n> And now I expect to have tree looking like this:\n> \n> A$ ls -R\n> .:\n> greetings/\n> greetings:\n> hello.txt\n> goodbye.txt\n\nSo git _fails_ (your expectations) in this case:\nA$ ls -R\n.:\ndata greetings\n\n./data:\ngoodbye.txt\n\n./greetings:\nhello.txt\n"},{"id":"29411","messageId":"Pine.LNX.4.64.0610201214530.3962@g5.osdl.org","threadId":"5925","inReplyTo":"45391DC3.7060002@utoronto.ca","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-20T19:31:17Z","receivedAt":"2006-10-20T19:31:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Aaron Bentley wrote:\n> > \n> > Btw, this is a pet peeve of mine, and it is not at all restricted to \n> > the SCM world.\n> \n> I guess I don't mind a bit of high-mmv discussion, so long as it doesn't\n> get in the way of real work. Polishing these kinds of things seems to\n> fall in the category of 10% of functionality that takes 90% of effort.\n\nWell, the thing is, that 10% of the functionality usually takes a whole \nlot _less_ than 10% of the work.\n\nThe stuff you can think through (and argue about) tends to be the easy \nstuff. Exactly because you _can_ think about it abstractly.\n\nThe stuff that is actually really hard and time-consuming is the stuff \nthat you find out in practice, and you have to iterate on.\n\nIn kernels, for example, it seems like 99% of the effort ends up being \nhardware-dependent stuff. Getting architecture interfaces right, and \ngetting working drivers. Hotplugging and device management turns out to be \na _much_ bigger issue than schedulers or VM page-out has _ever_ been. \n\nBut show me a single paper about them. I'm sure they exist. I'm just \nsaying that they're sure as heck not getting 99% of the attention (or even \n1% of the attention) in discussions, even though they're definitely 99% of \nthe real everyday work and effort.\n\n(Maybe it's not 99%. Numbers taken out of my nether regions. The point \nshould be clear).\n\nThe same is actually true of SCM's too, I'm totally convinced. At least in \ngit, we really haven't spent _that_ much time on merges, for example. My \noriginal stupid three-way merge was really simple, and I think the way I \nintroduced \"stages\" into the git index was really clever, but it was still \na small detail. And it worked surprisingly way.\n\nAfter that merge, people improved it. And \"recursive\" is a _huge_ \nimprovement, don't get me wrong: it's still entirely a 3-way merge on the \nfile contents, but it now does those 3-way merges in several stages if \nthere are multiple independent common parents, and the rename logic is \nclearly important.\n\nBut if you actually look at how much effort was spent on merging, and how \nmuch was spent on just \"details in general\", I think you'll find merging \nto be pretty low down the list, even though the recursive merge ended up \n_also_ getting re-written in C. Perhaps it was one of the bigger \n_individual_ efforts, but compared to all the work we've continually done \non performance and usability, for example, it's been pretty small in the \nend.\n\nAs an example: I suspect that in git just the CVS importer has gotten \n_way_ more attention than merging ever got. Importing from CVS is simply a \nmuch harder problem in practice, and we've probably had more people \nworking on it (and that's _despite_ the fact that this is one of the areas \nwhere git has successfully re-used other projects that had similar goals: \ncvsps, cvs2svn etc). It's hard to \"think\" about, because a lot of the \nproblems with importing from CVS are literally all about the details and \nthe nasty crud. I really think \"merging\" is _way_ easier.\n\n\t\t\tLinus\n"},{"id":"29413","messageId":"Pine.LNX.4.64.0610201231570.3962@g5.osdl.org","threadId":"5925","inReplyTo":"45391F1C.80100@utoronto.ca","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-20T19:46:39Z","receivedAt":"2006-10-20T19:46:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Aaron Bentley wrote:\n> \n> Linus Torvalds wrote:\n> > Git goes one step further: it _really_ doesn't matter about how you got to \n> > a certain state. Absolutely _none_ of what the commits in between the \n> > final stages and the common ancestor matter in the least. The only thing \n> > that matters is what the states at the end-point are.\n> \n> That's interesting, because I've always thought one of the strengths of\n> file-ids was that you only had to worry about end-points, not how you\n> got there.\n> \n> How do you handle renames without looking at the history?\n\nYou first handle all the non-renames that just merge on their own. That \ntakes care of 99.99% of the stuff (and I'm not exaggerating: in the \nkernel, you have ~21000 files, and most merges don't have a single rename \nto worry about - and even when you do have them, they tend to be in the \n\"you can count them on one hand\" kind of situation).\n\nThen you just look at all the pathnames you _couldn't_ resolve, and that's \nusually cut down the thing to something where you can literally use a lot \nof CPU power per file, because now you only have a small number of \ncandidates left.\n\nIf you were to use one hundredth of a second per file regardless of file, \na stupid per-file merge would take 210 seconds, which is just \nunacceptable. So you really don't want to do that. You want to merge whole \nsubdirectories in one go (and with git, you can: since the SHA1 of a \ndirectory defines _all_ of the contents under it, if the two branches you \nmerge have an identical subdirectory, you don't need to do anything at \n_all_ about that one. See?).\n\nSo instead of trying to be really fast on individual files and doing them \none at a time, git makes individual files basically totally free (you \nliterally often don't need to look at them AT ALL). And then for the few \nfiles you can't resolve, you can afford to spend more time.\n\nSo say that you spend one second per file-pair because you do complex \nheuristics etc - you'll still have a merge that is a _lot_ faster than \nyour 210-second one.\n\nSo recursive basically generates the matrix of similarity for the \nnew/deleted files, and tries to match them up, and there you have your \nrenames - without ever looking at the history of how you ended up where \nyou are.\n\nBtw, that \"210 second\" merge is not at all unlikely. Some of the SCM's \nseem to scale much worse than that to big archives, and I've heard people \ntalk about merges that took 20 minutes or more. In contrast, git doing a \nmerge in ~2-3 seconds for the kernel is _normal_.\n\n[ In fact, I just re-tested doing my last kernel merge: it took 0.970 \n seconds, and that was _including_ the diffstat of the result - not \n obviously not including the time to fetch the other branch over the \n network.\n\n I don't know if people appreciate how good it is to do a merge of two \n 21000-file branches in less than a second. It didn't have any renames, \n and it only had a single well-defined common parent, but not only is \n that the common case, being that fast for the simple case is what \n _allows_ you to do well on the complex cases too, because it's what gets \n rid of all the files you should _not_ worry about ]\n\nPerformance does matter. \n\n\t\t\tLinus\n"},{"id":"29414","messageId":"45392D98.307@utoronto.ca","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201214530.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-20T20:12:08Z","receivedAt":"2006-10-20T20:12:08Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nLinus Torvalds wrote:\n> \n> On Fri, 20 Oct 2006, Aaron Bentley wrote:\n> \n>>>Btw, this is a pet peeve of mine, and it is not at all restricted to \n>>>the SCM world.\n>>\n>>I guess I don't mind a bit of high-mmv discussion, so long as it doesn't\n>>get in the way of real work. Polishing these kinds of things seems to\n>>fall in the category of 10% of functionality that takes 90% of effort.\n> \n> \n> Well, the thing is, that 10% of the functionality usually takes a whole \n> lot _less_ than 10% of the work.\n\nI guess this depends on whether you consider the brainstorming and\ndiscussion to be part of the work of polishing, and I do mean polishing.\n Getting from something that works 90% of the time to something that\nworks 99% of the time can be a questionable expenditure of time and effort.\n\n> The same is actually true of SCM's too, I'm totally convinced. At least in \n> git, we really haven't spent _that_ much time on merges, for example. My \n> original stupid three-way merge was really simple, and I think the way I \n> introduced \"stages\" into the git index was really clever, but it was still \n> a small detail. And it worked surprisingly way.\n\nI did rewrite our merge code once, but that was because the API was\nquite hard to deal with and made it hard to maintain. I agree that it's\nimportant to focus effort on the areas that make a difference.\n\nOn the other hand, our \"exotic\" text merge algorithms have been praised\nby the people who work on Launchpad. So that's a win.\n\n> As an example: I suspect that in git just the CVS importer has gotten \n> _way_ more attention than merging ever got. Importing from CVS is simply a \n> much harder problem in practice, and we've probably had more people \n> working on it (and that's _despite_ the fact that this is one of the areas \n> where git has successfully re-used other projects that had similar goals: \n> cvsps, cvs2svn etc). It's hard to \"think\" about, because a lot of the \n> problems with importing from CVS are literally all about the details and \n> the nasty crud. I really think \"merging\" is _way_ easier.\n\nYes, I don't even want to think about CVS when I don't have to.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFOS2Y0F+nu1YWqI0RAiOcAJ0TXmBdiCcvnTzmg+nnF+kayJ25cgCggMFx\nw6xFlFHwPoNm9dt/T4LnmCU=\n=zNuy\n-----END PGP SIGNATURE-----\n"},{"id":"29415","messageId":"7v1wp2oi6s.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201049250.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-20T20:17:47Z","receivedAt":"2006-10-20T20:17:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> ... We're starting to see \n> git actually being able to track file content moving between files: even \n> when the files themselves didn't move (ie Junio's \"git pickaxe\" work could \n> do things like that).\n\nI've reordered the git-pickaxe I parked in \"pu\" while 1.4.3-rc\ncycle and merged it into \"next\".\n\nThe earlier one I was futzing with in \"pu\" had built-in\nheuristics and pure mechanisms mixed together in the same patch,\nwhich was quite bad as development history. I think the\nreordered sequence shows the logical evolution better.\n\n 1. git-pickaxe: blame rewritten.\n\n This implements the infrastructure (parent traversal,\n identifying \"corresponding path\" in the parent -- aka\n \"handling renames\", passing blames to the parents and\n taking responsibility for the remainder) and uses the the\n same old \"single diff with parent file identifies what we\n inherited from the parent\" logic git-blame uses for passing\n blames.\n\n 2. git-pickaxe -M: blame line movements within a file.\n\n This adds logic to find swapped groups of lines in the same\n file. When the file in the parent had A and B and the child\n has B and A, \"single diff with parent\" would find only one\n of A or B is inherited from the parent, not both. This\n re-diffs the remainder with the parent's file to find both.\n\n I used to have heuristics to avoid trivial groups of lines\n from being subject to this step, but in this version they\n have been removed, so that we can see the core logic and\n need for heuristics more clearly.\n\n On the other hand, the version I used to have in \"pu\" gave\n blame to the first match. This one tries to find the best\n match and assign the blame to it.\n\n 3. git-pickaxe -C: blame cut-and-pasted lines.\n\n This adds logic to find groups of lines brought in from\n existing file in the parent. We scan the remainder using\n the same logic as -M detection, but it is done against\n other files in the parent.\n\n There was a heuristic that gave the blame to the parent\n right then and there when we find a copy-and-paste instead\n of allowing the parent to pass blame further on to its\n ancestors; again I removed this heuristics in the reordered\n series.\n\nThe next logical step is to come up with a good set of\nheuristics to avoid excessive nonsense matches the code\ncurrently gives.\n\nGroups of small number of empty lines, lines with indentation\nblanks followed by a closing brace, and '#include' lines that\ninclude common header files occur so commonly, that without any\nheuristics (which can be seen in the \"next\" branch today) the\nalgorithm would give surprisingly idiotic results. For example:\n\n\tgit -p pickaxe -C -f -n v1.4.3 -- commit.c\n\ntells you that the first line of commit.c in v1.4.3 release,\nwhich is '#include \"cache.h\"' came from the first line of\nreceive-pack.c which is total nonsense (this particular line\ncould actually be a bug in the -M or -C logic -- I need to\ncheck).\n\nA less \"obviously wrong\" but still idiotic case is that we find\nll.409-411 came from ll.94-96 of describe.c in commit 908e5310.\nThese three lines read as:\n\n\t409\t\t}\n 410\t}\n 411\n\nWhile this blame assignment might be technically correct, it\ndoes not add much value to pass blames on in such a case.\n\nOn the brighter side, we find that ll.415-419 (the beginning of\nfunction \"static int get_one_line()\") originally came from\ndiff-tree.c (commit cee99d22, ll.275-279).\n"},{"id":"29416","messageId":"20061020202318.GJ20017@pasky.or.cz","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201045550.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-20T20:23:19Z","receivedAt":"2006-10-20T20:23:19Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Oct 20, 2006 at 07:48:58PM CEST, I got a letter\nwhere Linus Torvalds said that...\n> So yeah, I've seen a few strange cases myself, but they've actually been \n> interesting. Like seeing how much of a file was just a copyright license, \n> and then a file being considered a \"copy\" just because it didn't actually \n> introduce any real new code.\n\nWell it's certainly \"interesting\" and fun to see, but is it equally fun\nto handle mismerges caused by a broken detection?\n\nI've talked to some people who really didn't mind (or even liked) Git's\nheuristics when it came to _inspecting_ movement of content, but were\nreally nervous about merge following such heuristics.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i \n> On Fri, 20 Oct 2006, Aaron Bentley wrote:\n> \n>>Linus Torvalds wrote:\n>>\n>>>Git goes one step further: it _really_ doesn't matter about how you got to \n>>>a certain state. Absolutely _none_ of what the commits in between the \n>>>final stages and the common ancestor matter in the least. The only thing \n>>>that matters is what the states at the end-point are.\n>>\n>>That's interesting, because I've always thought one of the strengths of\n>>file-ids was that you only had to worry about end-points, not how you\n>>got there.\n>>\n>>How do you handle renames without looking at the history?\n> \n> \n> You first handle all the non-renames that just merge on their own.\n> If you were to use one hundredth of a second per file regardless of file, \n> a stupid per-file merge would take 210 seconds, which is just \n> unacceptable. So you really don't want to do that.\n\nAgreed. We start by comparing BASE and OTHER, so all those comparisons\nare in-memory operations that don't hit disk. Only for files where BASE\nand OTHER differ do we even examine the THIS version.\n\nWe can do a do-nothing kernel merge in < 20 seconds, and that's\ncomparing every single file in the tree. In Python. I was aiming for\nless than 10 seconds, but didn't quite hit it.\n\n> So recursive basically generates the matrix of similarity for the \n> new/deleted files, and tries to match them up, and there you have your \n> renames - without ever looking at the history of how you ended up where \n> you are.\n\nSo in the simple case, you compare unmatched THIS, OTHER and BASE files\nto find the renames?\n\n> I don't know if people appreciate how good it is to do a merge of two \n> 21000-file branches in less than a second. It didn't have any renames, \n> and it only had a single well-defined common parent, but not only is \n> that the common case, being that fast for the simple case is what \n> _allows_ you to do well on the complex cases too, because it's what gets \n> rid of all the files you should _not_ worry about ]\n\nWell, I certainly appreciate that. I've never worried about the speed\nof text merge algorithms, because you rarely merge very many files. The\nkey is making the tree merge fast.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFOTGN0F+nu1YWqI0RAii+AJ0eduC3bYya5Ao8vm1EpBb38tJP4ACeJRYe\n9/D+ahDRJa87NTryc7j3C+U=\n=plWA\n-----END PGP SIGNATURE-----\n"},{"id":"29418","messageId":"ehbc7l$kvr$1@sea.gmane.org","threadId":"5925","inReplyTo":"7v1wp2oi6s.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T20:40:29Z","receivedAt":"2006-10-20T20:40:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> 2. git-pickaxe -M: blame line movements within a file.\n> \n> This adds logic to find swapped groups of lines in the same\n> file. When the file in the parent had A and B and the child\n> has B and A, \"single diff with parent\" would find only one\n> of A or B is inherited from the parent, not both. This\n> re-diffs the remainder with the parent's file to find both.\n> \n> I used to have heuristics to avoid trivial groups of lines\n> from being subject to this step, but in this version they\n> have been removed, so that we can see the core logic and\n> need for heuristics more clearly.\n> \n> On the other hand, the version I used to have in \"pu\" gave\n> blame to the first match. This one tries to find the best\n> match and assign the blame to it.\n> \n> 3. git-pickaxe -C: blame cut-and-pasted lines.\n> \n> This adds logic to find groups of lines brought in from\n> existing file in the parent. We scan the remainder using\n> the same logic as -M detection, but it is done against\n> other files in the parent.\n> \n> There was a heuristic that gave the blame to the parent\n> right then and there when we find a copy-and-paste instead\n> of allowing the parent to pass blame further on to its\n> ancestors; again I removed this heuristics in the reordered\n> series.\n\nThe names of options clash somewhat with -M and -C in diffcore,\nwhich detect contents 'M'oving (renaming files), and contents\n'C'opying (copying files), where in git-pickaxe -C is still about\ncode movement, only across files (-M -M or --MM?).\n\nWould git-pickaxe try to do also copy-and-paste within the file,\nand across files?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29419","messageId":"Pine.LNX.4.63.0610201345440.5248@qynat.qvtvafvgr.pbz","threadId":"5925","inReplyTo":"20061020202318.GJ20017@pasky.or.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-10-20T20:49:53Z","receivedAt":"2006-10-20T20:49:53Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Fri, 20 Oct 2006, Petr Baudis wrote:\n\n> \n> Dear diary, on Fri, Oct 20, 2006 at 07:48:58PM CEST, I got a letter\n> where Linus Torvalds said that...\n>> So yeah, I've seen a few strange cases myself, but they've actually been\n>> interesting. Like seeing how much of a file was just a copyright license,\n>> and then a file being considered a \"copy\" just because it didn't actually\n>> introduce any real new code.\n>\n> Well it's certainly \"interesting\" and fun to see, but is it equally fun\n> to handle mismerges caused by a broken detection?\n>\n> I've talked to some people who really didn't mind (or even liked) Git's\n> heuristics when it came to _inspecting_ movement of content, but were\n> really nervous about merge following such heuristics.\n\nremember, git only stores the results. so when you are merging it doesn't even \nlook for renames.\n\nthe only time you get renames is after-the-fact when you ask git for a report \nabout what changed. then (if you enable rename detection) it will tell you what \nfiles have changed, and what files look like they may have been renames \n(possibly with changes). but if you don't ask git to look for renames it won't \nbother and you can just ignore the concept entirely.\n\nor if you only want complete renames (as opposed to rename + change) then use \nthe option to tell it that you don't want to consider it a rename unless it's \n100% the same (or 99%, or whatever satisfies you)\n\nDavid Lang\n"},{"id":"29420","messageId":"20061020205305.GG18019@spearce.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201045550.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-20T20:53:05Z","receivedAt":"2006-10-20T20:53:05Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Fri, 20 Oct 2006, Shawn Pearce wrote:\n> > \n> > I renamed hundreds of small files in one shot and also did a few\n> > hundered adds and deletes of other small XML files. Git generated\n> > a lot of those unrelated adds/deletes as rename/modifies, as their\n> > content was very similiar. Some people involved in the project\n> > freaked as the files actually had nothing in common with one\n> > another... except for a lot of XML elements (as they shared the\n> > same DTD).\n> \n> Heh. We can probably tweak the heuristics (one of the _great_ things about \n> content detection is that you can fix it after the fact, unlike the \n> alternative).\n> \n> That said, I've personally actually found the content-based similarity \n> analysis to often be quite informative, even when (and perhaps \n> _especially_ when) it ended up showing something that the actual author of \n> the thing didn't intend.\n> \n> So yeah, I've seen a few strange cases myself, but they've actually been \n> interesting. Like seeing how much of a file was just a copyright license, \n> and then a file being considered a \"copy\" just because it didn't actually \n> introduce any real new code.\n\nAside from that one strange case I just mentioned I've always seen\nthe strategy to work very well. Its never done something I didn't\nexpect and I've never seen copies or that I didn't expect to see,\nknowing what the author of the change did.\n\nSo even though I had a little bit of trouble with that rename\nsituation above I'm _very_ happy with the way Git handles renames.\n\nAnd the truth is that case above really was quite correct: XML is\nvery verbose. When 70% of the file is just required XML to frame\nthe other 30% of the file's payload its not surprising that files\nare considered to be similar when they only differ by a little bit\nof payload.\n"},{"id":"29421","messageId":"20061020205330.GK20017@pasky.or.cz","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610201345440.5248@qynat.qvtvafvgr.pbz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-20T20:53:30Z","receivedAt":"2006-10-20T20:53:30Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Oct 20, 2006 at 10:49:53PM CEST, I got a letter\nwhere David Lang said that...\n> On Fri, 20 Oct 2006, Petr Baudis wrote:\n> \n> >\n> >Dear diary, on Fri, Oct 20, 2006 at 07:48:58PM CEST, I got a letter\n> >where Linus Torvalds said that...\n> >>So yeah, I've seen a few strange cases myself, but they've actually been\n> >>interesting. Like seeing how much of a file was just a copyright license,\n> >>and then a file being considered a \"copy\" just because it didn't actually\n> >>introduce any real new code.\n> >\n> >Well it's certainly \"interesting\" and fun to see, but is it equally fun\n> >to handle mismerges caused by a broken detection?\n> >\n> >I've talked to some people who really didn't mind (or even liked) Git's\n> >heuristics when it came to _inspecting_ movement of content, but were\n> >really nervous about merge following such heuristics.\n> \n> remember, git only stores the results. so when you are merging it doesn't \n> even look for renames.\n\nOf course it does look for renames; when you use the recursive strategy,\nit will try to merge across renames.\n"},{"id":"29422","messageId":"Pine.LNX.4.63.0610201355260.5248@qynat.qvtvafvgr.pbz","threadId":"5925","inReplyTo":"20061020205330.GK20017@pasky.or.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-10-20T20:55:46Z","receivedAt":"2006-10-20T20:55:46Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Fri, 20 Oct 2006, Petr Baudis wrote:\n\n>>> I've talked to some people who really didn't mind (or even liked) Git's\n>>> heuristics when it came to _inspecting_ movement of content, but were\n>>> really nervous about merge following such heuristics.\n>>\n>> remember, git only stores the results. so when you are merging it doesn't\n>> even look for renames.\n>\n> Of course it does look for renames; when you use the recursive strategy,\n> it will try to merge across renames.\n\nsorry, missed that.\n\nDavid Lang\n"},{"id":"29423","messageId":"Pine.LNX.4.64.0610201333240.3962@g5.osdl.org","threadId":"5925","inReplyTo":"4539318D.9040004@utoronto.ca","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-20T20:57:27Z","receivedAt":"2006-10-20T20:57:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Aaron Bentley wrote:\n> \n> Agreed. We start by comparing BASE and OTHER, so all those comparisons\n> are in-memory operations that don't hit disk. Only for files where BASE\n> and OTHER differ do we even examine the THIS version.\n\nGit just slurps in all three trees. I actually think that the current \nmerge-recursive.c does it the stupid way (ie it expands all trees \nrecursively, regardless of whether it's needed or not), but I should \nreally check with Dscho, since I had nothing to do with that code.\n\nI wrote a tree-level merger that avoided doing the recursive tree reading \nwhen the tree-SHA1's matched entirely, and re-doing the latest merge using \nthat took all of 0.037s, because it didn't recursively expand any of the \nuninteresting trees.\n\nBut the default recursive merge was ported from the python script that \ndid it a full tree at a time, so it's comparatively \"slow\". But it's fast \nenough (witness the under-1s time ;) that I think the motivation to be \nsmarter about reading the trees was basically not just there, so my \n\"git-merge-tree\" thing is languishing as a proof-of-concept.\n\nSo right now, git merging itself doesn't even take advantage of the \"you \ncan compare two whole directories in one go\". We do that all over the \nplace in other situations, though (it's a big reason for why doing a \n\"diff\" between different revisions is so fast - you can cut the problem \nspace up and ignore the known-identical parts much faster).\n\nThat tree-based data structure turned out to be wonderful. Originally (as \nin \"first weeks of actual git work\" in April 2005) git had a flat \"file \nmanifest\" kind of thing, and that really sucked. So the data structures \nare important, and I think we got those right fairly early on.\n\n> We can do a do-nothing kernel merge in < 20 seconds, and that's\n> comparing every single file in the tree. In Python. I was aiming for\n> less than 10 seconds, but didn't quite hit it.\n\nWell, so I know I can do that particular actual merge in 0.037 seconds \n(that's not counting the history traversal to actually find the common \nparent, which is another 0.01s or more ;), so we should be able to \ncomfortably do the simple merges in less than a tenth of a second. But at \nsome point, apparently nobody just cares.\n\nOf course, this kind of thing depends a lot on developer behaviour. We had \nsome performance bugs that we didn't notice simply because the kernel \ndidn't show any of those patterns, but people using it for other things \nhad slower merges. Sometimes you don't see the problem, just because you \nend up looking at the wrong pattern for performance.\n\n> > So recursive basically generates the matrix of similarity for the \n> > new/deleted files, and tries to match them up, and there you have your \n> > renames - without ever looking at the history of how you ended up where \n> > you are.\n> \n> So in the simple case, you compare unmatched THIS, OTHER and BASE files\n> to find the renames?\n\nRight. Some cases are easy: if one of the branches only added files (which \nis relatively common), that obviously cannot be a rename. So you don't \neven have to compare all possible combinarions - you know you don't have \nrenames from one branch to the other ;)\n\nBut I'm not even the authorative person to explain all the details of the \ncurrent recursive merge, and I might have missed something. Dscho? \nFredrik? Anything you want to add?\n\n\t\t\tLinus\n"},{"id":"29426","messageId":"87irie1wvv.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"45382120.9060702@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-20T21:48:52Z","receivedAt":"2006-10-20T21:48:52Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 19 Oct 2006 21:06:40 -0400, Aaron Bentley wrote:\n> I understand your argument now.\n\nWell, I'm glad to know we each feel like we are communicating at\ntimes, here.\n\n> It's nothing to do with numbers per se,\n> and all about per-branch namespaces. Correct?\n\nThe entire discussion is about how to name things in a distributed\nsystem. The premise that Linus has put forth in a very compelling way,\nis that attempting to use sequential numbers for names in a\ndistributed system will break down. The breakdown could be that the\nnames are not stable, or that the system is used in a centralized way\nto avoid the instability of the names.\n\nNow, that causality might not accurately describe the way bzr has\ndeveloped. It may be that the centralization bias was determined by\nother reasons, and that given those, using sequential numbers for\nnames makes perfect sense.\n\nBut it really is fundamental and unavoidable that sequential numbers\ndon't work as names in a distributed version control system.\n\n> I meant that the active branch and a mirror of the abandoned branch\n> could be stored in the same repository, for ease of access.\n\nGranted, everything can be stored in one repository. But that still\ndoesn't change what I was trying to say with my example. One of the\nrepositories would \"win\" (the names it published during the fork would\nstill be valid). And the other repository would \"lose\" (the names it\npublished would be not valid anymore). Right?\n\nNow, maybe there's some \"simple\" mapping from old names to new names\nfor the losing repository, (something like adding a prefix of\n\"losers/\" to the beginning of the names or something or adding a \"15.\"\nprefix or whatever). The point is that the old names are\ninvalidated. And there's no way to guarantee this kind of change won't\nhappen in the future, (no matter how old a project is).\n\nI constructed that example to show that the naming has a social impact\nin forcing a distinction between winners and losers in the merge, (or\nmainline and side branch, or whatever you want to name the\ndistinction). The two re-joining projects could be really amiable,\ncreate a new virgin mainline and treat both histories as side\nbranches. In this version, everyone loses as all the old names are\ninvalidated.\n\n> Bazaar encourages you to stick lots and lots of branches in your\n> repository. They don't even have to be related. For example, my repo\n> contains branches of bzr, bzrtools, Meld, and BazaarInspect.\n\nGit allows this just fine. And lots of branches belonging to a single\nproject is definitely the common usage. It is not common (nor\nencouraged) for unrelated projects to share a repository, since a git\nclone will fetch every branch in the repository. common for a single\nbase URL to provide a common basis for a hierarchy of git\nrepositories, (see, for example http://repo.or.cz/), and that may\nprovide similar benefits.\n\nI'm noticing another terminology conflict here. The notion of \"branch\"\nin bzr is obviously very different than in git. For example the bzr\nman page has a sentence beginning with \"if there is already a branch\nat the location but it has no working tree\". I'm still not sure\nexactly what a bzr branch is, but it's clearly something different\nfrom a git branch, (which is absolutely nothing more than a name\nreferencing a particular commit object). [Note: after playing with it\na bit more down below, a bzr \"branch\" appears to be something like a\ngit \"repository\" that can only hold a single branch.]\n\n> I can see where you're coming from, but to me, the trade-off seems\n> worthwhile. Because historical data gets less and less valuable the\n> older it gets. By the time the URL for a branch goes dark, there's\n> unlikely to be any reason to refer to one of its revisions at all.\n\nI strongly disagree on this point. One, I don't think that the \"time\nfor a branch to go dark\" is necessarily long, (or if it is, then\nthat's another barrier that's setup against distributed\ndevelopment---people have to have a long-term repository before they\ncan usefully start publishing a branch). Second, I'm not comfortable\nwith any limit on usefulness of history. Would you willingly throw\naway commits, mailing list posts, or closed bug reports older than any\ngiven age for any projects that you care about?\n\n> When you create a new branch from scratch, the number starts at zero.\n> If you copy a branch, you copy its number, too.\n>\n> Every time you commit, the number is incremented. If you pull, your\n> numbers are adjusted to be identical to those of the branch you pulled from.\n>\n> Is that really complicated?\n\nOK. So now I had to actually try things out. I went ahead and\ninstalled bzr and was able to init and commit from the man page. I had\nto go to IRC to figure out how to create and change branches, (the\ndocumentation for \"bzr branch\" just said FROM_LOCATION and TO_LOCATION\nand I couldn't figure out what to pass for those).\n\nHere's the setup I came up with for a tweaked version of the a[bc]m\ndiamond example I showed with git earlier, (I just added a second\ncommit to each branch before merging):\n\n\tmkdir bzrtest; cd bzrtest\n\tmkdir master; cd master; bzr init\n\ttouch a; bzr add a; bzr commit -m \"Initial commit of a\"\n\tcd ..\n\tbzr branch master b; cd b\n\ttouch b; bzr add b; bzr commit -m \"Commit b on b branch\"\n\techo \"change\" > b; bzr commit -m \"Change b on b branch\"\n\tcd ..\n\tbzr branch master c; cd c\n\ttouch c; bzr add c; bzr commit -m \"Commit c on c branch\"\n\techo \"change\" > c; bzr commit -m \"Change c on c branch\"\n\tcd ../master\n\tbzr merge ../b; bzr commit -m \"Merge in b\"\n\tbzr merge ../c; bzr commit -m \"Merge in c\"\n\nFirst, I've been told that this is a lot less efficient than possible\nsince I have what in bzr terms is three unshared \"branches\" here,\n(what git would really call three separate \"repositories\").\n\nSecond, I think that using the filesystem for separating branches is a\nreally bad idea. One, it intrudes on my branch namespace, (note that\nin many commands above I have to use things like \"../b\" where I'd like\nto just name my branch \"b\". Two, it prevents bzr from having any\nnotion of \"all branches\" in places where git takes advantage of it,\n(such as git-clone and \"gitk --all\"). Three, it certainly encourages\nthe storage problem I ran into above, (and I'd be interested to see a\n\"corrected\" version of the commands above to fix the storage\ninefficiencies).\n\nBut anyway, those are all new topics, what we were trying to talk\nabout is revision numbers. After the above commands I can run bzr log\nin my three branches, master, b, and c and I get the following\nrevision number sequences:\n\nmaster: 1 2 3\nb: 1 2 3\nc: 1 2 3\n\nAnd from this state if I ask questions with bzr missing and look at\njust the revision numbers, then the answers are useless. I get answers\nlike:\n\n\t.../b:$ bzr missing ../c\n\tYou have 2 extra revision(s):\n\trevno: 3\n\t Change b on b branch\n\trevno: 2\n\t Commit b on b branch\n\n\tYou are missing 2 revision(s):\n\trevno: 3\n\t Change c on c branch\n\trevno: 2\n\t Commit c on c branch\n\n\t.../b:$ bzr missing ../master\n\tYou are missing 2 revision(s):\n\trevno: 3\n\t Merge in c\n\trevno: 2\n\t Merge in b\n\nSo there we have the revision numbers 2 and 3 each being used to name\nthree different revisions. That's a lot of aliasing already.\nThen, if the b and c branches each treat master as their mainline and\neach pull, then both branches get their numbers all shuffled.\n\nOh, drat. I just realized that I'm running 0.11 here which doesn't\nhave the dotted-decimal numbers. (I'm trying to get bzr.dev too, but\nit appears to be stuck about 40% of the way through \"Fetch phase\n1/4\" [Note: it ). In this version, the commits brought in as part of a merge\ndon't get any \"simple\" number at all and instead \"bzr log\" shows a\nmerge ID.\n\nI hadn't realized that the dotted decimal notation was so new that the\ncommunity hadn't had a lot of experience with it yet. But, your\ndescription doesn't actually presume that notation. What you asked\nwas:\n\n\t> When you create a new branch from scratch, the number starts at zero.\n\t> If you copy a branch, you copy its number, too.\n\t>\n\t> Every time you commit, the number is incremented. If you pull, your\n\t> numbers are adjusted to be identical to those of the branch you pulled from.\n\t>\n\t> Is that really complicated?\n\nAnd to answer. That description doesn't describe at all what happens\nto the \"simple\" numbers of commits that are merged. In the version I\nhave, they disappear and get replaced with \"ugly\" numbers. In 0.12\nsomething else happens instead, (that's the part I don't understand\nyet).\n\nAnd my argument isn't just \"confusing\" it's \"confusing or\nuseless\". I understand that pull destroys numbers, and how, but that\nmakes the numbers I had generated earlier useless. I still don't\nunderstand how people can avoid number changing, (since pull seems the\nonly way to synch up without infinite new merge commits being added\nback and forth).\n\nSo, yes, it really is complicated or my brain is just too small.\n\n> > The naming in git really is beautiful and beautifully simple.\n>\n> Well, you've got to admit that those names are at least superficially ugly.\n\nSure. But I'll gladly take a simple system with superficial warts than\na complex system with superficial beauty.\n\n> What's nice is being able see the revno 753 and knowing that \"diff -r\n> 752..753\" will show the changes it introduced. Checking the revo on a\n> branch mirror and knowing how out-of-date it is.\n\nWith git I get to see a revision number of b62710d4 and know that\n\"diff b62710d4^ b62710d4\" will show its changes, though much more\nlikely just \"show b62710d4\". I really cannot fathom a place where\narithmetic on revision numbers does something useful that git revision\nspecifications don't do just as easily. Anybody have an example for\nme?\n\n-Carl\n\nPS. The \"bzr branch\" of bzr.dev did eventually finish. I can see the\ndotted-decimal numbers in my example now, (1.1.1 and 1.2.2 for the\ncommits that came from branch b; 1.2.1 and 1.2.2 for the commits that\ncame from branch c). At 5 characters a piece these are well on their\nway to getting just as \"ugly\" as git names, (once it's all\ncut-and-paste the difference in ugliness is negligible).\n\nAnd now, I see it's not just pull that does number rewriting. If I use\nthe following command (after the chunk of commands above):\n\n\tcd ..; bzr branch -r 1.2.2 master 1.2.2\n\nIt appears to just create newly linearized revision numbers from whole\ncloth for the new branch (1, 2, and 3 corresponding to mainline 1,\n1.2.1, and 1.2.2). That's totally surprising, very confusing, and\nwould invalidate any use I wanted to make of published revision\nnumbers for the mainline branch while I was working on this branch.\n\nSee? This stuff really doesn't work.\n\nMotivating scenario for the above: Imagine 1.2.3 commited garbage so I\nwant to fix it by branching from 1.2.2 rather than the mainline\n\"2\". Then after I branch, I learn something about \"1.2.1\" that I want\nto investigate more closely. I try to inspect that in my branch, but\nouch! I don't have that revision.\n\nIs there even a way to say \"show me the change introduced by what is\nnamed '1.2.1' in the source branch in this scenario\" ?\n\nNote: In #bzr I just learned that there is a way for me to do this\n_if_ I also happen to have a pull of the original branch somewhere on\nmy machine. Something like:\n\n\tbzr diff -r1.2.0:../master -r1.2.1:../master\n\nI don't know if there's a way to get diff's .. notation to work with\nthat, (I can't manage to). But these simple numbers are getting less\nsimple all the time.\n\nWith git, if I find a revision number somewhere, I can cut-and-paste\nit and get the right thing:\n\n\tgit show b62710d4f8602203d848daf2d444865b611fff09\n\nBut with bzr if I find \"1.2.1\" somewhere I'm likely to type:\n\n\tbzr diff -r1.2.0..1.2.1\n\nIf I'm lucky, then that fails with:\n\n\tbzr: ERROR: Requested revision: '1.2.0' does not exist in branch:\n\nand I go back to the source, find out what branch it was referring to,\nremember where that is on my machine (../master, say), and manually\ntype that to my command line to get:\n\n\tbzr diff -r1.2.0:../master -r1.2.1:../master\n\nIf I'm unlucky then the first diff comes up with some unrelated commit\nand I get to be confused before I go through that same process.\n\nNow do you see? It really, really does not work. This stuff is about\nas un-simple as could be, and this things will happen."},{"id":"29427","messageId":"1161382416.9241.19.camel@localhost.localdomain","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201133260.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jeff Licquia","fromEmail":"jeff@licquia.org","sentAt":"2006-10-20T22:13:36Z","receivedAt":"2006-10-20T22:13:36Z","isPatch":false,"sender":{"key":"jeff@licquia.org","avatar":null},"body":"On Fri, 2006-10-20 at 11:48 -0700, Linus Torvalds wrote:\n> Here's a real-life schenario that we hit several times with BK over the \n> years:\n> \n> - take a real repository, and a patch that gets discussed that adds a new \n> file.\n> - take two different people applying that patch to their trees (or, do \n> the equivalent thing, which is to just create the same filename\n> independently, because the solution is obvious - and the same - to \n> both developers).\n> - now, have somebody merge both of those two peoples trees (eg me)\n> - have the two people continue to use their trees, modifying it, and \n> getting merged.\n> \n> Trust me, this isn't even _unlikely_. It happens. And it's a serious \n> problem for a file-ID case. Why? Because you have two different file ID's \n> for the same pathname. \n\nI tried this to see what bzr would do. Here's the critical point where\nthe first merges are done (\"a\" is mainline, \"b\" and \"c\" are external\nbranches being merged into \"a\").\n\n---\njeff@lsblap:~/tmp/linus-file-id/a$ bzr pull ../b\nAll changes applied successfully.\n1 revision(s) pulled.\njeff@lsblap:~/tmp/linus-file-id/a$ bzr pull ../c\nbzr: ERROR: These branches have diverged. Use the merge command to reconcile them.\njeff@lsblap:~/tmp/linus-file-id/a$ bzr merge ../c\nConflict adding file file2. Moved existing file to file2.moved.\n1 conflicts encountered.\njeff@lsblap:~/tmp/linus-file-id/a$ bzr status\nadded:\n file2\nrenamed:\n file2 => file2.moved\nconflicts:\n Conflict adding file file2. Moved existing file to file2.moved.\npending merges:\n Jeff Licquia 2006-10-20 commit c of file2\n---\n\nfile2 and file2.moved have identical contents at this point. I fixed it\nby deleting file2.moved, \"bzr resolve file2\", and committing.\n\nAfter this conflict is resolved, merging from b causes conflicts, while\nmerging from c appears to work fine. This continues until b merges from\na (and resolves a conflict in a similar manner to a), at which time\nmerging/pulling works as you'd expect between the branches. Whenever b\nis marked as conflicting before it merges from a, bzr preserves b's\nchanges by moving b's modified file.\n\nAll in all, not ideal, but it seems bzr handles this better than bk.\nCertainly, bzr doesn't silently drop anyone's changes, at least. I\nsuspect that bzr could improve its handling of this use case, but not,\nI'm sure, to Linus's specifications; some of the fun and games does seem\nto come from the use of file IDs.\n"},{"id":"29429","messageId":"20061020224030.GL20017@pasky.or.cz","threadId":"5925","inReplyTo":"4538EC8F.7020502@utoronto.ca","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-20T22:40:30Z","receivedAt":"2006-10-20T22:40:30Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Oct 20, 2006 at 05:34:39PM CEST, I got a letter\nwhere Aaron Bentley said that...\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> Jakub Narebski wrote:\n> > Aaron Bentley wrote:\n> >>In Bazaar bundles, the text of the diff is an integral part of the data.\n> >> It is used to generate the text of all the files in the revision.\n> > \n> > \n> > I thought that the diff was combined diff of changes.\n> \n> It is. It's a description of how to produce revision X given revision\n> Y, where Y is the last-merged mainline revision.\n\nAha, so by default a bundle can carry just a _single_ revision?\n\nThat doesn't sound right either, because then it wouldn't make sense to\ntalk about \"combined\" or \"simple\" diffs. So I guess sending a bundle\nreally is taking n revisions at your side, bundling them to a single\ndiff and when the other side takes it, it will result in a single\nrevision? That is basically what our merge --squash does.\n\nHmm, but that doesn't sound right either, that's certainly no revolting\nfunctionality and seems to be in contradiction with previous bundles\ndescription. But if it doesn't squash the changes, I don't see how the\ncombined diff can be integral part of the data. Sorry, I don't get it.\n\n> The bundle format can also support sending a single bundles that\n> displays the series of patches, though there's currently no UI to select\n> this.\n..snip..\n> > I was under an impression that user sees only mega-patch of all the\n> > revisions in bundle together, and rest is for machine consumption only.\n> \n> All of it is for machine consumption. The MIME-encoded sections are a\n> series of patches. They're usually MIME-encoded to avoid confusion with\n> the overview patch, but this is optional.\n> \n> I've attached an example of what a combined patch-by-patch bundle looks\n> like.\n\nBut that's the one there's no UI to select? Or where is the combined\ndiff?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i\n---\n\n * This comes on top of \"next\". The next one makes output from\n \"pickaxe -C commit\" actually make sense.\n\n builtin-pickaxe.c | 71 +++++++++++++++++++++++++++++++++++-----------------\n 1 files changed, 48 insertions(+), 23 deletions(-)\n\ndiff --git a/builtin-pickaxe.c b/builtin-pickaxe.c\nindex 74c7c9a..3c73d82 100644\n--- a/builtin-pickaxe.c\n+++ b/builtin-pickaxe.c\n@@ -34,8 +34,7 @@ static int longest_file;\n static int longest_author;\n static int max_orig_digits;\n static int max_digits;\n-\n-#define DEBUG 0\n+static int max_score_digits;\n \n #define PICKAXE_BLAME_MOVE\t\t01\n #define PICKAXE_BLAME_COPY\t\t02\n@@ -78,6 +77,11 @@ struct blame_entry {\n \t * suspect's file; internally all line numbers are 0 based.\n \t */\n \tint s_lno;\n+\n+\t/* how significant this entry is -- cached to avoid\n+\t * scanning the lines over and over\n+\t */\n+\tunsigned score;\n };\n \n struct scoreboard {\n@@ -215,9 +219,6 @@ static void process_u_diff(void *state_,\n \tstruct chunk *chunk;\n \tint off1, off2, len1, len2, num;\n \n-\tif (DEBUG)\n-\t\tfprintf(stderr, \"%.*s\", (int) len, line);\n-\n \tnum = state->ret->num;\n \tif (len < 4 || line[0] != '@' || line[1] != '@') {\n \t\tif (state->hunk_in_pre_context && line[0] == ' ')\n@@ -295,10 +296,6 @@ static struct patch *get_patch(struct or\n \tchar *blob_p, *blob_o;\n \tstruct patch *patch;\n \n-\tif (DEBUG) fprintf(stderr, \"get patch %.8s %.8s\\n\",\n-\t\t\t sha1_to_hex(parent->commit->object.sha1),\n-\t\t\t sha1_to_hex(origin->commit->object.sha1));\n-\n \tblob_p = read_sha1_file(parent->blob_sha1, type,\n \t\t\t\t(unsigned long *) &file_p.size);\n \tblob_o = read_sha1_file(origin->blob_sha1, type,\n@@ -352,6 +349,7 @@ static void dup_entry(struct blame_entry\n \tmemcpy(dst, src, sizeof(*src));\n \tdst->prev = p;\n \tdst->next = n;\n+\tdst->score = 0;\n }\n \n static const char *nth_line(struct scoreboard *sb, int lno)\n@@ -448,7 +446,7 @@ static void split_blame(struct scoreboar\n \t\tadd_blame_entry(sb, new_entry);\n \t}\n \n-\tif (DEBUG) {\n+\tif (1) { /* sanity */\n \t\tstruct blame_entry *ent;\n \t\tint lno = 0, corrupt = 0;\n \n@@ -530,12 +528,6 @@ static int pass_blame_to_parent(struct s\n \tfor (i = 0; i < patch->num; i++) {\n \t\tstruct chunk *chunk = &patch->chunks[i];\n \n-\t\tif (DEBUG)\n-\t\t\tfprintf(stderr,\n-\t\t\t\t\"plno = %d, tlno = %d, \"\n-\t\t\t\t\"same as parent up to %d, resync %d and %d\\n\",\n-\t\t\t\tplno, tlno,\n-\t\t\t\tchunk->same, chunk->p_next, chunk->t_next);\n \t\tblame_chunk(sb, tlno, plno, chunk->same, target, parent);\n \t\tplno = chunk->p_next;\n \t\ttlno = chunk->t_next;\n@@ -547,14 +539,37 @@ static int pass_blame_to_parent(struct s\n \treturn 0;\n }\n \n-static void copy_split_if_better(struct blame_entry best_so_far[3],\n+static unsigned ent_score(struct scoreboard *sb, struct blame_entry *e)\n+{\n+\tunsigned score;\n+\tconst char *cp, *ep;\n+\n+\tif (e->score)\n+\t\treturn e->score;\n+\n+\tscore = 0;\n+\tcp = nth_line(sb, e->lno);\n+\tep = nth_line(sb, e->lno + e->num_lines);\n+\twhile (cp < ep) {\n+\t\tunsigned ch = *((unsigned char *)cp);\n+\t\tif (isalnum(ch))\n+\t\t\tscore++;\n+\t\tcp++;\n+\t}\n+\te->score = score;\n+\treturn score;\n+}\n+\n+static void copy_split_if_better(struct scoreboard *sb,\n+\t\t\t\t struct blame_entry best_so_far[3],\n \t\t\t\t struct blame_entry this[3])\n {\n \tif (!this[1].suspect)\n \t\treturn;\n-\tif (best_so_far[1].suspect &&\n-\t (this[1].num_lines < best_so_far[1].num_lines))\n-\t\treturn;\n+\tif (best_so_far[1].suspect) {\n+\t\tif (ent_score(sb, &this[1]) < ent_score(sb, &best_so_far[1]))\n+\t\t\treturn;\n+\t}\n \tmemcpy(best_so_far, this, sizeof(struct blame_entry [3]));\n }\n \n@@ -596,7 +611,7 @@ static void find_copy_in_blob(struct sco\n \t\t\t\t tlno + ent->s_lno, plno,\n \t\t\t\t chunk->same + ent->s_lno,\n \t\t\t\t parent);\n-\t\t\tcopy_split_if_better(split, this);\n+\t\t\tcopy_split_if_better(sb, split, this);\n \t\t}\n \t\tplno = chunk->p_next;\n \t\ttlno = chunk->t_next;\n@@ -699,7 +714,7 @@ static int find_copy_in_parent(struct sc\n \t\t\t\tcontinue;\n \t\t\t}\n \t\t\tfind_copy_in_blob(sb, ent, norigin, this, &file_p);\n-\t\t\tcopy_split_if_better(split, this);\n+\t\t\tcopy_split_if_better(sb, split, this);\n \t\t}\n \t\tif (split[1].suspect)\n \t\t\tsplit_blame(sb, split, ent);\n@@ -944,6 +959,7 @@ #define OUTPUT_RAW_TIMESTAMP\t004\n #define OUTPUT_PORCELAIN\t010\n #define OUTPUT_SHOW_NAME\t020\n #define OUTPUT_SHOW_NUMBER\t040\n+#define OUTPUT_SHOW_SCORE 0100\n \n static void emit_porcelain(struct scoreboard *sb, struct blame_entry *ent)\n {\n@@ -1016,6 +1032,8 @@ static void emit_other(struct scoreboard\n \t\t\t\t\t show_raw_time),\n \t\t\t ent->lno + 1 + cnt);\n \t\telse {\n+\t\t\tif (opt & OUTPUT_SHOW_SCORE)\n+\t\t\t\tprintf(\" %*d\", max_score_digits, ent->score);\n \t\t\tif (opt & OUTPUT_SHOW_NAME)\n \t\t\t\tprintf(\" %-*.*s\", longest_file, longest_file,\n \t\t\t\t suspect->path);\n@@ -1060,8 +1078,9 @@ static void output(struct scoreboard *sb\n \tfor (ent = sb->ent; ent; ent = ent->next) {\n \t\tif (option & OUTPUT_PORCELAIN)\n \t\t\temit_porcelain(sb, ent);\n-\t\telse\n+\t\telse {\n \t\t\temit_other(sb, ent, option);\n+\t\t}\n \t}\n }\n \n@@ -1118,6 +1137,7 @@ static void find_alignment(struct scoreb\n {\n \tint longest_src_lines = 0;\n \tint longest_dst_lines = 0;\n+\tunsigned largest_score = 0;\n \tstruct blame_entry *e;\n \n \tfor (e = sb->ent; e; e = e->next) {\n@@ -1143,9 +1163,12 @@ static void find_alignment(struct scoreb\n \t\tnum = e->lno + e->num_lines;\n \t\tif (longest_dst_lines < num)\n \t\t\tlongest_dst_lines = num;\n+\t\tif (largest_score < ent_score(sb, e))\n+\t\t\tlargest_score = ent_score(sb, e);\n \t}\n \tmax_orig_digits = lineno_width(longest_src_lines);\n \tmax_digits = lineno_width(longest_dst_lines);\n+\tmax_score_digits = lineno_width(largest_score);\n }\n \n static int has_path_in_work_tree(const char *path)\n@@ -1206,6 +1229,8 @@ int cmd_pickaxe(int argc, const char **a\n \t\t\t\ttmp = top; top = bottom; bottom = tmp;\n \t\t\t}\n \t\t}\n+\t\telse if (!strcmp(\"--score-debug\", arg))\n+\t\t\toutput_option |= OUTPUT_SHOW_SCORE;\n \t\telse if (!strcmp(\"-f\", arg) ||\n \t\t\t !strcmp(\"--show-name\", arg))\n \t\t\toutput_option |= OUTPUT_SHOW_NAME;\n-- \n1.4.3.ge193\n"},{"id":"29431","messageId":"7vpscmmwz2.fsf_-_@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"7v1wp2oi6s.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH 2/2] git-pickaxe: introduce heuristics to avoid \"trivial\" chunks","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-20T22:41:21Z","receivedAt":"2006-10-20T22:41:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This adds scoring logic to blame_entry to prevent blames on very\ntrivial chunks (e.g. lots of empty lines, indent followed by a\nclosing brace) from being passed down to unrelated lines in the\nparent.\n\nThe current heuristics are quite simple and may need to be\ntweaked later, but we need to start from somewhere.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-pickaxe.c | 36 ++++++++++++++++++++++++++++++++----\n 1 files changed, 32 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin-pickaxe.c b/builtin-pickaxe.c\nindex 3c73d82..49673a5 100644\n--- a/builtin-pickaxe.c\n+++ b/builtin-pickaxe.c\n@@ -40,6 +40,15 @@ #define PICKAXE_BLAME_MOVE\t\t01\n #define PICKAXE_BLAME_COPY\t\t02\n #define PICKAXE_BLAME_COPY_HARDER\t04\n \n+/*\n+ * blame for a blame_entry with score lower than these threasholds\n+ * is not passed to the parent using move/copy logic.\n+ */\n+static unsigned blame_move_score;\n+static unsigned blame_copy_score;\n+#define BLAME_DEFAULT_MOVE_SCORE\t20\n+#define BLAME_DEFAULT_COPY_SCORE\t40\n+\n /* bits #0..7 in revision.h, #8..11 used for merge_bases() in commit.c */\n #define METAINFO_SHOWN\t\t(1u<<12)\n #define MORE_THAN_ONE_PATH\t(1u<<13)\n@@ -645,7 +654,8 @@ static int find_move_in_parent(struct sc\n \t\tif (ent->suspect != target || ent->guilty)\n \t\t\tcontinue;\n \t\tfind_copy_in_blob(sb, ent, parent, split, &file_p);\n-\t\tif (split[1].suspect)\n+\t\tif (split[1].suspect &&\n+\t\t blame_move_score < ent_score(sb, &split[1]))\n \t\t\tsplit_blame(sb, split, ent);\n \t}\n \tfree(blob_p);\n@@ -716,7 +726,8 @@ static int find_copy_in_parent(struct sc\n \t\t\tfind_copy_in_blob(sb, ent, norigin, this, &file_p);\n \t\t\tcopy_split_if_better(sb, split, this);\n \t\t}\n-\t\tif (split[1].suspect)\n+\t\tif (split[1].suspect &&\n+\t\t blame_copy_score < ent_score(sb, &split[1]))\n \t\t\tsplit_blame(sb, split, ent);\n \t}\n \tdiff_flush(&diff_opts);\n@@ -1177,6 +1188,15 @@ static int has_path_in_work_tree(const c\n \treturn !lstat(path, &st);\n }\n \n+static unsigned parse_score(const char *arg)\n+{\n+\tchar *end;\n+\tunsigned long score = strtoul(arg, &end, 10);\n+\tif (*end)\n+\t\treturn 0;\n+\treturn score;\n+}\n+\n int cmd_pickaxe(int argc, const char **argv, const char *prefix)\n {\n \tstruct rev_info revs;\n@@ -1206,12 +1226,15 @@ int cmd_pickaxe(int argc, const char **a\n \t\t\toutput_option |= OUTPUT_LONG_OBJECT_NAME;\n \t\telse if (!strcmp(\"-S\", arg) && ++i < argc)\n \t\t\trevs_file = argv[i];\n-\t\telse if (!strcmp(\"-M\", arg))\n+\t\telse if (!strncmp(\"-M\", arg, 2)) {\n \t\t\topt |= PICKAXE_BLAME_MOVE;\n-\t\telse if (!strcmp(\"-C\", arg)) {\n+\t\t\tblame_move_score = parse_score(arg+2);\n+\t\t}\n+\t\telse if (!strncmp(\"-C\", arg, 2)) {\n \t\t\tif (opt & PICKAXE_BLAME_COPY)\n \t\t\t\topt |= PICKAXE_BLAME_COPY_HARDER;\n \t\t\topt |= PICKAXE_BLAME_COPY | PICKAXE_BLAME_MOVE;\n+\t\t\tblame_copy_score = parse_score(arg+2);\n \t\t}\n \t\telse if (!strcmp(\"-L\", arg) && ++i < argc) {\n \t\t\tchar *term;\n@@ -1249,6 +1272,11 @@ int cmd_pickaxe(int argc, const char **a\n \t\t\targv[unk++] = arg;\n \t}\n \n+\tif (!blame_move_score)\n+\t\tblame_move_score = BLAME_DEFAULT_MOVE_SCORE;\n+\tif (!blame_copy_score)\n+\t\tblame_copy_score = BLAME_DEFAULT_COPY_SCORE;\n+\n \t/* We have collected options unknown to us in argv[1..unk]\n \t * which are to be passed to revision machinery if we are\n \t * going to do the \"bottom\" procesing.\n-- \n1.4.3.ge193\n"},{"id":"29432","messageId":"200610210050.32254.jnareb@gmail.com","threadId":"5925","inReplyTo":"a7e835d40610200759h49859a20k8a409fe34f68630a@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T22:50:31Z","receivedAt":"2006-10-20T22:50:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 20-10-2006, James Henstridge wrote:\n> On 20/10/06, Jakub Narebski wrote:\n>> James Henstridge wrote:\n\n>>> With the above layout, I would just type:\n>>> bzr branch http://server/repo/branch1\n>>\n>> With Cogito (you can think of it either as alternate Git UI, or as SCM\n>> built on top of Git) you would use\n>>\n>> $ cg clone http://server/repo#branch\n>>\n>> for example\n>>\n>> $ cg clone git://git.kernel.org/pub/scm/git/git.git#next\n>>\n>> to clone _single_ branch (in bzr terminology, \"heavy checkout\" of branch).\n> \n> My understanding of git is that this would be equivalent to the \"bzr\n> branch\" command. A checkout (heavy or lightweight) has the property\n> that commits are made to the original branch.\n\nNot exactly (my mistake in explaining it). \"cg clone git://host/repo@branch\"\nclones only part of history DAG of commits reachable from given branch.\nStill it is full repository. You can add branches to it later with\ncg-branch-add and fetch changes with cg-fetch.\n\n>> But you can also clone _whole_ repository, _all_ published branches with\n>>\n>> $ cg clone git://git.kernel.org/pub/scm/git/git.git\n> \n> I suppose that'd be useful if you want a copy of all the branches at\n> once. There is no builtin command in Bazaar to do that at present.\n\nThat is _very_ useful. And that is default option for Git. For\nexample with git.git repository I'm interested both in 'master'\nbranch (main line of development), and in 'next' branch (development\nbranch). For example I send some patches, based on 'master', they\nget accepted but in 'next' (to cook for a while for example), and\nI want to do further work in this direction I have to base my\nnew work on 'next' branch.\n\nIt looks like the Bazaar-NG \"branches\" are equivalent of the\none-branch-clone of Git.\n\nAnd if there is no command to clone whole repository, how\nyou do public repository?\n\nSee below.\n\n[...] \n> Two points:\n> (1) if we are publishing branches, we wouldn't include working trees\n> -- they are not needed to pull or merge from such a branch.\n\nSame with Git. Public repositories are usually \"bare\" clones, i.e.\nwithout working directory. We can clone/fetch from \"clothed\" repo\nwithout problem - we just have to point to .git.\n\n> (2) if we did have working trees, they'd be rooted at /repo/branch1\n> and /repo/branch2 -- not at /repo (since /repo is not a branch).\n\nThat's explains it.\n\n> In case (2) there is a potential for conflicts if you nest branches,\n> but people don't generally trigger this problem with the way they use\n> Bazaar.\n\nThere is no problem in Git to have git repository nested within\nworking area: of course you better ignore .git directory; you can\nignore files in this embedded repository or not.\n\n[...]\n>> How checked out working area looks like in Bazaar-NG?\n> \n> The layout of a standalone branch would be:\n> .bzr/repository/ -- storage of trees and metadata\n> .bzr/branch/ -- branch metadagta (e.g. pointer to the head revision)\n> .bzr/checkout/ -- working tree book-keeping files\n> source code\n\nThe layout of git repository (git clone, as it is equivalent of bzr branch)\nyou have the following layout:\n .git/objects/ -- repository objects database\n .git/refs/ -- heads (branches) and tags\n .git/index -- staging area for commit (adding files, merge resolving)\n .git/HEAD -- which branch is current branch\n source code\n\n> If we use a shared repository, the contained branches would lack the\n> .bzr/repository/ directory. The parent directory would instead have a\n> .bzr/repository/, but usually wouldn't have .bzr/branch/ (unless there\n> is a branch rooted at the base of the repository).\n\nThe equivalent of shared repository would be having .git/objects/\nto be symlink to some directory which would serve as common area\nto store object database.\n\nYou can use alternates file: .git/objects/info/alternates can have\nlist of absolute pathnames (one per line) where objects can be found\ninstead. If I understand correctly new objects gets commited to current\nrepository object database, therefore to have equivalent of symlinking\n.git/objects directory you would have for every repository which you\nwant to share object database to have in alternates file all repositories\nexcept self. \n\nOr you can use GIT_ALTERNATE_OBJECT_DIRECTORIES environmental variable.\n\nRepository using any kind of alternates mechanism is not suitable\nto publish using \"dumb\" (non-git-aware) transports.\n\n> if we are publishing a branch to a web server, we'd skip the working\n> tree, so the source code and .bzr/checkout/ directory would be\n> missing.\n\nFor \"bare\" clone only 'source files' would be missing. Well, perhaps\nalso '.git/index' but I'm not sure.\n\n> In the case of a checkout, the .bzr/branch/ directory has a special\n> format and acts as a pointer to the original branch. If the checkout\n> is lightweight, the .bzr/repository/ directory would be missing, and\n> bzr would need to contact the original branch for the data.\n\nThere is no equivalent for bzr \"checkout\" (and could you please use\nother name for that, like \"lazy branch\"?) in Git. There was some talk\nabout how to do \"lazy clone\"/\"remote alternates\" in Git, but no consensus\nwas reached about how to do this effectively, and for both \"dumb\"\n(http, https, ftp, rsync) transports and git-aware (local, git, ssh+git)\ntransports. From what I've read Bazaar-NG doesn't try the \"effective\"\npart...\n\n[...]\n>> Yes, but using Git that way has serious disadvantages. For example\n>> there is only one current branch pointer and only one index (dircache)\n>> per git repository.\n> \n> Okay. So using Bazaar terminology, this seems to be an issue of the\n> working tree being associated with the repository rather than the\n> branch?\n \nFrom the point of view of Git users, there is (in Bazaar-NG) an issue\nof working tree being associated with the individual branch rather than\nrepository.\n\nIn git to work on some project you clone its repository; in bzr to\nwork on some project you get one of its branches.\n\n\nIMVHO if \"Cheap Branching Anywhere\" was changed to \"Lightweight Branches\"\nthen Bazaar-NG would have to put \"Partial\" in there. Unless you setup\nyour branches to share data, branches are not cheap (in the sense of\ndisk space). That's probably the cause for _need_ for \"checkouts\".\nBazaar-NG doesn't encourage using temporary branches, with\nlifespan no longer than day. Can you ever switch between branches\nusing only one working area; can you do it fast?\n\nIt looks somewhat like bzr started without permanent branches, and\nthey were added later (sharing repository data). But I might be mistaken.\n\nP.S. what Git lacks at least now is a way to generate diff between\ntwo different local repositories, but you can always setup alternates\nfile and fetch the other repository into some tag.\n-- \nJakub Narebski\nPoland\n"},{"id":"29433","messageId":"20061020225803.GM20017@pasky.or.cz","threadId":"5925","inReplyTo":"200610210050.32254.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-20T22:58:03Z","receivedAt":"2006-10-20T22:58:03Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Oct 21, 2006 at 12:50:31AM CEST, I got a letter\nwhere Jakub Narebski said that...\n> P.S. what Git lacks at least now is a way to generate diff between\n> two different local repositories, but you can always setup alternates\n> file and fetch the other repository into some tag.\n\nIt's not exactly convenient, but you can do\n\n\txpasky@machine[0:0]~/git$ GIT_ALTERNATE_OBJECT_DIRECTORIES=../cogito/.git/objects cg-diff -r `GIT_DIR=../cogito/.git cg-object-id -c HEAD`..HEAD\n\nI don't personally think it's worth a special UI, but there're no\nboundaries for initiative... :-)\n"},{"id":"29434","messageId":"20061020225917.GA30584@coredump.intra.peff.net","threadId":"5925","inReplyTo":"20061020181210.GA29843@artax.karlin.mff.cuni.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-20T22:59:17Z","receivedAt":"2006-10-20T22:59:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 20, 2006 at 08:12:10PM +0200, Jan Hudec wrote:\n\n> At this point, I expect the tree to look like this:\n> A$ ls -R\n> .:\n> data/\n> data:\n> hello.txt\n> A$ cat data/hello.txt\n> Hello World!\n\nGit does what you expect here.\n\n> A$ VCT mv data greetings\n> A$ VCT commit -m \"Renamed the data directory to greetings\"\n> B$ echo \"Goodbye World!\" > data/goodbye.txt\n> B$ VCT add data/goodbye.txt\n> B$ VCT commit -m \"Added goodbye message.\"\n> A$ VCT merge B\n> \n> And now I expect to have tree looking like this:\n> \n> A$ ls -R\n> .:\n> greetings/\n> greetings:\n> hello.txt\n> goodbye.txt\n\nGit does not do what you expect here. It notes that files moved, but it\ndoes not have a concept of directories moving. Git could, even without\nfile-ids or special patch types, figure out what happened by noting that\nevery file in data/ was renamed to its analogue in greetings/, and infer\nthat previously non-existant files in data/ should also be moved to\ngreetings/.\n\nHowever, I'm not sure that I personally would prefer that behavior. In\nsome cases you might actually WANT data/goodbye.txt, and in some other\ncases a conflict might be more appropriate. In any case, I would rather\nthe SCM do the simple and predictable thing (which I consider to be\ncreating data/goodbye.txt) rather than be clever and wrong (even if it's\nonly wrong a small percentage of the time).\n\nIn short, git doesn't do what you expect, but I'm not convinced that\nit's a bug or lack of feature, and not simply a difference in desired\nbehavior.\n\n-Peff\n"},{"id":"29435","messageId":"1161385512.13697.61.camel@localhost.localdomain","threadId":"5925","inReplyTo":"1161382416.9241.19.camel@localhost.localdomain","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Robert Collins","fromEmail":"robertc@robertcollins.net","sentAt":"2006-10-20T23:05:12Z","receivedAt":"2006-10-20T23:05:12Z","isPatch":false,"sender":{"key":"robertc@robertcollins.net","avatar":null},"body":"On Fri, 2006-10-20 at 18:13 -0400, Jeff Licquia wrote:\n> \n> All in all, not ideal, but it seems bzr handles this better than bk.\n> Certainly, bzr doesn't silently drop anyone's changes, at least. I\n> suspect that bzr could improve its handling of this use case, but not,\n> I'm sure, to Linus's specifications; some of the fun and games does\n> seem to come from the use of file IDs. \n\nWe have a few features we're focusing on right now, but coming shortly\nafter them we hope to address parallel imports [which this is a case of]\nbetter than we do now. I have a number of ideas, and I'm sure other devs\ndo too, about the right way to solve this. Fundamentally, I think using\n1-1 mapped path ids [which can be considered a memo of the origin commit\nid + path] of a path is not sufficiently rich a representation of what\nhappens to paths - there is a dual that you can convert to, which is\nidentity via ancestry traversal - each path has N <= M parent paths in\neach of M parent revisions. Our current path ids can only represent the\ncase where when you traverse to the start of history this graph has a\nsingle tail (that is, that a single file must start at one and only one\nplace). The graph however is not intrinsically limited in this way -\nfiles can split and join, and we should be able to represent this more\nfully.\n\nI'll happily acknowledge that we dont need fileids per se: tracking\nrenames can be done without a memo of the origin.\n\nHowever, I'm still convinced that tracking the user intention of renames\nleads to a slicker system than renames via inference. My off the cuff\nlist of corner cases is:\n\n - change file, rename: rename the changed file/change the renamed file.\n - change file, remove: conflict on removal/text change\n - add path to dir, rename the dir: move the current contents of the\ndirectory/add the new path to the renamed directory.\n - move paths out of a directory, rename the directory: leave the paths\nmoved out where they were moved to/move the paths from wherever their\nnew location is.\n - introduce path A + rename old A to B , change path A: change path\nB/rename A to B and introduce the new A.\n\nAll these cases work roughly along the form of 'have two branches, do\none action in one, one in the other: merge other to one/merge one to\nother'. I haven't yet seen an inference system get all these right.\n\nThere are other, more complex cases, but I think they all boil down to\none of those primitives to all intents and purposes.\n\nRob\n-- \nGPG key available at: .\n"},{"id":"29436","messageId":"1161386129.13697.63.camel@localhost.localdomain","threadId":"5925","inReplyTo":"1161385512.13697.61.camel@localhost.localdomain","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Robert Collins","fromEmail":"robertc@robertcollins.net","sentAt":"2006-10-20T23:15:29Z","receivedAt":"2006-10-20T23:15:29Z","isPatch":false,"sender":{"key":"robertc@robertcollins.net","avatar":null},"body":"On Sat, 2006-10-21 at 09:05 +1000, Robert Collins wrote:\n> On Fri, 2006-10-20 at 18:13 -0400, Jeff Licquia wrote:\n> > \n> > All in all, not ideal, but it seems bzr handles this better than bk.\n> > Certainly, bzr doesn't silently drop anyone's changes, at least. I\n> > suspect that bzr could improve its handling of this use case, but not,\n> > I'm sure, to Linus's specifications; some of the fun and games does\n> > seem to come from the use of file IDs. \n...\n> However, I'm still convinced that tracking the user intention of renames\n> leads to a slicker system than renames via inference. My off the cuff\n> list of corner cases is:\n\nI meant to add, that I think inference is a great tool to use as an\nadjunct to whatever explicit data one can capture.\n\n-Rob\n-- \nGPG key available at: .\n"},{"id":"29437","messageId":"7vlknalgne.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"200610201350.12273.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-20T23:19:17Z","receivedAt":"2006-10-20T23:19:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n>> The lack of parents ordering in Git is directly connected with\n>> fast-forwarding.\n>\n> There are exactly _two_ places where Git treats first parent specially \n> (correct me if I'm wrong).\n\nI am not bold enough to say _exactly_ N places, but you missed\nat least one more important one. Merge simplification favors\nthe earlier parents over later ones.\n"},{"id":"29438","messageId":"ehblrq$lh3$1@sea.gmane.org","threadId":"5925","inReplyTo":"1161385512.13697.61.camel@localhost.localdomain","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-20T23:24:51Z","receivedAt":"2006-10-20T23:24:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Robert Collins wrote:\n\n> However, I'm still convinced that tracking the user intention of renames\n> leads to a slicker system than renames via inference.\n\nWell, there was (abandoned for now) idea of rr2-cache, the cache of how\nrenames were resolved during merge conflict resolving.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29439","messageId":"20061020232816.GN20017@pasky.or.cz","threadId":"5925","inReplyTo":"ehblrq$lh3$1@sea.gmane.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-20T23:28:16Z","receivedAt":"2006-10-20T23:28:16Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Oct 21, 2006 at 01:24:51AM CEST, I got a letter\nwhere Jakub Narebski said that...\n> Robert Collins wrote:\n> \n> > However, I'm still convinced that tracking the user intention of renames\n> > leads to a slicker system than renames via inference.\n> \n> Well, there was (abandoned for now) idea of rr2-cache, the cache of how\n> renames were resolved during merge conflict resolving.\n\nIs that really relevant? It rather seems something like rerere, which is\nhandy, but only if you are the one who is actually supposed to have clue\non how should it be resolved; the caches aren't replicated on clones.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Dear diary, on Fri, Oct 20, 2006 at 05:34:39PM CEST, I got a letter\n> where Aaron Bentley said that...\n>> -----BEGIN PGP SIGNED MESSAGE-----\n>> Hash: SHA1\n>>\n>> Jakub Narebski wrote:\n>>> Aaron Bentley wrote:\n>>>> In Bazaar bundles, the text of the diff is an integral part of the data.\n>>>> It is used to generate the text of all the files in the revision.\n>>>\n>>> I thought that the diff was combined diff of changes.\n>> It is. It's a description of how to produce revision X given revision\n>> Y, where Y is the last-merged mainline revision.\n> \n> Aha, so by default a bundle can carry just a _single_ revision?\n\nNo, bundles contain 1 or more revisions. They contain all the ancestors\nof X that are not ancestors of Y.\n\nOnly the diff from X to Y is shown, but the diffs for all other\nrevisions are present in the MIME-encoded section.\n\nConsider these four revisions in a straight-line ancestry: a, b, c, d.\n'a' is a common ancestor. b, c and d are the revisions that are missing\nfrom the target repository.\n\nA default bundle will contain\n\nmetadata for d\ndiff from a -> d in plaintext\nmetadata for c\ndiff from b -> c in MIME encoding\nmetadata for b\ndiff from a -> b in MIME encoding\n\nTo install b, the diff for a->b is applied to a. To install c, the diff\nfor b->c is applied to b. To install d, the diff for a -> d is applied\nto a.\n\nDoing a diff from a -> d instead of from c -> d introduces some\nredundancy, of course. But we do that because we want an overview diff.\n\n> That doesn't sound right either, because then it wouldn't make sense to\n> talk about \"combined\" or \"simple\" diffs. So I guess sending a bundle\n> really is taking n revisions at your side, bundling them to a single\n> diff and when the other side takes it, it will result in a single\n> revision?\n\nNo, it copies the revisions verbatim, and we are careful to avoid data loss.\n\n> Hmm, but that doesn't sound right either, that's certainly no revolting\n> functionality and seems to be in contradiction with previous bundles\n> description. But if it doesn't squash the changes, I don't see how the\n> combined diff can be integral part of the data. Sorry, I don't get it.\n\nIt's because there's no other diff in the bundle that produces 'd'.\n\n>> I've attached an example of what a combined patch-by-patch bundle looks\n>> like.\n> \n> But that's the one there's no UI to select? Or where is the combined\n> diff?\n\nThat is the one that doesn't have UI to select it. I've attached a\nnormal bundle for comparison.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFOVzR0F+nu1YWqI0RAkACAJ4z2SJZgelZLfhoFKhEZbmvRIXMjACfag+h\n6j+5vvIeHt7xMZOvp6CUcPk=\n=33G4\n-----END PGP SIGNATURE-----\n\n\n# Bazaar revision bundle v0.8\n#\n# message:\n# Added 'world'\n# committer: Aaron Bentley \n# date: Fri 2006-10-20 11:30:21.903000116 -0400\n\n=== added directory // file-id:TREE_ROOT\n=== added file world // file-id:world-20061020152929-12bknd8mm9mx48as-1\n--- /dev/null\n+++ world\n@@ -0,0 +1,1 @@\n+Hello, world\n\n# revision id: abentley@panoramicfeedback.com-20061020153021-b5fcea14e9cd2b34\n# sha1: 6d553e72158aaa76c258d98c15cd24922d171cd9\n# inventory sha1: 64af82c4d81d9d6ad4f33fc734d32c2a1eaa0df5\n# parent ids:\n# abentley@panoramicfeedback.com-20061020152951-10cff5ff5a51e9a2\n# base id: null:\n# properties:\n# branch-nick: bar\n\n# message:\n# Capitalized\n# committer: Aaron Bentley \n# date: Fri 2006-10-20 11:29:51.953999996 -0400\n\n=== modified file world // encoding:base64\nLS0tIHdvcmxkCisrKyB3b3JsZApAQCAtMSwxICsxLDEgQEAKLWhlbGxvCitIZWxsbwoK\n\n=== modified directory // last-changed:abentley@panoramicfeedback.com-20061020\n... 152951-10cff5ff5a51e9a2\n# revision id: abentley@panoramicfeedback.com-20061020152951-10cff5ff5a51e9a2\n# sha1: f7b79934bc3b0a944e35168b5df6b106c5b29ebf\n# inventory sha1: 1400d56451752300cc31c9c94ff7ee2188e8ef8c\n# parent ids:\n# abentley@panoramicfeedback.com-20061020152935-64bde004f622131f\n# properties:\n# branch-nick: bar\n\n# message:\n# initial commit\n# committer: Aaron Bentley \n# date: Fri 2006-10-20 11:29:35.536999941 -0400\n\n=== added directory // file-id:TREE_ROOT\n=== added file world // file-id:world-20061020152929-12bknd8mm9mx48as-1 // enco\n... ding:base64\nLS0tIC9kZXYvbnVsbAorKysgd29ybGQKQEAgLTAsMCArMSwxIEBACitoZWxsbwoK\n\n# revision id: abentley@panoramicfeedback.com-20061020152935-64bde004f622131f\n# sha1: 0728f761b891b257f0a71e2e360799eec080cd21\n# inventory sha1: e52e030ea40f6bf5da78f4e8eb8efcd072b0930a\n# properties:\n# branch-nick: bar\n\n"},{"id":"29441","messageId":"1161387547.9241.69.camel@localhost.localdomain","threadId":"5925","inReplyTo":"1161386129.13697.63.camel@localhost.localdomain","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jeff Licquia","fromEmail":"jeff@licquia.org","sentAt":"2006-10-20T23:39:07Z","receivedAt":"2006-10-20T23:39:07Z","isPatch":false,"sender":{"key":"jeff@licquia.org","avatar":null},"body":"On Sat, 2006-10-21 at 09:15 +1000, Robert Collins wrote:\n> I meant to add, that I think inference is a great tool to use as an\n> adjunct to whatever explicit data one can capture.\n\nIf you ask me, that's the most interesting idea in this whole thread.\n"},{"id":"29443","messageId":"Pine.LNX.4.64.0610201630000.3962@g5.osdl.org","threadId":"5925","inReplyTo":"1161382416.9241.19.camel@localhost.localdomain","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-20T23:59:40Z","receivedAt":"2006-10-20T23:59:40Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Jeff Licquia wrote:\n> \n> After this conflict is resolved, merging from b causes conflicts, while\n> merging from c appears to work fine. This continues until b merges from\n> a (and resolves a conflict in a similar manner to a), at which time\n> merging/pulling works as you'd expect between the branches. Whenever b\n> is marked as conflicting before it merges from a, bzr preserves b's\n> changes by moving b's modified file.\n\nThis sounds somewhat like what I think BK did. I'm not sure if BK actually \nmarked it as a conflict or whether BK just warned about \"changes to \ndeleted file\" or something similar, but it didn't entirely _silently_ \nthrow them away.\n\nBut I hope this shows some of the basic problems.\n\nThe much more _serious_ problem of \"file identity\" tracking is actually \nthat you can't track partial file movement or file copies sanely. The \nthing is, tracking things at file boundaries simply is fundamnetally a \nbroken notion, simply because _code_ doesn't get done at file boundaries.\n\nBoth of these things that git can actually do. Admittedly it does not do \nthat in any _released_ version, so you'd have to work with the development \nbranch, and it's a fairly early thing, but currently it can actually \nnotice that our \"revision.c\" file largely came from the \"rev-list.c\" file \nthat still exists!\n\nAnd btw, that's not just some random feature that happened to get \nimplemented last week. Yes, it actually _did_ get implemented last week, \nbut this was something I outlined when I started git in April of last \nyear, and tried to explain to people WHY TRACKING FILE ID'S ARE WRONG!\n\nYou can find me explaining these things to people in April-2005, which \nshould tell you something: the initial revision of \"git\" was on Thursday, \nApril 7. So the lack of file identity tracking has been controversial from \nthe very beginning, but I was right then, and I'm right now.\n\nBecause the _fact_ is, that as long as you track stuff on a file basis, \nyou're _never_ going to be able to do the things that git alreadt does, \nand that are very natural.\n\nHere's the real-world example of something that git CAN DO TODAY:\n\n - we used to have a file called \"rev-list.c\", which did a lot of the \n commit history revision traversal, and is the source of the git command \n \"git rev-list\".\n\n - I (and others) extended it a lot, and turned it into a more generic \n library interface, so that other commands could traverse the commit \n graph on their own, rather than forking and executing \"git-rev-list\" \n and piping the output between them.\n\n - as a result, the old \"rev-list.c\" still exists (except it was renamed \n to \"builtin-rev-list.c\" since it's now a builtin command to the main \n \"git\" binary). \n\n - HOWEVER, a lot of the actual code got split into the library file, \n called \"revision.c\", which contains the real smarts of the program.\n\nSee? There was a file rename involved (rev-list.c => builtin-rev-list.c), \nbut that actually happened after a lot of the really _interesting_ code \nhad been excised from that file, and put into the new internal library \nfile (revision.c).\n\nNow, as a result, in many ways the rename is _much_ less interesting than \nthe question about the history of the code in \"revision.c\" (because that's \nreally some very core code). And that was never a rename at all. That was \njust a file create, where a lot of the contents happened to come from a \nfile that continued to exist.\n\nWouldn't you want \"annotate\" to be able to follow this kind of data \nmovement? Notice how there is no \"file\" that moved at all. Only code that \nmoved between files.\n\nI tell you: as long as you work with \"file ID's\", you'll always be \ninferior. You'll never be able to see that some code was copied \n_partially_ from one file into another. You'll never be able to see an \nimportant function moving between file boundaries.\n\nUnless you work with \"git\", that is. Because git isn't so _stupid_ as to \nthink that file boundaries matter. Git knows better. The only thing that \nmatters is the actual _data_, and file boundaries are just one way of \ndelimiting that data.\n\nJust try it out. Get the \"next\" branch of the git repository (that's the \n\"stable development\" branch in git.git - ie it's going to be in the next \nrelease and is expected to work, unless some of the more \"experimental \ndevelopment\" that is in the \"pu\" branch - pu = proposed updates), compile \nit, and run\n\n\tgit pickaxe -C revision.c | less -S\n\nand marvel. Marvel at my shining intelligence (and the small matter of \nprogramming, which was all done by Junio, but I'm taking all the credit \n_anyway_, because *dammit* I talked about this last year when people \ndidn't understand! And besides, I always take all the credit regardless, \nso what are you whining about? Get off my back!).\n\nMore seriously, Junio really did a kick-ass job. I really had nothing at \nall to do with it, and deserve no real credit. But I _did_ forsee it, and \nyes, it really is about the fact that git tracks _contents_.\n\nAs somebody smarter that I have said (*): \"I'm always right, but this time \nI'm even more right than usual\".\n\n\t\t\tLinus\n\n(*) Just kidding. It was me. Of course.\n"},{"id":"29445","messageId":"Pine.LNX.4.64.0610201702580.3962@g5.osdl.org","threadId":"5925","inReplyTo":"7vlknalgne.fsf@assigned-by-dhcp.cox.net","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-21T00:07:27Z","receivedAt":"2006-10-21T00:07:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Junio C Hamano wrote:\n> \n> I am not bold enough to say _exactly_ N places, but you missed\n> at least one more important one. Merge simplification favors\n> the earlier parents over later ones.\n\nWhich is probably slightly inconsistent (although I seriously doubt \nanybody really cares - when we simplify a merge we obvioously do it \nexactly because the parents are identical wrt the files we are following).\n\nMost of the rest of commit traversal tend to have a rule that says \n\"traverse youngest parent first\", simply by virtue of the fact that \nrevlist() normally pops off the queue in date order. But Jakub is \ncertainly correct that when we do \"^\" we just take the first one. \n\nAnd \"gitweb\" does consider the first one special, since it shows diffs \nagainst that one (although I've argued that it probably shouldn't, and \nthat there should be some way to show branches against arbitrary parents)\n\nSo we're a bit confused. Not that it probably really ever matters. We \nmight as well say that parent order is random, and that our \"random number \ngenerators\" are pretty damn lazy ;)\n\n\t\tLinus\n"},{"id":"29452","messageId":"7vy7rajwyn.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201702580.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-21T01:09:52Z","receivedAt":"2006-10-21T01:09:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> And \"gitweb\" does consider the first one special, since it shows diffs \n> against that one (although I've argued that it probably shouldn't, and \n> that there should be some way to show branches against arbitrary parents)\n>\n> So we're a bit confused. Not that it probably really ever matters.\n\nThere is another one similar to the gitweb one you mentioned:\ngit-show --stat on a merge. We deliberately chose to show the\ndifference from the first parent; it is called \"showing the\nchanges the person who made this merge saw\".\n"},{"id":"29453","messageId":"Pine.LNX.4.64.0610201818210.3962@g5.osdl.org","threadId":"5925","inReplyTo":"7vy7rajwyn.fsf@assigned-by-dhcp.cox.net","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-21T01:19:45Z","receivedAt":"2006-10-21T01:19:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Junio C Hamano wrote:\n> \n> There is another one similar to the gitweb one you mentioned:\n> git-show --stat on a merge. We deliberately chose to show the\n> difference from the first parent; it is called \"showing the\n> changes the person who made this merge saw\".\n\nWell, that one actually makes sense. It's just the stat from the previous \nstate, after all, and it actually is done _together_ with the operation \nthat causes the diffs.\n\nSo that one I don't think you can really even claim.\n\nAlso, it's not even the \"first parent\". Look closer. It's literally \n\"previous state\", because it does so for a fast-forward too. It's from \nORIG_HEAD.\n\n\t\tLinus\n"},{"id":"29454","messageId":"7vk62ujw7j.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201630000.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-21T01:26:08Z","receivedAt":"2006-10-21T01:26:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Both of these things that git can actually do. Admittedly it does not do \n> that in any _released_ version, so you'd have to work with the development \n> branch, and it's a fairly early thing, but currently it can actually \n> notice that our \"revision.c\" file largely came from the \"rev-list.c\" file \n> that still exists!\n>\n> And btw, that's not just some random feature that happened to get \n> implemented last week. Yes, it actually _did_ get implemented last week, \n> but this was something I outlined when I started git in April of last \n> year, and tried to explain to people WHY TRACKING FILE ID'S ARE WRONG!\n>\n> You can find me explaining these things to people in April-2005, which \n> should tell you something: the initial revision of \"git\" was on Thursday, \n> April 7. So the lack of file identity tracking has been controversial from \n> the very beginning, but I was right then, and I'm right now.\n\nFor people new to the list, the message is:\n\n http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217\n\nI think I've quoted this link at least three times on this list;\nI consider it is _the_ most important message in the whole list\narchive. If you haven't read it, read it now, print it out,\nread it three more times, place it under the pillow before you\nsleep tonight. Repeat that until you can recite the whole\nmessage. It should not take more than a week.\n\nTo me, personally, achieving that ideal \"drill down\" dream was\none of the more important goals of my involvement in this\nproject. I did diffcore-rename to fill some part of the dream,\nand then diffcore-pickaxe to fill some other part. Neither was\neven close. I think the recent round of pickaxe is getting much\ncloser.\n"},{"id":"29455","messageId":"7vfydijw5x.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201818210.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-21T01:27:06Z","receivedAt":"2006-10-21T01:27:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 20 Oct 2006, Junio C Hamano wrote:\n>> \n>> There is another one similar to the gitweb one you mentioned:\n>> git-show --stat on a merge. We deliberately chose to show the\n>> difference from the first parent; it is called \"showing the\n>> changes the person who made this merge saw\".\n>\n> Well, that one actually makes sense. It's just the stat from the previous \n> state, after all, and it actually is done _together_ with the operation \n> that causes the diffs.\n>\n> So that one I don't think you can really even claim.\n>\n> Also, it's not even the \"first parent\". Look closer. It's literally \n> \"previous state\", because it does so for a fast-forward too. It's from \n> ORIG_HEAD.\n\nI was not talking about \"git pull\". I was talking about \"git\nshow\".\n"},{"id":"29457","messageId":"Pine.LNX.4.64.0610201854350.3962@g5.osdl.org","threadId":"5925","inReplyTo":"7vfydijw5x.fsf@assigned-by-dhcp.cox.net","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-21T01:55:55Z","receivedAt":"2006-10-21T01:55:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Junio C Hamano wrote:\n> \n> I was not talking about \"git pull\". I was talking about \"git\n> show\".\n\nDuh. I don't know why I misread that.\n\nYeah, that makes no sense at all. I _think_ \"git show\" should be the same \nthing as a single-entry \"git log -p\".\n\n\t\tLinus\n"},{"id":"29458","messageId":"Pine.LNX.4.63.0610210359040.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201333240.3962@g5.osdl.org","subject":"git-merge-recursive, was Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-21T02:03:18Z","receivedAt":"2006-10-21T02:03:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\n\nOn Fri, 20 Oct 2006, Linus Torvalds wrote:\n\n> On Fri, 20 Oct 2006, Aaron Bentley wrote:\n> > \n> > Agreed. We start by comparing BASE and OTHER, so all those comparisons\n> > are in-memory operations that don't hit disk. Only for files where BASE\n> > and OTHER differ do we even examine the THIS version.\n> \n> Git just slurps in all three trees. I actually think that the current \n> merge-recursive.c does it the stupid way (ie it expands all trees \n> recursively, regardless of whether it's needed or not), but I should \n> really check with Dscho, since I had nothing to do with that code.\n\nAFAIR yes, it does the dumb thing, namely it does not take advantage of \ntrees being identical when their SHA1s are identical.\n\nThis will be a _tremendous_ speed-up.\n\n> > > So recursive basically generates the matrix of similarity for the \n> > > new/deleted files, and tries to match them up, and there you have your \n> > > renames - without ever looking at the history of how you ended up where \n> > > you are.\n> > \n> > So in the simple case, you compare unmatched THIS, OTHER and BASE files\n> > to find the renames?\n> \n> Right. Some cases are easy: if one of the branches only added files (which \n> is relatively common), that obviously cannot be a rename. So you don't \n> even have to compare all possible combinarions - you know you don't have \n> renames from one branch to the other ;)\n> \n> But I'm not even the authorative person to explain all the details of the \n> current recursive merge, and I might have missed something. Dscho? \n> Fredrik? Anything you want to add?\n\nNot me. Only that there is much potential for optimization (meaning \nperformance, not the basic algorithm).\n\nCiao,\nDscho\n"},{"id":"29460","messageId":"7v4ptyjttb.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610210359040.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git-merge-recursive, was Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-21T02:17:52Z","receivedAt":"2006-10-21T02:17:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Fri, 20 Oct 2006, Linus Torvalds wrote:\n>\n>> Git just slurps in all three trees. I actually think that the current \n>> merge-recursive.c does it the stupid way (ie it expands all trees \n>> recursively, regardless of whether it's needed or not), but I should \n>> really check with Dscho, since I had nothing to do with that code.\n>\n> AFAIR yes, it does the dumb thing, namely it does not take advantage of \n> trees being identical when their SHA1s are identical.\n>\n> This will be a _tremendous_ speed-up.\n\nWhile we are talking about merge-recursive, I could use some\nhelp from somebody familiar with merge-recursive to complete the\nread-tree changes Linus mentioned early this month.\n\nThe issue is that we would want to remove one verify_absent()\ncall in unpack-tree.c:threeway_merge(). When read-tree decides\nto leave higher stages around, we do not want it to check if the\nmerge could clobber a working tree file, because having an\nunrelated file at the same path in the working tree sometimes is\nand sometimes is not a conflict, depending on the outcome of the\nmerge, and that part of the code does not _know_ the outcome\nyet.\n\nWhat this means is that we would need to have the equivalent\ncheck in the merge strategy that uses read-tree for three-way\nmerge when we remove this overcautious safety check from\nread-tree. I've adjusted merge-one-file to do so, but not many\npeople use 'resolve' strategy these days, and we would need the\nmatching change in merge-recursive.\n\nIf you are interested, you can see the details in commit 0b35995.\n"},{"id":"29468","messageId":"7vzmbqgqvy.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610191258290.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-21T05:49:21Z","receivedAt":"2006-10-21T05:49:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> For example, while git now does \"annotate\" (or \"blame\"), it's not \n> lightning fast, and I simply don't care. Doing a\n>\n> \tgit blame kernel/sched.c\n>\n> takes about three seconds for me, and that's on a pretty good machine (and \n> on the kernel tree, which for me is always in the cache ;).\n\nll.6041-6091 of that file is blamed to arch/ia64/kernel/domain.c\nby pickaxe -C (attributed to commit 2.6.12-rc2) while blame says\nthey are brought in by commit 9c1cfa, which says \"Move the ia64\ndomain setup code to the generic code\". I am slowly realizing\nthat comparing the output from blame and pickaxe might be a good\nway to study the project history.\n"},{"id":"29472","messageId":"vpqk62uhzkk.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"ehao3e$2qv$1@sea.gmane.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-21T07:56:27Z","receivedAt":"2006-10-21T07:56:27Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n>> It's my understanding that most changes discussed on lkml are provided\n>> as a series of patches. Bazaar bundles are intended as a direct\n>> replacement for patches in that use case.\n>\n> As _series_ of patches. You have git-format-patch + git-send-email\n> to format and send them, git-am to apply them (as patches, not as branch).\n>\n> I was under an impression that user sees only mega-patch of all the\n> revisions in bundle together, and rest is for machine consumption only.\n\nNothing prevents you from using series of bundles.\n\nA bundle for a single revision looks like a patch with a few comments\non top and bottom. _If_ you have several revisions in your patch, you\nget the diff as human readable, and the intermediate revisions as\nMIME-encoded.\n\nFor big changes, people do send several bundles.\n\nSo, a bundle is a direct replacement for a patch, not for series of\npatches.\n\n-- \nMatthieu\n"},{"id":"29473","messageId":"ehclkf$v3e$1@sea.gmane.org","threadId":"5925","inReplyTo":"20061017080702.615a3b2f.seanlkml__27953.817000571$1161408618$gmane$org@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T08:27:05Z","receivedAt":"2006-10-21T08:27:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sean wrote:\n\n> On Tue, 17 Oct 2006 13:45:31 +0200\n> Jakub Narebski wrote:\n> \n>> Git cannot do that remotely (with exception of git-tar-tree/git-archive \n>> which has --remote option), yet. But you can get contents of a file \n>> (with \"git cat-file -p [:|::]\"), list \n>> directory (with \"git ls-tree \") and compare files or \n>> directories (git diff family of commands) without need for working \n>> directory.\n> \n> Interesting, I didn't know about the --remote option. So in fact as long\n> as the remote has enabled upload-tar then anyone can do a \"light\n> checkout\". \n\nNot exactly. \"Light checkout\" (aka \"lazy one-branch clone\") in bzr\ncontains also info about the repository it came from, and has some\nmetadata that you can commit to it locally. git tar-tree --remote\njust gets snapshot. \n\n> However, it appears that kernel.org for instance doesn't enable this\n> feature. \n\nOne can get snapshot from gitweb... if gitweb is new enough and\nhas this feature enabled (it is enabled by default). Again not\nthe case of kernel.org\n"},{"id":"29474","messageId":"ehcluh$v3e$2@sea.gmane.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610201854350.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T08:32:28Z","receivedAt":"2006-10-21T08:32:28Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> On Fri, 20 Oct 2006, Junio C Hamano wrote:\n>> \n>> I was not talking about \"git pull\". I was talking about \"git\n>> show\".\n> \n> Duh. I don't know why I misread that.\n> \n> Yeah, that makes no sense at all. I _think_ \"git show\" should be the same \n> thing as a single-entry \"git log -p\".\n\nHuh?\n\n$ git show ff49fae6a547e5c70117970e01c53b64d983cd10\ncommit ff49fae6a547e5c70117970e01c53b64d983cd10\nMerge: 7ad4ee7... 75f9007... 14eab2b... 0b35995... eee4609...\n[...]\ndiff --cc Makefile\nindex 36b9e06,68ae43b,66c8b4b,66c8b4b,09f60bb..a2f2f7c\n[...]\n\n\"git show\" doesn't prefer first parent: it uses compact combined\n(that is the meaning of --cc, isn't it?) format for merges.\n\ngit version 1.4.2.1\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29475","messageId":"200610211036.44679.jnareb@gmail.com","threadId":"5925","inReplyTo":"vpqk62uhzkk.fsf@ecrins.imag.fr","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T08:36:44Z","receivedAt":"2006-10-21T08:36:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthieu Moy wrote:\n> Jakub Narebski writes:\n> \n>>> It's my understanding that most changes discussed on lkml are provided\n>>> as a series of patches. Bazaar bundles are intended as a direct\n>>> replacement for patches in that use case.\n>>\n>> As _series_ of patches. You have git-format-patch + git-send-email\n>> to format and send them, git-am to apply them (as patches, not as branch).\n>>\n>> I was under an impression that user sees only mega-patch of all the\n>> revisions in bundle together, and rest is for machine consumption only.\n> \n> Nothing prevents you from using series of bundles.\n> \n> A bundle for a single revision looks like a patch with a few comments\n> on top and bottom. _If_ you have several revisions in your patch, you\n> get the diff as human readable, and the intermediate revisions as\n> MIME-encoded.\n> \n> For big changes, people do send several bundles.\n> \n> So, a bundle is a direct replacement for a patch, not for series of\n> patches.\n\nAh, that explains this. So why people use bundles instead of patches\n(with some metainfo like commit message)? And do bzr have command to\napply in correct ordering series of bundles send either chain replied\nto (each patch in the series is reply to previous patch) or being\nreplies to patchseries introductory message?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29476","messageId":"200610211040.44333.jnareb@gmail.com","threadId":"5925","inReplyTo":"7vk62ujw7j.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T08:40:43Z","receivedAt":"2006-10-21T08:40:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> For people new to the list, the message is:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217\n> \n> I think I've quoted this link at least three times on this list;\n> I consider it is _the_ most important message in the whole list\n> archive. If you haven't read it, read it now, print it out,\n> read it three more times, place it under the pillow before you\n> sleep tonight. Repeat that until you can recite the whole\n> message. It should not take more than a week.\n> \n> To me, personally, achieving that ideal \"drill down\" dream was\n> one of the more important goals of my involvement in this\n> project. I did diffcore-rename to fill some part of the dream,\n> and then diffcore-pickaxe to fill some other part. Neither was\n> even close. I think the recent round of pickaxe is getting much\n> closer.\n\nWhat I find lacking in this mail, and in git as it is now, is\nsomehow remembering and perhaps even propagating user's corrections\nto automatic contents movement (which includes file renames and\nfile copying) detection.\n-- \nJakub Narebski\nPoland\n"},{"id":"29478","messageId":"845b6e870610210148l1337fc06n238eca0a2f382d0b@mail.gmail.com","threadId":"5925","inReplyTo":"ehclkf$v3e$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-21T08:48:25Z","receivedAt":"2006-10-21T08:48:25Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"On 10/21/06, Jakub Narebski wrote:\n> Sean wrote:\n>\n> > On Tue, 17 Oct 2006 13:45:31 +0200\n> > Jakub Narebski wrote:\n> >\n> >> Git cannot do that remotely (with exception of git-tar-tree/git-archive\n> >> which has --remote option), yet. But you can get contents of a file\n> >> (with \"git cat-file -p [:|::]\"), list\n> >> directory (with \"git ls-tree \") and compare files or\n> >> directories (git diff family of commands) without need for working\n> >> directory.\n> >\n> > Interesting, I didn't know about the --remote option. So in fact as long\n> > as the remote has enabled upload-tar then anyone can do a \"light\n> > checkout\".\n>\n> Not exactly. \"Light checkout\" (aka \"lazy one-branch clone\") in bzr\n> contains also info about the repository it came from, and has some\n> metadata that you can commit to it locally. git tar-tree --remote\n> just gets snapshot.\n\nNo, a lightweight checkout doesn't have that. A lightweight checkout\nis basically just the latest revision checked out, a snapshot. For\neverything else it needs to go the remote branch to get information.\nYou cannot commit locally on a \"lightwieght checkout\"\n\nA \"normal/heavyweight\" checkout has the ability to commit locally.\n\n/Erik\n"},{"id":"29483","messageId":"vpq64eeyo8v.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"200610211036.44679.jnareb@gmail.com","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-21T10:09:04Z","receivedAt":"2006-10-21T10:09:04Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n> Ah, that explains this. So why people use bundles instead of patches\n> (with some metainfo like commit message)?\n\nYou need more metainfo than the commit message. Since revision-id is\nnot based on the content, you need at least to specify the\nrevision-id.\n\nAnd bzr's bundle give indeed _all_ the information that is in the\nrepository about this revision (i.e. commit message, ancestors, ...).\n\nAnother relevant difference between a patch and a bundle is that the\nbundles knows its ancestor, so, when you apply the bundle, it builds\nthe new revision with exact patching. If you need a merge, then it\nwill happen exactly in the same way as a merge between two branches\n(ie. three-way merge for example).\n\n> And do bzr have command to apply in correct ordering series of\n> bundles send either chain replied to (each patch in the series is\n> reply to previous patch) or being replies to patchseries\n> introductory message?\n\nNot directly AFAIK, but since the bundle knows which revision it\napplies to, it will refuse to apply the second if the first one is not\nin your repository already for example.\n\nIt would probably be interesting to have more features to help sending\nseries of bundles and apply them, but no one have been really asking\nfor it up to now.\n\n-- \nMatthieu\n"},{"id":"29484","messageId":"200610211234.31967.jnareb@gmail.com","threadId":"5925","inReplyTo":"vpq64eeyo8v.fsf@ecrins.imag.fr","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T10:34:31Z","receivedAt":"2006-10-21T10:34:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthieu Moy wrote:\n\n> Another relevant difference between a patch and a bundle is that the\n> bundles knows its ancestor, so, when you apply the bundle, it builds\n> the new revision with exact patching. If you need a merge, then it\n> will happen exactly in the same way as a merge between two branches\n> (ie. three-way merge for example).\n\nBy the way, if patch send via email is git enchanced patch, with\n[shortened] sha1 of blobs (file contents), and our repository has\nthe blob the patch is supposedly to apply to (but for example line\nof development moved forwards) we can request via --3way command\noption to git-am to fall back on 3-way merge if the patch doesn't\napply cleanly.\n\nIt is not as powerfull as merge of branches, but it is sufficient\nin most cases. And in other cases you have to resolve conflict by\nhand, anyway; git-rerere (which records resolving of conflicts and\nreuses them) can help there.\n-- \nJakub Narebski\nPoland\n"},{"id":"29488","messageId":"20061021123027.GB29843@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"45384B0F.4040901@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-21T12:30:27Z","receivedAt":"2006-10-21T12:30:27Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Fri, Oct 20, 2006 at 12:05:35AM -0400, Aaron Bentley wrote:\n> Tim Webster wrote:\n> > Also svn does not allow files in the same directory to live in\n> > multiple repos\n> \n> It would surprise me if many SCMs that support atomic commit also\n> support intermixing files from multiple repos in the same directory.\n\nIn fact I think svk would. You would have to switch them by setting\nan environment variable, but it's probably doable. That is because\nunlike other version control systems, it does not store the information\nabout checkout in the checkout, but in the central directory and that\ncan be set. I don't know git well enough to tell whether git could do\nthe same by setting GIT_DIR.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29489","messageId":"20061021123048.GK75501@over-yonder.net","threadId":"5925","inReplyTo":"eha926$uc$2@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-21T12:30:48Z","receivedAt":"2006-10-21T12:30:48Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Fri, Oct 20, 2006 at 12:40:11PM +0200 I heard the voice of\nJakub Narebski, and lo! it spake thus:\n> \n> I'd like to put ComparisonWithBazaarNG page on GitWiki\n> (http://git.or.cz/gitwiki/) some time soon,\n\nThis is a good idea; I think we've plowed a lot of ground in this\nthread that would be useful to document somewhere easily\nreferenceable. I've thought a few times while going through these\nmails of putting some of the material up on the Bazaar wiki. I'm not\nreally the best person to try and sort it out, but I may try and put\ntogether some notes at least.\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29490","messageId":"20061021130111.GL75501@over-yonder.net","threadId":"5925","inReplyTo":"87irie1wvv.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-21T13:01:11Z","receivedAt":"2006-10-21T13:01:11Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Fri, Oct 20, 2006 at 02:48:52PM -0700 I heard the voice of\nCarl Worth, and lo! it spake thus:\n> \n> The entire discussion is about how to name things in a distributed\n> system.\n\nI think we're getting into scratched-record-mode on this.\n\n\nGit: Revnos aren't globally unique or persistent.\n\nBzr: Yes, we know.\n\nG: Therefore they're useless.\n\nB: No, they're very useful in [situation] and [situation], and we deal\n with [situation] all the time, and they work great for that.\n\nG: But they fall apart totally in [situation].\n\nB: Yes, so use revids there.\n\nG: So use revids everywhere.\n\nB: Revnos are handier tools for [situation] and [situation] for\n [reason] and [reason].\n\n*brrrrrrrrrrrrrrrrip!!!* *skip back to start*\n\n\nI'm not sure there's any unturned stone left along this line, so I'm\nnot sure how productive it really is to keep walking down it. So, to\nmake something productive of it, I'm going to put it onto my todo list\nto spend some time with bzr trying to use revids for stuff. I'm\nfairly certain that, due to the bzr cultural tendancy to use revnos\nwhere possible, there are some rough edges in the UI when using revids\nthat should be filed down (though I think it much less likely to turn\nup underlying model failures that interfere with using revids).\n\n\n> It may be that the centralization bias\n\nI think it's more accurately describable as a branch-identity bias.\nThe git claim seems to be that the two statements are identical, but I\nhave some trouble swallowing that.\n\n\n> I'm still not sure exactly what a bzr branch is, but it's clearly\n> something different from a git branch,\n\nThe term is somewhat overloaded, which is why it's causing you trouble\n(and did me). It refers both to the conceptual entity (\"a line of\ndevelopment\" roughly, much like what 'branch' means in git and VCS in\ngeneral), and to the physical location (directory, URL) where that\nbranch is stored, and where it'll often have a working tree. Branches\nare always referred to by location, never by name.\n\n\n> (and I'd be interested to see a \"corrected\" version of the commands\n> above to fix the storage inefficiencies).\n\nThe 'corrected' step would be:\n\n> \tmkdir bzrtest; cd bzrtest\n bzr init-repo .\n> \tmkdir master; cd master; bzr init\n\nThen all branches stored under that 'bzrtest' dir will use the\nbzrtest/.bzr/ dir for storing the revisions, and shared revisions will\nonly exist once saving the space/time for multiple copies.\n\nProbably, you'd actually want 'init-repo --trees' in this case,\nbecause repos default to being [working]tree-less. In a tree-less\nsetup, you'd create a [lightweight] checkout of the branch(es) you\nwanted to work on elsewhere, giving you a layout much like CVS or SVN\nwhere \"my VCS files are THERE, my working tree is HERE\".\n\n\n> (since pull seems the only way to synch up without infinite new\n> merge commits being added back and forth).\n\nThe infinite-merge-commits case doesn't happen in bzr-land because we\ngenerally don't merge other branches except when the branch owner says\n\"Hey, I've got something for you to merge\". If you were to setup a\nscript to merge two branches back and forth until they were 'equal',\nyes, it'd churn away until you filled up your disk with the N bytes of\nmetadata every new revision uses up.\n\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29491","messageId":"ehd5u7$c5g$1@sea.gmane.org","threadId":"5925","inReplyTo":"20061021123027.GB29843@artax.karlin.mff.cuni.cz","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T13:05:22Z","receivedAt":"2006-10-21T13:05:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jan Hudec wrote:\n\n> On Fri, Oct 20, 2006 at 12:05:35AM -0400, Aaron Bentley wrote:\n>> Tim Webster wrote:\n>> > Also svn does not allow files in the same directory to live in\n>> > multiple repos\n>> \n>> It would surprise me if many SCMs that support atomic commit also\n>> support intermixing files from multiple repos in the same directory.\n> \n> In fact I think svk would. You would have to switch them by setting\n> an environment variable, but it's probably doable. That is because\n> unlike other version control systems, it does not store the information\n> about checkout in the checkout, but in the central directory and that\n> can be set. I don't know git well enough to tell whether git could do\n> the same by setting GIT_DIR.\n\nYou can very simply embed one \"clothed\" repository into another in GIT,\nlike shown below\n\n project/.git\n project/subdir/\n project/subdir/file\n project/subproject/\n project/subproject/.git\n project/subproject/file\n ...\n\nIt depends on circumstances if one wants files belonging to subdirectory\nbe ignored by top repository. You would want to ignore .git/ directory,\nthough.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29492","messageId":"20061021131551.GC29843@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"ehd5u7$c5g$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-21T13:15:51Z","receivedAt":"2006-10-21T13:15:51Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sat, Oct 21, 2006 at 03:05:22PM +0200, Jakub Narebski wrote:\n> Jan Hudec wrote:\n> \n> > On Fri, Oct 20, 2006 at 12:05:35AM -0400, Aaron Bentley wrote:\n> >> Tim Webster wrote:\n> >> > Also svn does not allow files in the same directory to live in\n> >> > multiple repos\n> >> \n> >> It would surprise me if many SCMs that support atomic commit also\n> >> support intermixing files from multiple repos in the same directory.\n> > \n> > In fact I think svk would. You would have to switch them by setting\n> > an environment variable, but it's probably doable. That is because\n> > unlike other version control systems, it does not store the information\n> > about checkout in the checkout, but in the central directory and that\n> > can be set. I don't know git well enough to tell whether git could do\n> > the same by setting GIT_DIR.\n> \n> You can very simply embed one \"clothed\" repository into another in GIT,\n> like shown below\n> \n> project/.git\n> project/subdir/\n> project/subdir/file\n> project/subproject/\n> project/subproject/.git\n> project/subproject/file\n> ...\n> \n> It depends on circumstances if one wants files belonging to subdirectory\n> be ignored by top repository. You would want to ignore .git/ directory,\n> though.\n\nYes, you can do that with bzr and most other tools I know of as well.\nBut I understand the original question as requesting the working trees\nto be rooted at the same place (ie. all in /etc), because each has some\nfiles and some directories that have to be placed next to each other.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29494","messageId":"200610211529.33426.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061021131551.GC29843@artax.karlin.mff.cuni.cz","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T13:29:33Z","receivedAt":"2006-10-21T13:29:33Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia sobota 21. października 2006 15:15, Jan Hudec napisał:\n> On Sat, Oct 21, 2006 at 03:05:22PM +0200, Jakub Narebski wrote:\n>> Jan Hudec wrote:\n>> \n>>> On Fri, Oct 20, 2006 at 12:05:35AM -0400, Aaron Bentley wrote:\n>>>> Tim Webster wrote:\n>>>>> Also svn does not allow files in the same directory to live in\n>>>>> multiple repos\n>>>> \n>>>> It would surprise me if many SCMs that support atomic commit also\n>>>> support intermixing files from multiple repos in the same directory.\n>>> \n>>> In fact I think svk would. You would have to switch them by setting\n>>> an environment variable, but it's probably doable. That is because\n>>> unlike other version control systems, it does not store the information\n>>> about checkout in the checkout, but in the central directory and that\n>>> can be set. I don't know git well enough to tell whether git could do\n>>> the same by setting GIT_DIR.\n>> \n>> You can very simply embed one \"clothed\" repository into another in GIT,\n>> like shown below\n[...]\n>> It depends on circumstances if one wants files belonging to subdirectory\n>> be ignored by top repository. You would want to ignore .git/ directory,\n>> though.\n> \n> Yes, you can do that with bzr and most other tools I know of as well.\n> But I understand the original question as requesting the working trees\n> to be rooted at the same place (ie. all in /etc), because each has some\n> files and some directories that have to be placed next to each other.\n\nYou can separate working area from the repository (you don't need to have\nrepository in top directory of working area), but you must then provide\nfor each git command you do the location of repository, either via setting\nGIT_DIR environmental variable (GIT_DIR=/path/to/repo.git git commit ...),\nor use --git-dir option of git wrapper (git --git-dir=/path/to/repo.git diff),\nas automatical detection of repository wouldn't work, of course.\n-- \nJakub Narebski\nPoland\n"},{"id":"29496","messageId":"20061021134840.GD29843@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"eh7c5t$gd1$1@sea.gmane.org","subject":"Re: Alternate revno proposal (Was: Re: VCS comparison table)","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-21T13:48:40Z","receivedAt":"2006-10-21T13:48:40Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Thu, Oct 19, 2006 at 11:19:30AM +0300, Alexander Belchenko wrote:\n> Jan Hudec ??????????:\n> >Reading this thread I came to think, that the revnos should be assigned\n> >to _all_ revisions _available_, in order of when they entered the\n> >repository (there are some possible variations I will mention below)\n> ...\n> > - They would be the same as subversion and svk, and IIRC mercurial as\n> > well, use, so:\n> > - They would already be familiar to users comming from those systems.\n> > - They are known to be useful that way. In fact for svk it's the only\n> > way to refer to revisions and seem to work satisfactorily (though\n> > note that svk is not really suitable to ad-hoc topologies).\n> \n> I think that SVN model of revision numbers is wrong. And apply it to bzr\n> break many UI habits. Per example, when ones use svn and their repo has\n> many branches you never could say what revisions belongs to mainline. So\n> things like\n> bzr diff -rM..N\n> (where M and N absolute revisions numbers, and N = M+1(+2) etc.)\n> will more complicated, because in this case you first need to run log\n> command, remember actual numbers of those revisions.\n\nWell, you need to run log anyway, because you usually want to see a diff\nbetween some particular revisions, so you need to find them anyway.\n\nOn the other hand in subversion all revisions actually exist on all\nbranches, so svn diff -r N-1:N always shows changes introduced by\nrevision N, while here you would have to use before:N..N.\n\n> And I each time frustrating to see that after mainline svn revision 1000\n> might be mainline revision 1020. It's very-very-very confusing. May be\n> only for me.\n\nI got used to this pretty quickly when I used svk. And there it actually\nhappens much more often than in subversion itself, because you have the\nmirrored branches and each commit on them also gets a revision number.\nBut yes, they feel more weird.\n\n> There is 2 things why I don't want to switch to svn (if I can do my own\n> choice): their strange tags implementation (their tags is the same as\n> branches, so what difference?) and their revisions numbers.\n> \n> I also think that dotted revisions is not answer in this case, but it\n> looks very logical and nice.\n> \n> I think bzr need to have a switch, a flag, probably in .bazaar.conf to\n> show revno to user or revid. And user can easily select what model is\n> more appropriate for him:\n> \n> * decentralized (with revno)\n> * or distrubuted (with revid i.e. UUID)\n\nPersonally I'd like the ui to make the revision ids more visible since\nthey are the canonical way for refering to revisions and as shown among\nother in this thread people who know something about distributed version\ncontrol are actually confused by them not being visible and think they\nare not there.\n\n> >Comments?\n> \n> -1 to make revno as in svn.\n\nHm, you are probably right. In any case it's more useful to teach the\nusers not to get attached to the revnos too much.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29497","messageId":"200610211608.18895.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061021130111.GL75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T14:08:18Z","receivedAt":"2006-10-21T14:08:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia sobota 21. października 2006 15:01, Matthew D. Fuller napisał:\n> On Fri, Oct 20, 2006 at 02:48:52PM -0700 I heard the voice of\n> Carl Worth, and lo! it spake thus:\n> > \n> > The entire discussion is about how to name things in a distributed\n> > system.\n> \n> I think we're getting into scratched-record-mode on this.\n> \n> \n> Git: Revnos aren't globally unique or persistent.\n> \n> Bzr: Yes, we know.\n> \n> G: Therefore they're useless.\n> \n> B: No, they're very useful in [situation] and [situation], and we deal\n> with [situation] all the time, and they work great for that.\n> \n> G: But they fall apart totally in [situation].\n\nG: But revnos force centralized/star-topology development. And even in\n [situation] have [disadvantages].\n\n> B: Yes, so use revids there.\n> \n> G: So use revids everywhere.\n> \n> B: Revnos are handier tools for [situation] and [situation] for\n> [reason] and [reason].\n\nG: Shortened sha1 commit-ids are almost as handy.\n\n> *brrrrrrrrrrrrrrrrip!!!* *skip back to start*\n\nThere _are_ terminology conflicts. For example bzr \"branch\" is roughly \nequivalent to one-branch git \"repository\"; bzr \"repository\" is just \ncollection of branches sharing common storage, which is similar to set \nof git \"repositories\" with .git/objects/ linked to common object \nrepository (storage area) or appropriately set alternates file \n(although that is not common usage in git, and for example you would \nhave to be carefull with running git-prune); bzr \"lightweight checkout\" \nis equivalent to nonexistent \"lazy clone\"/\"remote alternates\" discussed \non git mailing list but not implemented because of performance \nconcerns; bzr \"normal checkout\" is I think similar to git \"shared \nclone\" (but shared clone is limited to repositories on the same \nfilesystem); bzr \"heavyweight checkout\" is roughly equivalent to \none-branch-only \"clone\" in git or cg (cg = Cogito).\n\nAnd there are differences in opinion. For example \"simple namespace for \nrevisions\" which is important for bzr, is superficially simple for git \n(as it works only for centralized approach, and for leaf repositories \nyou have to have access to central repository to get final revnos); on \nthe other hand \"not simpleness\" of git's sha1 identifiers is not that \ncomplicated in everydays work, as one usually use branch and tag names, \n~ and .. syntax, sometimes shortened sha1 names and \nfull sha1 names only rarely. For bzr it is more important to tell from \nrevno which commit on branch was earlier, for git it is more important \nthat commitids never ever change; we can use git commands to check \nwhich commit was earlier. For bzr plugins are important, for git it is \nimportant to be easy to add new commands, using scripts for fast \nprototyping.\n\n> > It may be that the centralization bias\n> \n> I think it's more accurately describable as a branch-identity bias.\n> The git claim seems to be that the two statements are identical, but I\n> have some trouble swallowing that.\n\nWhen two clones of the same repository (in git terminology), or two \n\"branches\" (in bzr terminology), used by different people, cannot be \ntotally equivalent that is centralization bias. By equivalent I mean \nthat \"old history\" is exactly the same (the same diagram, the same\nidentifiers - make it usually used identifiers).\n \nThe fact that you have two different commands, \"merge\" vs \"pull\"\nfor using in one mother/mainline \"branch\" vs other \"branches\" tells\nus that there is bias towards centralization.\n\n> > I'm still not sure exactly what a bzr branch is, but it's clearly\n> > something different from a git branch,\n> \n> The term is somewhat overloaded, which is why it's causing you trouble\n> (and did me). It refers both to the conceptual entity (\"a line of\n> development\" roughly, much like what 'branch' means in git and VCS in\n> general), and to the physical location (directory, URL) where that\n> branch is stored, and where it'll often have a working tree. Branches\n> are always referred to by location, never by name.\n\nI'd rather use other name then. Perhaps \"forks\" for physical \"branch\",\ni.e. branch metadata (like revno to revid mapping) + object repository \nor pointer to it + optionally working area/working files. \n\n[...]\n> > (since pull seems the only way to synch up without infinite new\n> > merge commits being added back and forth).\n> \n> The infinite-merge-commits case doesn't happen in bzr-land because we\n> generally don't merge other branches except when the branch owner says\n> \"Hey, I've got something for you to merge\". If you were to setup a\n> script to merge two branches back and forth until they were 'equal',\n> yes, it'd churn away until you filled up your disk with the N bytes of\n> metadata every new revision uses up.\n\nAnd you say that bzr is not biased towards centralization? In git you \ncan just pull (fetch) to check if there were any changes, and if there \nwere not you don't get useless marker-merges.\n\n\nTake for example two simple git scenarios:\n1. Single branch repository. We have two clones of the same repository, \nboth with only one branch, 'master', both working on this branch, and \nboth considered equal. If only one person worked on branch, \"pull\" \nwould result in fast-forward. If both worked on branch, \"pull\" would \nresult in merge. This is the \"diamond\" example by Pasky, which \nexplained why git doesn't treat first parent like special - because of \nfast forward. Bzr treats first parent/mainline/\"the branch\" special \ntherefore it generates superficial merge commits if we preserve revnos; \nBTW doesn't \"pull\" clobber your changes?\n\n2. But the preferred git workflow is to have two branches in each of two \nclones. The 'origin' branch where you fetch changes from other \nrepository (so called \"tracking branch\") and you don't commit your \nchanges to (by convention, as git doesn't protect the branch from \ncommiting to, although it would refuse to fetch in non fast-forward \ncase unless forced). You put your work in the 'master' branch, and you \nmerge 'origin' branch into 'master'. This allows for example fetching \nchanges to 'origin' but _not_ merging them immediately into 'master',\nfor example if you are in the middle of some larger work byt want to \ncheck what other side did to not to create conflict if not neccessary.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29498","messageId":"20061021141328.GE29843@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"20061017073839.3728d1e7.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-21T14:13:28Z","receivedAt":"2006-10-21T14:13:28Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Oct 17, 2006 at 07:38:39AM -0400, Sean wrote:\n> On Tue, 17 Oct 2006 13:19:08 +0200\n> Matthieu Moy wrote:\n> \n> > 1) a working tree without any history information, pointing to some\n> > other location for the history itself (a la svn/CVS/...).\n> > (this is \"light checkout\")\n> \n> Git can do this from a local repository, it just can't do it from\n> a remote repo (at least over the git native protocol). However,\n> over gitweb you can grab and unpack a tarball from a remote repo.\n> In practice this is probably enough support for such a feature.\n> \n> > 2) a bound branch. It's not _very_ different from a normal branch, but\n> > mostly \"commit\" behaves differently:\n> > - it commits both on the local and the remote branch (equivalent to\n> > \"commit\" + \"push\", but in a transactional way).\n> > - it refuses to commit if you're out of date with the branch you're\n> > bound to.\n> > (this is \"heavy checkout\")\n> \n> This doesn't sound right, at least in the spirit of git. Git really\n> wants to have a local commit which you may or may not push to a\n> remote repo at a later time. There is no upside to forcing it all to\n> happen in one step, and a lot of downsides. Gits focus is to support\n> distributed offline development, not requiring a remote repo to be\n> available at commit time.\n\nWhile there is no upside to forcing it all to _always_ happen in one\nstep, there are good reasons to allow it in particular cases.\n\nThe most common is if you work on something from two different computers\n(at home and at work or from desktop or notebook or similar cases) and\nwant to be sure you don't forget to synchronize your changes.\n\nYou can always unbind the branch or do a commit --local, which allows\ndoing a local commit anyway (eg. when disconnected) and then the next\ncommit will require a merge if the branches diverged.\n\n> > In both cases, this has the side effect that you can't commit if the\n> > \"upstream\" branch is read-only. That's not fundamental, but handy.\n> \n> Again this seems really anti-git. There is no reason for your local\n> branch to be marked read only just because some upstream branch is\n> so marked.\n\nAgain, it only is if you want, and opt for, making it so. Eg. people who\noften have many terminals with different current directories may use it\nto protect themselves from accidentaly running commands in the wrong\none. You don't have to use it if you don't want to.\n\n> > I use it for example to have several \"checkouts\" of the same branch on\n> > different machines. When I commit, bzr tells me \"hey, boss, you're out\n> > of date, why don't you update first\" if I'm out of date. And if commit\n> > succeeds, I'm sure it is already commited to the main branch. I'm sure\n> > I won't pollute my history with merges which would only be the result\n> > of forgetting to update.\n> \n> This is exactly the same in Git. You really only ever push upstream\n> when your local changes fast forward the remote, (ie. you're up to date).\n> Git will warn you if your changes don't fast forward the remote.\n\nIn bzr push and pull only work for the fast-forward case. They operate\non branches and actually apply the changes on the target. But that's a\ndifferent thing. Bound branches are mainly about not forgetting to\nsynchronize it.\n\n> > The more fundamental thing I suppose is that it allows people to work\n> > in a centralized way (checkout/commit/update/...), and Bazaar was\n> > designed to allow several different workflows, including the\n> > centralized one.\n> \n> While Git really isn't meant to work in a centralized way there's nothing\n> preventing such a work flow. It just requires the use of some surrounding\n> infrastructure.\n\nBzr is meant to be used in both ways, depending on user's choice.\nTherefore it comes with that infrastructure and you can choose whether\nyou want to use it or not.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29499","messageId":"BAYC1-PASMTP116A2EE9056E50B25534D5AE020@CEZ.ICE","threadId":"5925","inReplyTo":"20061021141328.GE29843@artax.karlin.mff.cuni.cz","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-21T14:23:46Z","receivedAt":"2006-10-21T14:23:46Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 16:13:28 +0200\nJan Hudec wrote:\n\n> Bzr is meant to be used in both ways, depending on user's choice.\n> Therefore it comes with that infrastructure and you can choose whether\n> you want to use it or not.\n\n>From what we've read on this thread, bzr appears to be biased towards\nworking with a central repo. That is the model that supports the use of\nrevnos etc that the bzr folks are so fond of. However Git is perfectly\ncapable of being used in any number of models, including centralized.\nGit just doesn't make the mistake of training new users into using\nfeatures that are only stable in a limited number of those models.\n\nSean\n"},{"id":"29500","messageId":"20061021102346.9cd3abce.seanlkml__45117.5057831735$1161440669$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"20061021141328.GE29843@artax.karlin.mff.cuni.cz","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-21T14:23:46Z","receivedAt":"2006-10-21T14:23:46Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 16:13:28 +0200\nJan Hudec wrote:\n\n> Bzr is meant to be used in both ways, depending on user's choice.\n> Therefore it comes with that infrastructure and you can choose whether\n> you want to use it or not.\n\n>From what we've read on this thread, bzr appears to be biased towards\nworking with a central repo. That is the model that supports the use of\nrevnos etc that the bzr folks are so fond of. However Git is perfectly\ncapable of being used in any number of models, including centralized.\nGit just doesn't make the mistake of training new users into using\nfeatures that are only stable in a limited number of those models.\n\nSean\n"},{"id":"29510","messageId":"20061021155624.GF29843@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"453656F8.3000504@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-21T15:56:24Z","receivedAt":"2006-10-21T15:56:24Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Oct 18, 2006 at 12:31:52PM -0400, Aaron Bentley wrote:\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> Jakub Narebski wrote:\n> > Aaron Bentley wrote:\n> > \n> >>Carl Worth wrote:\n> >>>There are even more important reasons to prefer a series of\n> >>>micro-commits over a mega-patch than just ease of merging.\n> >>\n> >>A bundle isn't a mega-patch. It contains all the source revisions. So\n> >>when you merge or pull it, you get all the original revisions in your\n> >>repository.\n> > \n> > \n> > But what patch reviewer see is a mega-patch showing the changeset\n> > of a whole \"bundle\", isn't it?\n> > [...]\n> \n> Yes. Carl was saying that, aside from the issue of what a reviewer\n> sees, a bundle is bad for other reasons. I am saying those other\n> reasons don't apply. I wasn't addressing the issue of what a reviewer sees.\n> \n> To me, seeing the individual patches is like reading a book where every\n> page has a different word on it, and so it's hard to put it together\n> into a full sentence. I'm not saying my way is The Right Way, just my\n> personal preference.\n> \n> For larger pieces of work, we try to split them up into logical units,\n> and merge those units independently.\n> \n> The Bundle format can also support a patch-by-patch output, but we don't\n> have UI to select that.\n\nAs for what the reviewer wants to see, I think it depends on what kind\nof code it is. Kernel code is complex and does not have (at least I have\nnot heared of) unit-tests, so short patches are preferable for review.\nAnd since C is of the more verbose languages, short patches mean\nspliting them up into several pieces.\n\nOn the other hand bzr has unit-tests and python is less verbose, so the\nsingle patch for a feature is not so big and is manageable. The patches\nto bzr still come in logical steps, but usually one step per feature is\nenough.\n\nAlso programmers usually don't develop even the single logical step as a\nsingle commit. Instead they they also commit to backup their work,\nwhen they try something they think they may in future return, when they\nneed to continue on another computer and so on. And these commits are\ngenerally not logical steps. Also the steps are often not in a logical\norder. Therefore showing diff for each commit in the bundle often does\nnot make sense.\n\nSo there is one bundle per logical step and therefore has a summary\ndiff. Individual bundles for individual steps are preferable anyway,\nsince the maintainer may decide to accept just some of them. A tool to\ngenerate a series of bundles (either each with just one commit or each\nwith several commits) would be possible, just noone was interested\nenough to do it yet.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29512","messageId":"200610211813.57374.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061021155624.GF29843@artax.karlin.mff.cuni.cz","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T16:13:56Z","receivedAt":"2006-10-21T16:13:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jan Hudec wrote:\n\n> Also programmers usually don't develop even the single logical step as a\n> single commit. Instead they they also commit to backup their work,\n\nIn git you can backup your work on temporary branch; besides there\nis git commit --amend to correct last commit.\n\n> when they try something they think they may in future return, when they\n> need to continue on another computer and so on. And these commits are\n> generally not logical steps. Also the steps are often not in a logical\n> order. Therefore showing diff for each commit in the bundle often does\n> not make sense.\n\nThat is why before sending patch series based on some feature branch,\nyou should at least rebase the branch on top of current work, to ensure\nthat the series would apply cleanly.\n\nIf feature branch/patch series needs cleanup (going from \"answer\" to\n\"solution\" http://lkml.org/lkml/2005/4/7/176), i.e. patch (commit)\nreordering, joining two patches into one, patch splitting, you can\nuse git-cherry-pick, git-cherry-pick --no-commit and git commit --amend\ncombination, or git-format-patch, patch editing and reordering, and git-am.\nOr just use StGit or pg.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29513","messageId":"845b6e870610210919i6d086654g3881343e6a3c9f84@mail.gmail.com","threadId":"5925","inReplyTo":"BAYC1-PASMTP116A2EE9056E50B25534D5AE020@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-21T16:19:54Z","receivedAt":"2006-10-21T16:19:54Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"On 10/21/06, Sean wrote:\n> On Sat, 21 Oct 2006 16:13:28 +0200\n> Jan Hudec wrote:\n>\n> > Bzr is meant to be used in both ways, depending on user's choice.\n> > Therefore it comes with that infrastructure and you can choose whether\n> > you want to use it or not.\n>\n> From what we've read on this thread, bzr appears to be biased towards\n> working with a central repo. That is the model that supports the use of\n> revnos etc that the bzr folks are so fond of. However Git is perfectly\n> capable of being used in any number of models, including centralized.\n> Git just doesn't make the mistake of training new users into using\n> features that are only stable in a limited number of those models.\n\nThis is just plain wrong.\n\nbzr is a fully decentralized VCS. I've read this thread for quite some\ntime now and I really cannot understand why people come to this\nconclusion.\n\nHowever, if you do want to work centralized, bzr has commands that\nfits that workflow really good.\n\n\n/Erik\n\n-- \ngoogle talk/jabber. zindar@gmail.com\nSIP-phones: sip:erik_bagfors@gizmoproject.com\nsip:17476714687@proxy01.sipphone.com\n"},{"id":"29515","messageId":"845b6e870610210931r19aaaac3y3dfd0d9c4af8ed40@mail.gmail.com","threadId":"5925","inReplyTo":"200610211608.18895.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-21T16:31:01Z","receivedAt":"2006-10-21T16:31:01Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"> There _are_ terminology conflicts. For example bzr \"branch\" is roughly\n> equivalent to one-branch git \"repository\";\n\nAgreed.\n\n> bzr \"repository\" is just\n> collection of branches sharing common storage,\nAgreed\n\n> which is similar to set\n> of git \"repositories\" with .git/objects/ linked to common object\n> repository (storage area) or appropriately set alternates file\n> (although that is not common usage in git, and for example you would\n> have to be carefull with running git-prune); bzr \"lightweight checkout\"\n> is equivalent to nonexistent \"lazy clone\"/\"remote alternates\" discussed\n> on git mailing list but not implemented because of performance\n> concerns; bzr \"normal checkout\" is I think similar to git \"shared\n> clone\" (but shared clone is limited to repositories on the same\n> filesystem); bzr \"heavyweight checkout\" is roughly equivalent to\n> one-branch-only \"clone\" in git or cg (cg = Cogito).\n\nThis is wrong. There are two kinds of checkouts\nlightweight.. and \"normal/heavyweight\".\n\nI think you are getting this alittle wrong, and I think the reason is\nthat you are thinking of repositories, while in bzr you normally think\nof branches.\n\nFor example, I think (correct me if I'm wrong) that if I have a git\nrepository of a upstream linux-repo (Linus' for example). I guess\nI'll use \"pull\" to keep my copy up to date with the upstream repo? If\nI then would like to hack something special, I would \"clone\" the repo\nand get a new repo and that's where I do my work. Is that correct?\n\nIn bzr you never (well...) clone a full repository, but you clone one\nline-of-development (a branch). So \"bzr branch\" is always a\n\"one-branch-only \"clone\" in git or cg\".\n\n\"bzr checkout\" is a \"bzr branch\" followed by a setting saying\n\"whenever you commit here, commit in the master branch also\".\n\n\"bzr checkout --lightweight\" is a way to get only a snapshot of the\nworking tree out of a branch. Whenever you commit, it's done in the\nremote branch.\n\n/Erik\n"},{"id":"29514","messageId":"200610211831.34462.jnareb@gmail.com","threadId":"5925","inReplyTo":"845b6e870610210919i6d086654g3881343e6a3c9f84@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T16:31:33Z","receivedAt":"2006-10-21T16:31:33Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Erik Bågfors wrote:\n> On 10/21/06, Sean wrote:\n>> On Sat, 21 Oct 2006 16:13:28 +0200\n>> Jan Hudec wrote:\n>>\n>>> Bzr is meant to be used in both ways, depending on user's choice.\n>>> Therefore it comes with that infrastructure and you can choose whether\n>>> you want to use it or not.\n>>\n>> From what we've read on this thread, bzr appears to be biased towards\n>> working with a central repo. That is the model that supports the use of\n>> revnos etc that the bzr folks are so fond of. However Git is perfectly\n>> capable of being used in any number of models, including centralized.\n>> Git just doesn't make the mistake of training new users into using\n>> features that are only stable in a limited number of those models.\n> \n> This is just plain wrong.\n> \n> bzr is a fully decentralized VCS. I've read this thread for quite some\n> time now and I really cannot understand why people come to this\n> conclusion.\n> \n> However, if you do want to work centralized, bzr has commands that\n> fits that workflow really good.\n\nRead carefully: bzr is _biased_ towards work with central repository.\nDefault workflow (as for example using revnos, as for example using\n\"merge\" for one repository and \"pull\" for other) of bzr is geared\ntowards star topology, i.e. some centralized repository.\n\nThat to be said, it is supposed to be able to work in fully decentralized\nway, using revids. But then for example you don't have \"simple rev\nnamespace\" (moreover you have _worse_ namespace than git's sha1 ids).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29516","messageId":"845b6e870610210935y2a97398enf18e17c41f123907@mail.gmail.com","threadId":"5925","inReplyTo":"BAYC1-PASMTP01706CD2FCBE923333A0CBAE020@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-21T16:35:18Z","receivedAt":"2006-10-21T16:35:18Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"On 10/21/06, Sean wrote:\n> On Sat, 21 Oct 2006 18:19:54 +0200\n> \"Erik Bågfors\" wrote:\n>\n> > This is just plain wrong.\n> >\n> > bzr is a fully decentralized VCS. I've read this thread for quite some\n> > time now and I really cannot understand why people come to this\n> > conclusion.\n> >\n> > However, if you do want to work centralized, bzr has commands that\n> > fits that workflow really good.\n>\n> Have you been reading this thread at all?\n\nYes.\n\n> Even the bzr people have now\n> stated rather firmly that the revno scheme doesn't work very well in\n> a number of situations. Numerous examples have been given where the\n> revno will be useless, or worse misleading when bzr is used without\n> a central server. The answer from the bzr folks has been then don't\n> use the revno in those situations. However, it's quite clear from the\n> bzr UI that there is a _bias_ towards using revno's.\n>\n> So yes, clearly you can use bzr without a central server; but it's just\n> as clearly biased against such usage.\n\nSo... I do agree that revnos might not fit perfectly in at all times.\nBut that they automatically mean that bzr is not a decentralized VCS,\nI strongly disagree with. They are just one part of the equation.\n\n/Erik\n-- \ngoogle talk/jabber. zindar@gmail.com\nSIP-phones: sip:erik_bagfors@gizmoproject.com\nsip:17476714687@proxy01.sipphone.com\n"},{"id":"29519","messageId":"453A513B.1070006@utoronto.ca","threadId":"5925","inReplyTo":"ehd5u7$c5g$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-21T16:56:27Z","receivedAt":"2006-10-21T16:56:27Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJakub Narebski wrote:\n> Jan Hudec wrote:\n> \n>> On Fri, Oct 20, 2006 at 12:05:35AM -0400, Aaron Bentley wrote:\n>>> Tim Webster wrote:\n>>>> Also svn does not allow files in the same directory to live in\n>>>> multiple repos\n>>> It would surprise me if many SCMs that support atomic commit also\n>>> support intermixing files from multiple repos in the same directory.\n>> In fact I think svk would. You would have to switch them by setting\n>> an environment variable, but it's probably doable. That is because\n>> unlike other version control systems, it does not store the information\n>> about checkout in the checkout, but in the central directory and that\n>> can be set. I don't know git well enough to tell whether git could do\n>> the same by setting GIT_DIR.\n> \n> You can very simply embed one \"clothed\" repository into another in GIT,\n> like shown below\n> \n> project/.git\n> project/subdir/\n> project/subdir/file\n> project/subproject/\n> project/subproject/.git\n> project/subproject/file\n> ...\n> \n> It depends on circumstances if one wants files belonging to subdirectory\n> be ignored by top repository. You would want to ignore .git/ directory,\n> though.\n\nAny SCM worth its salt should support that. AIUI, that's not what Tim\nwants. He wants to intermix files from different repos in the same\ndirectory.\n\ni.e.\n\nproject/file-1\nproject/file-2\nproject/.git-1\nproject/.git-2\n\nSo file-1 would be in the .git-1 repository, but file-2 would be in the\n.git-2 repository.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFOlE70F+nu1YWqI0RAvNcAJ0Rd6ovGoBNtKxcPNOrMH1yc+bzWQCfQlqT\nhREsUmCBAW8mIYzfzdnqZqU=\n=unGE\n-----END PGP SIGNATURE-----\n"},{"id":"29520","messageId":"200610211859.03420.jnareb@gmail.com","threadId":"5925","inReplyTo":"845b6e870610210931r19aaaac3y3dfd0d9c4af8ed40@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T16:59:02Z","receivedAt":"2006-10-21T16:59:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Erik Bågfors wrote:\n> Jakub Narebski wrote:\n>>\n>> There _are_ terminology conflicts. For example bzr \"branch\" is roughly\n>> equivalent to one-branch git \"repository\";\n> \n> Agreed.\n> \n>> bzr \"repository\" is just\n>> collection of branches sharing common storage,\n>\n> Agreed\n\nWhat is worse (in comparing git with bzr) that there are no exact\nequivalents. For example bzr \"branch\" is something between git\nrepository (clone of repository) and git branch. Bazaar-NG \"repository\"\nis something like multi-branch git repository, but also like collection\nof git repositories sharing object database.\n \n>> which is similar to set\n>> of git \"repositories\" with .git/objects/ linked to common object\n>> repository (storage area) or appropriately set alternates file\n>> (although that is not common usage in git, and for example you would\n>> have to be carefull with running git-prune); bzr \"lightweight checkout\"\n>> is equivalent to nonexistent \"lazy clone\"/\"remote alternates\" discussed\n>> on git mailing list but not implemented because of performance\n>> concerns; bzr \"normal checkout\" is I think similar to git \"shared\n>> clone\" (but shared clone is limited to repositories on the same\n>> filesystem); bzr \"heavyweight checkout\" is roughly equivalent to\n>> one-branch-only \"clone\" in git or cg (cg = Cogito).\n> \n> This is wrong. There are two kinds of checkouts\n> lightweight.. and \"normal/heavyweight\".\n> \n> I think you are getting this a little wrong, and I think the reason is\n> that you are thinking of repositories, while in bzr you normally think\n> of branches.\n\nAs I said: conflict of concepts. And perhaps philosophies.\n\n> For example, I think (correct me if I'm wrong) that if I have a git\n> repository of a upstream linux-repo (Linus' for example). I guess\n> I'll use \"pull\" to keep my copy up to date with the upstream repo? If\n> I then would like to hack something special, I would \"clone\" the repo\n> and get a new repo and that's where I do my work. Is that correct?\n\nNot exactly.\n\nTo work for example on Linus' version of Linux kernel you clone upstream\nlinux-repo git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\nWorking area is associated with repository in Git, not with \"branch\" like\nin Bazaar-NG. In default configuration 'master' (main) branch of cloned\nrepository (in the case of Linus' public repo it is the only branch)\ncorresponds to 'origin' branch in your repository.\n\nNow you can work on 'master' branch, putting your changes there. git-fetch\nwill update 'origin' branch to the current version of 'master' branch of\ncloned repo; git-pull will additionally merge into 'master', i.e. merge\nnew changes into your work.\n\nNow if you want to hack something special, that you prefer to use separate\nbranch for, you don't need to clone repository anew (although you could,\nusing --local --shared to reduce cost of cloning) but it is enough to\ncreate new branch in your repository. You can very easily switch between\nbranches using the same working area (in bzr it would probably mean \n\"branch checkout\" to the same directory).\n\n> In bzr you never (well...) clone a full repository, but you clone one\n\nIt's a pity... for example you usually want to have access to both\nstable ('master') and development ('next') branches, perhaps\nalso to fixes ('maint') and beta stage development ('pu') branches.\nIn bzr it is a bit work (to correctly setup \"repository\"), in git\nit is one command.\n\n> line-of-development (a branch). So \"bzr branch\" is always a\n> \"one-branch-only \"clone\" in git or cg\".\n\nMore or less.\n\n> \"bzr checkout\" is a \"bzr branch\" followed by a setting saying\n> \"whenever you commit here, commit in the master branch also\".\n\nGit doesn't have exact equivalent here. For \"bzr checkout\" on\nthe same system, it is similar to setting common object repository;\nfor remote \"bzr checkout\" it might be approximated by hooks which\nwould push changes to remote repository (although we would have\nto implement some transaction/journal framework).\n\n> \"bzr checkout --lightweight\" is a way to get only a snapshot of the\n> working tree out of a branch. Whenever you commit, it's done in the\n> remote branch.\n\nYes, but with \"bzr checkout --lightweight\" you get also pointer\nto remote branch where to commit changes. Git doesn't have something\nlike that, at least not for remote remote branch; mostly because of\npoor performance or need for fast and constant network connection\nto source branch.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29521","messageId":"200610211903.57655.jnareb@gmail.com","threadId":"5925","inReplyTo":"453A513B.1070006@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T17:03:57Z","receivedAt":"2006-10-21T17:03:57Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> AIUI, that's not what Tim wants.  He wants to intermix files from\n> different repos in the same directory.\n> \n> i.e.\n> \n> project/file-1\n> project/file-2\n> project/.git-1\n> project/.git-2\n> \n> So file-1 would be in the .git-1 repository, but file-2 would be\n> in the .git-2 repository.\n\nPossible (as I said), although it would screw up automatic repository \ndetection. So you would have to say \"git --git-dir=.git-1 commit -a\"\nor \"GIT_DIR=.git-2 git log -p; git diff; ...\", i.e. specify repo\nfor each command.\n\nOf course you would have to hide repositories from each other,\nand probably it would be better to hide files provided by other\nrepository.\n-- \nJakub Narebski\nPoland\n"},{"id":"29523","messageId":"Pine.LNX.4.64.0610211007320.3962@g5.osdl.org","threadId":"5925","inReplyTo":"453A513B.1070006@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-21T17:31:34Z","receivedAt":"2006-10-21T17:31:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 Oct 2006, Aaron Bentley wrote:\n> \n> Any SCM worth its salt should support that. AIUI, that's not what Tim\n> wants. He wants to intermix files from different repos in the same\n> directory.\n> \n> i.e.\n> \n> project/file-1\n> project/file-2\n> project/.git-1\n> project/.git-2\n\nOk, that's just insane.\n\nIt's going to always result in problems (ie some files are going to be \nconsidered \"untracked\" depending on which repository you're looking at \nright then and there).\n\nThat said, if you _really_ want this, you can do it. Here's now:\n\n\t# Create insane repository layout\n\tmkdir I-am-insane\n\tcd I-am-insane\n\n\t# Tell people we want to work with \".git-1\"\n\texport GIT_DIR=.git-1\n\n\tgit init-db\n\techo \"This is file 1 in repo 1\" > file-1\n\tgit add file-1\n\tgit commit -m \"Silly commit\" \n\n\t# Now we switch repos\n\texport GIT_DIR=.git-2\n\n\tgit init-db\n\techo \"This is another file in repo 2\" > file-2\n\tgit add file-2\n\tgit commit -m \"Silly commit in another repo\"\n\nand now you literally have two repositories in the same subdirectory, and \nthey don't know about each other, and you can switch your \"attention\" \nbetween them by simply doing\n\n\texport GIT_DIR=.git-1\n\n(or .git-2). Then you can just do \"git diff\" etc normally, and work in the \nrepo totally ignoring the other one in the same directory structure.\n\nOf course, things like \"git status\" that show untracked files will always \nthen show the \"other\" repository files as untracked - the two things will \nreally be _totally_ independent, they don't at any point know about each \nothers files, although they can actually _share_ checked-out files if you \nwant to:\n\n\techo \"This is a shared file\" > file-shared\n\n\texport GIT_DIR=.git-1\n\tgit add file-shared\n\tgit commit -m \"Add shared file to repo 1\"\n\n\texport GIT_DIR=.git-2\n\tgit add file-shared\n\tgit commit -m \"Add shared file to repo 2\"\n\nand now if you change that file, both repositories will see it as being \nchanged.\n\nINSANE. And probably totally useless. But you can do it. If you really \nwant to.\n\nThe git directories don't even have to be in the same subdirectory \nstructure. You could have done\n\n\texport GIT_DIR=~/insane-git-setup/dir1\n\ninstead, and the git information for that thing would have been put in \nthat subdirectory.\n\nNote: the above literally creates two different repositories. You can do \nthe same thing with a single object repository (so that any actual shared \ndata shows up in a shared database) by still using different GIT_DIR \nvariables, but using GIT_OBJECT_DIRECTORY to point to a shared database \ndirectory (which again could be anywhere - it could be under \".git-1\", or \nit could be in a separate place in your home directory).\n\nOr you could do it even _more_ differently by actually having just a \nsingle repository, and having two different branches in that repository, \nand just tracking them separately: in that case you would keep the same \nGIT_DIR/GIT_OBJECT_DIRECTORY (or keep them unset, which just means that \nthey default to \".git\" and \".git/objects\" as normal), and then just switch \nthe \"index\" file and the HEAD files around. That would mean that to switch \nfrom one \"view\" to the other, you'd do something like\n\n\texport GIT_INDEX_FILE=.git/index1\n\tgit symbolic-ref HEAD refs/heads/branch1\n\nto set your view to \"branch1\".\n\nAnyway, I would strongly discourage people from actually doing anything \nlike this. It should _work_, but quite frankly, if you actually want to do \nthis, you have serious mental problems.\n\nWhat's probably much better is to have two separate development \nrepositories, and then perhaps mixing the end _result_ somewhere else. For \nexample, you can use the\n\n\tgit checkout-index -a -f --prefix=/usr/shared/result/\n\nin both (separate) repositories, and you'll end up with basically a \nsnapshot of the \"union\" in /usr/shared/result.\n\n(Not that I see why you'd want to do that _either_, but hey, at least \nyou're not going to be _totally_ confused by the end result).\n\nAnyway. Git certainly allows you to do some really insane things. The \nabove is just the beginning - it's not even talking about alternate object \ndirectories where you can share databases _partially_ between two \notherwise totally independent repositories etc.\n\n\t\t\tLinus\n"},{"id":"29524","messageId":"845b6e870610211033h4b9d2667u6498fc7461473997@mail.gmail.com","threadId":"5925","inReplyTo":"BAYC1-PASMTP04FAD1FBB91BA4C07A5E79AE020@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-21T17:33:08Z","receivedAt":"2006-10-21T17:33:08Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"On 10/21/06, Sean wrote:\n> On Sat, 21 Oct 2006 18:35:18 +0200\n> \"Erik Bågfors\" wrote:\n>\n>\n> > So... I do agree that revnos might not fit perfectly in at all times.\n> > But that they automatically mean that bzr is not a decentralized VCS,\n> > I strongly disagree with. They are just one part of the equation.\n>\n> Whoe are you strongly disagreeing with? Nobody said it wasn't a\n> decentralized VCS. But there is a _clear_ bias towards using it\n> with a central server.\n\n\nOk, I take that back :)\n\nWhen I think \"centralized\" I think \"everyone must commit to a central\nrepository\"... which is not what we are talking about here...\n\n/Erik\nps. Sean, your mailer does something wierd with my last name in the\nto-field, so I can't just hit \"reply\" without removing my name\nfirst...\n\n/Erik\n\n-- \ngoogle talk/jabber. zindar@gmail.com\nSIP-phones: sip:erik_bagfors@gizmoproject.com\nsip:17476714687@proxy01.sipphone.com\n"},{"id":"29525","messageId":"Pine.LNX.4.64.0610211035170.3962@g5.osdl.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610211007320.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-21T17:38:50Z","receivedAt":"2006-10-21T17:38:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 Oct 2006, Linus Torvalds wrote:\n> \n> \t# Tell people we want to work with \".git-1\"\n> \texport GIT_DIR=.git-1\n\nActually, I think Jakub's approach is better: you'd be better off doing \nthis as\n\n\talias git-1=\"git --git-dir=.git-1\"\n\talias git-2=\"git --git-dir=.git-2\"\n\nand now you should be able to just do\n\n\tgit-1 diff\n\n(or any other git command) and\n\n\tgit-2 diff\n\nand can happily share the same directory and mix git commands without \nchanging an environment variable all the time.\n\nThat would still be insane, but it wouldn't likely be _quite_ as confusing \n(or error-prone in case you forgot to switch the variable).\n\n\t\t\tLinus\n\nPS. I'd still _not_ suggest doing this. It should _work_, but I mean - \nreally..\n"},{"id":"29526","messageId":"20061021174056.GA29927@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"20061020225917.GA30584@coredump.intra.peff.net","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-21T17:40:56Z","receivedAt":"2006-10-21T17:40:56Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Fri, Oct 20, 2006 at 06:59:17PM -0400, Jeff King wrote:\n> On Fri, Oct 20, 2006 at 08:12:10PM +0200, Jan Hudec wrote:\n> \n> > At this point, I expect the tree to look like this:\n> > A$ ls -R\n> > .:\n> > data/\n> > data:\n> > hello.txt\n> > A$ cat data/hello.txt\n> > Hello World!\n> \n> Git does what you expect here.\n> \n> > A$ VCT mv data greetings\n> > A$ VCT commit -m \"Renamed the data directory to greetings\"\n> > B$ echo \"Goodbye World!\" > data/goodbye.txt\n> > B$ VCT add data/goodbye.txt\n> > B$ VCT commit -m \"Added goodbye message.\"\n> > A$ VCT merge B\n> > \n> > And now I expect to have tree looking like this:\n> > \n> > A$ ls -R\n> > .:\n> > greetings/\n> > greetings:\n> > hello.txt\n> > goodbye.txt\n> \n> Git does not do what you expect here. It notes that files moved, but it\n> does not have a concept of directories moving. Git could, even without\n> file-ids or special patch types, figure out what happened by noting that\n> every file in data/ was renamed to its analogue in greetings/, and infer\n> that previously non-existant files in data/ should also be moved to\n> greetings/.\n> \n> However, I'm not sure that I personally would prefer that behavior. In\n> some cases you might actually WANT data/goodbye.txt, and in some other\n> cases a conflict might be more appropriate. In any case, I would rather\n> the SCM do the simple and predictable thing (which I consider to be\n> creating data/goodbye.txt) rather than be clever and wrong (even if it's\n> only wrong a small percentage of the time).\n> \n> In short, git doesn't do what you expect, but I'm not convinced that\n> it's a bug or lack of feature, and not simply a difference in desired\n> behavior.\n\nI still consider it a bug, but different problems of the file-id\nsolution have already been described in this thread that I consider bugs\nas well.\n\nBesides I start to think that it should be actually possible to solve\nthis case with the git-style approach. I have to state beforehand, that\nI don't know how the most recent git algorithm works, but I imagine\nthere is some kind of 'brackets' saying the text is in a given file. Now\nif those 'brackets' were not flat, but nested, ie. instead of saying\n'this is in foo/bar' it would say 'this is in bar is in foo', the\ndifference when renaming directory would only affect the 'outer bracket'\nand therefore merge correctly with adding content inside it.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29527","messageId":"200610211941.07635.jnareb@gmail.com","threadId":"5925","inReplyTo":"200610211859.03420.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T17:41:07Z","receivedAt":"2006-10-21T17:41:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Note: instead of symlinking .git/objects/ objects database,\nyou can simply set and export GIT_OBJECT_DIRECTORY environment\nvariable.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29528","messageId":"200610211951.43495.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061021174056.GA29927@artax.karlin.mff.cuni.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T17:51:43Z","receivedAt":"2006-10-21T17:51:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jan Hudec wrote:\n\n> Besides I start to think that it should be actually possible to solve\n> this case with the git-style approach. I have to state beforehand, that\n> I don't know how the most recent git algorithm works, but I imagine\n> there is some kind of 'brackets' saying the text is in a given file. Now\n> if those 'brackets' were not flat, but nested, ie. instead of saying\n> 'this is in foo/bar' it would say 'this is in bar is in foo', the\n> difference when renaming directory would only affect the 'outer bracket'\n> and therefore merge correctly with adding content inside it.\n\nYou mean, to consider \"contents\" of a directory union of contents\nof files and directories it contains, and then use the same \"rename\ndetection\" algorithm as for files?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29530","messageId":"453A5F6D.7020306@utoronto.ca","threadId":"5925","inReplyTo":"20061020141222.GA17497@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-21T17:57:01Z","receivedAt":"2006-10-21T17:57:01Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJeff King wrote:\n> On Thu, Oct 19, 2006 at 09:06:40PM -0400, Aaron Bentley wrote:\n> \n>> What's nice is being able see the revno 753 and knowing that \"diff -r\n>> 752..753\" will show the changes it introduced. Checking the revo on a\n>> branch mirror and knowing how out-of-date it is.\n> \n> I was accustomed to doing such things in CVS, but I find the git way\n> much more pleasant, since I don't have to do any arithmetic:\n> diff d8a60^..d8a60\n\n> Does bzr have a similar shorthand for mentioning relative commits?\n\nYes, you could e.g. do:\n\nbzr diff -r before:753..753\n\nAaron\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFOl9s0F+nu1YWqI0RAhW7AJ4vi4kgen/8h6j2AgueU+kcsmLrPwCeKry9\npp68K4rAmXjjkPvK32LvmPk=\n=qDn2\n-----END PGP SIGNATURE-----\n"},{"id":"29532","messageId":"20061021181149.GM75501@over-yonder.net","threadId":"5925","inReplyTo":"200610211608.18895.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-21T18:11:49Z","receivedAt":"2006-10-21T18:11:49Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Sat, Oct 21, 2006 at 04:08:18PM +0200 I heard the voice of\nJakub Narebski, and lo! it spake thus:\n> Dnia sobota 21. października 2006 15:01, Matthew D. Fuller napisał:\n> > \n> > I think we're getting into scratched-record-mode on this.\n>\n> [....]\n\nThank you for demonstrating my point 8-}\n\n\n> When two clones of the same repository (in git terminology), or two\n> \"branches\" (in bzr terminology), used by different people, cannot be\n> totally equivalent that is centralization bias.\n\nThis is obviously some new meaning of \"centralization\" bearing no\nresemblance whatsoever to how I understand the word.\n\nIn git, apparently, you don't give a crap about a branch's identity\n(alternately expressible as \"it has none\"), and so you throw it away\nall the time. Given that, revnos even if git had them would never be\nof ANY use to you, so it's no wonder you have no use for the notion.\n\nI DO give a crap about my branchs' identities. I WANT them to retain\nthem. If I have 8 branches, they have 8 identities. When I merge one\ninto another, I don't WANT it to lose its identity. When I merge a\nbranch that's a strict superset of second into that second, I don't\nWANT the second branch to turn into a copy of the first. If I wanted\nthat, I'd just use the second branch, or make another copy of it. I\ndon't WANT to copy it. I just want to merge the changes in, and keep\non with my branch's current identity.\n\nMaybe that's what you mean by 'centralization'; each branch is central\nto itself. That seems a pretty useless definition, though. In my\nmind, actually, it's MORE distributed; my branch remains my branch,\nand your branch remains your branch, and the difference doesn't keep\nus from working together and moving changes back and forth. Forcing\nmy branch to become your branch sounds a lot more \"centralized\" to me.\n\n\nNow, we can discuss THAT distinction. I'm not _opposed_ to git's\nmodel per se, and I can think of a lot of cases where it's be really\nhandy. But those aren't most of my cases. And as long as we don't\nagree on branch identity, it's completely pointless to keep yakking\nabout revnos, because they're a direct CONSEQUENCE of that difference\nin mental model. See? They're an EFFECT, not a CAUSE. If bzr didn't\nhave revnos, I'd STILL want my branch to keep its identity. You could\nname the mainline revisions after COLORS if you wanted, and I'd still\nwant my branch to keep its identity. Aren't we through rehashing the\nsame discussion about the EFFECTS?\n\n\n> > It refers both to the conceptual entity (\"a line of development\"\n> > roughly, much like what 'branch' means in git and VCS in general),\n> > and to the physical location (directory, URL)\n> \n> I'd rather use other name then. Perhaps \"forks\" for physical\n> \"branch\", i.e. branch metadata (like revno to revid mapping) +\n> object repository or pointer to it + optionally working area/working\n> files. \n\nIt's the same name in bzr because branches are their location, not\ntheir 'name'. Every branch always has a location, and every location\nrefers to a branch (well, as long as it's a location that's meaningful\nto bzr; \"/etc/passwd\" is a location, but it's nothing to do with bzr,\nso it's not a branch. Don't dawdle in irrelevancies).\n\n\n> And you say that bzr is not biased towards centralization? In git\n> you can just pull (fetch) to check if there were any changes, and if\n> there were not you don't get useless marker-merges.\n\nIf I don't tell you my branch has something in it ready to grab, you\nshouldn't merge it. It probably won't work, and is quite likely to\nset your computer on fire, slaughter and fillet your pet goldfish, and\nmake demons fly out of your nose. If you wanna get stuck with all my\nincomplete WIP, let's just use a CVS module and be done with it.\n\n\n> 2. But the preferred git workflow is to have two branches in each of\n> two clones. The 'origin' branch where you fetch changes from other\n> repository (so called \"tracking branch\") and you don't commit your\n> changes to [...]\n\nFunny, since this reads to me EXACTLY like the bzr flow of \"upstream\nbranch I pull\" and \"my branch I merge from upstream\" that's getting\nkvetched around...\n\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29534","messageId":"200610212020.08539.jnareb@gmail.com","threadId":"5925","inReplyTo":"453A5F6D.7020306@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T18:20:08Z","receivedAt":"2006-10-21T18:20:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> Jeff King wrote:\n>> On Thu, Oct 19, 2006 at 09:06:40PM -0400, Aaron Bentley wrote:\n>>\n>>> What's nice is being able see the revno 753 and knowing that \"diff -r\n>>> 752..753\" will show the changes it introduced. Checking the revo on a\n>>> branch mirror and knowing how out-of-date it is.\n>>\n>> I was accustomed to doing such things in CVS, but I find the git way\n>> much more pleasant, since I don't have to do any arithmetic:\n>> diff d8a60^..d8a60\n> \n>> Does bzr have a similar shorthand for mentioning relative commits?\n> \n> Yes, you could e.g. do:\n> \n> bzr diff -r before:753..753\n\nWhat about grandparent of commit (d8a60^^ or d8a60~2 in git),\nor choosing one of the parents in merge commit (d8a60^2 is second\nparent of a commit)? before:before:753 ?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29535","messageId":"20061021183428.GB29927@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"20061021102346.9cd3abce.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-21T18:34:28Z","receivedAt":"2006-10-21T18:34:28Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sat, Oct 21, 2006 at 10:23:46AM -0400, Sean wrote:\n> On Sat, 21 Oct 2006 16:13:28 +0200\n> Jan Hudec wrote:\n> \n> > Bzr is meant to be used in both ways, depending on user's choice.\n> > Therefore it comes with that infrastructure and you can choose whether\n> > you want to use it or not.\n> \n> >From what we've read on this thread, bzr appears to be biased towards\n> working with a central repo. That is the model that supports the use of\n> revnos etc that the bzr folks are so fond of. However Git is perfectly\n> capable of being used in any number of models, including centralized.\n> Git just doesn't make the mistake of training new users into using\n> features that are only stable in a limited number of those models.\n\nFor one think I, like others already expressed, think difference should\nbe made between 'centralized' and 'star-topology'. Subversion is\ncentralized -- I don't think bzr is biased towards that kind of\ncentralization, though it provides tools (bound branches) to make it\neasy.\n\nI would agree it IS biased towards viewing branches as organized in a\nhierarchy, while git strictly treats them as equal peers, which I'd call\nstar-topology (and I don't think it is because it _has_ revnos, but\nbecause the user interface strongly favors them over revids).\n\nOn the other hand git is biased away from centralized (as in subversion\nis centralized) in that it takes extra work to make sure you are always\nsynchronized (while bzr has bound branches to do the checking for you).\nFor open-source development, centralized is a wrong way to go, but\npeople use version control tools for other purposes as well and for some\nof them staying synchronized is important.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29537","messageId":"Pine.LNX.4.64.0610211102250.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061021174056.GA29927@artax.karlin.mff.cuni.cz","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-21T18:42:58Z","receivedAt":"2006-10-21T18:42:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 Oct 2006, Jan Hudec wrote:\n>\n> [ On not moving files that weren't moved originally, but whose\n> directories were moved ]\n> \n> I still consider it a bug, but different problems of the file-id\n> solution have already been described in this thread that I consider bugs\n> as well.\n> \n> Besides I start to think that it should be actually possible to solve\n> this case with the git-style approach.\n\nIt's certainly _possible_ to figure out, but one reason git does what it \ndoes is that it's just simpler (ie just ignore the whole \"directory move\" \nsituation entirely, and just consider it to be \"many files moved\"). \n\nAnother reason is that this really is an ambigious case. When the \ndirectory was moved, the file in question really didn't exist. So when it \nwas created independently of the move, it really _is_ somewhat ambiguous \nwhether the intention was to move it with the other files or whether the \nnew creation point is the right one.\n\nI think that for a human, the details would likely be obvious (and I \nsuspect that in most cases it would indeed move with the directory). But \nit really isn't totally clear: what does moving a directory imply for the \nfuture? Does it imply that the directory should never exist in the future, \nor does it just imply that the _current_ contents move?\n\nGit \"tends to\" have a policy of not caring about directories at all. For \nexample, git will not track an empty directory by default. You _can_ make \nit track one in your commits (the data structures support it), but you're \nreally just better of just thinking of git as tracking individual files, \nand nor really directories. So as far as git is concerned, \"directories\" \nmostly don't really have any existence on their own, they only exist as \npaths to reach files.\n\nIn that kind of mindset, renaming a directory really is about renaming the \nfiles that are in that directory, and that explains the git behaviour. It \nmay not necessarily be what you expect, but it _is_ consistent, and it's \nnot really \"wrong\" either. It's just another way of looking at the thing.\n\nAlso, I'd like to point out that people worry way too much about merges. \nThere are much harder merge conflicts to fix up. If you notice that things \ndidn't go the way you expected in a merge, even if it was done \nautomatically, you can just do a\n\n\tgit mv unexpected/directory/file expected/directory/file\n\tgit commit --amend\n\nwhich basically \"fixes up\" the automatic merge (that's what the \"--amend\" \nmeans: it means \"re-do the last commit with _this_ state instead).\n\n(Of course, you could also just make a separate commit to move the file, \nbut I think the \"manual fixup of the merge\" is just cleaner - just add a \nnote in the commit message to say you fixed it up by hand. When you do \nyour \"git commit --amend\", it will automatically just give you an editor \nto edit up the commit message too while you're at it).\n\nSo again: merges are certainly fairly \"hard\" from a SCM standpoint, but \nfrom a user standpoint, they tend to be not at all as important. I would \nagain argue that more important than the merge itself (which you can \ntrivially just fix up to match your expectations) is to make it easy to \nlater _show_ what happened, ie if you examine the file later, you should \nbe able to see where it came from.\n\n(And again, with git, things like \"git pickaxe\" - think of it as just a \n\"better annotate\" - will indeed pick up the similarity, regardless of \nwhether the rename was done manually or automatically as part of the \nmerge - exactly because git only really cares about actual contents).\n\nBtw, just to be honest: git _mostly_ thinks in terms of \"constant \npathname patterns\" as opposed to \"individual paths that move around\". \nThat's at least partly because of how I work. I actually fairly seldom \nlook at an individual file, and tend to much more often look at a group of \nfiles, and then it's a _lot_ more convenient to do\n\n\tgitk drivers/usb include/linux/usb*\n\nwhere those argument pathnames are _not_ a set of filenames that we track, \nbut really somethign more generic, namely a \"repository pathname subset\" \nwhich is constant. The above will show the _subset_ of the kernel \nrepository history that is relevant for all the named pathnames, but the \npathnames are _fixed_. It won't follow files that move out of the \nsubdirectories: it will show the history as seen from the viewpoint of a \ncertain subset of pathnames.\n\nThis also extends to things like \"git log\". So when you do\n\n\tgit log kernel/sched.c\n\nif you have a \"file ID\" mentality, you expect the above to follow renames. \nIt doesn't - even though git -can- follow renames, what the above actually \n_means_ is \"show the log for the fixed pathname set that only includes one \nsingle path\". \n\nSo if \"kernel/sched.c\" had originally been called something else, the \nabove wouldn't show the rename at all. It would just show that \"oh, this \npathname suddenly was created as a new file\", because from the viewpoint \nof that fixed pathname, that's _exactly_ what happens.\n\nWe've discussed adding a \"--follow\" flag to tell \"git log\" to consider the \nargument to not be a \"pathname filter\", but a \"individual file\" kind of \nthing, and I think there was even a patch for it, but I suspect it hasn't \nbeen a big issue, probably partly because you get rather used to the \n\"pathname filter\" approach fairly quickly. If you knew what the old \npathname was, for example, you could get git to _tell_ you about the \nrename by doing\n\n\tgit log -M -- \n\nand git would happily see the renames that happen _within_ that pathname \nfilter (the \"-M\" is there because by default \"git log\" doesn't show any \npatches at all, of course, so if you want to see the rename, you need to \ntell git so).\n\nAs a particular example of this behaviour, if you do\n\n\tgit log -M kernel/\n\nyou'll always see any renames that happen _within_ that subdirectory, but \nany files that are moved into (or out of) the subdirectory will be \nconsidered to be \"create\" or \"delete\" events - because you've literally \ntold git to ignore all history that is not relevant to the kernel/ \nsubdirectory (so they really _are_ \"create/delete\" events as far as that \nsubdirectory is concerned).\n\nIs this different from other SCM's? Hell yes. git does a lot of things \ndifferently. Is it useful? Again, hell yes. Especially for a maintainer, \nthe ability to talk about pathname _patterns_ is generally much more \nimportant than talking about any particular file.\n\n[ The pathname thing also means that it's trivial to ask questions like \n \"ok, so what happened to file xyz that I _know_ we used to have, but \n clearly don't have any more?\".\n\n You just do \"git log -- xyz\", and you'll see exactly what you wanted to \n see. The \"--\" here (and in a previous example) is because to avoid \n ambiguity, git requires that if you name files that don't actually \n exist, you make it clear that they are filenames, not just mistyped \n revision ID's or something else. ]\n\nIn general, git gives you the best of both worlds. It knows how to follow \nindividual files if you want to, but by default it uses this much more \ngeneric concept of \"pathname filters\". The default is definitely \ninfluenced both by my usage, and my (obviously very strong) opinions on \nwhat is more important (and thus the git \"mental model\").\n\n\t\tLinus\n"},{"id":"29538","messageId":"BAYC1-PASMTP05955CD84D4736EAEBB89AAE020@CEZ.ICE","threadId":"5925","inReplyTo":"20061021183428.GB29927@artax.karlin.mff.cuni.cz","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-21T18:47:04Z","receivedAt":"2006-10-21T18:47:04Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 20:34:28 +0200\nJan Hudec wrote:\n\n> For one think I, like others already expressed, think difference should\n> be made between 'centralized' and 'star-topology'. Subversion is\n> centralized -- I don't think bzr is biased towards that kind of\n> centralization, though it provides tools (bound branches) to make it\n> easy.\n\nA star-topology assumes there is a central server from which the points\nof the start emerge. It is very much a centralized model and one that\nbzr is clearly optimized for. The difference between bzr and say\ncvs is that bzr provides offline abilities where checkins to the\ncentral server can be deferred by checking them in locally first.\n\nThe bzr bias towards this model is implicit in its affection for\nrevnos, which depend on a central repository to syncronize them for\nall the points of the star.\n\n[...]\n> On the other hand git is biased away from centralized (as in subversion\n> is centralized) in that it takes extra work to make sure you are always\n> synchronized (while bzr has bound branches to do the checking for you).\n> For open-source development, centralized is a wrong way to go, but\n> people use version control tools for other purposes as well and for some\n> of them staying synchronized is important.\n\nPlease reconsider this point, Git can be configured to push every commit\nto a central server immediately. It's just that such a model is so inferior\nin almost every way, that it's not typically done.\n\nSean\n"},{"id":"29539","messageId":"20061021144704.71d75e83.seanlkml__27217.2001692981$1161456490$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"20061021183428.GB29927@artax.karlin.mff.cuni.cz","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-21T18:47:04Z","receivedAt":"2006-10-21T18:47:04Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 20:34:28 +0200\nJan Hudec wrote:\n\n> For one think I, like others already expressed, think difference should\n> be made between 'centralized' and 'star-topology'. Subversion is\n> centralized -- I don't think bzr is biased towards that kind of\n> centralization, though it provides tools (bound branches) to make it\n> easy.\n\nA star-topology assumes there is a central server from which the points\nof the start emerge. It is very much a centralized model and one that\nbzr is clearly optimized for. The difference between bzr and say\ncvs is that bzr provides offline abilities where checkins to the\ncentral server can be deferred by checking them in locally first.\n\nThe bzr bias towards this model is implicit in its affection for\nrevnos, which depend on a central repository to syncronize them for\nall the points of the star.\n\n[...]\n> On the other hand git is biased away from centralized (as in subversion\n> is centralized) in that it takes extra work to make sure you are always\n> synchronized (while bzr has bound branches to do the checking for you).\n> For open-source development, centralized is a wrong way to go, but\n> people use version control tools for other purposes as well and for some\n> of them staying synchronized is important.\n\nPlease reconsider this point, Git can be configured to push every commit\nto a central server immediately. It's just that such a model is so inferior\nin almost every way, that it's not typically done.\n\nSean\n"},{"id":"29541","messageId":"20061021185825.GC29927@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"4535345C.6090905@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-21T18:58:25Z","receivedAt":"2006-10-21T18:58:25Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Oct 17, 2006 at 03:51:56PM -0400, Aaron Bentley wrote:\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> Sean wrote:\n> > On Tue, 17 Oct 2006 00:24:15 -0400\n> > Aaron Bentley wrote:\n> >>- - you can use a checkout to maintain a local mirror of a read-only\n> >> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).\n> > \n> > \n> > I'm not sure what you mean here. A bzr checkout doesn't have any history\n> > does it?\n> \n> By default, they do. You must use a flag to get a checkout with no history.\n\nIf I can add some clarification: There is a lightweight checkout and\nheavyweight checkout. The former contains no history and does everything\n(except status and I am not sure about diff) by accessing the remote\ndata. The later contains mirror of the history data and does\nwrite-through on commit (and otherwise behaves like normal branch with\nrepository)\n\nWhat would be really useful would be a checkout, or even a branch (ie.\nwith ability to commit locally), that would only contain history data\nsince some point. This would allow downloading very little data when\nbranching, but than working locally as with normal repository clone.\n\nIn bzr this was already discussed and the storage supports so called\n\"ghost\" revisions, whose existence is known, but not their data. There\nare even repositories around that contain them (created by converting\ndata from arch), but to my best knowledge there is no user interface to\ncreate branches or checkouts with partial data.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29542","messageId":"BAYC1-PASMTP0816D1AFF1061427F862A3AE020@CEZ.ICE","threadId":"5925","inReplyTo":"20061021185825.GC29927@artax.karlin.mff.cuni.cz","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-21T19:02:33Z","receivedAt":"2006-10-21T19:02:33Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 20:58:25 +0200\nJan Hudec wrote:\n\n> In bzr this was already discussed and the storage supports so called\n> \"ghost\" revisions, whose existence is known, but not their data. There\n> are even repositories around that contain them (created by converting\n> data from arch), but to my best knowledge there is no user interface to\n> create branches or checkouts with partial data.\n\nIn Git the same functionality can be achieved with so called shallow-\nclones. Unfortunately, they've only been discussed and not yet\nimplemented.\n\nSean\n"},{"id":"29543","messageId":"20061021150233.c29e11c5.seanlkml__32740.957910619$1161457371$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"20061021185825.GC29927@artax.karlin.mff.cuni.cz","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-21T19:02:33Z","receivedAt":"2006-10-21T19:02:33Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 20:58:25 +0200\nJan Hudec wrote:\n\n> In bzr this was already discussed and the storage supports so called\n> \"ghost\" revisions, whose existence is known, but not their data. There\n> are even repositories around that contain them (created by converting\n> data from arch), but to my best knowledge there is no user interface to\n> create branches or checkouts with partial data.\n\nIn Git the same functionality can be achieved with so called shallow-\nclones. Unfortunately, they've only been discussed and not yet\nimplemented.\n\nSean\n"},{"id":"29544","messageId":"20061021191949.GA8096@coredump.intra.peff.net","threadId":"5925","inReplyTo":"20061021181149.GM75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-21T19:19:49Z","receivedAt":"2006-10-21T19:19:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 21, 2006 at 01:11:49PM -0500, Matthew D. Fuller wrote:\n\n> Maybe that's what you mean by 'centralization'; each branch is central\n> to itself. That seems a pretty useless definition, though. In my\n> mind, actually, it's MORE distributed; my branch remains my branch,\n> and your branch remains your branch, and the difference doesn't keep\n> us from working together and moving changes back and forth. Forcing\n> my branch to become your branch sounds a lot more \"centralized\" to me.\n> \n> Now, we can discuss THAT distinction. I'm not _opposed_ to git's\n\nOK, let's discuss. :)\n\nI think the concept of \"my\" branch doesn't make any sense in git.\nEveryone is working collectively on a DAG of the history, and we all\nhave pointers into the DAG. Something is \"my\" branch in the sense that I\nhave a repository with a pointer into the DAG, but then again, so do N\nother people. I control my pointer, but that's it.\n\nSo don't think of it as \"git throws away branch identity\" as much as\n\"git never cared about branch identity in the first place, and doesn't\nthink it's relevant.\"\n\nNow, there are presumably advantages and disadvantages to these\napproaches. I like the fact that I can prepare a repository from\nscratch, import it from cvs, copy it, push it, or do whatever I like,\nand the end result is always exactly the same (revids included). With\nyour model, on the other hand, it seems the advantages are that in many\ncases you can do things like distributed revnos.\n\n> agree on branch identity, it's completely pointless to keep yakking\n> about revnos, because they're a direct CONSEQUENCE of that difference\n> in mental model. See? They're an EFFECT, not a CAUSE. If bzr didn't\n> have revnos, I'd STILL want my branch to keep its identity. You could\n> name the mainline revisions after COLORS if you wanted, and I'd still\n> want my branch to keep its identity. Aren't we through rehashing the\n> same discussion about the EFFECTS?\n\nI agree completely.\n\n> > 2. But the preferred git workflow is to have two branches in each of\n> > two clones. The 'origin' branch where you fetch changes from other\n> > repository (so called \"tracking branch\") and you don't commit your\n> > changes to [...]\n> \n> Funny, since this reads to me EXACTLY like the bzr flow of \"upstream\n> branch I pull\" and \"my branch I merge from upstream\" that's getting\n> kvetched around...\n\nThe difference, I think, is that it's easier in git to move the upstream\naround: you simply start fetching from a different place. I'm not clear\non how that works in bzr (if it invalidates revnos or has other side\neffects).\n\n-Peff\n"},{"id":"29545","messageId":"20061021192038.GD29927@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"200610211951.43495.jnareb@gmail.com","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-21T19:20:38Z","receivedAt":"2006-10-21T19:20:38Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sat, Oct 21, 2006 at 07:51:43PM +0200, Jakub Narebski wrote:\n> Jan Hudec wrote:\n> \n> > Besides I start to think that it should be actually possible to solve\n> > this case with the git-style approach. I have to state beforehand, that\n> > I don't know how the most recent git algorithm works, but I imagine\n> > there is some kind of 'brackets' saying the text is in a given file. Now\n> > if those 'brackets' were not flat, but nested, ie. instead of saying\n> > 'this is in foo/bar' it would say 'this is in bar is in foo', the\n> > difference when renaming directory would only affect the 'outer bracket'\n> > and therefore merge correctly with adding content inside it.\n> \n> You mean, to consider \"contents\" of a directory union of contents\n> of files and directories it contains, and then use the same \"rename\n> detection\" algorithm as for files?\n\nYes, something like that.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29546","messageId":"200610212121.58245.jnareb@gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610211102250.3962@g5.osdl.org","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T19:21:57Z","receivedAt":"2006-10-21T19:21:57Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> We've discussed adding a \"--follow\" flag to tell \"git log\" to consider the \n> argument to not be a \"pathname filter\", but a \"individual file\" kind of \n> thing, and I think there was even a patch for it, but I suspect it hasn't \n> been a big issue, probably partly because you get rather used to the \n> \"pathname filter\" approach fairly quickly.\n\nIf I remember correctly, the patch implementing --follow was fairly\nintrusive, and was unfortunate in that it was posted during changes\nin diffcore.\n\nLack of --follow is not a big issue because you can do this \"by hand\";\nyou can use git-diff-tree -M at the end of file history to check if\n[git considers] it was moved from somewhere.\n\nDuring discussion we have agreed that we would like to have both\n--follow rename following limiter and static path limiter (and \nthat it would be nice to extend static path limiter to include globs).\n-- \nJakub Narebski\nPoland\n"},{"id":"29547","messageId":"200610212130.31414.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061021191949.GA8096@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T19:30:30Z","receivedAt":"2006-10-21T19:30:30Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King wrote:\n\n> The difference, I think, is that it's easier in git to move the upstream\n> around: you simply start fetching from a different place. I'm not clear\n> on how that works in bzr (if it invalidates revnos or has other side\n> effects).\n\nThat's good example of fully distributed approach. I can fetch directly\n(actually, I cannot) from Junio private repository, I can fetch from\npublic git.git repository, either using git:// or http:// protocol,\nI can fetch from somebody else clone of git repository: intermixing\nthose fetches, and revids (commit-ids) remain constant and unchanged.\n-- \nJakub Narebski\nPoland\n"},{"id":"29549","messageId":"200610212141.51829.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061021181149.GM75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T19:41:50Z","receivedAt":"2006-10-21T19:41:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthew D. Fuller wrote:\n> On Sat, Oct 21, 2006 at 04:08:18PM +0200 I heard the voice of\n> Jakub Narebski, and lo! it spake thus:\n>> Dnia sobota 21. października 2006 15:01, Matthew D. Fuller napisał:\n\n>> When two clones of the same repository (in git terminology), or two\n>> \"branches\" (in bzr terminology), used by different people, cannot be\n>> totally equivalent that is centralization bias.\n> \n> This is obviously some new meaning of \"centralization\" bearing no\n> resemblance whatsoever to how I understand the word.\n\nPerhaps I'd better use \"star topology bias\" instead of \"centralization\nbias\".\n \n> In git, apparently, you don't give a crap about a branch's identity\n> (alternately expressible as \"it has none\"), and so you throw it away\n> all the time.  Given that, revnos even if git had them would never be\n> of ANY use to you, so it's no wonder you have no use for the notion.\n\nIn git branches are lightweight. Branch names are local to repository.\nRepositories have identity. Bzr \"branch\" is strange mix of one-branch\ngit repository and git branch.\n\nGit main workflow is fully decentralized workflow. All clones of the\nsame repository are created equal. In bzr the suggested workflow\n(with revnos) forces one (or more) branches to be mainline (use \"merge\",\nget empty-merges, revnos don't change) and leaf (use \"pull\", revnos\nchange).\n \n> I DO give a crap about my branchs' identities.  I WANT them to retain\n> them.  If I have 8 branches, they have 8 identities.  When I merge one\n> into another, I don't WANT it to lose its identity.  When I merge a\n> branch that's a strict superset of second into that second, I don't\n> WANT the second branch to turn into a copy of the first.  If I wanted\n> that, I'd just use the second branch, or make another copy of it.  I\n> don't WANT to copy it.  I just want to merge the changes in, and keep\n> on with my branch's current identity.\n\nI don't understand. If I merge 'next' branch into 'master' in git, I \nstill have two branches: 'master' and 'next'.\n\nAnd I don't understand why you are so hung on branch identities. Yes, if\nsomebody clones your 'repo' repository, he can have your 'master' branch\n(refs/heads/master) named 'repo' (refs/heads/repo) or 'repo/master'\n(refs/remotes/repo/master), but why that matters to you. It is _his_\n(or her ;-) clone. \n\n> Now, we can discuss THAT distinction.  I'm not _opposed_ to git's\n> model per se, and I can think of a lot of cases where it's be really\n> handy.  But those aren't most of my cases.  And as long as we don't\n> agree on branch identity, it's completely pointless to keep yakking\n> about revnos, because they're a direct CONSEQUENCE of that difference\n> in mental model.  See?  They're an EFFECT, not a CAUSE.  If bzr didn't\n> have revnos, I'd STILL want my branch to keep its identity.  You could\n> name the mainline revisions after COLORS if you wanted, and I'd still\n> want my branch to keep its identity.  Aren't we through rehashing the\n> same discussion about the EFFECTS?\n\nFor revnos to work you MUST have one \"branch\" to be considered\nspecial, the hub in star topology. This very much precludes fully\ndistributed development. \n\nBTW. I get that you can use revids in revnos in bzr for fully\ndistributed and not star-topology geared development. But\nBazaar-NG revids are uglier that Git commit-ids.\n\n[...]\n>> And you say that bzr is not biased towards centralization? In git\n>> you can just pull (fetch) to check if there were any changes, and if\n>> there were not you don't get useless marker-merges.\n> \n> If I don't tell you my branch has something in it ready to grab, you\n> shouldn't merge it.  It probably won't work, and is quite likely to\n> set your computer on fire, slaughter and fillet your pet goldfish, and\n> make demons fly out of your nose.  If you wanna get stuck with all my\n> incomplete WIP, let's just use a CVS module and be done with it.\n\nIn git I can fetch your changes but I don't need to merge them. Take\nfor example Junio 'pu' (proposed updates) branch: this is the branch\nyou shouldn't merge as it's history is constantly being rewritten.\n\nIf you don't want for your WIP to be publicly available, you don't\npublish it. For example as far as I understand Junio works on Git\nin his private repository, with many, many feature branches, but\nhe does push to public [bare] repository only some subset of branches,\nand we can fetch/pull only those.\n\nBut still, if I am impatient I can pull from Junio every hour, and\nI don't get 24 totally useless empty merge messages if he took day\noff and didn't publish any changes till day later.\n\n>> 2. But the preferred git workflow is to have two branches in each of\n>> two clones. The 'origin' branch where you fetch changes from other\n>> repository (so called \"tracking branch\") and you don't commit your\n>> changes to [...]\n> \n> Funny, since this reads to me EXACTLY like the bzr flow of \"upstream\n> branch I pull\" and \"my branch I merge from upstream\" that's getting\n> kvetched around...\n\nBut please, have you realized that in this workflow the two clones\nof the same repository are totally symmetrical? One's 'master' is\nanother 'origin' and vice versa. After pull on one side, and pull\non the other side (without any changes in between) we have the same\ncontents, and the same revision names (commit-ids in git), even if\nthe changes (revisions) got to those clones in different order.\nIn bzr those two \"branches\" would get different revnos. No symmetry.\nFull distributed vs star topology (one branch \"central\", hence\n\"centralized\" - I don't mean need to access to one central repository,\nalthough...)\n\n-- \nJakub Narebski\nShadeHawk on #git\nPoland\n"},{"id":"29550","messageId":"20061021194703.GE29927@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"200610212130.31414.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-21T19:47:03Z","receivedAt":"2006-10-21T19:47:03Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sat, Oct 21, 2006 at 09:30:30PM +0200, Jakub Narebski wrote:\n> Jeff King wrote:\n> \n> > The difference, I think, is that it's easier in git to move the upstream\n> > around: you simply start fetching from a different place. I'm not clear\n> > on how that works in bzr (if it invalidates revnos or has other side\n> > effects).\n\nMoving upstram around does not invalidate revnos. Switching to different\nupstream (ie. the head revisions are different) does. And this may\nhappen by doing a merge with the previous mainline as non-first parent\n-- revnos are simply short aliases for revids, not persistent unique\nidenfiers.\n\n> That's good example of fully distributed approach. I can fetch directly\n> (actually, I cannot) from Junio private repository, I can fetch from\n> public git.git repository, either using git:// or http:// protocol,\n> I can fetch from somebody else clone of git repository: intermixing\n> those fetches, and revids (commit-ids) remain constant and unchanged.\n\nSo they (revids) do in bzr.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29551","messageId":"Pine.LNX.4.64.0610211237460.3962@g5.osdl.org","threadId":"5925","inReplyTo":"200610212130.31414.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-21T19:55:44Z","receivedAt":"2006-10-21T19:55:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 Oct 2006, Jakub Narebski wrote:\n> \n> That's good example of fully distributed approach. I can fetch directly\n> (actually, I cannot) from Junio private repository, I can fetch from\n> public git.git repository, either using git:// or http:// protocol,\n> I can fetch from somebody else clone of git repository: intermixing\n> those fetches, and revids (commit-ids) remain constant and unchanged.\n\nThis is nice for a couple of situations:\n\n - if some particular machine is down, nobody really cares. It doesn't \n really change the workflow at all if \"master.kernel.org\" were to be \n off-line due to some trouble - it just happens to be a machine with \n good bandwidth that a number of kernel (and git) developers have access \n to, but if you want to sync with something else, go wild. We could just \n sync directly between developers, although most people tend to have \n firewalls (I certainly have a very anal one - not even ssh gets in) \n making it usually easier to go through some - any - public place.\n\n But in git, the \"public place\" really is just an intermediary. It has \n nothing to do with anything history-wise, and it's revision ID's are a \n non-issue. It's just a temporary staging area (although re-using the \n same repo over and over for pushing things out obviously means you can \n do just incremental updates, so most everybody does that)\n\n - sometimes you have multiple branches in the same tree that have very \n _different_ sources. For example, you might start out cloning my tree, \n but if you _also_ want to track the stable tree, you just do so: you \n can just do\n\n\tgit fetch :\n\n at any time, and you now have a new branch that tracks a different \n repository entirely (to make it easier to keep track of them, you'd \n probably want to make note of this in your .config file or your remote \n tracking data, but that's a small \"usability detail\", not a real \n conceptual issue).\n\n - the same \"multi-source\" thing is true for pushing things out too, not \n just fetching: I still have my personal git.git repository on \n kernel.org for historical reasons, even though Junio maintains the \n normal one. So when I did some experimental (and broken) stuff for \"git \n unpack-objects\" in a local branch, and others were interested in fixing \n it, I just pushed it out to my git repo as a new branch - one that \n Junio doesn't have.\n\n So now my kernel.org git repo not only tracks all of Junio's branches \n (basically just a mirror of his tree), I also have a few stale branches \n of my own that I did some work on separately. So it's kind of a \n \"frankensteins monster\" of different branches from different sources. \n\n And I think that's fairly common, actually (ie many kernel developers \n that publicise their own git trees often have a \"linus\" branch that \n tracks mine, along with their own \"real\" branches)\n\nAnd note how in none of these situtations does it matter what the \n\"original\" branch was. It might even be a way to just pre-populate the \ntree. For a real-life example, a week or two ago, Jesper Juhl wanted to \ndownload my kernel tree (which is about 140MB in size), but he's somewhere \nin Europe, and apparently the connection to kernel.org was just _really_ \nslow. \n\nSo what I told him to do was:\n\n Hmm. I suspect most mirrors avoid the /pub/scm directory, but there are a \n few places that mirror git trees in general, eg\n\n http://www.jur-linux.org/git/\n\n might be closer to you.\n\n Once you have _one_ kernel repo, you can clone another easily using\n\n git clone --reference [localdir]\n\n but you do need to have the thing in git format, not just a snapshot, to \n do that.\n\nand that's exactly what he did (and he could have just fetched into the \noriginal archive entirely):\n\n I could only get 2-3kb/sec from kernel.org and at that speed 140MB is \n *HUGE*.\n\n That was a lot better. got more than 200kb/sec from there.\n\nso the point here is, \"distributed\" really is more than star-topology. If \nyou think outside the star, you can take useful shortcuts.\n\nNow, I'm sure that bzr can probably do all the same things. This is likely \nless an issue of \"technology\" than of \"mindset\". The \"git way\" tends to \nmake all of these things very trivial - the notion of tracking multiple \nbranches from multiple _different_ repositories in one local repo just \nfits very naturally in the whole git mentality.\n\n\t\t\tLinus\n"},{"id":"29552","messageId":"453A7D7E.8060105@utoronto.ca","threadId":"5925","inReplyTo":"87irie1wvv.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-21T20:05:18Z","receivedAt":"2006-10-21T20:05:18Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nCarl Worth wrote:\n> On Thu, 19 Oct 2006 21:06:40 -0400, Aaron Bentley wrote:\n>> I understand your argument now.\n>> It's nothing to do with numbers per se,\n>> and all about per-branch namespaces. Correct?\n> \n> The entire discussion is about how to name things in a distributed\n> system. The premise that Linus has put forth in a very compelling way,\n> is that attempting to use sequential numbers for names in a\n> distributed system will break down. The breakdown could be that the\n> names are not stable, or that the system is used in a centralized way\n> to avoid the instability of the names.\n\nSo I'd say that revnos without the context of a location can only refer\nto the current branch that the user is working on. They don't refer to\nthe mainline, which typically has its own numbers that don't match the\nuser's.\n\nIf you're saying that bzr is \"centralized\" in that the user's current\nbranch is special, then I'll say \"guilty as charged\".\n\n> But it really is fundamental and unavoidable that sequential numbers\n> don't work as names in a distributed version control system.\n\nRight. You need something guaranteed to be unique. It's the revno +\nurl combo that is unique. That may not be permanent, but anyone can\ncreate one of those names, so it is decentralized.\n\n>> I meant that the active branch and a mirror of the abandoned branch\n>> could be stored in the same repository, for ease of access.\n> \n> Granted, everything can be stored in one repository. But that still\n> doesn't change what I was trying to say with my example. One of the\n> repositories would \"win\" (the names it published during the fork would\n> still be valid). And the other repository would \"lose\" (the names it\n> published would be not valid anymore). Right?\n\nNo. It would be silly for the losing side to publish a mirror of the\nwinning branch at the same location where they had previously published\ntheir own branch. So the old number + URL combination would remain valid.\n\nIf the losing faction decided to maintain their own branch after the\nmerge, they'd have two options\n\n1. continue to develop against the losing \"branch\", without updating its\nnumbers from the \"winning\" branch. It would be hard to tell who had won\nor lost in this case.\n\n2. create a new mirror of the \"winning\" branch and develop against that.\n I'm not sure what this point of this would be.\n\nI think the most realistic thing in this scenario is that they leave the\n\"losing\" branch exactly where it was, and develop against the \"winning\"\nbranch.\n\n>> Bazaar encourages you to stick lots and lots of branches in your\n>> repository. They don't even have to be related. For example, my repo\n>> contains branches of bzr, bzrtools, Meld, and BazaarInspect.\n> \n> Git allows this just fine. And lots of branches belonging to a single\n> project is definitely the common usage. It is not common (nor\n> encouraged) for unrelated projects to share a repository, since a git\n> clone will fetch every branch in the repository.\n\nRight. This is a difference between Bazaar and Git that's I'd\ncharacterize as being \"branch-oriented\" vs \"repository-oriented\". We'll\nsee more of this below.\n\n> I'm noticing another terminology conflict here. The notion of \"branch\"\n> in bzr is obviously very different than in git. For example the bzr\n> man page has a sentence beginning with \"if there is already a branch\n> at the location but it has no working tree\". I'm still not sure\n> exactly what a bzr branch is, but it's clearly something different\n> from a git branch, (which is absolutely nothing more than a name\n> referencing a particular commit object).\n\nI got the impression there was also a local ordering of revisions. Is\nthat wrong?\n\nA Bazaar branch is a directory inside a repository that contains:\n - a name referencing a particular revision\n - (optional) the location of the default branch to pull/merge from\n - (optional) the location of the default branch to push to\n - (optional) the policy for GPG signing\n - (optional) an alternate committer-id to use for this branch\n - (optional) a nickname for the branch\n - other configuration options\n\nA Bazaar branch doesn't contain any commit objects (\"revisions\" in\nBazaar parlance). Those are retrieved from the containing repository.\n\nIt doesn't contain any working files, but a branch and a working tree\nmay coexist in the same directory. Similarly, a branch and a repository\nmay coexist in the same directory.\n\nSo this is one common layout:\n\nRepository:\n~/repo/\n\nBranch:\n~/repo/branch\n\nWorking Tree:\n~/workingtee\n\nThis is another common layout:\n\nRepository:\n~/\n\nBranch:\n~/mybranch\n\nWorking Tree\n~/mybranch\n\nThis layout is our default, a \"standalone tree\":\n\nRepository:\n~/mybranch\n\nBranch:\n~/mybranch\n\nWorking Tree:\n~/mybranch\n\nThis layout is an imitation of Git, as I understand it:\nRepository:\n~/repo\n\nBranches:\n~/repo/origin\n~/repo/master\n\nWorkingtree\n~/repo\n\n> Second, I'm not comfortable\n> with any limit on usefulness of history. Would you willingly throw\n> away commits, mailing list posts, or closed bug reports older than any\n> given age for any projects that you care about?\n\nI think the mailing list posts age the best, because they provide a\nrecord of rationales for design decsions. But I'd throw away old\ncommits if there were a good reason, like lack of disk space. Not so\nsure about bug reports.\n\n> Second, I think that using the filesystem for separating branches is a\n> really bad idea. \n\nThe canonical way to name branches in Bazaar is with URLs, though we\nsupport file paths where possible. Part of the \"simple namespace\" thing\nis that branches are simply URLs, so in order to retrieve a branch, all\nyou need is one URL.\n\n> One, it intrudes on my branch namespace, (note that\n> in many commands above I have to use things like \"../b\" where I'd like\n> to just name my branch \"b\". \n\nWhile \"bzr merge ../b\" is a minor inconvenience, I think that \"bzr merge\nhttp://bazaar-vcs.org/bzr/bzr.dev\" is a big win.\n\n> Two, it prevents bzr from having any\n> notion of \"all branches\" in places where git takes advantage of it,\n> (such as git-clone and \"gitk --all\").\n\nNo, it doesn't. Bazaar can easily list all the branches in a\nrepository, just by starting with the repository root, and recursing\nthrough all the subdirectories, looking for branches.\n\nThat said, we do have mentality that branches, not repositories, are\nwhat's important to users in day-to-day use.\n\n> Three, it certainly encourages\n> the storage problem I ran into above, (and I'd be interested to see a\n> \"corrected\" version of the commands above to fix the storage\n> inefficiencies).\n\n$ bzr init-repo bzrtest --trees\n$ bzr init bzrtest/master; cd bzrtest/master\n$ touch a; bzr add a; bzr commit -m \"Initial commit of a\"\n$ bzr branch . ../b; cd ../b\n$ touch b; bzr add b; bzr commit -m \"Commit b on b branch\"\n$ echo \"change\" > b; bzr commit -m \"Change b on b branch\"\n$ bzr branch ../master ../c; cd ../c\n$ touch c; bzr add c; bzr commit -m \"Commit c on c branch\"\n$ echo \"change\" > c; bzr commit -m \"Change c on c branch\"\n$ cd ../master\n$ bzr merge ../b; bzr commit -m \"Merge in b\"\n$ bzr merge ../c; bzr commit -m \"Merge in c\"\n\n> I hadn't realized that the dotted decimal notation was so new that the\n> community hadn't had a lot of experience with it yet. But, your\n> description doesn't actually presume that notation. What you asked\n> was:\n> \n> \t> When you create a new branch from scratch, the number starts at zero.\n> \t> If you copy a branch, you copy its number, too.\n> \t>\n> \t> Every time you commit, the number is incremented. If you pull, your\n> \t> numbers are adjusted to be identical to those of the branch you pulled from.\n> \t>\n> \t> Is that really complicated?\n> \n> And to answer. That description doesn't describe at all what happens\n> to the \"simple\" numbers of commits that are merged.\n\nNothing happens to them, because they were never part of this branch, so\nthey didn't ever exist in this context.\n\n> I still don't\n> understand how people can avoid number changing, (since pull seems the\n> only way to synch up without infinite new merge commits being added\n> back and forth).\n\nWhy would anyone commit if the merge introduced no changes?\n\n>> What's nice is being able see the revno 753 and knowing that \"diff -r\n>> 752..753\" will show the changes it introduced. Checking the revo on a\n>> branch mirror and knowing how out-of-date it is.\n> \n> With git I get to see a revision number of b62710d4 and know that\n> \"diff b62710d4^ b62710d4\" will show its changes, though much more\n> likely just \"show b62710d4\". I really cannot fathom a place where\n> arithmetic on revision numbers does something useful that git revision\n> specifications don't do just as easily. Anybody have an example for\n> me?\n\nMy understanding is that ^ is treated as a special metacharacter by some\nshells, which is why bzr revision specs are more long-winded.\n\n> PS. The \"bzr branch\" of bzr.dev did eventually finish. I can see the\n> dotted-decimal numbers in my example now, (1.1.1 and 1.2.2 for the\n> commits that came from branch b; 1.2.1 and 1.2.2 for the commits that\n> came from branch c). At 5 characters a piece these are well on their\n> way to getting just as \"ugly\" as git names, (once it's all\n> cut-and-paste the difference in ugliness is negligible).\n\nYeah, I'm not sure I like those dotted numbers, either.\n\n> And now, I see it's not just pull that does number rewriting. If I use\n> the following command (after the chunk of commands above):\n> \n> \tcd ..; bzr branch -r 1.2.2 master 1.2.2\n\nIt's not number rewriting, it's number writing. It doesn't change the\nnumbers in master, or any other existing branch. (Push also does number\nrewriting, because it's mostly the inverse of pull).\n\n> It appears to just create newly linearized revision numbers from whole\n> cloth for the new branch (1, 2, and 3 corresponding to mainline 1,\n> 1.2.1, and 1.2.2). That's totally surprising, very confusing, and\n> would invalidate any use I wanted to make of published revision\n> numbers for the mainline branch while I was working on this branch.\n\nI think the intent of those numbers was for operations like \"diff\". I\nnever branch from a revision, always from a branch, which will preserve\nnumbers.\n\n> See? This stuff really doesn't work.\n\nOur experience really is that it does work.\n\n> Is there even a way to say \"show me the change introduced by what is\n> named '1.2.1' in the source branch in this scenario\" ?\n\nThe revno:branch notation ought to work, but I guess there's a bug. Not\nsurprising, since dotted revnos are new in this release.\n\n> > Note: In #bzr I just learned that there is a way for me to do this\n> _if_ I also happen to have a pull of the original branch somewhere on\n> my machine. \n\nThis should work with any URL, not just locations on your machine.\n\n> But with bzr if I find \"1.2.1\" somewhere I'm likely to type:\n\nThe problem here is the \"somewhere\". Since each branch has its own\nrevno namespace, you need to know where to use the revno effectively.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFFOn190F+nu1YWqI0RAn1nAKCDqT8gbzm/xIMjbc3kTFCkpMbJvwCeJiWr\n3fLtDo4uLwtAWi+pQOrgPLU=\n=0GeT\n-----END PGP SIGNATURE-----\n"},{"id":"29553","messageId":"200610212219.14115.jnareb@gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610211237460.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T20:19:13Z","receivedAt":"2006-10-21T20:19:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n>  - sometimes you have multiple branches in the same tree that have very \n>    _different_ sources. For example, you might start out cloning my tree, \n>    but if you _also_ want to track the stable tree, you just do so: you \n>    can just do\n> \n>         git fetch :\n> \n>    at any time, and you now have a new branch that tracks a different \n>    repository entirely (to make it easier to keep track of them, you'd \n>    probably want to make note of this in your .config file or your remote \n>    tracking data, but that's a small \"usability detail\", not a real \n>    conceptual issue).\n\nThat for example allows of joining two initially separate projects\ninto one project. For example that was the case for gitk and gitweb\nwhich are now in git.git repository. Most probably gitweb/gitk was\nfetched into separate gitweb/gitk branch, then merged with the 'master'\nbranch of git (in case of gitweb we \"resolved conflict\" by moving \nall gitweb files to gitweb/ subdirectory) then propagated to other\nbranches by merging with master.\n\nFor example git has 7 \"initial\" (parentless) commits. Two of them\nare superficial 'html' and 'man' branches for automatic generation\nof HTML and man version of git documentation, keeping it current.\nThere is 'todo' branch, [also] totally separate for notes. And there\nare initial commits of git, git-tools, gitk and gitweb:\n * Initial revision of \"git\", the information manager from hell\n * Start of early patch applicator tools for git.\n * Add initial version of gitk to the CVS repository\n * first working version \n [of gitweb: this commit message should be more descriptive]\n\n$ git rev-list --parents --all | grep -v \" \" | xargs git -p show\n-- \nJakub Narebski\nPoland\n"},{"id":"29554","messageId":"87ac3p1jn7.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"20061021130111.GL75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-21T20:47:08Z","receivedAt":"2006-10-21T20:47:08Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 08:01:11 -0500, \"Matthew D. Fuller\" wrote:\n> I think we're getting into scratched-record-mode on this.\n\nI apologize if I've come across as beating a dead horse on this. I've\nreally tried to only respond where I still confused, or there are\nexplicit indications that the reader hasn't understood what I was\nsaying, (\"I don't understand how you've come to that conclusion\",\netc.). I'll be even more careful about that below, labeling paragraphs\nas \"I'm missing something\" or \"Maybe I wasn't clear\".\n\n> G: So use revids everywhere.\n>\n> B: Revnos are handier tools for [situation] and [situation] for\n> [reason] and [reason].\n\nI'm missing something:\n\nI still haven't seen strong examples for this last claim. When are\nthey handier? I asked a couple of messages back and two people replied\nthat given one revno it's trivial to compute the revno of its\nparent. But that's no win over git's revision specifications,\n(particularly since they provide \"parent of\" operators).\n\n> > It may be that the centralization bias\n>\n> I think it's more accurately describable as a branch-identity bias.\n> The git claim seems to be that the two statements are identical, but I\n> have some trouble swallowing that.\n\nMaybe I wasn't clear:\n\nThere's no doubt that there has been semantic confusion over the term\nbranch that has been confounding communication on both sides. Here's\nmy attempt to describe the situation, (which only became this clear\nrecently as I started playing with bzr more). This is not an attempt\nat a complete description, but is hopefully accurate, neutral, and\nsufficient for the current discussion:\n\n Abstract: In a distributed VCS we are using a distributed process to\n create a DAG, (nodes are associated with revisions and point to parent\n nodes). The distributed nature means that the collective DAG will have\n multiple source nodes, (often termed heads or tips).\n\n Git: A subset of the DAG is stored in a \"repository\". The DAG in the\n repository may have many source nodes. A \"branch\" is a named reference\n to a node (whether or not a source). Multiple local repositories may\n share storage for common objects. There are inter-repository commands\n for copying revisions and adjusting branch references, but basically\n all other operations act within a single repository.\n\n Bzr: A subset of the DAG is stored in a \"branch\". The DAG in the\n branch has a single source node. Multiple local branches may share\n storage for common objects through a \"repository\". Basically all\n operations (where applicable) can act between branches.\n\nLet me know if I botched any of that.\n\nOne concept that is really not introduced in the above is the\ncolloquial concept of a \"branch\" as a \"line of development\". In my\nexperience, this notion is a fundamentally short-lived thing. For\nexample, work happens on a feature branch for a while, and then it\ngets merged into the mainline. After the merge, there's not that much\nsignificance to the branch anymore. In a sense, it no longer exists\nbut for a few edges in the graph.\n\nI imagine that both git and bzr users both use this short-lived aspect\nin practice. After merging, git users drop their branch references and\nbzr users drop their directories containing their branches. Anything\nelse would be unwieldy as the number of merged-in, \"uninteresting\"\nbranches would grow without bound and there wouldn't be any advantage\nto keeping them around.\n\nBut dropping a merged branch in bzr means throwing away the ability to\nreference any of its commits by its custom, branch-specific revision\nnumbers. And the revision numbers _do_ change, pull, branch, and merge\nall introduce revision number differences between branches, (or\nchanges within a branch in the case of pull). And there is no simple\nway to correlate the numbers between branches.\n\nMaybe you can argue that there isn't any centralization bias in\nbzr. But anyone that claims that the revnos. are stable really is\ntalking from a standpoint that favors centralization.\n\nBut, here's a unifying point about git and bzr. Git also allows\nbranch-specific, unstable names for revisions. And they're even more\nunstable than the ones bzr generates. But there are some important\ndifferences between how they are used, (both by the tool and by\npeople).\n\nTo illustrate, yesterday I gave an example where performing a bzr\nbranch from a dotted-decimal revision would rewrite the numbers from\nthe originating branch (1.2.2, 1.2.1, and 1) to unrelated numbers in\nthe new branch (3, 2, 1). I was surprised at first, and couldn't\nimagine any sane reason for the tool to go off and invent new names.\nIt prevents a user of the new branch from referencing any commits by\ntheir original names. It also prevents the user from communicating\nwith anyone with these new names, (unless the user publishes the\nbranch, and any parties to the communication retain the new branch for\nas long as said communication might be reference).\n\nBut then I realized why bzr is doing this. It's because, bzr users\ndon't just use the revision numbers for external communication, but\nthey also use them for lots of direct interaction with the tool. The\nrewriting makes it easy to write something like \"bzr diff -r1..3\".\n\nAnd it turns out that git also allows branch specific naming for the\nexact same reason. In place of 3, 2, 1 in the same situation git would\nallow the names HEAD, HEAD~1, and HEAD~2 to refer to the same three\nrevisions. So the easy diff command would be \"git diff HEAD~2 HEAD\".\n(And where I have HEAD here I could also use any branch name, or any\nother reference to a commit as well.)\n\nSo there are two fundamentally different uses for names, (and Linus\nrecently talked about this in some length): 1. day-to-day working with\nthe tool and 2. externally communicating about specific revisions.\n\nBoth bzr and git allow for unstable, branch-specific names to be used\nas a convenience in the case of the day-to-day working. Maybe some of\nthe people that dislike git's \"ugly\" names so much is that they\nimagine that to compare two revisions a user of git must inspect the\nlogs, fish out the sha1sum for each, and then cut-and-paste to create\nthe command needed. I agree that if that were required, it would be\nexceedingly painful. But that's not required, what the git user uses\nis branch names and simple variations.\n\nNow, there are some important difference in the unstable names that\ngit and bzr has. Most importantly, git's are even less stable, (with\nrespect to the association between a name and any specific\nrevision). With every commit, all of the git names effectively shift\nas the branch moves, (HEAD points to the new commit, HEAD~1 points to\nwhat HEAD previously pointed to). This is remarkably useful since it\nprovides stability in terms of what the user cares about, (the latest\ncommit and it's closest ancestors). This means that \"diff from\ngrandparent to current commit\" is always \"git diff HEAD~1 HEAD\" where\nas in bzr it is \"git diff -r..\" and the user actually does\nneed to lookup X first, (unless there's more to the bzr revision\nspecification than I've seen).\n\nFinally, since these branch-specific names are changing all the time,\nthere's never any temptation for people to attempt to use them to for\nexternal communication. In contrast, by being numbered in the opposite\ndirection, bzr revision numbers give a false appearance of stability\nand people _do_ use them for communication. This is the mistake we've\nbeen warning bzr users about in this thread.\n\nAlso, since the git names are so predictable, git almost never emits\nthem. It accepts them as names just fine, but it doesn't generate\nthem, (log, and commit never show the branch-specific names). I think\nthe only git command that even can emit such a name was a recently\nadded git-name-rev which exists solely for the purpose of mapping a\ncommit identifier to a local, branch-specific name which might have\nmore intuitive meaning for the user.\n\nSo the fact that things like git-log doesn't print these names also\nhelps avoid any trap of users trying to communicate with something\nunstable.\n\n-Carl\n"},{"id":"29555","messageId":"200610212248.37935.jnareb@gmail.com","threadId":"5925","inReplyTo":"453A7D7E.8060105@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T20:48:37Z","receivedAt":"2006-10-21T20:48:37Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> Carl Worth wrote:\n\n>> I'm noticing another terminology conflict here. The notion of \"branch\"\n>> in bzr is obviously very different than in git. For example the bzr\n>> man page has a sentence beginning with \"if there is already a branch\n>> at the location but it has no working tree\". I'm still not sure\n>> exactly what a bzr branch is, but it's clearly something different\n>> from a git branch, (which is absolutely nothing more than a name\n>> referencing a particular commit object).\n> \n> I got the impression there was also a local ordering of revisions. Is\n> that wrong?\n\nNo, there is no such thing like local ordering of revisions.\n\nEach revision (commit) has link to its parent(s). Branch technically\nis just a reference to a particular commit object. The commit itself\ngives us sub-DAG of DAG of whole history, the DAG of all parents of\nsaid commit. Such lineage of commit pointed by branch is conceptually\na branch; i.e. branch is DAG of development (not line of development,\nas there is no special meaning of first parent).\n\nYou can have (in git repository) also reflog, which records values\nof branch-as-reference, or branch tip of branch-as-named-lineage.\nBut for example fetch and fast-forward 5 commits in history is\nrecorded as single event, single change in reflog.\n \n> A Bazaar branch is a directory inside a repository that contains:\n> - a name referencing a particular revision\n> - (optional) the location of the default branch to pull/merge from\n> - (optional) the location of the default branch to push to\n> - (optional) the policy for GPG signing\n> - (optional) an alternate committer-id to use for this branch\n> - (optional) a nickname for the branch\n> - other configuration options\nErm, wasn't revno to revid mapping also part of bzr \"branch\"?\n\nWe store configuration per repository, not per branch, although\nthere is some branch specific configuration.\n\n[...]\n> This layout is an imitation of Git, as I understand it:\n> Repository:\n> ~/repo\n> \n> Branches:\n> ~/repo/origin\n> ~/repo/master\n> \n> Workingtree:\n> ~/repo\n\nWorkingtree:\n~/\n\nif I understand notation correctly.\n\n>> One, it intrudes on my branch namespace, (note that\n>> in many commands above I have to use things like \"../b\" where I'd like\n>> to just name my branch \"b\".\n> \n> While \"bzr merge ../b\" is a minor inconvenience, I think that \"bzr merge\n> http://bazaar-vcs.org/bzr/bzr.dev\" is a big win.\n\nGaah, it's even more inconvenient. Certainly more than using name\nof branch itself, like in git.\n \n>> Two, it prevents bzr from having any\n>> notion of \"all branches\" in places where git takes advantage of it,\n>> (such as git-clone and \"gitk --all\").\n> \n> No, it doesn't. Bazaar can easily list all the branches in a\n> repository, just by starting with the repository root, and recursing\n> through all the subdirectories, looking for branches.\n\nIs there a command to list all branches in bzr? Is there a command\nto copy (clone in SCM jargon) whole repository with all branches?\n \n> That said, we do have mentality that branches, not repositories, are\n> what's important to users in day-to-day use.\n\nThats opposite to git view. In git, working area is associated with\nrepository (clone of repository), not branch. We copy whole repositories\n(sometimes only part of repository), not branches.\n\n>>> What's nice is being able see the revno 753 and knowing that \"diff -r\n>>> 752..753\" will show the changes it introduced. Checking the revo on a\n>>> branch mirror and knowing how out-of-date it is.\n>>\n>> With git I get to see a revision number of b62710d4 and know that\n>> \"diff b62710d4^ b62710d4\" will show its changes, though much more\n>> likely just \"show b62710d4\". I really cannot fathom a place where\n>> arithmetic on revision numbers does something useful that git revision\n>> specifications don't do just as easily. Anybody have an example for\n>> me?\n> \n> My understanding is that ^ is treated as a special metacharacter by some\n> shells, which is why bzr revision specs are more long-winded.\n\nWhich shells? If I understand it '^' was chosen (for example as\nNOT operator for specify sub-DAG instead of '!') because of no problems\nfor shell expansion. And considering that many git commands are/were\nwritten in shell, one certainly would notice that.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29556","messageId":"BAYC1-PASMTP07D0D16EAA6ABADDAD39B1AE020@CEZ.ICE","threadId":"5925","inReplyTo":"453A7D7E.8060105@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-21T20:53:13Z","receivedAt":"2006-10-21T20:53:13Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 16:05:18 -0400\nAaron Bentley wrote:\n\n> Our experience really is that it does work.\n\nOf course it works as long as you accept the implicit requirements of\nsupporting them and ignore the cases where they change out from\nunderneath the user. But as soon as users want to embrace distributive\nmodels where there isn't a central shared repo, at best revno's are\nunhelpful and at worst they are counterproductive. The proof of this\nis that if revno's were sufficient bzr wouldn't need revid's.\n\nSince the utility provided by revno's seems so minimal even in the\ncase where they do work, Git simply doesn't bother with them. And\n\"our\" experience is that Git really does work well without them.\n\nSean\n"},{"id":"29557","messageId":"20061021165313.dba67497.seanlkml__31643.6986359351$1161464024$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"453A7D7E.8060105@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-21T20:53:13Z","receivedAt":"2006-10-21T20:53:13Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 16:05:18 -0400\nAaron Bentley wrote:\n\n> Our experience really is that it does work.\n\nOf course it works as long as you accept the implicit requirements of\nsupporting them and ignore the cases where they change out from\nunderneath the user. But as soon as users want to embrace distributive\nmodels where there isn't a central shared repo, at best revno's are\nunhelpful and at worst they are counterproductive. The proof of this\nis that if revno's were sufficient bzr wouldn't need revid's.\n\nSince the utility provided by revno's seems so minimal even in the\ncase where they do work, Git simply doesn't bother with them. And\n\"our\" experience is that Git really does work well without them.\n\nSean\n"},{"id":"29558","messageId":"200610212255.49791.jnareb@gmail.com","threadId":"5925","inReplyTo":"87ac3p1jn7.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T20:55:49Z","receivedAt":"2006-10-21T20:55:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carl Worth wrote:\n\n> Also, since the git names are so predictable, git almost never emits\n> them. It accepts them as names just fine, but it doesn't generate\n> them, (log, and commit never show the branch-specific names). I think\n> the only git command that even can emit such a name was a recently\n> added git-name-rev which exists solely for the purpose of mapping a\n> commit identifier to a local, branch-specific name which might have\n> more intuitive meaning for the user.\n\ngit-show-branch also shows git-name-rev like names.\n\nBTW. git-show-branch has somewhat strange, and different from other git \ncommands UI. You can think of it as text version of gitk/qgit history \nviewer (although you can use tig for CLI (ncurses) graph).\n-- \nJakub Narebski\nPoland\n"},{"id":"29559","messageId":"Pine.LNX.4.64.0610211353070.3962@g5.osdl.org","threadId":"5925","inReplyTo":"845b6e870610210919i6d086654g3881343e6a3c9f84@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-21T21:04:56Z","receivedAt":"2006-10-21T21:04:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 Oct 2006, Erik Bågfors wrote:\n> \n> bzr is a fully decentralized VCS. I've read this thread for quite some\n> time now and I really cannot understand why people come to this\n> conclusion.\n\nEven the bzr people agree, so what's not to understand?\n\nThe revision numbers are totally unstable in a distributed environment \n_unless_ you use a certain work-flow. And that work-flow is definitely not \n\"distributed\" it's much closer to \"disconnected centralized\".\n\nNow, you could be truly distributed: BK used the same revision numbering \nthing, but was distributed. But BK didn't even try to claim that their \nrevision numbers were \"simple\" and that fast-forwarding is sometimes the \nwrong thing to do.\n\nSo BK always fast-forwarded, and the revision numbers were just randomly \nchanging numbers. They weren't stable, they weren't simple, and nobody \nclaimed they were.\n\nSo bzr can bite the bullet and say: \"revision numbers are changing and \nmeaningless, and we should just fast-forward on merges\", or you should \njust admit that bzr is really more about \"disconnected operation\" than \ntruly distributed.\n\nYou can't have your cake and eat it too. Truly distributed _cannot_ be \ndone with a stable dotted numbering scheme (unless the \"dotted numbering \nscheme\" is just a way to show a hash like git does - so the numbering has \nno _sequential_ meaning).\n\nBtw, this isn't just an \"opinion\". This is a _fact_. It's something they \nteach in any good introductory course to distributed algorithms. Usually \nit's talked about in the context of \"global clock\". \n\nAnybody who thinks that there exists a globally ticking clock in the \nsystem (and stably increasing dotted numbers are just one such thing) is \ntalking about some fantasy-world that doesn't exist, or a world that has \nnothing to do with \"distributed\".\n\n\t\t\tLinus"},{"id":"29560","messageId":"Pine.LNX.4.64.0610211405380.3962@g5.osdl.org","threadId":"5925","inReplyTo":"BAYC1-PASMTP07D0D16EAA6ABADDAD39B1AE020@CEZ.ICE","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-21T21:10:59Z","receivedAt":"2006-10-21T21:10:59Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 Oct 2006, Sean wrote:\n> \n> Since the utility provided by revno's seems so minimal even in the\n> case where they do work, Git simply doesn't bother with them. And\n> \"our\" experience is that Git really does work well without them.\n\nYes. This really is what it boils down to.\n\nThe _only_ time you actually use revision numbers (as opposed to \nbranch-names or tag-names) is when you want a _stable_ number.\n\nIt's that simple. You never really need a revision number otherwise. In \nother situations, you do things like \n\n\tgit log --since=2.days.ago\n\tgitk v2.6.18..\n\tgit diff --stat --summary ORIG_HEAD.. \n\nor whatever. It's clearly not \"stable\", but it's also clearly not a \nrevision number from a UI perspective.\n\nWhen you want a revision number is _exactly_ when you're moving things \nbetween branches, or reporting a bug to somebody else, or similar. And \nthat's also _exactly_ when you want the number to be stable and meaningful \n(ie the other end should be able to rely on the number).\n\nAnd if you need refer to a central repository to do that, it's clearly not \ndistributed. Not needing such a central reference point is what the word \n\"distributed\" _means_ in computer science for chrissake!\n\n\t\t\tLinus\n"},{"id":"29561","messageId":"20061021214629.GO75501@over-yonder.net","threadId":"5925","inReplyTo":"20061021191949.GA8096@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-21T21:46:29Z","receivedAt":"2006-10-21T21:46:29Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Sat, Oct 21, 2006 at 03:19:49PM -0400 I heard the voice of\nJeff King, and lo! it spake thus:\n> \n> I think the concept of \"my\" branch doesn't make any sense in git.\n> [...]\n> So don't think of it as \"git throws away branch identity\" as much as\n> \"git never cared about branch identity in the first place, and\n> doesn't think it's relevant.\"\n\nThis is as I understand it.\n\n\nBut in my mind, it does make sense. I fundamentally DO think of \"my\ncommits\" differently from \"revisions I've merged\", and I want the tool\nto preserve that for me. \"My commits\" tend to be steps along a path,\n\"merges\" tend to be completed paths. I usually use bzr's \"log\n--short\" for looking at logs, which doesn't show merged revs at all.\nThat works, because most of the time I don't care about them; I know\nif I merged something, it's a completed piece, which I described in\nthe log message; it's not a PART of a task like my commits usually\nare. So, just the message for my merge rev tells me what I need to\nknow, and if I need to drill down into it, I can use the regular\n(--long) log output to look at the revision in it. This lets me know,\nfor instance, that if I want to re-check something I did 3 commits\nago, and I just merged another branch, the commit I'm interested in is\nthe 4th commit back on the mainline; I don't need to grub through a\nbunch of revisions that aren't mine to try and find it.\n\nSo, if me and Bob are working on different bits of the same project in\nparallel, finish up, and merge back and forth to sync up (ignoring for\nthe moment the \"empty merge commit\" bit), even though we now both have\nthe 'same' stuff, we have the same head rev with all the same parents,\nthe parents are in a different order, and my 'mainline' (the path of\nleft-most parents, or 'first' as I understand git calls them) is\ndifferent than his; my mainline is my commits, his mainline is his.\nIf one of us were to 'pull' the other, our branch would become a\nduplicate of his and so adopt his 'mainline', which we want to avoid\nbecause then it doesn't fit the mental model of \"what I did\", which is\nwhat I think of my branch as.\n\n\nObviously, this is a totally foreign mentality to git, and that's\ngreat because it seems to work for you. I can see advantages to it,\nand I can conceive of situations where I might want that behavior.\nBut, in my day-to-day VCS use, I don't hit them, which is why I keep\ntyping 'bzr' instead of 'git' when I annoyingly need to type 'cvs'.\n\n\n> The difference, I think, is that it's easier in git to move the\n> upstream around: you simply start fetching from a different place.\n> I'm not clear on how that works in bzr (if it invalidates revnos or\n> has other side effects).\n\nDepends on what you're fetching. You can always tell 'bzr pull' a new\nURL to look from. If it's a later version of the 'same' branch, it'll\njust update. If it's a 'different' branch (a branch that's a superset\nof your current branch/set-of-revisions, but with a different\n'mainline' path through the revisions counts as 'different' here),\npull will complain and require a --overwrite to do the deed.\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29562","messageId":"BAYC1-PASMTP03CB0610A4C02971F3CE7FAE020@CEZ.ICE","threadId":"5925","inReplyTo":"20061021214629.GO75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-21T22:06:53Z","receivedAt":"2006-10-21T22:06:53Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 16:46:29 -0500\n\"Matthew D. Fuller\" wrote:\n\n> Obviously, this is a totally foreign mentality to git, and that's\n> great because it seems to work for you. I can see advantages to it,\n> and I can conceive of situations where I might want that behavior.\n> But, in my day-to-day VCS use, I don't hit them, which is why I keep\n> typing 'bzr' instead of 'git' when I annoyingly need to type 'cvs'.\n\nIt's not completely foreign, it's one of the things you can use the\ngit reflog feature to record. It's just that it's utterly clear in\nGit that this is a local feature and is never replicated as part\nof the distributed data.\n\n> Depends on what you're fetching. You can always tell 'bzr pull' a new\n> URL to look from. If it's a later version of the 'same' branch, it'll\n> just update. If it's a 'different' branch (a branch that's a superset\n> of your current branch/set-of-revisions, but with a different\n> 'mainline' path through the revisions counts as 'different' here),\n> pull will complain and require a --overwrite to do the deed.\n\nThis is where the git model is clearly superior and allows a true\ndistributed model. Because there is no concept of a \"mainline\"\n(except locally via reflog) you can always merge with anyone\nparticipating in the DAG without having to overwrite or lose ordering.\n\nSean\n"},{"id":"29563","messageId":"200610220025.32108.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061021214629.GO75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-21T22:25:31Z","receivedAt":"2006-10-21T22:25:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthew D. Fuller wrote:\n\n[cut]\n> Obviously, this is a totally foreign mentality to git, and that's\n> great because it seems to work for you.  I can see advantages to it,\n> and I can conceive of situations where I might want that behavior.\n> But, in my day-to-day VCS use, I don't hit them, which is why I keep\n> typing 'bzr' instead of 'git' when I annoyingly need to type 'cvs'.\n\nWell, not exactly. If you are interested in your changes, i.e. commits \ngenerated by you, you can (with new git) filter commits by author name,\ne.g. 'git log --author=\"$(git repo-config --get user.email)\"'. If you\nare interested in commits which you entered into repository, you can\n(with new git) filter commits by commiter.\n\nIf you are interested in history of your branch, you can enable reflog\nfor this branch. This is of course totally local information, and \ndoesn't get propagated. It records things like commits, merges, \nrebasing, starting branch anew, amending commits etc. Because it\nis separate from branch and DAG of revisions, we can do fast-forward\nand have identical DAG while having information about local history.\n\nBesides git users are used to refer to graphical history viewers,\nincluding gitk (Tcl/Tk, in git repository), qgit (Qt), gitview (GTK+, in \ncontrib/, less popular), git-show-branch (core git, strange UI, command \nline), tig (ncurses) for more complicated cases.\n\n\nI wonder if searching for one's own commits isn't the sign that\nthe project is of one-main-developer size (i.e. small project,\nwithout large number of distributed contributors). I think in large \nproject you rather ask of history of specified file, of specified part \nof project (specified directory), ask about why certain change was \nintroduced etc.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29568","messageId":"20061022005248.168709cb.froese@gmx.de","threadId":"5925","inReplyTo":"200610212248.37935.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Edgar Toernig","fromEmail":"froese@gmx.de","sentAt":"2006-10-21T22:52:48Z","receivedAt":"2006-10-21T22:52:48Z","isPatch":false,"sender":{"key":"froese@gmx.de","avatar":null},"body":"Jakub Narebski wrote:\n>\n> > My understanding is that ^ is treated as a special metacharacter by some\n> > shells, which is why bzr revision specs are more long-winded.\n> \n> Which shells?\n\nIn the traditional Bourne shell ^ is an alias for the pipe symbol |.\n\nCiao, ET.\n"},{"id":"29569","messageId":"1161472030.9241.174.camel@localhost.localdomain","threadId":"5925","inReplyTo":"87ac3p1jn7.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Jeff Licquia","fromEmail":"jeff@licquia.org","sentAt":"2006-10-21T23:07:10Z","receivedAt":"2006-10-21T23:07:10Z","isPatch":false,"sender":{"key":"jeff@licquia.org","avatar":null},"body":"On Sat, 2006-10-21 at 13:47 -0700, Carl Worth wrote:\n> I still haven't seen strong examples for this last claim. When are\n> they handier? I asked a couple of messages back and two people replied\n> that given one revno it's trivial to compute the revno of its\n> parent. But that's no win over git's revision specifications,\n> (particularly since they provide \"parent of\" operators).\n\nHaving used both (though my familiarity with git is less), in my opinion\nthe biggest win is the obvious one: sequential numbers work in the head\nbetter than SHA1 checksums.\n\n\"But it's not a problem in practice!\" is a good retort, except that I\nwonder whether the set of \"practices\" you're using includes anyone who\ndecided to pass on git in favor of something else--perhaps because they\nsaw a few SHAs float by and ran in terror. Beware of self-selection\nbias.\n\nPut another way, \"strength\" of example is often in the eye of the\nbeholder. That we continue to give you the same \"weak\" examples may be\nevidence that we have a different impression of their strengths, and\nthat your analysis of their strengths isn't convincing to us.\n\nI suppose this line of conversation still has value if you don't see any\nbenefit at all, but OTOH if you really don't see how sequential numbers\nare easier to work with in the head than SHA sums with modifiers, I'm\nnot sure that's a gap we can bridge.\n\n> Let me know if I botched any of that.\n\nI don't see any problems with it.\n\n> But dropping a merged branch in bzr means throwing away the ability to\n> reference any of its commits by its custom, branch-specific revision\n> numbers. And the revision numbers _do_ change, pull, branch, and merge\n> all introduce revision number differences between branches, (or\n> changes within a branch in the case of pull). And there is no simple\n> way to correlate the numbers between branches.\n> \n> Maybe you can argue that there isn't any centralization bias in\n> bzr. But anyone that claims that the revnos. are stable really is\n> talking from a standpoint that favors centralization.\n\nI wonder if part of the problem is that the revno scheme we've been\ntalking about (the x.y.z... format) doesn't technically exist in any\nreleased version of bzr that I know of.\n\nPrevious to 0.12, bzr revnos were absolutely a local thing; revisions\nfrom merges didn't even have revnos (except for the merge commit\nitself). If you merged a branch and you later wanted to recreate that\nbranch, or see a diff from that branch, etc., you had to use revids.\n\nSo when you talk of a \"centralization bias\" in bzr, a lot of us get\nconfused, defensive, etc., because from our perspective, bzr and git\nweren't all that much different until just recently.\n\nNow it may be that you're right that \"global\" revnos like bzr has now\nintroduce a bias in favor of centralization. If that's true, I'm not\nsure that totally vindicates the git model. We have to ask if the bias\nis a good thing, but so do you; after all, we may have done so because\nof user demand, and if our users want it, maybe yours will want it too\nsomeday.\n\n(I say \"may\" because I haven't been paying close attention to the new\nrevno conversation, so I don't want to sound more sure than I am.)\n\nBut I think bzr people are more willing to take a wait-and-see approach.\nLocal revnos weren't a big deal, so we're willing to bet that the new\n0.12 revnos won't be, either.\n\n> And it turns out that git also allows branch specific naming for the\n> exact same reason. In place of 3, 2, 1 in the same situation git would\n> allow the names HEAD, HEAD~1, and HEAD~2 to refer to the same three\n> revisions. So the easy diff command would be \"git diff HEAD~2 HEAD\".\n> (And where I have HEAD here I could also use any branch name, or any\n> other reference to a commit as well.)\n\nFYI: The strict analogy to HEAD~1 in bzr would be -2. And yes, -2 is\nevery bit as unstable as HEAD~1.\n\n> Finally, since these branch-specific names are changing all the time,\n> there's never any temptation for people to attempt to use them to for\n> external communication. In contrast, by being numbered in the opposite\n> direction, bzr revision numbers give a false appearance of stability\n> and people _do_ use them for communication. This is the mistake we've\n> been warning bzr users about in this thread.\n\nURLs are also used for communication, despite having many of the same\ndrawbacks as revnos in DVC systems. This could have been a fatal flaw,\nbut in reality, this has resulted in some best practices (\"permalinks\",\nfor example), and a sense of where a URL is appropriate and where it\nisn't. It's not perfect, and yet it's been wildly successful.\n\nCopying the flaws of a highly successful system does not guarantee\nsuccess, of course. On the other hand, it does influence our evaluation\nof the severity of the flaws.\n\nThere may be a danger, though, that the bzr community may want to pay\ncloser attention to.\n\nSeveral of us have pointed to the (branch, revno) combination as a\nsufficiently reliable communication method, and we may be right about\nthat. But, so far, those revnos have been entirely local to a single\nbranch, and have also been as absolutely reliable (locally speaking) as\na revid; the branch \"foo\" may go away, but while it's around, \"revision\n14 of branch foo\" will always mean the same thing. But we're now adding\nthe 0.12 revno scheme, with \"global\" revnos. Will those be as reliable?\nWill \"revision 2418.1.4 on bzr.dev\" work as well as \"revision 2418 on\nbzr.dev\" does now?\n"},{"id":"29570","messageId":"BAYC1-PASMTP03C2E7EB518177BA364DFBAE020@CEZ.ICE","threadId":"5925","inReplyTo":"1161472030.9241.174.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-21T23:25:39Z","receivedAt":"2006-10-21T23:25:39Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 19:07:10 -0400\nJeff Licquia wrote:\n\n> Several of us have pointed to the (branch, revno) combination as a\n> sufficiently reliable communication method, and we may be right about\n> that. But, so far, those revnos have been entirely local to a single\n> branch, and have also been as absolutely reliable (locally speaking) as\n> a revid; the branch \"foo\" may go away, but while it's around, \"revision\n> 14 of branch foo\" will always mean the same thing. But we're now adding\n> the 0.12 revno scheme, with \"global\" revnos. Will those be as reliable?\n> Will \"revision 2418.1.4 on bzr.dev\" work as well as \"revision 2418 on\n> bzr.dev\" does now?\n\nThere is no need to speculate, the numbers will only be reliable on a local\nbasis. So yes you can force a single repository like bzr.dev to always \"win\"\nany conflict and force the other guy to change ie. a central repo model.\nBut they can not be maintained consistently in a truly distributed\nsystem. As Linus pointed out that is fact, not opinion.\n\nNow the opinion of the bzr people is that it doesn't matter and that for\nall important cases it works well enough. If all the people who don't like\nthe look of sha1's self select bzr, so be it, but that doesn't change the\nfundamental argument.\n\nBut just to reiterate, the design of Git is flexible enough to where you\ncan automatically generate \"revno\" tags for every commit in your repo\n_today_. You'd end up with the exact same problems that bzr will\neventually hit, but Git already has everything you need today to refer\nto every commit in your repo as r1 r2 r3 r4 etc... \n\nSean\n"},{"id":"29571","messageId":"20061021192539.4a00cc3e.seanlkml__25816.3545084701$1161473173$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"1161472030.9241.174.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-21T23:25:39Z","receivedAt":"2006-10-21T23:25:39Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 19:07:10 -0400\nJeff Licquia wrote:\n\n> Several of us have pointed to the (branch, revno) combination as a\n> sufficiently reliable communication method, and we may be right about\n> that. But, so far, those revnos have been entirely local to a single\n> branch, and have also been as absolutely reliable (locally speaking) as\n> a revid; the branch \"foo\" may go away, but while it's around, \"revision\n> 14 of branch foo\" will always mean the same thing. But we're now adding\n> the 0.12 revno scheme, with \"global\" revnos. Will those be as reliable?\n> Will \"revision 2418.1.4 on bzr.dev\" work as well as \"revision 2418 on\n> bzr.dev\" does now?\n\nThere is no need to speculate, the numbers will only be reliable on a local\nbasis. So yes you can force a single repository like bzr.dev to always \"win\"\nany conflict and force the other guy to change ie. a central repo model.\nBut they can not be maintained consistently in a truly distributed\nsystem. As Linus pointed out that is fact, not opinion.\n\nNow the opinion of the bzr people is that it doesn't matter and that for\nall important cases it works well enough. If all the people who don't like\nthe look of sha1's self select bzr, so be it, but that doesn't change the\nfundamental argument.\n\nBut just to reiterate, the design of Git is flexible enough to where you\ncan automatically generate \"revno\" tags for every commit in your repo\n_today_. You'd end up with the exact same problems that bzr will\neventually hit, but Git already has everything you need today to refer\nto every commit in your repo as r1 r2 r3 r4 etc... \n\nSean\n"},{"id":"29572","messageId":"453AAFBD.7020009@utoronto.ca","threadId":"5925","inReplyTo":"200610212248.37935.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-21T23:39:41Z","receivedAt":"2006-10-21T23:39:41Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJakub Narebski wrote:\n> Aaron Bentley wrote:\n>> Carl Worth wrote:\n> \n> No, there is no such thing like local ordering of revisions.\n\n> You can have (in git repository) also reflog, which records values\n> of branch-as-reference, or branch tip of branch-as-named-lineage.\n> But for example fetch and fast-forward 5 commits in history is\n> recorded as single event, single change in reflog.\n\nThat must be what I was thinking of.\n\n>> A Bazaar branch is a directory inside a repository that contains:\n>> - a name referencing a particular revision\n>> - (optional) the location of the default branch to pull/merge from\n>> - (optional) the location of the default branch to push to\n>> - (optional) the policy for GPG signing\n>> - (optional) an alternate committer-id to use for this branch\n>> - (optional) a nickname for the branch\n>> - other configuration options\n> Erm, wasn't revno to revid mapping also part of bzr \"branch\"?\n\nIt's not part of the conceptual model. The revno-to-revid mapping is\ndone using the DAG. The branch just tracks the head.\n\nThe .bzr/branch/revision-history file is from an earlier model in which\nbranches had a local ordering. Nowadays, it can be treated as:\n - a reference to the head revision\n - a cache of the revno-to-revid mapping\n\n>> This layout is an imitation of Git, as I understand it:\n>> Repository:\n>> ~/repo\n>>\n>> Branches:\n>> ~/repo/origin\n>> ~/repo/master\n>>\n>> Workingtree:\n>> ~/repo\n> \n> Workingtree:\n> ~/\n> \n> if I understand notation correctly.\n\nThe notation was that ~/repo would contain the .git directory for the\nrepository.\n\n>> While \"bzr merge ../b\" is a minor inconvenience, I think that \"bzr merge\n>> http://bazaar-vcs.org/bzr/bzr.dev\" is a big win.\n> \n> Gaah, it's even more inconvenient. Certainly more than using name\n> of branch itself, like in git.\n\nOf course if you have a copy of bzr.dev on your computer, you don't need\nto type the full URL. it's just like the 'merge ../b' above.\n\nBut how can you use the branch name of a branch that isn't on your\ncomputer? I suspect git requires a separate 'clone' step to get it onto\nyour computer first.\n\n> Is there a command to list all branches in bzr?\n\nThere's one in the 'bzrtools' plugin.\n\n> Is there a command\n> to copy (clone in SCM jargon) whole repository with all branches?\n\nNo.\n\n>> My understanding is that ^ is treated as a special metacharacter by some\n>> shells, which is why bzr revision specs are more long-winded.\n> \n> Which shells? If I understand it '^' was chosen (for example as\n> NOT operator for specify sub-DAG instead of '!') because of no problems\n> for shell expansion. And considering that many git commands are/were\n> written in shell, one certainly would notice that.\n\nSorry, it's been quite a long time since people complained at me for\nusing ^, so I don't remember. Perhaps Edgar is right about it being the\npipe character in old shells.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD4DBQFFOq+80F+nu1YWqI0RAp/KAJ9Bw1q9/nd3gUAjcX3c+24aoEifeQCYlbD0\ntUZ01ra11vkQ7V3RzarXeg==\n=oFIC\n-----END PGP SIGNATURE-----\n"},{"id":"29573","messageId":"1161474168.9241.188.camel@localhost.localdomain","threadId":"5925","inReplyTo":"200610220025.32108.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Jeff Licquia","fromEmail":"jeff@licquia.org","sentAt":"2006-10-21T23:42:47Z","receivedAt":"2006-10-21T23:42:47Z","isPatch":false,"sender":{"key":"jeff@licquia.org","avatar":null},"body":"On Sun, 2006-10-22 at 00:25 +0200, Jakub Narebski wrote:\n> I wonder if searching for one's own commits isn't the sign that\n> the project is of one-main-developer size (i.e. small project,\n> without large number of distributed contributors). I think in large \n> project you rather ask of history of specified file, of specified part \n> of project (specified directory), ask about why certain change was \n> introduced etc.\n\nI don't think so. Recently, I've been trying to track a particular\npatch in the kernel. It was done as a series of commits, and probably\nwould have been its own branch in bzr, but when I was trying to group\nthe commits together to analyze them as a group, the easiest way to do\nthat was by the original committer's name.\n\nNow, there's probably a better way to hunt that stuff down, but in this\ncase hunting the user down worked for me. (It may have made a\ndifference that I was using gitweb instead of a local clone.)\n\nAnd the case of hunting down your own commits is just a degenerate case\nof hunting down someone else's.\n"},{"id":"29574","messageId":"8764ed1b7z.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"1161474168.9241.188.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-21T23:49:04Z","receivedAt":"2006-10-21T23:49:04Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 19:42:47 -0400, Jeff Licquia wrote:\n> I don't think so. Recently, I've been trying to track a particular\n> patch in the kernel. It was done as a series of commits, and probably\n> would have been its own branch in bzr, but when I was trying to group\n> the commits together to analyze them as a group, the easiest way to do\n> that was by the original committer's name.\n\nAs far as \"its own branch in bzr\" would such a branch remain available\nindefinitely even after being merged in to the main tree?\n\n> Now, there's probably a better way to hunt that stuff down, but in this\n> case hunting the user down worked for me. (It may have made a\n> difference that I was using gitweb instead of a local clone.)\n\nVast, huge, gaping, cosmic difference.\n\nAlmost none of the power of git is exposed by gitweb. It's really not\nworth comparing. (Now a gitweb-alike that provided all the kinds of\nvery easy browsing and filtering of the history like gitk and git\nmight be nice to have.)\n\n-Carl\n"},{"id":"29575","messageId":"Pine.LNX.4.64.0610211655130.3962@g5.osdl.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610211353070.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-21T23:58:56Z","receivedAt":"2006-10-21T23:58:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 Oct 2006, Linus Torvalds wrote:\n> \n> And that work-flow is definitely not \"distributed\" it's much closer to \n> \"disconnected centralized\".\n\nSide note: the only reason I think that distinction is worth making at all \nis when comparing git to bzr, and even then this is a fairly subtle \ndistinction, and probably not a huge deal in practice.\n\nI obviously think git is a nicer distributed design, but in the end, if \nyou compare to something like CVS or SVN that isn't even disconnected, the \ndifference between git and bzr in this sense is basically zero. \n\nSo I sound like I care, but at the same time, I realize very well that \nwhen coming from a totally centralized world, the details we're arguing \nare _so_ not important.\n\n\t\t\tLinus\n"},{"id":"29576","messageId":"874ptx1ahp.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"453AAFBD.7020009@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-22T00:04:50Z","receivedAt":"2006-10-22T00:04:50Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 19:39:41 -0400, Aaron Bentley wrote:\n> Of course if you have a copy of bzr.dev on your computer, you don't need\n> to type the full URL. it's just like the 'merge ../b' above.\n>\n> But how can you use the branch name of a branch that isn't on your\n> computer? I suspect git requires a separate 'clone' step to get it onto\n> your computer first.\n\nNo. You can merge a branch from a remote repository in a single step:\n\n\tgit pull http://example.com/git/repo branch-of-interest\n\nBut if you want to do something besides (or before) a merge, (for\nexample, just explore its history, do some diffs etc.) then you would\nfetch it instead, assigning it a local branch name in the process:\n\n\tgit fetch http://example.com/git/repo branch-of-interest:local-name\n\nAfter which \"local-name\" is all one would need to use. So after a\nfetch like the above, the equivalent of \"bzr missing --theirs-only\"\nwould be:\n\n\tgit log ..local-name\n\n[This shows some of the expressive power of git revision\nspecifications. There's no need for a separate \"missing\" command. It's\njust one case of viewing a particular subset of the DAG. And the\nspecification language makes almost all interesting subsets easy. The\n--mine-only specification would be \"local-name..\"]\n\nAnd beyond what bzr missing does (I believe) it's easy to also see the\npatch content of each commit with:\n\n\tgit log -p ..local-name\n\nAnd then if everything is happy, one could merge that branch in:\n\n\tgit pull . local-name\n\n(And, yes, it is the case that \"pull\" with a repository URL of \".\" is\nhow merging is done. It's bizarre to me that this is not \"git merge\nlocal-name\" instead. There actually _is_ a \"git merge\" command that\ncould be used here, but it is somewhat awkward to use, (requiring both\na commit message (without the -m of git-commit(!)) and an explicit\nmention of the current branch). So using it would be something like:\n\n\tgit merge \"merge of local-name\" HEAD local-name\n\nI've never claimed that git is completely free of its UI\nwarts---though there are fewer now than when I started using it.)\n\nBut, yes, the notion in git is to bring things in to the current\nrepository and then work with them locally. This has an advantage that\nnetwork traffic is spent only once if doing multiple operations, (say\nthe three steps shown above: 1) investigate commit messages, 2)\ninvestigate patch content, 3) perform the merge).\n\n-Carl\n"},{"id":"29577","messageId":"1161475645.9241.195.camel@localhost.localdomain","threadId":"5925","inReplyTo":"8764ed1b7z.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Jeff Licquia","fromEmail":"jeff@licquia.org","sentAt":"2006-10-22T00:07:25Z","receivedAt":"2006-10-22T00:07:25Z","isPatch":false,"sender":{"key":"jeff@licquia.org","avatar":null},"body":"On Sat, 2006-10-21 at 16:49 -0700, Carl Worth wrote:\n> On Sat, 21 Oct 2006 19:42:47 -0400, Jeff Licquia wrote:\n> > I don't think so. Recently, I've been trying to track a particular\n> > patch in the kernel. It was done as a series of commits, and probably\n> > would have been its own branch in bzr, but when I was trying to group\n> > the commits together to analyze them as a group, the easiest way to do\n> > that was by the original committer's name.\n> \n> As far as \"its own branch in bzr\" would such a branch remain available\n> indefinitely even after being merged in to the main tree?\n\nYes, in the sense that you can recreate the branch by using that\nbranch's last commit. But not in the git sense that there's a branch ID\npointing at the commit in question.\n\nYou know what? It occurs to me that much of the problem with git\nbranches vs. bzr branches might be solved when bzr gets proper tagging\nsupport. Because, after all, aren't branches more like special tags in\ngit?\n\n> > Now, there's probably a better way to hunt that stuff down, but in this\n> > case hunting the user down worked for me. (It may have made a\n> > difference that I was using gitweb instead of a local clone.)\n> \n> Vast, huge, gaping, cosmic difference.\n> \n> Almost none of the power of git is exposed by gitweb. It's really not\n> worth comparing. (Now a gitweb-alike that provided all the kinds of\n> very easy browsing and filtering of the history like gitk and git\n> might be nice to have.)\n\nSo, very probably, I would have had a far easier time of it if I had\nbeen able to really use git to do the work, instead of gitweb.\n\nI still don't think, though, that it's a sign of a small project to be\nconcerned about one's own branches more than others.\n"},{"id":"29578","messageId":"845b6e870610211709p13821dfdv1abab7225b0ab3a9@mail.gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610211353070.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-22T00:09:51Z","receivedAt":"2006-10-22T00:09:51Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"On 10/21/06, Linus Torvalds wrote:\n>\n>\n> On Sat, 21 Oct 2006, Erik Bågfors wrote:\n> >\n> > bzr is a fully decentralized VCS. I've read this thread for quite some\n> > time now and I really cannot understand why people come to this\n> > conclusion.\n>\n> Even the bzr people agree, so what's not to understand?\n\nThe use of the word \"decentralized\".\n\nWhen I think centralized, I think \"all users must commit to a central\nrepo/branch\". In this sense bzr is 100% fully decentralized. You are\nfree to commit to a none-central branch.\n\nWhat I mean is that it's fully decentralized, but it may have a bias\nto the usage of a central branch/repo.\n\n/Erik\n-- \ngoogle talk/jabber. zindar@gmail.com\nSIP-phones: sip:erik_bagfors@gizmoproject.com\nsip:17476714687@proxy01.sipphone.com\n"},{"id":"29579","messageId":"845b6e870610211713m413afd28tcdf24934df25d3f5@mail.gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610211655130.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-22T00:13:22Z","receivedAt":"2006-10-22T00:13:22Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"On 10/22/06, Linus Torvalds wrote:\n>\n>\n> On Sat, 21 Oct 2006, Linus Torvalds wrote:\n> >\n> > And that work-flow is definitely not \"distributed\" it's much closer to\n> > \"disconnected centralized\".\n>\n> Side note: the only reason I think that distinction is worth making at all\n> is when comparing git to bzr, and even then this is a fairly subtle\n> distinction, and probably not a huge deal in practice.\n>\n> I obviously think git is a nicer distributed design, but in the end, if\n> you compare to something like CVS or SVN that isn't even disconnected, the\n> difference between git and bzr in this sense is basically zero.\n>\n> So I sound like I care, but at the same time, I realize very well that\n> when coming from a totally centralized world, the details we're arguing\n> are _so_ not important.\n\nI have to agree. Personally I think both git, bzr and mercurial are\nall VERY nice systems. If they weren't all started about the same\ntime, I doubt we would have all three.\n\nI am happy to use either, but I have a small preference with bzr\nbecause it suites me. I'm saying this, just as a user, nothing else.\n\n/Erik\n-- \ngoogle talk/jabber. zindar@gmail.com\nSIP-phones: sip:erik_bagfors@gizmoproject.com\nsip:17476714687@proxy01.sipphone.com\n"},{"id":"29580","messageId":"200610220214.59368.jnareb@gmail.com","threadId":"5925","inReplyTo":"453AAFBD.7020009@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-22T00:14:58Z","receivedAt":"2006-10-22T00:14:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> Jakub Narebski wrote:\n>> Aaron Bentley wrote:\n\n>>> A Bazaar branch is a directory inside a repository that contains:\n>>> - a name referencing a particular revision\n>>> - (optional) the location of the default branch to pull/merge from\n>>> - (optional) the location of the default branch to push to\n>>> - (optional) the policy for GPG signing\n>>> - (optional) an alternate committer-id to use for this branch\n>>> - (optional) a nickname for the branch\n>>> - other configuration options\n>> Erm, wasn't revno to revid mapping also part of bzr \"branch\"?\n> \n> It's not part of the conceptual model. The revno-to-revid mapping is\n> done using the DAG. The branch just tracks the head.\n> \n> The .bzr/branch/revision-history file is from an earlier model in which\n> branches had a local ordering. Nowadays, it can be treated as:\n> - a reference to the head revision\n> - a cache of the revno-to-revid mapping\n\nIn git DAG is DAG od parents. There are no \"child\" links. So it is natural\nto refer to n-th ancestor of given commit (in git ~, in bzr -).\n\nTo have incrementing (from 1 for first revision on given branch) revision\nnumbers you either have to have links to \"children\", which automatically\nmeans that revisions cannot be immutable to allow for branching at\narbitrary revision, or to transverse DAG here and back again (perhaps\nwith cache of revno-to-revid mapping to help performance).\n\nAdditionally to have incrementing revision numbers you have to remember\nwhich part of DAG is our branch; which parent in merge to chose to follow.\nBazaar-NG decides here to distinguish first parent; to have first parent\nimmutable it doesn't use fast-forward and always use merge, sometimes\ngiving empty-merge. If you use \"pull\" numbers change.\n \n>>> This layout is an imitation of Git, as I understand it:\n>>> Repository:\n>>> ~/repo\n>>>\n>>> Branches:\n>>> ~/repo/origin\n>>> ~/repo/master\n>>>\n>>> Workingtree:\n>>> ~/repo\n>>\n>> Workingtree:\n>> ~/\n>>\n>> if I understand notation correctly.\n> \n> The notation was that ~/repo would contain the .git directory for the\n> repository.\n\nThe default layout of \"clothed\" repository is\n\n Repository:\n ~/repo/.git/\n\n Branches:\n ~/repo/.git/refs/heads/\n\n Workingtree:\n ~/repo/\n\n>>> While \"bzr merge ../b\" is a minor inconvenience, I think that \"bzr merge\n>>> http://bazaar-vcs.org/bzr/bzr.dev\" is a big win.\n>>\n>> Gaah, it's even more inconvenient. Certainly more than using name\n>> of branch itself, like in git.\n> \n> Of course if you have a copy of bzr.dev on your computer, you don't need\n> to type the full URL. it's just like the 'merge ../b' above.\n> \n> But how can you use the branch name of a branch that isn't on your\n> computer? I suspect git requires a separate 'clone' step to get it onto\n> your computer first.\n\nNo, as it was said in other messages in this thread, you can fetch\na branch (branches), even from other repository that the one you cloned\nfrom, into given branch (branches). For git it would be\n $ git fetch :\nYou probably would want to save above info in remotes file or in config.\nFor cg (Cogito) it would be\n $ cg branch-add #\n $ cg fetch \n\nIn git you always use names like 'master', 'next', 'HEAD' (meaning current\nbranch) and also HEAD^, next~5 when comparing branches, viewing history,\nmerging branches, switching to branch etc. Not '../master'...\n"},{"id":"29581","messageId":"200610220222.29009.jnareb@gmail.com","threadId":"5925","inReplyTo":"845b6e870610211713m413afd28tcdf24934df25d3f5@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-22T00:22:28Z","receivedAt":"2006-10-22T00:22:28Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Erik Bågfors wrote:\n\n>> So I sound like I care, but at the same time, I realize very well that\n>> when coming from a totally centralized world, the details we're arguing\n>> are _so_ not important.\n> \n> I have to agree. Personally I think both git, bzr and mercurial are\n> all VERY nice systems.  If they weren't all started about the same\n> time, I doubt we would have all three.\n\nIf I understand correctly bzr came to life much earlier than Monotone,\nMercurial and Git but it was in beta stages very long. Bazaar-NG\n\"repositories\" to group bunch of \"branches\" seems inspoted by hg or git.\nGit (and probably Mercurial) was inspired both by BitKeeper and Monotone.\nMonotone started to be reasonable fast around time when Git and Mercurial\ncame to be.\n\nP.S. I'd like very much to see \"history of SCM\", with links denoting\nborrowing of ideas, similar to the \"history of UNIX\" graphs...\n-- \nJakub Narebski\nPoland\n"},{"id":"29582","messageId":"1161478005.9241.210.camel@localhost.localdomain","threadId":"5925","inReplyTo":"20061021192539.4a00cc3e.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Jeff Licquia","fromEmail":"jeff@licquia.org","sentAt":"2006-10-22T00:46:45Z","receivedAt":"2006-10-22T00:46:45Z","isPatch":false,"sender":{"key":"jeff@licquia.org","avatar":null},"body":"On Sat, 2006-10-21 at 19:25 -0400, Sean wrote:\n> Now the opinion of the bzr people is that it doesn't matter and that for\n> all important cases it works well enough. If all the people who don't like\n> the look of sha1's self select bzr, so be it, but that doesn't change the\n> fundamental argument.\n\nWhich opinion is this? The opinion that old-style local revnos aren't a\nbig deal, or that new-style dotted revnos aren't a big deal?\n\nI suspect you're conflating the two, and interpreting certainty for the\nformer as certainty for the latter. Though I don't mind being\ncorrected.\n"},{"id":"29583","messageId":"Pine.LNX.4.64.0610211714440.3962@g5.osdl.org","threadId":"5925","inReplyTo":"1161475645.9241.195.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-22T00:47:40Z","receivedAt":"2006-10-22T00:47:40Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 Oct 2006, Jeff Licquia wrote:\n> \n> You know what? It occurs to me that much of the problem with git\n> branches vs. bzr branches might be solved when bzr gets proper tagging\n> support. Because, after all, aren't branches more like special tags in\n> git?\n\nBoth branches _and_ tags in git are 100% the same thing: they're just \nshorthand for the commit name. That's _literally_ all they are. They are a \nsymbolic name for a 160-bit SHA1 hash.\n\nSo yes, you can say that branches are like special tags, or that \n(unsigned) tags are like special branches. There's no real \"technical\" \ndifference: in both cases, it's just an arbitrary name for the top commit.\n\nHowever, there are some purely UI differences between tags and branches, \nwhich really don't affect any of the \"name->SHA1\" translation at all, but \nwhich affect how you can _use_ a tag-name vs a branch-name.\n\n - A branch is always a pointer to a _commit_ object.\n\n In contrast, a tag can point to anything. It can point to a tree (and \n that means that you can do _diff_ between a tag and a branch, but such \n a tree doesn't have any \"history\" associated with it - it's purely \n about a certain \"state\", so you cannot say that it has a parent or \n anything like that).\n\n A tag can also point to a single file object (\"blob\": pure file \n content), which is soemthing that the git.git repository uses to point \n to the GPG public key that Junio uses to sign things, for example.\n\n But perhaps more commonly, a tag can also point to a special \"tag\" \n object, which is just a form of indirection that can optionally contain \n an explanation and a digitally signed verification. When I cut a kernel \n release, for example, my tag's don't point to the commit that is the \n release commit, they point to a GPG-signed tag-object that in turn \n points to the commit. \n\n With those signed tags, people can verify (if they get my public key) \n that a particular release was something I did. And due to the \n cryptographic nature of the hash, trusting the tag object also means \n that you can trust the commit it points to, and the whole history that \n points to.\n\n So while from a _revision_lookup_ standpoint a \"branch\" and a \"tag\" do \n 100% the same thing, we put some limitations on branches: they always \n have to point to a commit.\n\n - Thanks to the limitation on branches being commits, branches can be \n \"checked out\" which is saying that you can make it the active working \n tree state. You cannot \"check out\" a tag: you need to have a branch \n that you check out and can do development on. So a \"tag\" is considered \n purely a stationary pointer: it cannot be committed to, and it cannot \n participate directly in development.\n\n This literally has nothing to do with looking up the SHA1 name \n associated with a tag or a branch, this is _purely_ an agreed-upon \n convention (that is enforced by higher-level commands like \"git \n checkout\"). So if you want to check out the state as of some tag, you \n must always do it within the confines of some branch.\n\n So for example, you could do\n\n\tgit checkout -b newbranch v2.6.18\n\n which uses a tag (\"v2.6.18\") to define where to start the branch, and \n then creates a branch called \"newbranch\" and checks that out. That's \n purely shorthand for\n\n\tgit branch newbranch v2.6.18\t# create 'newbranch', initialize \n\t\t\t\t\t# it at v2.6.18\n\n\tgit checkout newbranch\t\t# make 'newbranch' our currently \n\t\t\t\t\t#active branch\n\n but you are _not_ allowed to do\n\n\tgit checkout v2.6.18\n\n because that would leave you with a situation where your \"top-of-tree\" \n is a tag, and you couldn't do any development on it because you don't \n have a branch to develop _on_.\n\nBut all of these kinds of differences between tags and branches are really \nnot \"core technology\" and are purely about having adopted a convention. It \nis literally about just having certain \"usage rules\" for specific \n\"symbolic namespaces\".\n\n\"branch\" and \"tag\" are just the normal namespaces git gives you and always \nhas. You can have others too (and you can define your own) and those names \nwill automatically be used for lookup by all the basic git tools. Git \nwon't _touch_ those names in any other way, but it means that you can \ncreate your own tools around git that have their own rules about how the \nnames are managed, and you can still use them for lookup.\n\nFor example, you could have a \"svn\" namespace for a project imported from \nsvn, and that namespace would contain the SVN revision names for the \nproject, so that you could do\n\n\tgit diff svn/56..\n\nto see the difference between \"svn revision 56\" and your current HEAD, \nwithout necessarily polluting the \"real\" git tag namespace.\n\n(Which can matter, since some commands take arguments like \"--tags\", which \njust collects all the regular tags - so you might not want to use normal \ntags to remember your SVN revision mapping, even if it might technically \nbe fine).\n\n(The above was a totally made-up example. I don't think any of the svn \nimporters actually do anything like that: but we do use a few other \n\"namespaces\" internally: \"git bisect\" puts the bisection results in the \n\"bisect\" namespace, and the \"remotes\" namespace can be used to track \nremote heads as something _different_ than a local branch - so that you \nwon't check such a \"remote branch\" out directly by mistake)\n\n\t\t\tLinus\n"},{"id":"29584","messageId":"20061022010010.GB9082@thunk.org","threadId":"5925","inReplyTo":"200610220222.29009.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2006-10-22T01:00:10Z","receivedAt":"2006-10-22T01:00:10Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Oct 22, 2006 at 02:22:28AM +0200, Jakub Narebski wrote:\n> If I understand correctly bzr came to life much earlier than Monotone,\n> Mercurial and Git but it was in beta stages very long. Bazaar-NG\n> \"repositories\" to group bunch of \"branches\" seems inspoted by hg or git.\n> Git (and probably Mercurial) was inspired both by BitKeeper and Monotone.\n> Monotone started to be reasonable fast around time when Git and Mercurial\n> came to be.\n\nYes, bzr predates Mercurial and Git; I remember talking to Martin Pool\nabout Bazaar-BG at the the 2005 Linux.conf.au, which was before the BK\nturnoff. At the time, I had considered using bzr-ng (which has since\nbeen renamed bzr), but it didn't have branch functionality at that\npoint if I remember correctly. Both git and Mercurial started\ndevelopment at almost the same time right after the Larry McVoy\nannounced the pending withdrawal of the BitKeeper no-cost license. \n\nAbout one month after the announced BK turnoff date, I looked at the\nvarious options for transitioning e2fsprogs, and at that point\nMercurial was **substantially** faster than bzr, and I believe\nslightly ahead in features. I also looked at git, but at that point\nHg was easier to learn how to use, and I figured for a project the\nsize of e2fsprogs, I didn't need the power of git, so I decided in\nfavor of Mercurial because it looked like it would be easier for\npeople to learn how to use it.\n\nI think it's fair to say that the exchange in ideas have profited all\nthree projects, and that the different projects have different\nstrengths, \n\n\t\t\t\t\t\t- Ted\n"},{"id":"29585","messageId":"BAYC1-PASMTP087AE8DF27B298813E8171AE030@CEZ.ICE","threadId":"5925","inReplyTo":"1161478005.9241.210.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-22T01:26:45Z","receivedAt":"2006-10-22T01:26:45Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 20:46:45 -0400\nJeff Licquia wrote:\n\n> Which opinion is this? The opinion that old-style local revnos aren't a\n> big deal, or that new-style dotted revnos aren't a big deal?\n> \n> I suspect you're conflating the two, and interpreting certainty for the\n> former as certainty for the latter. Though I don't mind being\n> corrected.\n\nThe archives have all the posts of people claiming that there were no\nissues with revno's and fully distributed models. But it's okay, the\nissue really isn't all that important in the big scheme of things. Bzr\nand Git have much more in common than they have differences. I reject\nthat revno's are an example of where bzr is superior than Git, but\nthere are no doubt examples where I would concede that bzr has the edge.\n\nCheers,\nSean\n"},{"id":"29586","messageId":"20061021212645.2f9ba751.seanlkml__27035.2822998122$1161480439$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"1161478005.9241.210.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-22T01:26:45Z","receivedAt":"2006-10-22T01:26:45Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 20:46:45 -0400\nJeff Licquia wrote:\n\n> Which opinion is this? The opinion that old-style local revnos aren't a\n> big deal, or that new-style dotted revnos aren't a big deal?\n> \n> I suspect you're conflating the two, and interpreting certainty for the\n> former as certainty for the latter. Though I don't mind being\n> corrected.\n\nThe archives have all the posts of people claiming that there were no\nissues with revno's and fully distributed models. But it's okay, the\nissue really isn't all that important in the big scheme of things. Bzr\nand Git have much more in common than they have differences. I reject\nthat revno's are an example of where bzr is superior than Git, but\nthere are no doubt examples where I would concede that bzr has the edge.\n\nCheers,\nSean\n"},{"id":"29588","messageId":"1161487417.9241.220.camel@localhost.localdomain","threadId":"5925","inReplyTo":"20061021212645.2f9ba751.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Jeff Licquia","fromEmail":"jeff@licquia.org","sentAt":"2006-10-22T03:23:37Z","receivedAt":"2006-10-22T03:23:37Z","isPatch":false,"sender":{"key":"jeff@licquia.org","avatar":null},"body":"On Sat, 2006-10-21 at 21:26 -0400, Sean wrote:\n> On Sat, 21 Oct 2006 20:46:45 -0400\n> Jeff Licquia wrote:\n> > I suspect you're conflating the two, and interpreting certainty for the\n> > former as certainty for the latter. Though I don't mind being\n> > corrected.\n> \n> The archives have all the posts of people claiming that there were no\n> issues with revno's and fully distributed models. \n\n\"revno's\"? Which \"revno's\"? ...\n\nOK. So you are conflating the two. Could someone who isn't comment?\n"},{"id":"29589","messageId":"BAYC1-PASMTP08D76F2C30E8C80EABB6FAAE030@CEZ.ICE","threadId":"5925","inReplyTo":"1161487417.9241.220.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-22T03:30:14Z","receivedAt":"2006-10-22T03:30:14Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 23:23:37 -0400\nJeff Licquia wrote:\n\n> > The archives have all the posts of people claiming that there were no\n> > issues with revno's and fully distributed models. \n> \n> \"revno's\"? Which \"revno's\"? ...\n> \n> OK. So you are conflating the two. Could someone who isn't comment?\n\nNo, actually i'm not. Single revno's or your dotted revno's _both_ have the\nsame property. They can only be local data and can not guarantee stability\nin a fully distributed environment.\n\nSean\n"},{"id":"29590","messageId":"20061021233014.d4525a1d.seanlkml__10280.2026238807$1161487839$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"1161487417.9241.220.camel@localhost.localdomain","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-22T03:30:14Z","receivedAt":"2006-10-22T03:30:14Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 21 Oct 2006 23:23:37 -0400\nJeff Licquia wrote:\n\n> > The archives have all the posts of people claiming that there were no\n> > issues with revno's and fully distributed models. \n> \n> \"revno's\"? Which \"revno's\"? ...\n> \n> OK. So you are conflating the two. Could someone who isn't comment?\n\nNo, actually i'm not. Single revno's or your dotted revno's _both_ have the\nsame property. They can only be local data and can not guarantee stability\nin a fully distributed environment.\n\nSean\n"},{"id":"29593","messageId":"20061022074513.GF29927@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"453A7D7E.8060105@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-22T07:45:13Z","receivedAt":"2006-10-22T07:45:13Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sat, Oct 21, 2006 at 04:05:18PM -0400, Aaron Bentley wrote:\n> Carl Worth wrote:\n> > On Thu, 19 Oct 2006 21:06:40 -0400, Aaron Bentley wrote:\n> [...]\n> > But it really is fundamental and unavoidable that sequential numbers\n> > don't work as names in a distributed version control system.\n> \n> Right. You need something guaranteed to be unique. It's the revno +\n> url combo that is unique. That may not be permanent, but anyone can\n> create one of those names, so it is decentralized.\n\nBut it is *not* *distributed*. The definition of a distributed system\namong other things require, that resource identifiers are independent on\nthe location of the resources. So only using the revision-ids is really\ndistributed.\n\n> >> I meant that the active branch and a mirror of the abandoned branch\n> >> could be stored in the same repository, for ease of access.\n> > \n> > Granted, everything can be stored in one repository. But that still\n> > doesn't change what I was trying to say with my example. One of the\n> > repositories would \"win\" (the names it published during the fork would\n> > still be valid). And the other repository would \"lose\" (the names it\n> > published would be not valid anymore). Right?\n> \n> No. It would be silly for the losing side to publish a mirror of the\n> winning branch at the same location where they had previously published\n> their own branch. So the old number + URL combination would remain valid.\n\nI regularly use bzr and I never used git. But I'd not hesitate a second\nto pull --overwrite over the old location. Because the url has a meaning\n\"the base I develop against\" for me and I'd want to preserve that\nmeaning.\n\n> If the losing faction decided to maintain their own branch after the\n> merge, they'd have two options\n> \n> 1. continue to develop against the losing \"branch\", without updating its\n> numbers from the \"winning\" branch. It would be hard to tell who had won\n> or lost in this case.\n> \n> 2. create a new mirror of the \"winning\" branch and develop against that.\n> I'm not sure what this point of this would be.\n> \n> I think the most realistic thing in this scenario is that they leave the\n> \"losing\" branch exactly where it was, and develop against the \"winning\"\n> branch.\n> \n> >> Bazaar encourages you to stick lots and lots of branches in your\n> >> repository. They don't even have to be related. For example, my repo\n> >> contains branches of bzr, bzrtools, Meld, and BazaarInspect.\n> > \n> > Git allows this just fine. And lots of branches belonging to a single\n> > project is definitely the common usage. It is not common (nor\n> > encouraged) for unrelated projects to share a repository, since a git\n> > clone will fetch every branch in the repository.\n> \n> Right. This is a difference between Bazaar and Git that's I'd\n> characterize as being \"branch-oriented\" vs \"repository-oriented\". We'll\n> see more of this below.\n\nThis is one of things I on the other hand like better on bzr than git.\nBecause it is really branches and not repositories that I usually care\nabout.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"},{"id":"29594","messageId":"72877ab10610220049i602ab936m11181f1a2daf2aee@mail.gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610211007320.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Tim Webster","fromEmail":"tdwebste@gmail.com","sentAt":"2006-10-22T07:49:06Z","receivedAt":"2006-10-22T07:49:06Z","isPatch":false,"sender":{"key":"tdwebste@gmail.com","avatar":null},"body":"On 10/22/06, Linus Torvalds wrote:\n>\n>\n> On Sat, 21 Oct 2006, Aaron Bentley wrote:\n> >\n> > Any SCM worth its salt should support that. AIUI, that's not what Tim\n> > wants. He wants to intermix files from different repos in the same\n> > directory.\n> >\n> > i.e.\n> >\n> > project/file-1\n> > project/file-2\n> > project/.git-1\n> > project/.git-2\n>\n> Ok, that's just insane.\n[snip]\n> Anyway. Git certainly allows you to do some really insane things. The\n> above is just the beginning - it's not even talking about alternate object\n> directories where you can share databases _partially_ between two\n> otherwise totally independent repositories etc.\n\n\nPerhaps this is insane, but it does not make sense to track all config\nfiles in etc as though they belong in a single repo. Each\napplication/pkg has a set of associated config files. Actually in some\ncases it is easy to track which files belong in each application/pkg\nrepo. For example dpkg list conffiles per pkg. Additional config files\nnot in the application/pkg maintainer repo branch are easily added to\nthe application/pkg local repo branch.\n\nMy question is where should file metadata be stored in git? With hook\nscripts, the file metadata can be captured and applied appropriately.\n\nIf a similar thing can be done with bzr as Linus described for git, I\nam all ears.\n"},{"id":"29595","messageId":"200610221105.26421.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061022074513.GF29927@artax.karlin.mff.cuni.cz","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-22T09:05:25Z","receivedAt":"2006-10-22T09:05:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jan Hudec wrote:\n> On Sat, Oct 21, 2006 at 04:05:18PM -0400, Aaron Bentley wrote:\n>> Carl Worth wrote:\n>>> On Thu, 19 Oct 2006 21:06:40 -0400, Aaron Bentley wrote:\n\n>>>> Bazaar encourages you to stick lots and lots of branches in your\n>>>> repository.  They don't even have to be related.  For example, my repo\n>>>> contains branches of bzr, bzrtools, Meld, and BazaarInspect.\n>>> \n>>> Git allows this just fine. And lots of branches belonging to a single\n>>> project is definitely the common usage. It is not common (nor\n>>> encouraged) for unrelated projects to share a repository, since a git\n>>> clone will fetch every branch in the repository.\n>> \n>> Right.  This is a difference between Bazaar and Git that's I'd\n>> characterize as being \"branch-oriented\" vs \"repository-oriented\".  We'll\n>> see more of this below.\n> \n> This is one of things I on the other hand like better on bzr than git.\n> Because it is really branches and not repositories that I usually care\n> about.\n\nThat's probably because you are used to Bazaar-NG, and your habits\nspeaking. Think of git clone of repository as of bzr \"branch\".\n\nFor example git encourages using many short and longer-lived feature\nbranches; I don't see bzr encouraging this workflow.\n-- \nJakub Narebski\nPoland\n"},{"id":"29598","messageId":"845b6e870610220256u39d3d06wefd4f71851670812@mail.gmail.com","threadId":"5925","inReplyTo":"200610221105.26421.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-22T09:56:32Z","receivedAt":"2006-10-22T09:56:32Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"> For example git encourages using many short and longer-lived feature\n> branches; I don't see bzr encouraging this workflow.\n\nWhy not? I think it really does. And due to the fact that merges are\nmerges and will show up as such, I think it's very suitable for\nfeature branches.\n\nIn fact, in the bzr development of bzr itself. All commits are done\nin feature branches and then merged into bzr.dev (the main \"trunk\" of\nbzr) when they are considered stable.\n\nConsider the following\nbzr branch mainline featureA\ncd featureA\nhack hack; bzr commit -m 'f1'; hack hack bzr commit -m f2; etc\nNo I want to merge in mainline again\nbzr merge ../mainline; bzr commit -m merge\nhack hack; bzr commit -m f3; hack hack bzr commit -m f4; etc\n\nright now, I would have something line this in the branch log\n-----------------------------------------------------------------\ncommitter: Erik Bågfors \nbranch nick: featureA\nmessage:\n f4\n-----------------------------------------------------------------\ncommitter: Erik Bågfors \nbranch nick: featureA\nmessage:\n f3\n----------------------------------------------------------------\ncommitter: Erik Bågfors \nbranch nick: featureA\nmessage:\n merge\n -----------------------------------------------------------------\n committer: Foo Bar \n branch nick: mainline\n message:\n something done in mainline\n -----------------------------------------------------------------\n committer: Foo Bar \n branch nick: mainline\n message:\n something else done in mainline\n-----------------------------------------------------------------\ncommitter: Erik Bågfors \nbranch nick: featureA\nmessage:\n f2\n-----------------------------------------------------------------\ncommitter: Erik Bågfors \nbranch nick: featureA\nmessage:\n f1\n\nIn this view,I can easily see what was part of this feature branch,\nbecause the committs that belongs to the feature branch are not\nindented, and they have a \"branch nick\" of \"featureA\". I can also\neasily see what comes from other branches.\n\nI can also run bzr log with --line or --short which shows you only the\ncommits made in this branch and not the once that are merged in. So\nwith --line I would get something line\nErik Bågfors 2006-10-19 f4\nErik Bågfors 2006-10-19 f3\nErik Bågfors 2006-10-19 merge\nErik Bågfors 2006-10-19 f2\nErik Bågfors 2006-10-19 f1\n\nWhich will give me a good view of what has been done in this feature\nbranch only.\n\nIf I understand it correctly, in git, you don't really know what has\nbeen committed as part of this branch/repo, and what has been\ncommitted in another branch/repo (this is my understanding from\nreading this thread, I might be wrong, feel free to correct me again\n:) )\n\n/Erik\n-- \ngoogle talk/jabber. zindar@gmail.com\nSIP-phones: sip:erik_bagfors@gizmoproject.com\nsip:17476714687@proxy01.sipphone.com\n"},{"id":"29597","messageId":"20061022100028.GQ75501@over-yonder.net","threadId":"5925","inReplyTo":"20061021233014.d4525a1d.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-22T10:00:28Z","receivedAt":"2006-10-22T10:00:28Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Sat, Oct 21, 2006 at 11:30:14PM -0400 I heard the voice of\nSean, and lo! it spake thus:\n> On Sat, 21 Oct 2006 23:23:37 -0400\n> Jeff Licquia wrote:\n> > \n> > OK. So you are conflating the two. Could someone who isn't\n> > comment?\n> \n> No, actually i'm not. Single revno's or your dotted revno's _both_\n> have the same property.\n\nI think Jeff's actually meaning the other way around. We're confident\nthrough experience of the utility of the single revnos. We're NOT (at\nleast, I'm not) so convinced of the utility and usability of the\ndotted ones; they haven't gone through the crucible of experience yet.\n\nDuring the dotted-decimal discussion, I favored numbering from the\nmerge point (rather than the ancestral point) for a lot of the same\nreasons brought up here. e.g., the log-ish output would look\nsomething like:\n\n200\n199\n 199.3\n 199.2\n 199.1\n198\n[...]\n\nSee \nfor instance.\n\nOf course, now we have them, and they number from ancestors. So\nafter that's in a couple releases, we'll get to see how it works in\npractice.\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29604","messageId":"BAYC1-PASMTP06A1103ECEE8ECB006B3BDAE030@CEZ.ICE","threadId":"5925","inReplyTo":"20061022100028.GQ75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-22T11:44:22Z","receivedAt":"2006-10-22T11:44:22Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 22 Oct 2006 05:00:28 -0500\n\"Matthew D. Fuller\" wrote:\n\n> I think Jeff's actually meaning the other way around. We're confident\n> through experience of the utility of the single revnos. We're NOT (at\n> least, I'm not) so convinced of the utility and usability of the\n> dotted ones; they haven't gone through the crucible of experience yet.\n> \n\nYes, that's the way I took what he said as well.\n\nBzr revnos (dotted or otherwise) can not be guaranteed to be stable\nin a truly distributed system. Now it's clear that you folks\njust don't really care about that and you're happy enough that they\nwork out fine for your uses. That's a fair enough decision to make;\nthere's no law that says you have to care about the situations where\nthere will be clashes and/or the numbers will change. Git makes\na different choice, and for my money it's a better choice.\n\nCheers,\nSean\n"},{"id":"29605","messageId":"20061022074422.50dcbee6.seanlkml__21103.2852800146$1161517652$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"20061022100028.GQ75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-22T11:44:22Z","receivedAt":"2006-10-22T11:44:22Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 22 Oct 2006 05:00:28 -0500\n\"Matthew D. Fuller\" wrote:\n\n> I think Jeff's actually meaning the other way around. We're confident\n> through experience of the utility of the single revnos. We're NOT (at\n> least, I'm not) so convinced of the utility and usability of the\n> dotted ones; they haven't gone through the crucible of experience yet.\n> \n\nYes, that's the way I took what he said as well.\n\nBzr revnos (dotted or otherwise) can not be guaranteed to be stable\nin a truly distributed system. Now it's clear that you folks\njust don't really care about that and you're happy enough that they\nwork out fine for your uses. That's a fair enough decision to make;\nthere's no law that says you have to care about the situations where\nthere will be clashes and/or the numbers will change. Git makes\na different choice, and for my money it's a better choice.\n\nCheers,\nSean\n"},{"id":"29608","messageId":"20061022124635.GR75501@over-yonder.net","threadId":"5925","inReplyTo":"87ac3p1jn7.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-22T12:46:35Z","receivedAt":"2006-10-22T12:46:35Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"[ Time to trim up CC's a bit ]\n\nOn Sat, Oct 21, 2006 at 01:47:08PM -0700 I heard the voice of\nCarl Worth, and lo! it spake thus:\n> On Sat, 21 Oct 2006 08:01:11 -0500, \"Matthew D. Fuller\" wrote:\n> > I think we're getting into scratched-record-mode on this.\n> \n> I apologize if I've come across as beating a dead horse on this.\n\nOh, I don't mean the whole topic in general. It's just that there are\nonly so many ways one can say \"revnos are only valid in certain\nsituations\", and I really think we must have hit them all by now. We\nall agree on that; we just disagree (probably highly based on\ndiffering workflows) on the commonness and extent of those situations.\n\n\n> > B: Revnos are handier tools for [situation] and [situation] for\n> > [reason] and [reason].\n> \n> I'm missing something:\n> \n> I still haven't seen strong examples for this last claim. When are\n> they handier?\n\nThis ties in a bit with what you say below, so I'll address it there.\n\n\n> There's no doubt that there has been semantic confusion over the\n> term branch that has been confounding communication on both sides.\n [...]\n> Let me know if I botched any of that.\n\nThis seems correct; at least, it's correct enough to work from until\nwe find a detail wrong.\n\n\n> But dropping a merged branch in bzr means throwing away the ability to\n> reference any of its commits by its custom, branch-specific revision\n> numbers.\n\nTrue (though see below).\n\n\n> And there is no simple way to correlate the numbers between\n> branches.\n\nRather, unless you can one way or another access the branch the number\nwas for, there's NO way.\n\n\n> Maybe you can argue that there isn't any centralization bias in bzr.\n> But anyone that claims that the revnos. are stable really is talking\n> from a standpoint that favors centralization.\n\nI think it's using that 'c' word there that's causing contention here;\nwe're ascribing different meanings to it.\n\nRevnos only apply to a specific \"branch\" (in this usage, I'm talking\nabout branch abstractly and somewhat specifically; more in a moment),\nand so except by wild coincidence are only useful in talking about\nthat branch. One of the two cases (the second discussed later) where\nthat's useful is when you have long-lived branches. In git,\napparently, you don't have long-lived \"branches\" in this particular\nmeaning of the word, but the way people use bzr they do. Perhaps this\nis what you mean by 'centralization'.\n\nThat long-lived branch doesn't have to be any sort of \"trunk\", though\nit usually is; it could as easily be something totally peripheral.\n\n\nNow, details of that use of \"branch\". In mathematical terms, a branch\nmay be defined purely by its head rev (and the graph built up by\nrecursing through all the parents), but in [bzr] UI and mental model\nterms, a \"branch\" is that plus its mainline[0]; the left-most or first\nline of descent, which colloquially is the difference between 'things\nI commit' and 'things I merge'.\n\nLet me try flexing my git-expression muscles here. Given a branch at\na specific point in time, you point at the head rev, and there's a\nsubset we call 'mainline' of the whole set of parents, which is\nexpressed by following the 'first' parent pointers back to a single\norigin (there can be 50 origins in the whole graph, of course, but\nonly one of them is on the 'mainline'). At some later time, more\nrevisions have been added to the graph, and the head rev is now\nsomething \"later\". If, at that later time, all the nodes which were\npreviously on that 'mainline' are still on it tracing back from the\nnew head, then in the sense I'm using \"branch\", it's still the same\n\"branch\". All the revnos referring to its earlier incarnation are\nstill valid for this one (though there are new ones tacked onto the\nend; that doesn't affect the pre-existing ones).\n\n[I THINK we all understand that, but just making sure]\n\n\n[0] This probably causes some confusion too, since I know I'm guilty\n of using the word 'mainline' both in the sense of a 'trunk'\n branch, and this particular path through one branch. _I_ think\n it's usually clear from context, but I guess it probably isn't for\n those with a different mental modeling of \"branch\".\n\n\n> To illustrate, yesterday I gave an example where performing a bzr\n> branch from a dotted-decimal revision would rewrite the numbers from\n> the originating branch (1.2.2, 1.2.1, and 1) to unrelated numbers in\n> the new branch (3, 2, 1).\n\nOne thing to note here is that that 1.2.1 and 1.2.2 came into your\nfirst branch here by merging from another branch (call that branch\n'b'). When you created your new branch here that now has (3,2,1),\nthose numbers are the same as the numbers that existed locally in 'b'\nat the time 1.2.2 was its 'head'. In a sense, then, you've just\nrecreated [a copy of] \"branch\" 'b' at that time. So, in a way, by\ntaking a copy of the current bzr.dev branch, you can recreate the\nentire state of any branches that were merged into it as of the time\nthey were merged (excluding cases of cherrypicking, or when merging\nprior to the head of those branches of course).\n\n\n> But then I realized why bzr is doing this. It's because, bzr users\n> don't just use the revision numbers for external communication, but\n> they also use them for lots of direct interaction with the tool. The\n> rewriting makes it easy to write something like \"bzr diff -r1..3\".\n\nThis is an instance of the second case (first above) where the revnos,\napplying just to one branch, become useful. And, it's probably the\ncase I'm most attached to.\n\nThe great majority (I'd say easily 80%) of my references to revisions\nare transient. Most of 'em have probably exhausted their usefulness\nin an hour; many of them (as in interaction with the tool you\nmentioned) in just a couple seconds. Virtually all my branches live\nlonger than that, so the limited lifespan of the numbers in the grand\nscheme doesn't matter a whit.\n\nSo, from above, some of the places they're handier:\n\n- Typing. I know, copy and paste copies and pastes one string just as\n well as another, and long strings just as well as short. But I\n don't want to copy&paste; I want to ^Z out of log and run a quick\n diff, between two revisions only one of which is on my screen at the\n time. I can just remember the offscreen revno I'm comparing\n against, and it's very easy to quickly type the numbers,\n particularly since 95% of the time I'm comparing mainline revs so I\n don't even have to think about dotted forms.\n\n\n- Some forms of communicating. I can yell numbers across the room\n without concern about whether they'll be interpreted right. Even 6\n digits of an SHA-1 hash are a lot harder to do that with. I can\n hold revnos in my head while I walk down the hall to talk to\n somebody about them, or pick up a phone, or go to a meeting. I can\n scrawl them on notepads or whiteboards. In all these cases, the\n only reason for which I'm communicating that revno will be exhausted\n very shortly, so it's completely irrelevant whether it's meaningful\n in 5 years, or next week.\n\n\n- Visual comparing (this is one that's useful on the long-lived\n branches, as well as transient stuff) and information gathering. I\n can hold in my head \"Yeah, I looked at 1350 of Joe's branch\", and if\n I see an email from him \"Oh, I fixed a bug in 1358\" or \"in 1293\", I\n can know just from that whether I saw the fix or not.\n\n If somebody says \"I introduced a bug in revision 3841, and fixed it\n in 3843\", I know the window where that bug is in play is probably\n pretty small, whereas \"introduced in 3841, fixed in 5337\" tells me\n it was alive a looong time.\n\n bzr.dev is currently on revno 2091. I didn't know that, I had to\n look it up. But I knew it was a little past 2000, just from loosely\n watching it. If somebody talks about something that happened in\n revno 1800, I know automatically \"That was fairly recent\", compared\n to talking about revno 75, where I know \"Wow, that was a long time\n ago\".\n\n This property is true of bzr revids as well. If I see talk about\n revision \"mbp@sourcefrog.net-20050520021228-bc46a17f07eff7f9\", I\n know right away Martin committed it, and it was a year and a half\n ago. If I see talk about an oops in revision \"af38cc3\", that just\n tells me that somebody screwed up, and it gets mentally filed away\n or goes in one eye and out the other. But if I see talk about an\n oops in revision \"fullermd@over-yonder.net-[...]\", that rings bright\n blue bells that tell me that *I* screwed up and I need to jump on\n that right now. In a sufficiently small projects with sufficiently\n discrete task division, I may even be able to guess offhand based on\n the person and date what bit of functionality the commit references,\n though that's a much lower probability.\n\n It can also be useful in looking at cases where you don't\n necessarily have the tool. Compare putting CVS's rcsid tags in\n strings in the source. static const char *rcsid = \"$Id\"; and the\n like. Then you can use 'ident' on the compiled binaries to see the\n revs of files in them. If somebody says \"foo.c has a bug in 1.34,\n fixed in 1.37\", I can without any VCS interaction just look at the\n compiled binary and tell whether I'm prior to the bug, have the bug,\n or after the fix. If the binary is known to be compiled from a\n particular branch, a tree-wide revno tells me that too. A revid\n (even one containing a date) won't tell me that; I'll have to find\n the tool and a copy of the tree and find out if my rev contains that\n other rev.\n\n Now, on any given revision reference, I probably don't care about\n most of those bits of info. I may not care about any of them, but I\n often care about at least one or two. And we all probably have\n wildly varying appraisals of the commonness of various of the\n situations described. And yes, a lot of them are just mental\n heuristics. Sure, with a completely opaque id, I could pull up the\n tool to look up any of those (and a lot more information besides),\n the gain is I don't HAVE to. Just knowing some bit of that info can\n often tell me if I don't care to investigate whatever the revision\n is being referenced for at all, or that I need to put doing so at\n the top of my priority list.\n\n\n\n> And it turns out that git also allows branch specific naming for the\n> exact same reason. In place of 3, 2, 1 in the same situation git\n> would allow the names HEAD, HEAD~1, and HEAD~2 to refer to the same\n> three revisions. So the easy diff command would be \"git diff HEAD~2\n> HEAD\".\n\nIn bzr, that would be \"bzr diff -r-2..-1\" (or just \"-r-2..\" since\nopen-ended revspecs pretty much work like you'd expect them to). IME,\nthat only works well maybe 4 or 5 revs back; past that, you spend too\nmuch time counting, and it's easier to just whack in the number from\nlog.\n\nbzr _doesn't_, OTOH, have anything like HEAD^2, for selecting\nalternate parent paths. That's probably use-pattern bias; we hardly\never do something like that, so it's never occurred to us to add the\nability to.\n\n\n> Maybe some of the people that dislike git's \"ugly\" names so much is\n> that they imagine that to compare two revisions a user of git must\n> inspect the logs, fish out the sha1sum for each, and then\n> cut-and-paste to create the command needed.\n\nI do imagine that. And I think I'd hit it, since I often look around\nrevs that aren't right near the tip; trying to figure out\n\"HEAD~293..HEAD~38\" is even worse than excavating the sha1sum's.\n\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29616","messageId":"20061022130322.GS75501@over-yonder.net","threadId":"5925","inReplyTo":"20061022074422.50dcbee6.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-22T13:03:22Z","receivedAt":"2006-10-22T13:03:22Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Sun, Oct 22, 2006 at 07:44:22AM -0400 I heard the voice of\nSean, and lo! it spake thus:\n> \n> Bzr revnos (dotted or otherwise) can not be guaranteed to be stable\n> in a truly distributed system.\n\nPerhaps the difference is that we're making a [fine] distinction\nbetween \"useful in a truely distributed system\" and \"useful when\nWORKING in a truely distributed system\". cworth's point back up a few\nposts is good; nearly all of my use of revnos is in direct interaction\nwith the tool, where the revnos just came from looking at the history.\nAnd of those uses that aren't in that class, nearly all of THOSE are\nvery transient. Non-local (in time or space) stability in either of\nthose cases is a total non-concern.\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29624","messageId":"200610221524.00408.jnareb@gmail.com","threadId":"5925","inReplyTo":"845b6e870610220256u39d3d06wefd4f71851670812@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-22T13:23:59Z","receivedAt":"2006-10-22T13:23:59Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Erik Bågfors wrote:\n> Jakub Narębski wrote:\n\n>> For example git encourages using many short and longer-lived feature\n>> branches; I don't see bzr encouraging this workflow.\n> \n> Why not? I think it really does. And due to the fact that merges are\n> merges and will show up as such, I think it's very suitable for\n> feature branches.\n\nI think I haven't properly explained what \"feature branch\" means.\n\"Feature branch\" is short (or medium) lived branch, created for\ndevelopment of one isolated feature. When feature is in stable\nstage, we merge feature branch and forget about it. We are not\ninterested in the fact that given feature was developed on given\nbranch. BTW. for example in published git.git repository are\nonly available in the form of \"digest\" 'pu' (proposed updates)\nbranch.\n\nI guess what you are talking about are long lived \"development\nbranches\" (like git.git 'maint', 'master', 'next' and 'pu' branches),\nor perhaps long lived another user's clone of given git repository.\n\nGit considers having clones of given repository totally equivalent,\nand having fast-forward property more important than remembering\n\"which branch (which clone) has this commit came from\" or at least\n\"this commit is from this (current) branch-clone\".\n\nYou have graphical history viewers (bzr has it's own: bzr-gtk),\ncommitter and author info, and reflog if enabled if you really,\nreally need this kind of information. \n \n> In fact, in the bzr development of bzr itself. All commits are done\n> in feature branches and then merged into bzr.dev (the main \"trunk\" of\n> bzr) when they are considered stable.\n> \n> Consider the following\n> bzr branch mainline featureA\nWhich if I remember correctly (at least by default) needs and generates\nnew working tree.\n\n> cd featureA\n> hack hack; bzr commit -m 'f1'; hack hack bzr commit -m f2; etc\n> No I want to merge in mainline again\n> bzr merge ../mainline; bzr commit -m merge\n> hack hack; bzr commit -m f3; hack hack bzr commit -m f4; etc\n\nAs it clarified during this long discussion, bzr \"branches\" are\nsomething between git branches and one-branch [local] clones.\nCan you for example create branch starting from an arbitrary revision,\nnot only tip of branch?\n\nThe above sequence of operations can be done in (at least) two different\nways in git.\n\nLess used:\n $ cd /somewhere/else\n $ git clone -l -s /.git featureA\n $ cd featureA\n $ hack; hack; git commit -a -m \"f1\"; hack; hack; git commit -a -m \"f2\"; etc \n $ cd \n $ git pull /somewhere/else/featureA/.git\n (this does commit and merge)\n\nBut more common used is:\n $ git branch featureA mainline\n $ git checkout featureA\n $ hack; hack; git commit -a -m \"f1\"; hack; hack; git commit -a -m \"f2\"; etc\n $ git checkout mainline\n $ git pull . featureA\n (although this would fast-forward in this example)\n\n> right now, I would have something line this in the branch log\n> -----------------------------------------------------------------\n> committer: Erik Bågfors \n> branch nick: featureA\n> message:\n> f4\n> -----------------------------------------------------------------\n> committer: Erik Bågfors \n> branch nick: featureA\n> message:\n> f3\n> ----------------------------------------------------------------\n> committer: Erik Bågfors \n> branch nick: featureA\n> message:\n> merge\n> -----------------------------------------------------------------\n> committer: Foo Bar \n> branch nick: mainline\n> message:\n> something done in mainline\n> -----------------------------------------------------------------\n> committer: Foo Bar \n> branch nick: mainline\n> message:\n> something else done in mainline\nThe automatic merge message takes care of this, if we enable\nmerge.summary config option. For example:\n\ncommit 2c8a02263c13c6e1891e9e338eb40a4286b613e5\nMerge: 2492932... 87b787a...\nAuthor: Jakub Narebski \nDate: Sat Oct 21 13:23:19 2006 +0200\n\n Merge branch 'master' of git://git.kernel.org/pub/scm/git/git\n \n * 'master' of git://git.kernel.org/pub/scm/git/git:\n git-clone: define die() and use it.\n Fix typo in show-index.c\n pager: default to LESS=FRS\n\n\nAnother example, this time of \"octopus\" merge.\n\ncommit ff49fae6a547e5c70117970e01c53b64d983cd10\nMerge: 7ad4ee7... 75f9007... 14eab2b... 0b35995... eee4609...\nAuthor: Junio C Hamano \nDate: Fri Oct 20 18:56:14 2006 -0700\n\n Merge branches 'jc/diff', 'jc/diff-apply-patch', 'jc/read-tree' and 'pb/web' into pu\n \n * jc/diff:\n para walk wip\n para-walk: walk n trees, index and working tree in parallel\n \n * jc/diff-apply-patch:\n git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)\n \n * jc/read-tree:\n merge: loosen overcautious \"working file will be lost\" check.\n \n * pb/web:\n gitweb: Show project README if available\n\nThat said we couldn't do that in abovementioned example\nas it is simple case of fast-forward. We have above messages\nfor \"true merges\" of two _diverging_ lines of development,\nand we could use similar format for \"git log\". In practice\nwe rather use history viewers: gitk, qgit, tig, git-show-branch.\n\nFor example:\n$ git show-branch origin next\n! [origin] git-clone: define die() and use it.\n ! [next] Merge branch 'master' into next\n--\n - [next] Merge branch 'master' into next\n++ [origin] git-clone: define die() and use it.\n\n> If I understand it correctly, in git, you don't really know what has\n> been committed as part of this branch/repo, and what has been\n> committed in another branch/repo (this is my understanding from\n> reading this thread, I might be wrong, feel free to correct me again\n> :) )\n\nYou can browse reflog to get to know which changes were commited\nas part of this repo, and which came from other repo (other clone\nof this repo).\n-- \nJakub Narebski\nPoland\n"},{"id":"29625","messageId":"BAYC1-PASMTP015345662E5CDF8D3E7117AE030@CEZ.ICE","threadId":"5925","inReplyTo":"20061022130322.GS75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-22T13:28:45Z","receivedAt":"2006-10-22T13:28:45Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 22 Oct 2006 08:03:22 -0500\n\"Matthew D. Fuller\" wrote:\n\n> Perhaps the difference is that we're making a [fine] distinction\n> between \"useful in a truely distributed system\" and \"useful when\n> WORKING in a truely distributed system\". cworth's point back up a few\n> posts is good; nearly all of my use of revnos is in direct interaction\n> with the tool, where the revnos just came from looking at the history.\n> And of those uses that aren't in that class, nearly all of THOSE are\n> very transient. Non-local (in time or space) stability in either of\n> those cases is a total non-concern.\n\nSure, but if they're just a local feature then why propagate them with\nthe distributed data? If they're meant only to be used locally,\nthey can be guaranteed to be stable by never replicating\nthem, with obvious benefits for the local user. However bzr makes the\n(IMO) mistake of including them in the data that is distributed \nbetween repos. This suggests bzr team just doesn't care about the\ndistributed models where this will not help and will quite possibly\nlead to frustration and confusion. And yes, I know that you\nhaven't seen those situations yourself yet. Obviously, it's the\nBzr teams trade-off to make, but if an avid user like yourself thinks\nof revno's as local, perhaps they've made the wrong choice.\n\nSean\n"},{"id":"29626","messageId":"20061022092845.233deb43.seanlkml__11180.3832035095$1161523756$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"20061022130322.GS75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-22T13:28:45Z","receivedAt":"2006-10-22T13:28:45Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 22 Oct 2006 08:03:22 -0500\n\"Matthew D. Fuller\" wrote:\n\n> Perhaps the difference is that we're making a [fine] distinction\n> between \"useful in a truely distributed system\" and \"useful when\n> WORKING in a truely distributed system\". cworth's point back up a few\n> posts is good; nearly all of my use of revnos is in direct interaction\n> with the tool, where the revnos just came from looking at the history.\n> And of those uses that aren't in that class, nearly all of THOSE are\n> very transient. Non-local (in time or space) stability in either of\n> those cases is a total non-concern.\n\nSure, but if they're just a local feature then why propagate them with\nthe distributed data? If they're meant only to be used locally,\nthey can be guaranteed to be stable by never replicating\nthem, with obvious benefits for the local user. However bzr makes the\n(IMO) mistake of including them in the data that is distributed \nbetween repos. This suggests bzr team just doesn't care about the\ndistributed models where this will not help and will quite possibly\nlead to frustration and confusion. And yes, I know that you\nhaven't seen those situations yourself yet. Obviously, it's the\nBzr teams trade-off to make, but if an avid user like yourself thinks\nof revno's as local, perhaps they've made the wrong choice.\n\nSean\n"},{"id":"29627","messageId":"20061022133336.GT75501@over-yonder.net","threadId":"5925","inReplyTo":"20061022092845.233deb43.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-22T13:33:36Z","receivedAt":"2006-10-22T13:33:36Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Sun, Oct 22, 2006 at 09:28:45AM -0400 I heard the voice of\nSean, and lo! it spake thus:\n> \n> Sure, but if they're just a local feature then why propagate them\n> with the distributed data?\n\nBecause they're 'local' to a given \"branch\"; see my message to cworth\na little while ago for expansion of the rather particular meaning of\nthe word used here. If somebody takes a clone of my _branch_, it's\nthe same \"branch\", so the numbers will be the same (and that's\ndesired).\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29628","messageId":"BAYC1-PASMTP11AD2F07D7CDC4198B1D1EAE030@CEZ.ICE","threadId":"5925","inReplyTo":"20061022133336.GT75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-22T13:40:41Z","receivedAt":"2006-10-22T13:40:41Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 22 Oct 2006 08:33:36 -0500\n\"Matthew D. Fuller\" wrote:\n\n> Because they're 'local' to a given \"branch\"; see my message to cworth\n> a little while ago for expansion of the rather particular meaning of\n> the word used here. If somebody takes a clone of my _branch_, it's\n> the same \"branch\", so the numbers will be the same (and that's\n> desired).\n\nThe fact is that once you start distributing them to other repositories\nyou CAN NOT GUARANTEE their stability. Those number may already be\nused by _HIS_ branch and when he tries to get _YOUR_ branch.. there\nis a conflict. AND THERE IS NOTHING YOU CAN DO TO FIX THAT. It's\na fundamental flaw with distributing revnos. The reason you likely\nhaven't seen a problem so far is that the bzr world seems to favor\nthe use of a central server that has the effect of more or less\nsynchronizing branch numbers to most of the nodes in the system.\nHowever, that's only one model. So while you may not have seen a\nproblem yourself, there are _inherent_ limitations of the system\nyou've embraced.\n\nBut it seems like nobody on the bzr team cares or wants to hear about\nit, so let's just move on.\n\nCheers,\nSean\n"},{"id":"29629","messageId":"20061022094041.77c06cc7.seanlkml__4078.99909555471$1161524523$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"20061022133336.GT75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-22T13:40:41Z","receivedAt":"2006-10-22T13:40:41Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 22 Oct 2006 08:33:36 -0500\n\"Matthew D. Fuller\" wrote:\n\n> Because they're 'local' to a given \"branch\"; see my message to cworth\n> a little while ago for expansion of the rather particular meaning of\n> the word used here. If somebody takes a clone of my _branch_, it's\n> the same \"branch\", so the numbers will be the same (and that's\n> desired).\n\nThe fact is that once you start distributing them to other repositories\nyou CAN NOT GUARANTEE their stability. Those number may already be\nused by _HIS_ branch and when he tries to get _YOUR_ branch.. there\nis a conflict. AND THERE IS NOTHING YOU CAN DO TO FIX THAT. It's\na fundamental flaw with distributing revnos. The reason you likely\nhaven't seen a problem so far is that the bzr world seems to favor\nthe use of a central server that has the effect of more or less\nsynchronizing branch numbers to most of the nodes in the system.\nHowever, that's only one model. So while you may not have seen a\nproblem yourself, there are _inherent_ limitations of the system\nyou've embraced.\n\nBut it seems like nobody on the bzr team cares or wants to hear about\nit, so let's just move on.\n\nCheers,\nSean\n"},{"id":"29630","messageId":"ehft1f$9le$1@sea.gmane.org","threadId":"5925","inReplyTo":"20061022124635.GR75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-22T13:51:54Z","receivedAt":"2006-10-22T13:51:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthew D. Fuller wrote:\n\n>   It can also be useful in looking at cases where you don't\n>   necessarily have the tool.  Compare putting CVS's rcsid tags in\n>   strings in the source.  static const char *rcsid = \"$Id\"; and the\n>   like.  Then you can use 'ident' on the compiled binaries to see the\n>   revs of files in them.  If somebody says \"foo.c has a bug in 1.34,\n>   fixed in 1.37\", I can without any VCS interaction just look at the\n>   compiled binary and tell whether I'm prior to the bug, have the bug,\n>   or after the fix.  If the binary is known to be compiled from a\n>   particular branch, a tree-wide revno tells me that too.  A revid\n>   (even one containing a date) won't tell me that; I'll have to find\n>   the tool and a copy of the tree and find out if my rev contains that\n>   other rev.\n\nWe use signed tags for tagging official releases (e.g. v1.4.0 tag),\nand we use \"git describe\" output to be embedded during build time\nin resulting binary. For example my current output of git-describe\non my clone of git repository is:\n\n $ git describe \n v1.4.3.1-g2c8a022\n\nGit project does this, gitweb does this, Linux kernel does this.\nThis is quite coarse grained, i.e. you know ahich released version\nit is after, but you need git tools (or access to git tools via\ngitweb) to check if it is after or before the fix.\n\nOf course that is when you run GIT version of tool...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29631","messageId":"20061022135702.GU75501@over-yonder.net","threadId":"5925","inReplyTo":"20061022094041.77c06cc7.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-22T13:57:02Z","receivedAt":"2006-10-22T13:57:02Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Sun, Oct 22, 2006 at 09:40:41AM -0400 I heard the voice of\nSean, and lo! it spake thus:\n> \n> The fact is that once you start distributing them to other\n> repositories you CAN NOT GUARANTEE their stability.\n\nTerminology. When those revisions get distributed to other BRANCHES,\ntheir stability is forfeit. We know. We don't care. We only care\nabout the numbers on ONE BRANCH.\n\n\n> Those number may already be used by _HIS_ branch and when he tries\n> to get _YOUR_ branch.. there is a conflict.\n\nTerminology again. When he has his branch and gets my branches, he\nhas two branches, mine and his, side by side, and the numbers in his\n'my' branch still correspond to the numbers in my 'my' branch. When\nhe merges the REVISIONS from my branch into his, my numbers have no\nmeaning on his side (there's not a 'conflict' because numbers don't\nget copied, they get derived).\n\n\n> So while you may not have seen a problem yourself,\n\nYou keep insisting that there's a PROBLEM here. You're right, I don't\nsee one. I KNOW the numbers only refer to a branch, I KNOW that when\nyou're talking about a different branch the numbers are meaningless,\nand I'm perfectly fine with that because referring to revisions on *A*\nbranch is exactly what I USE the numbers for.\n\nThere doesn't have to be a 'central' branch, nor is there any wish for\nsuch to be. Any given revno only refers to *A* branch, it doesn't\nhave to be central to a darn thing. HEAD in git only has meaning in\nthe context of *A* branch (and even 'worse', only refers to that\nbranch at a specific time[0]), but you'll keep on using it every day\nanyway I wager.\n\n\n\n[0] See again particular term of art \"branch\".\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29635","messageId":"845b6e870610220711t8040a13g3dedbe18a2949ce1@mail.gmail.com","threadId":"5925","inReplyTo":"200610221524.00408.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-22T14:11:16Z","receivedAt":"2006-10-22T14:11:16Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"On 10/22/06, Jakub Narebski wrote:\n> Erik Bågfors wrote:\n> > Jakub Narębski wrote:\n>\n> >> For example git encourages using many short and longer-lived feature\n> >> branches; I don't see bzr encouraging this workflow.\n> >\n> > Why not? I think it really does. And due to the fact that merges are\n> > merges and will show up as such, I think it's very suitable for\n> > feature branches.\n>\n> I think I haven't properly explained what \"feature branch\" means.\n> \"Feature branch\" is short (or medium) lived branch, created for\n> development of one isolated feature. When feature is in stable\n> stage, we merge feature branch and forget about it. We are not\n> interested in the fact that given feature was developed on given\n> branch. BTW. for example in published git.git repository are\n> only available in the form of \"digest\" 'pu' (proposed updates)\n> branch.\n\n\nThat's what I'm talking about too.\nFor example, in my bzr bzr-repo I have\nbzr.init-repo-tree/\nbzr.aliases/\nbzr.dev/\n\nand others...\nIn bzr.aliases for example, I built the support for defining aliases\nin the bzr config file. That was a unique feature that didn't exist in\nany other branch. The branch survived about 17 days before it was\nmerged into bzr.dev. During that time, I merge in another branch\ntwice. The branch I merged at this time was NOT bzr.dev, but rather\nanother branch, from one of the main developers. The reason I merged\nhis branch was that I needed a bugfix (or two? :) ) that he had done,\nbut that wasn't approved in bzr.dev yet.\n\nAfter a time, his branch was merged into bzr.dev, shortly thereafter,\nso was my branch.\n\nAfter my branch was merged, I forgot about it. I still have it laying\naround on my computer because it really doesn't take up any extra\nspace (since it's in a shared repository), but I really have forgotten\nabout it.\n\nThis is typically how all features in bzr are created.\nShort/medium/long-lived feature branches.\n\n/Erik\n"},{"id":"29632","messageId":"BAYC1-PASMTP081ED05E35BA4CFC6154A9AE030@CEZ.ICE","threadId":"5925","inReplyTo":"20061022135702.GU75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-22T14:24:54Z","receivedAt":"2006-10-22T14:24:54Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 22 Oct 2006 08:57:02 -0500\n\"Matthew D. Fuller\" wrote:\n\n> You keep insisting that there's a PROBLEM here. You're right, I don't\n> see one. I KNOW the numbers only refer to a branch, I KNOW that when\n> you're talking about a different branch the numbers are meaningless,\n> and I'm perfectly fine with that because referring to revisions on *A*\n> branch is exactly what I USE the numbers for.\n\nLight goes on. Okay. So a bzr \"branch\" is only ever editable on a \nsingle machine. So there is no distributed development on top of a \nbzr \"branch\". Everyone else just has read-only copies of it. In this\nway you ensure that there is never a conflict of the revno's. I'm not\nsure of the ramifications of this but at least I get where you're coming\nfrom now.\n\nSean\n"},{"id":"29633","messageId":"20061022102454.b9dea693.seanlkml__19614.2076900744$1161527145$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"20061022135702.GU75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-22T14:24:54Z","receivedAt":"2006-10-22T14:24:54Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 22 Oct 2006 08:57:02 -0500\n\"Matthew D. Fuller\" wrote:\n\n> You keep insisting that there's a PROBLEM here. You're right, I don't\n> see one. I KNOW the numbers only refer to a branch, I KNOW that when\n> you're talking about a different branch the numbers are meaningless,\n> and I'm perfectly fine with that because referring to revisions on *A*\n> branch is exactly what I USE the numbers for.\n\nLight goes on. Okay. So a bzr \"branch\" is only ever editable on a \nsingle machine. So there is no distributed development on top of a \nbzr \"branch\". Everyone else just has read-only copies of it. In this\nway you ensure that there is never a conflict of the revno's. I'm not\nsure of the ramifications of this but at least I get where you're coming\nfrom now.\n\nSean\n"},{"id":"29634","messageId":"87zmbozau2.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"845b6e870610220256u39d3d06wefd4f71851670812@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-22T14:25:41Z","receivedAt":"2006-10-22T14:25:41Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"At Sun, 22 Oct 2006 11:56:32 +0200, \"=?ISO-8859-1?Q?Erik_B=E5gfors?=\" wrote:\n> Consider the following\n> bzr branch mainline featureA\n> cd featureA\n> hack hack; bzr commit -m 'f1'; hack hack bzr commit -m f2; etc\n> No I want to merge in mainline again\n> bzr merge ../mainline; bzr commit -m merge\n> hack hack; bzr commit -m f3; hack hack bzr commit -m f4; etc\n\nThanks for sharing this example. I think when we look at concrete\nthings that the tools actually let you do, we have a better\nconversation. Plus, this example highlights some very interesting\ndifferences between the tools.\n\nSo here is a complete sequence of git commands to construct the\nscenario (even the extra hacking in mainline):\n\n\tmkdir gittest; cd gittest\n\tgit init-db\n\ttouch mainline; git add mainline; git commit -m \"Initial commit of mainline\"\n\tgit checkout -b featureA\n\ttouch f1; git add f1; git commit -m f1\n\ttouch f2; git add f2; git commit -m f2\n\tgit checkout -b mainline master\n\ttouch sd; git add sd; git commit -m \"something done in mainline\";\n\ttouch se; git add se; git commit -m \"something else done in mainline\";\n\tgit checkout featureA\n\tgit pull . mainline\n\ttouch f3; git add f3; git commit -m f3\n\ttouch f4; git add f4; git commit -m f4\n\nFor reference, here's the same with bzr:\n\n\tmkdir bzrtest; cd bzrtest\n\tbzr init-repo . --trees\n\tbzr init mainline; cd mainline\n\ttouch mainline; bzr add mainline; bzr commit -m \"Initial commit of mainline\"\n\tcd ..; bzr branch mainline featureA; cd featureA\n\ttouch f1; bzr add f1; bzr commit -m f1\n\ttouch f2; bzr add f2; bzr commit -m f2\n\tcd ../mainline/\n\ttouch sd; bzr add sd; bzr commit -m \"something done in mainline\"\n\ttouch se; bzr add se; bzr commit -m \"something else done in mainline\"\n\tcd ../featureA\n\tbzr merge ../mainline/; bzr commit -m \"merge\"\n\ttouch f3; bzr add f3; bzr commit -m f3\n\ttouch f4; bzr add f4; bzr commit -m f4\n\n[As has recently been pointed out, the tools really are more the same\nthan different, and I think the above illustrates that.]\n\n> right now, I would have something line this in the branch log\n\nOK. So here is a difference in the tools. With git, you don't get the\nindentation for the \"non-mainline\" commits. This is because git\ndoesn't recognize any branch in the DAG to be more significant than\nany other. Instead, git provides a flat, and (heuristically)\ntime-sorted view of the commits. (It's heuristic in that git just uses\nthe time stamps in the commit objects---but it doesn't actually care\nif these are totally \"wrong\"---git knows that there is no global\nclock.)\n\nThat said, git does store an order for the parent edges of each\ncommit, and this order is assigned deterministically by the commands\nthat create merge commits. So someone could use git carefully, (which\nit seems people are doing with bzr), to preserve \"mainline as first\nparent\" and someone could write a modified git-log that would do\nindentation.\n\nBut even without any of that manual care for creating a \"mainline\",\ngit already provides a very easy way to see the \"mainline\" view\nanyway. See below.\n\n> In this view,I can easily see what was part of this feature branch,\n> because the commits that belongs to the feature branch are not\n> indented, and they have a \"branch nick\" of \"featureA\". I can also\n> easily see what comes from other branches.\n\nAh, I hadn't realized that bzr commits stored an \"originating branch\"\ninside them. Git commits definitely do not have anything like\nthat. And as I said above, there's no indentation in git-log, so the\ncommits from separate branches are \"mixed up\". But see below.\n\n> I can also run bzr log with --line or --short which shows you only the\n> commits made in this branch and not the once that are merged in. So\n> with --line I would get something line\n> Erik Bågfors 2006-10-19 f4\n> Erik Bågfors 2006-10-19 f3\n> Erik Bågfors 2006-10-19 merge\n> Erik Bågfors 2006-10-19 f2\n> Erik Bågfors 2006-10-19 f1\n>\n> Which will give me a good view of what has been done in this feature\n> branch only.\n\nThank you. You've provided a concrete example of something to do,\n(\"see commits that belong to a feature branch\"), that is really very\npractical and useful. And bzr achieves this ability by adopting a\n\"mainline is special\" treatment in bzr. This special treatment\ninfluences or directly causes many of the things in bzr that we've\nbeen discussing:\n\n * mainline commits get special treatment from revision numbers\n (in old days, they're the only commits to have revision\n numbers---more recently they're the only commits to get non-dotted\n revision numbers)\n\n * bzr adds empty merge commits instead of fast-forwarding since it\n needs a new \"mainline\" commit\n\n * users have to be careful about merge direction to avoid\n accidentally going the \"wrong\" way\n\n * users are discouraged from using the \"give me their DAG\" pull\n command since it would scramble their local view of what \"mainline\"\n is.\n\nI've been arguing that all of these impacts are dubious. But I can\nunderstand that a bzr user hearing arguments against them might fear\nthat they would lose the ability to be able to see a view of commits\nthat \"belong\" to a particular branch.\n\nBut git provides that view perfectly well, and it's what git users\nwork with all the time. It doesn't require any special treatment of\none commit parent vs. another, nor storage of \"originating branch\" in\nthe commit, nor the user taking any care whatsoever about which\ndirection merges are performed, (nor \"who\" does the merge).\n\nAnd as a bonus, the command-line for this view is really simple:\n\n\tgit log mainline..featureA\n\nThis gives a log view just \"bzr log --line\" in that in only includes\nf1, f2, the merge commit, f3, and f4. You can even drop the merge if\nit's uninteresting:\n\n\tgit log --no-merges mainline..featureA\n\nThe mainline..featureA syntax literally just means:\n\n\tthe set of commits that are reachable by featureA\n\tand excluding the set of commits reachable by mainline\n\nIt's an extraordinarily powerful thing to say, and its exactly what\nyou want here. And it's more than a \"show mainline\" thing, since\ntheses sets of commits can consist of arbitrarily complex DAG\nsubsets. This syntax is just a really useful way to slice up the DAG.\n\nAnd this syntax is almost universally accepted by git commands. so you\ncan visualize a chunk of the DAG with:\n\n\tgitk mainline..featureA\n\nOr export it as patches with:\n\n\tgit format-patch mainline..featureA\n\nI haven't been able to find something similar in bzr yet. Does it\nexist?\n\n> If I understand it correctly, in git, you don't really know what has\n> been committed as part of this branch/repo, and what has been\n> committed in another branch/repo (this is my understanding from\n> reading this thread, I might be wrong, feel free to correct me again\n> :) )\n\nYou're correct that git doesn't _store_ any sort of \"branch ownership\"\nin the commit object. But this is a huge feature. It avoids a lot of\nthe things in bzr that look so bizarre to people coming from git.\n\n-Carl\n"},{"id":"29636","messageId":"vpq7iysjuis.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"200610212020.08539.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-22T14:27:07Z","receivedAt":"2006-10-22T14:27:07Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n> What about grandparent of commit (d8a60^^ or d8a60~2 in git),\n> or choosing one of the parents in merge commit (d8a60^2 is second\n> parent of a commit)? before:before:753 ?\n\nYes, \"before:\" can take any revision specifier, including\n\"before:something-else\".\n\n-- \nMatthieu\n"},{"id":"29637","messageId":"200610221639.54233.jnareb@gmail.com","threadId":"5925","inReplyTo":"845b6e870610220711t8040a13g3dedbe18a2949ce1@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-22T14:39:53Z","receivedAt":"2006-10-22T14:39:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Erik Bågfors wrote:\n> On 10/22/06, Jakub Narebski wrote:\n>> Erik Bågfors wrote:\n>>> Jakub Narębski wrote:\n>>\n>>>> For example git encourages using many short and longer-lived feature\n>>>> branches; I don't see bzr encouraging this workflow.\n>>>\n>>> Why not? I think it really does. And due to the fact that merges are\n>>> merges and will show up as such, I think it's very suitable for\n>>> feature branches.\n>>\n>> I think I haven't properly explained what \"feature branch\" means.\n>> \"Feature branch\" is short (or medium) lived branch, created for\n>> development of one isolated feature. When feature is in stable\n>> stage, we merge feature branch and forget about it. We are not\n>> interested in the fact that given feature was developed on given\n>> branch. BTW. for example in published git.git repository are\n>> only available in the form of \"digest\" 'pu' (proposed updates)\n>> branch. \n> \n> That's what I'm talking about too.\n> For example, in my bzr bzr-repo I have\n> bzr.init-repo-tree/\n> bzr.aliases/\n> bzr.dev/\n\nDue to the fact that git uses separate namespace for branch names,\nand not position on filesystem, one would probably use 'dev'\n(or 'master', or perhaps 'next'), 'aliases' and 'init-repo-tree'\nas branch names. No need for 'bzr.' prefix to distingush\nbranches from other directories for user.\n\nGit does use convention like above for bare repositories\n(clones of repositories without working tree; working tree\nis associated with repository, not with branch), e.g. git.git\nor linux-2.6.18.y.git though.\n\n> and others...\n> In bzr.aliases for example, I built the support for defining aliases\n> in the bzr config file. That was a unique feature that didn't exist in\n> any other branch. The branch survived about 17 days before it was\n> merged into bzr.dev. During that time, I merge in another branch\n> twice. The branch I merged at this time was NOT bzr.dev, but rather\n> another branch, from one of the main developers. The reason I merged\n> his branch was that I needed a bugfix (or two? :) ) that he had done,\n> but that wasn't approved in bzr.dev yet.\n\nThat is also quite common. Merging 'master' into feature branch,\nor 'next' into feature branch. One could of course cherry-pick\nonly the bugfix... can you do this in bzr?\n\n> After a time, his branch was merged into bzr.dev, shortly thereafter,\n> so was my branch.\n> \n> After my branch was merged, I forgot about it. I still have it laying\n> around on my computer because it really doesn't take up any extra\n> space (since it's in a shared repository), but I really have forgotten\n> about it.\n\nUsually after feature branch is merged (or fast-forwarded) we delete\nit. All the parentage information is in DAG anyway. We can later\nattach new branch with the same name to the point where the branch was.\n\n> This is typically how all features in bzr are created.\n> Short/medium/long-lived feature branches.\n\nLike I said, in git.git development we use development branches\n(e.g. 'master', 'maint', 'next'), tracking branches (e.g. 'origin',\n'linus'), feature branches (e.g. 'jc/pickaxe', 'np/pack'), \"helper\"\nbranches storing somewhat unrelated ('html' and 'man' branches for\nautogenerated documentation) or unrelated ('todo' for TODO notes)\nwtr. code stored to the main project, \"digest\" branches (e.g. 'pu'\nbranch in git.git, which is merge of WIP feature branches to be\npublished, and does not fast-forward), and temporary branches (for\nexample for shelving current work).\n\nFrom long, to medium, to short, to extremly short lived.\n-- \nJakub Narebski\nPoland\n"},{"id":"29642","messageId":"845b6e870610220748q681984e8ld371c64a37b99544@mail.gmail.com","threadId":"5925","inReplyTo":"87zmbozau2.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-22T14:48:11Z","receivedAt":"2006-10-22T14:48:11Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"Thanks for this mail, this makes me happy to see. The tools are pretty\nmuch the same but have some different view on how to do things..\n\nOn 10/22/06, Carl Worth wrote:\n>\n> git log --no-merges mainline..featureA\n>\n> The mainline..featureA syntax literally just means:\n>\n> the set of commits that are reachable by featureA\n> and excluding the set of commits reachable by mainline\n>\n> It's an extraordinarily powerful thing to say, and its exactly what\n> you want here. And it's more than a \"show mainline\" thing, since\n> theses sets of commits can consist of arbitrarily complex DAG\n> subsets. This syntax is just a really useful way to slice up the DAG.\n>\n> And this syntax is almost universally accepted by git commands. so you\n> can visualize a chunk of the DAG with:\n>\n> gitk mainline..featureA\n>\n> Or export it as patches with:\n>\n> git format-patch mainline..featureA\n>\n> I haven't been able to find something similar in bzr yet. Does it\n> exist?\n\nIf I understand you correctly, you'll get the same thing with \"bzr missing\".\n\n$ bzr missing ../mainline/\nYou have 1 extra revision(s):\n------------------------------------------------------------\nrevno: 2\ncommitter: Erik Bågfors \nbranch nick: newbranch\ntimestamp: Sun 2006-10-22 16:43:10 +0200\nmessage:\n hepp\n\n\nYou are missing 1 revision(s):\n------------------------------------------------------------\nrevno: 2\ncommitter: Erik Bågfors \nbranch nick: mainline\ntimestamp: Sun 2006-10-22 16:42:53 +0200\nmessage:\n hej\n\nYou can also run \"bzr missing\" with \"--theirs-only\" or \"--mine-only\"\nto get only one way.\n\nTo get the patches you can run \"bzr bundle ../mainline\", but then\nwe're back to the discussion that it currently gives a \"big patch\" for\nviewing, but when you merge it, you get each revision separately.\n\n/Erik\n"},{"id":"29639","messageId":"200610221655.11598.jnareb@gmail.com","threadId":"5925","inReplyTo":"87zmbozau2.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-22T14:55:11Z","receivedAt":"2006-10-22T14:55:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carl Worth wrote:\n> Erik Bågfors wrote:\n>> If I understand it correctly, in git, you don't really know what has\n>> been committed as part of this branch/repo, and what has been\n>> committed in another branch/repo (this is my understanding from\n>> reading this thread, I might be wrong, feel free to correct me again\n>> :) )\n> \n> You're correct that git doesn't _store_ any sort of \"branch ownership\"\n> in the commit object. But this is a huge feature. It avoids a lot of\n> the things in bzr that look so bizarre to people coming from git.\n\nBecause \"branch ownership\" is obvously local, we have reflog, which is\nlocal and not propagated. Reflog uses the following format\n\n oldsha1 SP newsha1 SP committer TAB reason LF\n\nwhere reason might be \"commit: \"\nor \"commit (amend): \", \"am: \" (applied mail patch), \"reset --hard HEAD^\" (dropped\ntop commit), \"branch: Created from origin^0\", or \"pull origin: In-index \nmerge\".\n\nWe have not yet tools to examine reflog (e.g. change committer\ninfo with it's timestamp to human readable format) yet.\n-- \nJakub Narebski\nPoland\n"},{"id":"29641","messageId":"20061022145658.GV75501@over-yonder.net","threadId":"5925","inReplyTo":"20061022102454.b9dea693.seanlkml@sympatico.ca","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-22T14:56:58Z","receivedAt":"2006-10-22T14:56:58Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Sun, Oct 22, 2006 at 10:24:54AM -0400 I heard the voice of\nSean, and lo! it spake thus:\n> \n> Light goes on. Okay. So a bzr \"branch\" is only ever editable on a\n> single machine. So there is no distributed development on top of a\n> bzr \"branch\". Everyone else just has read-only copies of it.\n\nAh! Yes, that's exactly[0] right. Mark up another of those \"so\nobvious we never think to state it\" thought-patterns :|\n\n\nDistributed development proper only happens on 'projects', not\nbranches. In practice, we say \"we're all working on branch X\", in the\nsense that we use it as a base to work from and intend to merge our\nstuff into it, but strictly speaking we're all working on our own\nbranches that just merge from/into X from time to time.\n\nThat's also why we use the phrases \"merge from\" and \"merge to\", rather\nthan \"merge WITH\". Of course, where possible, we could 'fast-forward'\nto X rather than merge from it, at which point we'd then momentarily\nhave exactly X, but culturally we don't seem to like doing that.\n\n\n\n[0] There are a few very special-case exceptions, notably around the\n'checkout' concept or where people are very carefully manually\nmaintaining sync, but they're irrelevant in this case; and they ARE\nstar-pattern developments that could be said to be 'centralized'. Now\nI grok where that's coming from.\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29643","messageId":"200610221704.12416.jnareb@gmail.com","threadId":"5925","inReplyTo":"845b6e870610220748q681984e8ld371c64a37b99544@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-22T15:04:11Z","receivedAt":"2006-10-22T15:04:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Erik Bågfors wrote:\n\n> On 10/22/06, Carl Worth wrote:\n>>\n>> git log --no-merges mainline..featureA\n>>\n>> The mainline..featureA syntax literally just means:\n>>\n>> the set of commits that are reachable by featureA\n>> and excluding the set of commits reachable by mainline\n>>\n[...]\n>> And this syntax is almost universally accepted by git commands. so you\n>> can visualize a chunk of the DAG with:\n>>\n>> gitk mainline..featureA\n>>\n>> Or export it as patches with:\n>>\n>> git format-patch mainline..featureA\n>>\n>> I haven't been able to find something similar in bzr yet. Does it\n>> exist?\n> \n> If I understand you correctly, you'll get the same thing with \"bzr missing\".\n> \n> $ bzr missing ../mainline/\n> You have 1 extra revision(s):\n> ------------------------------------------------------------\n> revno: 2\n> committer: Erik Bågfors \n> branch nick: newbranch\n> timestamp: Sun 2006-10-22 16:43:10 +0200\n> message:\n> hepp\n> \n> \n> You are missing 1 revision(s):\n> ------------------------------------------------------------\n> revno: 2\n> committer: Erik Bågfors \n> branch nick: mainline\n> timestamp: Sun 2006-10-22 16:42:53 +0200\n> message:\n> hej\n\nThat is (roughly) equivalent of\n $ git log mainline...featureA\n(which would give all commits which are _either_ in mainline,\nxor in featureA, although not separated; --topo-order might help), or\n $ git show-branch mainline featureA\n\n> You can also run \"bzr missing\" with \"--theirs-only\" or \"--mine-only\"\n> to get only one way.\n\nThat would be equivalent of\n $ git log mainline..featureA\n(--theirs-only), or\n $ git log featureA..mainline\n(--mine-only).\n\n> To get the patches you can run \"bzr bundle ../mainline\", but then\n> we're back to the discussion that it currently gives a \"big patch\" for\n> viewing, but when you merge it, you get each revision separately.\n\nWhat about\n $ gitk mainline..featureA\ni.e. showing selected part of DAG in graphical history viewer?\n\nAnd of course syntax is even more powerfull, e.g.\n $ git log maint master --not next\n-- \nJakub Narebski\nPoland\n"},{"id":"29644","messageId":"vpqbqo45r1k.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"20061022145658.GV75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-22T15:05:59Z","receivedAt":"2006-10-22T15:05:59Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Matthew D. Fuller\" writes:\n\n> On Sun, Oct 22, 2006 at 10:24:54AM -0400 I heard the voice of\n> Sean, and lo! it spake thus:\n>> \n>> Light goes on. Okay. So a bzr \"branch\" is only ever editable on a\n>> single machine. So there is no distributed development on top of a\n>> bzr \"branch\". Everyone else just has read-only copies of it.\n>\n> Ah! Yes, that's exactly[0] right. Mark up another of those \"so\n> obvious we never think to state it\" thought-patterns :|\n\nWell, I'm not sure you talk about the same thing still. Adding my\n2cents:\n\nIf ~/branch1 is a branch, I can get a read-write \"copy\" of it with\n\n$ bzr branch ~/branch1 ~/branch2\n\nwhich will roughly be equivalent to\n\n$ cp -r ~/branch1 ~/branch2\n\nWhether they are at this point \"the same branch\" or \"two distinct\nbranches with same content\" is just a matter of vocabulary since there\nis no real \"branch identity\" AFAIK in bzr.\n\nNow, if you commit in ~/branch1, then ~/branch2 is out of date with\nit. If you commit also to ~/branch2, then you get two divergent\nbranches.\n\n(and obviously, I could have done the same with branches in different\nmachines)\n\n-- \nMatthieu\n"},{"id":"29646","messageId":"200610221750.42662.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061016035326.GA8654@hope.sourcefrog.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-22T15:50:42Z","receivedAt":"2006-10-22T15:50:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 14 Oct 2006, Jakub Narebski wrote:\n> Jon Smirl wrote:\n> \n>> It refers to this comparison chart between source control systems.\n>> http://bazaar-vcs.org/RcsComparisons\n> \n> It is quite obvious that comparison of programs of given type (SMC)\n> on some program site (Bazaar-NG) is usually biased towards said program,\n> perhaps unconsciously: by emphasizing the features which were important\n> for developers of said program.\n\nThere are also clashes with SCM terminology used differently by different\nprojects, which are sometimes couled with differences in philosophy,\nand sometimes by different undestanding of given name.\n\nFor example \"lightweight checkouts\" and \"normal/heavyweight checkout\"\nare from what I gather, is supporting \"CVS/centralized model\" and\n\"disconnected CVS model\" (i.e. we can commit changes locally with\nno network access, and we save local changes), at least when we\ndo \"checkout\" remotely and not on one local filesystem out-of-the-box.\n"},{"id":"29647","messageId":"20061022160227.GP20017@pasky.or.cz","threadId":"5925","inReplyTo":"8764ed1b7z.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-22T16:02:27Z","receivedAt":"2006-10-22T16:02:27Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Oct 22, 2006 at 01:49:04AM CEST, I got a letter\nwhere Carl Worth said that...\n> Almost none of the power of git is exposed by gitweb. It's really not\n> worth comparing. (Now a gitweb-alike that provided all the kinds of\n> very easy browsing and filtering of the history like gitk and git\n> might be nice to have.)\n\nhttp://repo.or.cz/git-browser/by-commit.html?r=linux-2.6.git\n\nIt could use plenty of improvement, though.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i On 10/22/06, Linus Torvalds wrote:\n> > \n> > > project/file-1\n> > > project/file-2\n> > > project/.git-1\n> > > project/.git-2\n> > \n> > Ok, that's just insane.\n> [snip]\n> > Anyway. Git certainly allows you to do some really insane things. The\n> > above is just the beginning - it's not even talking about alternate object\n> > directories where you can share databases _partially_ between two\n> > otherwise totally independent repositories etc.\n> \n> \n> Perhaps this is insane, but it does not make sense to track all config\n> files in etc as though they belong in a single repo.\n\nOh, ok, now I see what you're going after.\n\nRight - if you track system directories in a repo, you'd quite possibly \nend up with multiple repositories. Although even then, I'd actually \nsuggest that as a git user, you would only have one actual repository, and \njust multiple branches that have a disjoint set of files (again, it's \ncertainly possible to have file overlap too, of course).\n\nBut the usage I would seriously suggest is to _not_ do development \"inside \n/etc\" itself. You'd have those git repositories somewhere else, say in \n\"/usr/src/etc-repo\" or similar, and then you'd have a few extra wrappers \nto help your particular usage. I have a few reasons for this:\n\n - I think being in /etc and doing development is just fundamentally scary \n in itself, because if you do something wrong in the current directory, \n you're just pretty badly off. It's better to have a \"buffer zone\" that \n you do development in, and when you're happy, you do a \"install\" \n command or something.\n\n - I think developing as \"root\" is totally broken, and some of the files \n you are tracking may not even be _readable_ to normal users in their \n real form, so you can't even do trivial things like \"diff\" as a normal \n user otherwise. So again, the solution to this would be to do \n development somewhere else, and have specific wrappers (with \"sudo\" as \n appropriate, and your developer ID obviously specially in the sudo \n files) to do those special \"realdiff\" and \"install\" commands.\n\n - finally: when you work with almost any SCM designed for source control, \n you're almost inevitably going to have to have some \"special\" way to \n track the things that source control usually does _not_ track because \n it makes no sense for source code. So you'd have to have some special \n file that tracks ownership/group/full permissions information, and \n perhaps special devices (if you're tracking things like /dev).\n\n Again, the way to solve this would tend to be to have a few helper \n scripts that use regular file-contents that _describe_ these things to \n do \"realdiff\" and \"install\".\n\nIn other words, for at least three _totally_ different reasons, you really \ndon't want to do tracking/development directly in /etc, but you want to \nhave a buffer zone to do it. And once you have that, you might as well do \n_that_ as the repository, and just add a few specialty commands (let's \ncall them \"plugins\" to make everybody happy) to do the special things.\n\nAnd once you have that kind of setup, you're really better off with \nmore of a \"several branches for different kinds of files\" or even totally \ndifferent repositories. That's a detail, and I don't think anybody really \ncares.\n\nAnyway, to make this slightly more grounded in examples, let me give a \nquick overview of what I'd do if I did this with git. Not a \"real\" setup \nat all, but kind of a \"maybe something like this\" - so don't get _too_ \nhung up about the details, ok? It's just a rough draft kind of thing.\n\nFirst off, let's just say that I want to track /etc/group, /etc/passwd and \n/etc/shadow as one \"thing\". Whether that thing is a repository of its own \nor a branch in a bigger repository doesn't matter (right now I'm only \ndoing those three), and quite frankly, I'm not going to even go into \nwhether it _really_ makes sense to track \"groups\" and the passwd files \ntogether, but it's just an example, ok?\n\nWhat I'd do is roughly:\n\n\t# set up the new repo (or branch, or..)\n\tmkdir identity-repo\n\tcd identity-repo\n\tgit init-db\n\n\t# copy the data, set up a PERMISSIONS file to track extra info\n\tsudo cp /etc/group /etc/passwd /etc/shadow .\n\tsudo chown user:user *\n\tcat < PERMISSIONS\n\tgroup root:root 0644\n\tpasswd root:root 0644\n\tshadow root:root 0400\n\tEOF\n\tgit add .\n\tgit commit -m \"Initial setup\"\n\nand now I have the initial setup, together with permissions and user/group \ninformation on the things, all ready to track. I can do development in \nthis as if it was a normal source-code repository.\n\nSo now I can do \"work work work commit commit commit\" as if these files \nwere nothign special. What else do I need? I need the \"plugins\" to \nactually expose (install) my work, and perhaps to check that /etc matches \nwhat I expect (and nobody else did anything behind my back that I'd need \nto merge).\n\nLet's call them \"install\" and \"realdiff\" as I did above, ok?\n\nAnd again, I'm not going to even claim that the above two \"plugins\" are \nthe right ones (maybe you want other operations too to interact with the \n\"real\" installed files), and I'm not going to really get all the details \nright, but here's kind of how you _might_ do it.\n\nTo create the script (let's make it shell, because that's what I'm used \nto, but it could be anything) \"git-install\" in your git binary directory, \nand make it do something like this:\n\n\t#!/bin/sh\n\twhile read name chown chmod\n\tdo\n\t\tcp $name $name.tmp &&\n\t\tsudo chown $chown $name.tmp &&\n\t\tsudo chmod $chmod $name.tmp &&\n\t\tsudo mv $name.tmp /etc/$name\n\tdone < PERMISSIONS\n\nand make it executable.\n\nNow, you can work in your git directory, and when you're happy, you can do\n\n\tgit install\n\nto actually copy it into the _real_ directory in /etc.\n\nSee? You can do something similar for \"realdiff\", that would compare the \ncontents in /etc with what you have now in your development tree (where \nyou want to script the thing to compare the PERMISSIONS file too).\n\nAnd note: if you do the \"plugin scripts\" properly, they can work for _all_ \nyour repositories that track different files in /etc. So you can work in \nmany different repos, and track different files in each, and \"git install\" \nwill do the right thing for each, regardless of the actual files you're \ntracking.\n\nDoesn't this sound like a workable situation? You get all the normal SCM \ntools (looking at history etc), and there's only a few special things you \nneed to do when you actually want to install a specific version.\n\nBtw: none of this is really \"git-specific\". The above tells you how to do \nlocal \"git plugins\", and it's obviously fairly trivial, but I suspect any \nSCM can be used in this manner.\n\n\t\tLinus\n"},{"id":"29657","messageId":"20061022185350.GW75501@over-yonder.net","threadId":"5925","inReplyTo":"87zmbozau2.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-22T18:53:50Z","receivedAt":"2006-10-22T18:53:50Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Sun, Oct 22, 2006 at 07:25:41AM -0700 I heard the voice of\nCarl Worth, and lo! it spake thus:\n>\n> \tgit pull . mainline\n\nThis throws me a little. I'd expect it to Just Do It when it's\nfast-forwarding, but if it's doing a merge, I'd prefer it to stop and\nwait before creating the commit, even if there are no textual\nconflicts. I realize you can just look at it afterward and back out\nthe commit if necessary, but still...\n\n\n> Ah, I hadn't realized that bzr commits stored an \"originating\n> branch\" inside them.\n\nEvery branch has a nickname, settable with 'bzr nick' (defaulting to\nwhatever the directory it's in is), and that's stored as a text field\nin each commit. It's mostly cosmetic, but it's handy to see at a\nglance.\n\n\n> This special treatment influences or directly causes many of the\n> things in bzr that we've been discussing:\n [...]\n> I've been arguing that all of these impacts are dubious. But I can\n> understand that a bzr user hearing arguments against them might fear\n> that they would lose the ability to be able to see a view of commits\n> that \"belong\" to a particular branch.\n\nDead center.\n\n\n> The mainline..featureA syntax literally just means:\n> \n> \tthe set of commits that are reachable by featureA\n> \tand excluding the set of commits reachable by mainline\n\n>From what I can gather from this, though, that means that when I merge\nstuff from featureA into mainline (and keep on with other stuff in\nfeatureA), I'll no longer be able to see those older commits from this\ncommand. And I'll see merged revisions from branches other than\nmainline (until they themselves get merged into mainline), correct?\nIt sounds more like a 'bzr missing --mine-only' than looking down a\nmainline in log...\n\n\n> I haven't been able to find something similar in bzr yet. Does it\n> exist?\n\nThe branch: (head) and ancestor: (latest common rev) revspecs let you\nrefer to the respective bits of other branches, which I think would\nfill this role.\n\n\n> It avoids a lot of the things in bzr that look so bizarre to people\n> coming from git.\n\nWell, what would be the fun in that? 8-}\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29658","messageId":"1161544685.22276.127.camel@zepto.home.zettazebra.com","threadId":"5925","inReplyTo":"200610212141.51829.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"David Clymer","fromEmail":"david@zettazebra.com","sentAt":"2006-10-22T19:18:05Z","receivedAt":"2006-10-22T19:18:05Z","isPatch":false,"sender":{"key":"david@zettazebra.com","avatar":"https://gravatar.com/avatar/cdcfe06796c2f046978e5667e21c2e6567f8db8c91d8eb81d7eb86f3f6bc77b7?d=mp&s=160"},"body":"On Sat, 2006-10-21 at 21:41 +0200, Jakub Narebski wrote:\n> Matthew D. Fuller wrote:\n> > On Sat, Oct 21, 2006 at 04:08:18PM +0200 I heard the voice of\n> > Jakub Narebski, and lo! it spake thus:\n> >> Dnia sobota 21. października 2006 15:01, Matthew D. Fuller napisał:\n> \n> >> When two clones of the same repository (in git terminology), or two\n> >> \"branches\" (in bzr terminology), used by different people, cannot be\n> >> totally equivalent that is centralization bias.\n> > \n> > This is obviously some new meaning of \"centralization\" bearing no\n> > resemblance whatsoever to how I understand the word.\n> \n> Perhaps I'd better use \"star topology bias\" instead of \"centralization\n> bias\".\n> \n> > In git, apparently, you don't give a crap about a branch's identity\n> > (alternately expressible as \"it has none\"), and so you throw it away\n> > all the time. Given that, revnos even if git had them would never be\n> > of ANY use to you, so it's no wonder you have no use for the notion.\n> \n> In git branches are lightweight. Branch names are local to repository.\n> Repositories have identity. Bzr \"branch\" is strange mix of one-branch\n> git repository and git branch.\n> \n> Git main workflow is fully decentralized workflow. All clones of the\n> same repository are created equal. In bzr the suggested workflow\n> (with revnos) forces one (or more) branches to be mainline (use \"merge\",\n> get empty-merges, revnos don't change) and leaf (use \"pull\", revnos\n> change).\n> \n> > I DO give a crap about my branchs' identities. I WANT them to retain\n> > them. If I have 8 branches, they have 8 identities. When I merge one\n> > into another, I don't WANT it to lose its identity. When I merge a\n> > branch that's a strict superset of second into that second, I don't\n> > WANT the second branch to turn into a copy of the first. If I wanted\n> > that, I'd just use the second branch, or make another copy of it. I\n> > don't WANT to copy it. I just want to merge the changes in, and keep\n> > on with my branch's current identity.\n> \n> I don't understand. If I merge 'next' branch into 'master' in git, I \n> still have two branches: 'master' and 'next'.\n> \n> And I don't understand why you are so hung on branch identities. Yes, if\n> somebody clones your 'repo' repository, he can have your 'master' branch\n> (refs/heads/master) named 'repo' (refs/heads/repo) or 'repo/master'\n> (refs/remotes/repo/master), but why that matters to you. It is _his_\n> (or her ;-) clone. \n> \n\nI think you missed the point. Speaking for myself, I want to maintain\nthe identity of _my_ branches. If you clone one of them, I _don't_ care.\nThat's your branch. Branch identity as presented here is not intended to\nbe globally significant. It's locally significant.\n\n> > Now, we can discuss THAT distinction. I'm not _opposed_ to git's\n> > model per se, and I can think of a lot of cases where it's be really\n> > handy. But those aren't most of my cases. And as long as we don't\n> > agree on branch identity, it's completely pointless to keep yakking\n> > about revnos, because they're a direct CONSEQUENCE of that difference\n> > in mental model. See? They're an EFFECT, not a CAUSE. If bzr didn't\n> > have revnos, I'd STILL want my branch to keep its identity. You could\n> > name the mainline revisions after COLORS if you wanted, and I'd still\n> > want my branch to keep its identity. Aren't we through rehashing the\n> > same discussion about the EFFECTS?\n> \n> For revnos to work you MUST have one \"branch\" to be considered\n> special, the hub in star topology. This very much precludes fully\n> distributed development. \n> \n> BTW. I get that you can use revids in revnos in bzr for fully\n> distributed and not star-topology geared development. But\n> Bazaar-NG revids are uglier that Git commit-ids.\n\nOK, just to clarify what you are saying here: \n\n1. revnos don't work because they don't serve the same purpose as revids\nor git's SHA1 commit ids.\n\n2. bzr does not support fully distributed development because revnos\n\"don't work\" as stated in #1.\n\n3. Ok, bzr does support distributed development, I just say it doesn't\nbecause I think revids are ugly.\n\nThus, revids are ugly.\n\nIs this really the argument you want to be making? I'm not disagreeing\nwith you; it's just that I'm not sure it's relevant.\n\nCan we just put the whole \"revnos don't work\" thing to rest?\n\nRevnos are only intended to be significant relative to a given branch.\nThey are not intended to serve as an absolute, global identifier.\n\nRevnos + a url _are_ globally significant, but are not static except in\ncertain topologies.\n\nRevids are globally significant and static in any topology.\n\nIf a user does not like or cannot use revnos, they may use revids.\nRevnos are not a tool to be used for every job. In no way does that mean\nthat they are broken.\n\nIf a given developer or group of developers primarily use revnos or\nrevids, it _may_ indicate that _they_ have a bias towards central (or\nstar) or distributed development, but does not necessarily have any\nbearing on the capability of the VCS being used.\n\n> \n> [...]\n> >> And you say that bzr is not biased towards centralization? In git\n> >> you can just pull (fetch) to check if there were any changes, and if\n> >> there were not you don't get useless marker-merges.\n> > \n> > If I don't tell you my branch has something in it ready to grab, you\n> > shouldn't merge it. It probably won't work, and is quite likely to\n> > set your computer on fire, slaughter and fillet your pet goldfish, and\n> > make demons fly out of your nose. If you wanna get stuck with all my\n> > incomplete WIP, let's just use a CVS module and be done with it.\n> \n> In git I can fetch your changes but I don't need to merge them. Take\n> for example Junio 'pu' (proposed updates) branch: this is the branch\n> you shouldn't merge as it's history is constantly being rewritten.\n> \n> If you don't want for your WIP to be publicly available, you don't\n> publish it. For example as far as I understand Junio works on Git\n> in his private repository, with many, many feature branches, but\n> he does push to public [bare] repository only some subset of branches,\n> and we can fetch/pull only those.\n> \n> But still, if I am impatient I can pull from Junio every hour, and\n> I don't get 24 totally useless empty merge messages if he took day\n> off and didn't publish any changes till day later.\n> \n> >> 2. But the preferred git workflow is to have two branches in each of\n> >> two clones. The 'origin' branch where you fetch changes from other\n> >> repository (so called \"tracking branch\") and you don't commit your\n> >> changes to [...]\n> > \n> > Funny, since this reads to me EXACTLY like the bzr flow of \"upstream\n> > branch I pull\" and \"my branch I merge from upstream\" that's getting\n> > kvetched around...\n> \n> But please, have you realized that in this workflow the two clones\n> of the same repository are totally symmetrical? One's 'master' is\n> another 'origin' and vice versa. After pull on one side, and pull\n> on the other side (without any changes in between) we have the same\n> contents, and the same revision names (commit-ids in git), even if\n> the changes (revisions) got to those clones in different order.\n> In bzr those two \"branches\" would get different revnos. No symmetry.\n> Full distributed vs star topology (one branch \"central\", hence\n> \"centralized\" - I don't mean need to access to one central repository,\n> although...)\n\nI think that when I attempt to pull from one branch to another, if they\nare identical, neither branch changes. Merging + pulling results in\nidentical history, causing revnos on the pulling branch to change. Just\nmerging maintains divergent views of the same history. \n\nPerhaps bzr has a central bias in the view that each developer has the\noption of seeing their own branch as the central focus of his/her\ndevelopment. This view would be the same from each branch; each\ndeveloper views his/her own branch as special. If the developer does not\nwant to view their own branch specially, they would merge + pull rather\nthan just merging. If I remember correctly, abentley covered this\nearlier in this whole \"VCS comparison table\" thread.\n\nAnyway, much of this seems to be a disagreement over the definition of\n\"distributed VCS.\" Perhaps this is too simplistic, but to my inexpert\neyes, these appear to be the positions of each side:\n\nBzr: Branches and all shared history may be stored locally in disparate\nlocations, and all VCS functions are available locally.\n\nGit: Same thing, except that all shared history must also be identically\nordered.\n\nDid I get that right?\n\nIn general, as a mere _user_ of distributed VCS, all I care about is if\nI can accurately point you to a particular commit or set of commits, and\nthat you can access them either in shared history or in a given branch.\nThe fact that the VCS does not require a central branch and facilitates\ncode interchange, means to me that it is distributed. As long as all\nmajor uses are fully supported, being slightly biased toward one use\ncase or another is not a distinction I consider to be worth making.\n\n-davidc\n-- \ngpg-key: http://www.zettazebra.com/files/key.gpg\n"},{"id":"29659","messageId":"200610222127.36197.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061022185350.GW75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-22T19:27:35Z","receivedAt":"2006-10-22T19:27:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Son, Oct 22, 2006 Matthew D. Fuller wrote:\n> On Sun, Oct 22, 2006 at 07:25:41AM -0700 I heard the voice of\n> Carl Worth, and lo! it spake thus:\n>>\n>> \tgit pull . mainline\n> \n> This throws me a little. I'd expect it to Just Do It when it's\n> fast-forwarding, but if it's doing a merge, I'd prefer it to stop and\n> wait before creating the commit, even if there are no textual\n> conflicts. I realize you can just look at it afterward and back out\n> the commit if necessary, but still...\n\nOr you can use --no-commit option to git pull, and commit later.\nBut it is true that you can always amend the commit with\ngot commit --amend, even if the commit is merge.\n \n>> Ah, I hadn't realized that bzr commits stored an \"originating\n>> branch\" inside them.\n> \n> Every branch has a nickname, settable with 'bzr nick' (defaulting to\n> whatever the directory it's in is), and that's stored as a text field\n> in each commit. It's mostly cosmetic, but it's handy to see at a\n> glance.\n\nIf I remember correctly Linus argued against it, because branch\nname is something local to repository (most common example is\n\"mine 'master' is yours 'origin'\").\n\nThere was proposal for \"note\" header for notes like merge algorithm\nused, or branch name, visible only in 'raw' mode, but it wasn't \nimplemented.\n\n>> The mainline..featureA syntax literally just means:\n>> \n>> \tthe set of commits that are reachable by featureA\n>> \tand excluding the set of commits reachable by mainline\n> \n> From what I can gather from this, though, that means that when I merge\n> stuff from featureA into mainline (and keep on with other stuff in\n> featureA), I'll no longer be able to see those older commits from this\n> command. And I'll see merged revisions from branches other than\n> mainline (until they themselves get merged into mainline), correct?\n> It sounds more like a 'bzr missing --mine-only' than looking down a\n> mainline in log...\n\nThat's true. That is what history viewers are for (gitk, qgit, tig,\ngitview, git-show-branch, git-browser) are for.\n\nAnd there is always reflog (if you enable it, of course).\n"},{"id":"29661","messageId":"1161545807.22276.135.camel@zepto.home.zettazebra.com","threadId":"5925","inReplyTo":"87ac3p1jn7.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"David Clymer","fromEmail":"david@zettazebra.com","sentAt":"2006-10-22T19:36:47Z","receivedAt":"2006-10-22T19:36:47Z","isPatch":false,"sender":{"key":"david@zettazebra.com","avatar":"https://gravatar.com/avatar/cdcfe06796c2f046978e5667e21c2e6567f8db8c91d8eb81d7eb86f3f6bc77b7?d=mp&s=160"},"body":"On Sat, 2006-10-21 at 13:47 -0700, Carl Worth wrote:\n> On Sat, 21 Oct 2006 08:01:11 -0500, \"Matthew D. Fuller\" wrote:\n> > I think we're getting into scratched-record-mode on this.\n> \n> I apologize if I've come across as beating a dead horse on this. I've\n> really tried to only respond where I still confused, or there are\n> explicit indications that the reader hasn't understood what I was\n> saying, (\"I don't understand how you've come to that conclusion\",\n> etc.). I'll be even more careful about that below, labeling paragraphs\n> as \"I'm missing something\" or \"Maybe I wasn't clear\".\n> \n> > G: So use revids everywhere.\n> >\n> > B: Revnos are handier tools for [situation] and [situation] for\n> > [reason] and [reason].\n> \n> I'm missing something:\n> \n> I still haven't seen strong examples for this last claim. When are\n> they handier? I asked a couple of messages back and two people replied\n> that given one revno it's trivial to compute the revno of its\n> parent. But that's no win over git's revision specifications,\n> (particularly since they provide \"parent of\" operators).\n\nI would say that: revnos are handier tools than revids...etc\n\nI think that since G: was making a statement about revids, B: was making\nan implicit comparison with them.\n\nbzr log -r before:1 \n\nbeing handier than\n\nbzr log -r before:revid:david@zettazebra.com-20061022175244-4b85cb5f0cbc79ad\n\n\n-davidc\n-- \ngpg-key: http://www.zettazebra.com/files/key.gpg\n"},{"id":"29664","messageId":"200610222157.16086.jnareb@gmail.com","threadId":"5925","inReplyTo":"1161544685.22276.127.camel@zepto.home.zettazebra.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-22T19:57:15Z","receivedAt":"2006-10-22T19:57:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David Clymer wrote:\n> Bzr: Branches and all shared history may be stored locally in disparate\n> locations, and all VCS functions are available locally.\n\nBranches in bzr are both one-source (one head) DAG (of parents), and\nthe \"mainline\" i.e. track of commits commited in this branch-as-place.\nBazaar-NG tries to keep both information in DAG by using first parent\nto mark commits on current branch-as-place.\n\nAdditionally bzr by default uses revnos, numbering commits on branch,\nwhich needs maintaining mainline identity for revnos not to change\neven for one branch-as-place.\n\nThis leads to the need to use \"merge\" if you want to maintain revnos\nunchanged, and \"pull\" if you are not interested in that.\n\n\nGit correctly realizes that mainline identity is local information,\nand instead of trying to save local information in DAG which is shared,\nit uses reflog.\n\n[That's of course totally biased view.]\n \n> Git: Same thing, except that all shared history must also be identically\n> ordered.\nThat is the EFFECT of preferring fast-forward over preserving\n\"first parent is my branch\" property. So the RESULT is that\nshared history is identically ordered.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29665","messageId":"200610222206.13973.jnareb@gmail.com","threadId":"5925","inReplyTo":"1161544685.22276.127.camel@zepto.home.zettazebra.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-22T20:06:13Z","receivedAt":"2006-10-22T20:06:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David Clymer wrote:\n> 1. revnos don't work because they don't serve the same purpose as revids\n> or git's SHA1 commit ids.\nRevnos works only locally, or in star-topology configuration. They have\nsome consequences: treating first parent specially, need for merges\ninstead of fast-forward even if fast-forward would be applicable,\ntwo different \"fetch\" operators: \"pull\" (which uses revids on the\npulled side) and \"merge\" (which preserves revids on pullee side).\n\n> 2. bzr does not support fully distributed development because revnos\n> \"don't work\" as stated in #1.\nBazaar is biased towards centralized/star-topology development if we\nwant to use revids. In fully distributed configuration there is no\n\"simple namespace\".\n\n> 3. Ok, bzr does support distributed development, I just say it doesn't\n> because I think revids are ugly.\nI think that bzr revids are uglier that git commit-ids.\n\nIf on the pros side of bzr is \"simple namespace\", you must remember that\nit is simple namespace only for not fully distributed development. The\npros of \"simple namespace\" with cons of \"merge\" vs \"pull\" and centralization\nrequired for uniqueness of revids.\n-- \nJakub Narebski\nPoland\n"},{"id":"29676","messageId":"Pine.LNX.4.63.0610222301080.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"7v4ptyjttb.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] threeway_merge: if file will not be touched, leave it alone","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-22T21:04:07Z","receivedAt":"2006-10-22T21:04:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nIf the merge base _and_ the to-be merged brach have a certain file, but\nHEAD has not, do not complain if that file exists anyway. It will not be\noverwritten.\n\nSigned-off-by: Johannes Schindelin \n\n---\n\n\tOn Fri, 20 Oct 2006, Junio C Hamano wrote:\n\n\t> While we are talking about merge-recursive, I could use some\n\t> help from somebody familiar with merge-recursive to complete the\n\t> read-tree changes Linus mentioned early this month.\n\t>\n\t> The issue is that we would want to remove one verify_absent()\n\t> call in unpack-tree.c:threeway_merge(). When read-tree decides\n\t> to leave higher stages around, we do not want it to check if the\n\t> merge could clobber a working tree file, because having an\n\t> unrelated file at the same path in the working tree sometimes is\n\t> and sometimes is not a conflict, depending on the outcome of the\n\t> merge, and that part of the code does not _know_ the outcome\n\t> yet.\n\n\tHow about this? It passes the testsuite, and I tested it with the \n\ttest case you did, and with the same test case with recursive \n\tmerge.\n\n unpack-trees.c | 5 ++---\n 1 files changed, 2 insertions(+), 3 deletions(-)\n\ndiff --git a/unpack-trees.c b/unpack-trees.c\nindex 3ac0289..b4994c4 100644\n--- a/unpack-trees.c\n+++ b/unpack-trees.c\n@@ -658,10 +658,9 @@ int threeway_merge(struct cache_entry **\n \t * up-to-date to avoid the files getting overwritten with\n \t * conflict resolution files.\n \t */\n-\tif (index) {\n+\tif (index)\n \t\tverify_uptodate(index, o);\n-\t}\n-\telse if (path)\n+\telse if (no_anc_exists)\n \t\tverify_absent(path, \"overwritten\", o);\n \n \to->nontrivial_merge = 1;\n-- \n1.4.3.1.ga3de1-dirty\n"},{"id":"29685","messageId":"7vlkn80wv2.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610222301080.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] threeway_merge: if file will not be touched, leave it alone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-22T23:11:29Z","receivedAt":"2006-10-22T23:11:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> \tHow about this? It passes the testsuite, and I tested it with the \n> \ttest case you did, and with the same test case with recursive \n> \tmerge.\n>\n> unpack-trees.c | 5 ++---\n> 1 files changed, 2 insertions(+), 3 deletions(-)\n>\n> diff --git a/unpack-trees.c b/unpack-trees.c\n> index 3ac0289..b4994c4 100644\n> --- a/unpack-trees.c\n> +++ b/unpack-trees.c\n> @@ -658,10 +658,9 @@ int threeway_merge(struct cache_entry **\n> \t * up-to-date to avoid the files getting overwritten with\n> \t * conflict resolution files.\n> \t */\n> -\tif (index) {\n> +\tif (index)\n> \t\tverify_uptodate(index, o);\n> -\t}\n> -\telse if (path)\n> +\telse if (no_anc_exists)\n> \t\tverify_absent(path, \"overwritten\", o);\n> \n> \to->nontrivial_merge = 1;\n\nThis feels wrong at the philosophical level. unpack-trees and\nread-tree do not know, and more importantly, do not want to\ndecide, the outcome of the merge, so it should not be doing\nverify_absent because it does not know if the path will be\noverwritten by the merge.\n\nComplaining when no_anc_exists means that threeway_merge() is\ndeciding that the merge result should have the path in this\ncase. It might be true for the current merge-recursive and\nmerge-resolve, but I do not think we should force that decision\non future merge strategies, since that is the whole point of\ndeclaring the merge to be nontrivial and _not_ deciding the\noutcome ourselves here.\n"},{"id":"29692","messageId":"Pine.LNX.4.63.0610230228340.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"7vlkn80wv2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] threeway_merge: if file will not be touched, leave it alone","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-23T00:48:14Z","receivedAt":"2006-10-23T00:48:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 22 Oct 2006, Junio C Hamano wrote:\n\n> Complaining when no_anc_exists means that threeway_merge() is deciding \n> that the merge result should have the path in this case.\n\nTwo points:\n\n- you are correct for at least the case of choosing the merge strategy \n\"theirs\". (Which does not exist yet.)\n\n- in merge-recursive.c:process_entry() (which is called on _all_ unmerged \nentries after threeway merge), \"Case A\" reads \"deleted in one branch\". \nReading the code again, I believe there is a bug, which should be fixed by\n\ndiff --git a/merge-recursive.c b/merge-recursive.c\nindex 2ba43ae..9f6538a 100644\n--- a/merge-recursive.c\n+++ b/merge-recursive.c\n@@ -1005,9 +1005,10 @@ static int process_entry(const char *pat\n \t\t (!a_sha && sha_eq(b_sha, o_sha))) {\n \t\t\t/* Deleted in both or deleted in one and\n \t\t\t * unchanged in the other */\n-\t\t\tif (a_sha)\n+\t\t\tif (!a_sha) {\n \t\t\t\toutput(\"Removing %s\", path);\n-\t\t\tremove_file(1, path);\n+\t\t\t\tremove_file(1, path);\n+\t\t\t}\n \t\t} else {\n \t\t\t/* Deleted in one and changed in the other */\n \t\t\tclean_merge = 0;\n\nNote that not only it groups the call to output() and remove_file(), which \nmatches the expectation, but also changes the condition to \"!a_sha\", \nmeaning that the file is deleted in branch \"a\", but existed in the merge \nbase, where it is identical to what is in branch \"b\".\n\nOf course, this assumes that even in the recursive case, branch \"a\" is to \nbe preferred over branch \"b\". (If I still remember correctly, then branch \n\"a\" is either the current head, or the temporary recursive merge, so this \nwould make sense to me.)\n\nSo, after applying this patchlet, merge-recursive (more precisely: the \nfunction process_entry()) should behave correctly with the change to \nunpack-trees.c you have in pu, i.e. the change that drops that \nverify_absent() call to the floor.\n\nHowever, I could use some additional optical lobes here.\n\nCiao,\nDscho\n\nP.S.: Maybe I was wrong on my earlier assessment, that merge-recursive \ndoes not optimize the \"subtrees have identical SHA1s\" case. This should be \nhandled pretty well by the call to unpack_trees() with threeway merge.\n"},{"id":"29698","messageId":"7vejszzmvy.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610230228340.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] threeway_merge: if file will not be touched, leave it alone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-23T04:17:37Z","receivedAt":"2006-10-23T04:17:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> diff --git a/merge-recursive.c b/merge-recursive.c\n> index 2ba43ae..9f6538a 100644\n> --- a/merge-recursive.c\n> +++ b/merge-recursive.c\n> @@ -1005,9 +1005,10 @@ static int process_entry(const char *pat\n> \t\t (!a_sha && sha_eq(b_sha, o_sha))) {\n> \t\t\t/* Deleted in both or deleted in one and\n> \t\t\t * unchanged in the other */\n> -\t\t\tif (a_sha)\n> +\t\t\tif (!a_sha) {\n> \t\t\t\toutput(\"Removing %s\", path);\n> -\t\t\tremove_file(1, path);\n> +\t\t\t\tremove_file(1, path);\n> +\t\t\t}\n> \t\t} else {\n> \t\t\t/* Deleted in one and changed in the other */\n> \t\t\tclean_merge = 0;\n>\n> Note that not only it groups the call to output() and remove_file(), which \n> matches the expectation, but also changes the condition to \"!a_sha\", \n> meaning that the file is deleted in branch \"a\", but existed in the merge \n> base, where it is identical to what is in branch \"b\".\n\nI think the conditional \"output\" is to mimic the first case in\ngit-merge-one-file; there we conditionally give that message\nonly when ours had that path. If we lost the path while they\nhave it the same way as the common ancestor, then we do not have\nthe path to begin with when we start the merge. It is not\ncorrect to say \"Removing\" in such a case.\n\nSo the output() call being tied to if (a_sha) _is_ correct in\nyour code.\n\nWhat we would want to prevent is to remove the path from the\nworking tree when we did not have the path at the beginning of\nthe merge and the merge result says we do not want that path.\nIn such a case, the file in the working tree is an untracked\nfile that is not touched by the merge.\n\nE.g gitweb/gitweb.cgi is not tracked in the current \"master\",\nbut used to be around v1.4.0 time. If you try to merge a\nbranch forked from v1.4.0 because you are interested in a work\non other part of the system (i.e. the branch did not touch\ngitweb/ at all), we want to successfully merge that branch into\nour \"master\" even after \"make\" created gitweb/gitweb.cgi.\n\nSuch a merge would start with your HEAD and index missing\ngitweb/gitweb.cgi but the path still in your working tree. The\ncommon ancestor and their tree has the path tracked, so you\nwould end up with identical stage #1 and #3 with missing stage\n#2.\n\nThe merge machinery should say the merge result does not have\nthe path, so it should remove it from the index. However, it\nshould _not_ touch the untracked (from the beginning of the time\nthe merge started) working tree file. So remove_file() call you\ntouch in your patch needs to be told not to update working\ndirectory in such a case.\n\nUnder \"aggressive\" rule, threeway_merge() is requested to make\nthe merge policy decision, so it should also loosen this check\nitself. The change by commit 0b35995 needs to be updated with\nthis patch:\n\ndiff --git a/unpack-trees.c b/unpack-trees.c\nindex b1d78b8..7cfd628 100644\n--- a/unpack-trees.c\n+++ b/unpack-trees.c\n@@ -642,7 +642,7 @@ int threeway_merge(struct cache_entry **\n \t\t (remote_deleted && head && head_match)) {\n \t\t\tif (index)\n \t\t\t\treturn deleted_entry(index, index, o);\n-\t\t\telse if (path)\n+\t\t\telse if (path && !head_deleted)\n \t\t\t\tverify_absent(path, \"removed\", o);\n \t\t\treturn 0;\n \t\t}\n"},{"id":"29701","messageId":"20061023051932.GA8625@evofed.localdomain","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610220926170.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Matthew Hannigan","fromEmail":"mlh@zip.com.au","sentAt":"2006-10-23T05:19:32Z","receivedAt":"2006-10-23T05:19:32Z","isPatch":false,"sender":{"key":"mlh@zip.com.au","avatar":null},"body":"On Sun, Oct 22, 2006 at 10:12:00AM -0700, Linus Torvalds wrote:\n> [ ... ]\n> \n> Again, the way to solve this would tend to be to have a few helper \n> scripts that use regular file-contents that _describe_ these things to \n> do \"realdiff\" and \"install\".\n> \n> In other words, for at least three _totally_ different reasons, you really \n> don't want to do tracking/development directly in /etc, but you want to \n> have a buffer zone to do it. And once you have that, you might as well do \n> _that_ as the repository, and just add a few specialty commands (let's \n> call them \"plugins\" to make everybody happy) to do the special things.\n\nDamn you stole my idea! I had this scheme brewing in my head too,\nwith some slight variations:\n\n> \t# copy the data, set up a PERMISSIONS file to track extra info\n> \tsudo cp /etc/group /etc/passwd /etc/shadow .\n> \tsudo chown user:user *\n> \tcat < PERMISSIONS\n> \tgroup root:root 0644\n> \tpasswd root:root 0644\n> \tshadow root:root 0400\n> \tEOF\n\nYou may want one perms/metadata file per real file (file.meta?) with contents\nlike:\n\towner root\n\tgroup root\n\tperms u=r,go=\n\nfor possibly easier to digest diff output. You could omit \"don't care\" variables.\nYou could still have one overarching file (DEFAULT.meta) for defaults. Also, you\nmay want to track the implied umask instead of the real perms.\n\nYou could also track the pathname, (e.g. path /etc/group, path /etc/inet/hosts) so you\ndidn't have to match the structure of the working tree to the actual destination.\n\n> And again, I'm not going to even claim that the above two \"plugins\" are \n> the right ones (maybe you want other operations too to interact with the \n> \"real\" installed files), [ ... ]\n\nYes, there are other very useful transformations possible. One example is to\nsplit the /etc/group file into a series of files, each named after the group,\nwith contents the sorted list of members. Again, this is useful for 'diff' and\nany SCM. It's important that it's a lossless transformation in both\ndirections; you may want to scan the destination and make sure\nyour base revision matches it before 'git install'.\n\n> Btw: none of this is really \"git-specific\". The above tells you how to do \n> local \"git plugins\", and it's obviously fairly trivial, but I suspect any \n> SCM can be used in this manner.\n\nIndeed, the essential thing about this is you're representing any\nsystem modification as a text diff, so it makes sense for any\nSCM. In fact the 'plugin' for any SCM would be 95% the same code.\n\nThis might also be useful for SCMs that don't handle symlinks\nnatively.\n\n--\nMatt Hannigan\n"},{"id":"29711","messageId":"1161604564.22276.173.camel@zepto.home.zettazebra.com","threadId":"5925","inReplyTo":"200610222206.13973.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"David Clymer","fromEmail":"david@zettazebra.com","sentAt":"2006-10-23T11:56:04Z","receivedAt":"2006-10-23T11:56:04Z","isPatch":false,"sender":{"key":"david@zettazebra.com","avatar":"https://gravatar.com/avatar/cdcfe06796c2f046978e5667e21c2e6567f8db8c91d8eb81d7eb86f3f6bc77b7?d=mp&s=160"},"body":"On Sun, 2006-10-22 at 22:06 +0200, Jakub Narebski wrote:\n> David Clymer wrote:\n> > 1. revnos don't work because they don't serve the same purpose as revids\n> > or git's SHA1 commit ids.\n> Revnos works only locally, or in star-topology configuration. They have\n> some consequences: treating first parent specially, need for merges\n> instead of fast-forward even if fast-forward would be applicable,\n> two different \"fetch\" operators: \"pull\" (which uses revids on the\n> pulled side) and \"merge\" (which preserves revids on pullee side).\n\ns/revids/revnos/g but yes, I think I said this later in my previous\nemail.\n\n> \n> > 2. bzr does not support fully distributed development because revnos\n> > \"don't work\" as stated in #1.\n> Bazaar is biased towards centralized/star-topology development if we\n> want to use revids. In fully distributed configuration there is no\n> \"simple namespace\".\n\nSo revnos aren't globally meaningful in fully distributed settings. So\nwhat? I don't see how this translates into bias. There is a lot of\nfunctionality provided by bazaar that doesn't really apply to my use\ncase, but it doesn't mean that it is indicative of some bias in bazaar.\n\n> \n> > 3. Ok, bzr does support distributed development, I just say it doesn't\n> > because I think revids are ugly.\n> I think that bzr revids are uglier that git commit-ids.\n> \n> If on the pros side of bzr is \"simple namespace\", you must remember that\n> it is simple namespace only for not fully distributed development. The\n> pros of \"simple namespace\" with cons of \"merge\" vs \"pull\" and centralization\n> required for uniqueness of revids.\n\nI think you've switched revids and revnos, but I get what you are\nsaying. In fact, I think I said pretty much the same thing in the email\nyou are replying to. I don't think that anyone is disagreeing about\nanything other than the assertion that bzr is biased because revnos are\nused to simplify cases where it is possible to do so.\n\nIn any case, Matthew Fuller & Carl Worth cover this in greater detail in\nemails further down in this thread (or one of its siblings), so I think\nI'll stop here.\n\n-davidc\n\n-- \ngpg-key: http://www.zettazebra.com/files/key.gpg\n"},{"id":"29714","messageId":"200610231454.06355.jnareb@gmail.com","threadId":"5925","inReplyTo":"1161604564.22276.173.camel@zepto.home.zettazebra.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-23T12:54:02Z","receivedAt":"2006-10-23T12:54:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, Oct 23, 2006 David Clymer wrote:\n> On Sun, 2006-10-22 at 22:06 +0200, Jakub Narebski wrote:\n>> David Clymer wrote:\n\n>>> 2. bzr does not support fully distributed development because revnos\n>>> \"don't work\" as stated in #1.\n>>\n>> Bazaar is biased towards centralized/star-topology development if we\n>> want to use revnos. In fully distributed configuration there is no\n>> \"simple namespace\".\n> \n> So revnos aren't globally meaningful in fully distributed settings. So\n> what? I don't see how this translates into bias. There is a lot of\n> functionality provided by bazaar that doesn't really apply to my use\n> case, but it doesn't mean that it is indicative of some bias in bazaar.\n\nFirst, bzr is biased towards using revnos: bzr commands uses revnos\nby default to provide revision (you have to use revid: prefix/operator\nto use revision identifiers), bzr commands outputs revids only when\nrequested, examples of usage uses revision numbers.\n\nIn order to use revnos as _global_ identifiers in distributed development,\nyou need central \"branch\", mainline, to provide those revnos. You have\neither to have access to this \"revno server\" and refer to revisions by\n\"revno server\" URL and revision number, or designate one branch as holding\nrevision numbers (\"revno server\") and preserve revnos on \"revno server\"\nby using bzr \"merge\", while copying revnos when fetching by using bzr \"pull\"\nfor leaf branches. In short: for revnos to be global identifiers you need\nstar-topology.\n\nEven if you use revnos only locally, you need to know which revisions are\n\"yours\", i.e. beside branch as DAG of history of given revision you need\n\"ordered series of revisions\" (to quote Bazaar-NG wiki Glossary), or path\nthrough this diagram from given revision to one of the roots (initial,\nparentless revisions). Because bzr does that by preserving mentioned path\nas first-parent path (treating first parent specially), i.e. storing local\ninformation in a DAG (which is shared), to preserve revnos you need to\nuse \"merge\" instead of \"pull\", which means that you get empty-merge in\nclearly fast-forward case. This means \"local changes bias\", which some\nmight take as not being fully distributed.\n\nSidenote 1: Why Bazaar-NG tries to store \"branch as ordered series\nof revisions\"/\"branch as path through revisions DAG\" in DAG instead\nof storing it separately (like reflog stores history of tip of branch,\nwhich is roughly equivalent of \"branch as path\" in bzr). It needs\nsome kind of cache of mapping from revno to the revision itself anyway\n(unless performance doesn't matter for bzr developers ;-)! All what\nleft is to propagate this mapping on \"pull\"...\n\nSidenote 2: \"Fringe\" developer using default git configuration of\n'origin' branch tracking 'master' branch in cloned (mainline) repo,\nand 'master' branch on which he/she does his/her own work, who committed\nat least single revision on his/her 'master' branch, and whose changes\nare never pulled and if they get into mainline repo it is using \"side\"\nchannel like git-enchanced patches sent to project mailing list,\nwill see the picture similar to the bzr branch which uses \"merge\".\n\n\nThe whole discussion about validity of revision numbers started\nwith \"simple namespace\" feature in SCM comparison matrix on Bazaar-NG\nwiki...\n-- \nJakub Narebski\nPoland\n"},{"id":"29717","messageId":"a7e835d40610230801m4ac92409gbddcf66dcd1bb429@mail.gmail.com","threadId":"5925","inReplyTo":"200610231454.06355.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"James Henstridge","fromEmail":"james@jamesh.id.au","sentAt":"2006-10-23T15:01:42Z","receivedAt":"2006-10-23T15:01:42Z","isPatch":false,"sender":{"key":"james@jamesh.id.au","avatar":"https://gravatar.com/avatar/3007d1d261c8d1edc4e388f53ea5e53ab40fd5f8334748472ba0e2037b76e4aa?d=mp&s=160"},"body":"On 23/10/06, Jakub Narebski wrote:\n> First, bzr is biased towards using revnos: bzr commands uses revnos\n> by default to provide revision (you have to use revid: prefix/operator\n> to use revision identifiers), bzr commands outputs revids only when\n> requested, examples of usage uses revision numbers.\n\nAs has been said before, you can set an alias to always show revision\nIDs in \"bzr log\" output.\n\n\n> In order to use revnos as _global_ identifiers in distributed development,\n> you need central \"branch\", mainline, to provide those revnos. You have\n> either to have access to this \"revno server\" and refer to revisions by\n> \"revno server\" URL and revision number, or designate one branch as holding\n> revision numbers (\"revno server\") and preserve revnos on \"revno server\"\n> by using bzr \"merge\", while copying revnos when fetching by using bzr \"pull\"\n> for leaf branches. In short: for revnos to be global identifiers you need\n> star-topology.\n\nWhy do you continue to repeat this argument? No one is claiming that\na revision number by itself, as Bazaar uses them, is a global\nidentifier. In fact, we keep on saying that they only have meaning in\nthe context of a branch. If you want to use a revision number as part\nof a globally unique identifier, it needs to be in combination with\nits branch.\n\n\n> Even if you use revnos only locally, you need to know which revisions are\n> \"yours\", i.e. beside branch as DAG of history of given revision you need\n> \"ordered series of revisions\" (to quote Bazaar-NG wiki Glossary), or path\n> through this diagram from given revision to one of the roots (initial,\n> parentless revisions). Because bzr does that by preserving mentioned path\n> as first-parent path (treating first parent specially), i.e. storing local\n> information in a DAG (which is shared), to preserve revnos you need to\n> use \"merge\" instead of \"pull\", which means that you get empty-merge in\n> clearly fast-forward case. This means \"local changes bias\", which some\n> might take as not being fully distributed.\n\nI won't dispute that Bazaar has features that make it easier to work\nwith the revisions in the line of development of the branch you're\nworking on in comparison to the revisions from merges. But given that\nevery Bazaar branch has this same bias towards their own main line of\ndevelopment, how can that affect whether or not it is distributed?\n\nJames.\n"},{"id":"29730","messageId":"Pine.LNX.4.63.0610230943230.7756@qynat.qvtvafvgr.pbz","threadId":"5925","inReplyTo":"20061022185350.GW75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-10-23T16:57:45Z","receivedAt":"2006-10-23T16:57:45Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":">> This special treatment influences or directly causes many of the\n>> things in bzr that we've been discussing:\n> [...]\n>> I've been arguing that all of these impacts are dubious. But I can\n>> understand that a bzr user hearing arguments against them might fear\n>> that they would lose the ability to be able to see a view of commits\n>> that \"belong\" to a particular branch.\n>\n> Dead center.\n>\n>\n>> The mainline..featureA syntax literally just means:\n>>\n>> \tthe set of commits that are reachable by featureA\n>> \tand excluding the set of commits reachable by mainline\n>\n> From what I can gather from this, though, that means that when I merge\n> stuff from featureA into mainline (and keep on with other stuff in\n> featureA), I'll no longer be able to see those older commits from this\n> command. And I'll see merged revisions from branches other than\n> mainline (until they themselves get merged into mainline), correct?\n> It sounds more like a 'bzr missing --mine-only' than looking down a\n> mainline in log...\n\none thing you are missing 'mainline' in this git command is not saying \n'everything that's in the 'main' published branch'. it's saying 'everything \nreachable by the tag 'mainline'\n\nso when you branched off for your feature development you could set a tag that \nsays 'branchpoint' and no matter what gets merged in mainline after that you can \nalways do branchpoint..featureA and find what you've done.\n\nthat being said, mainline..featureA is also extremely useful, it tells you what \ndevelopment stuff you have done that have not yet been merged into mainline\n\nDavid Lang\n"},{"id":"29731","messageId":"453CF966.7000308@utoronto.ca","threadId":"5925","inReplyTo":"a7e835d40610230801m4ac92409gbddcf66dcd1bb429@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-23T17:18:30Z","receivedAt":"2006-10-23T17:18:30Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJames Henstridge wrote:\n> Why do you continue to repeat this argument? No one is claiming that\n> a revision number by itself, as Bazaar uses them, is a global\n> identifier. In fact, we keep on saying that they only have meaning in\n> the context of a branch.\n\nAnd, unlike git, Bazaar branches are all independent entities[1], and\nthey each have a URL.\n\nSo:\n\nhttp://code.aaronbentley.com/bzrrepo/bzr.ab 1695\n\nis a name for\n\nabentley@panoramicfeedback.com-20060927202832-9795d0528e311e31\n\nAnd it does not depend on any other branch, especially not bzr.dev\n\nSince:\n1. anyone with write access to the urls can create them\n2. anyone with read access to the urls can read them\n3. the maintainers of the mainline have no control over them\n (except as provided by 1)\n\nthese identifiers are not centralized.\n\nAaron\n\n[1] The fact that they may share storage is not important to the model.\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFPPlm0F+nu1YWqI0RAlmLAJ9cpw5X7UXQ82EmoIeUrKzEaFbhdACfZPsS\nCRJ69XWi7XAWJRi7Fgt9ICU=\n=WrV9\n-----END PGP SIGNATURE-----\n"},{"id":"29732","messageId":"Pine.LNX.4.64.0610231018410.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061022185350.GW75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-23T17:29:53Z","receivedAt":"2006-10-23T17:29:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 22 Oct 2006, Matthew D. Fuller wrote:\n> \n> > This special treatment influences or directly causes many of the\n> > things in bzr that we've been discussing:\n> [...]\n> > I've been arguing that all of these impacts are dubious. But I can\n> > understand that a bzr user hearing arguments against them might fear\n> > that they would lose the ability to be able to see a view of commits\n> > that \"belong\" to a particular branch.\n> \n> Dead center.\n\nThe thing that the bzr people don't seem to realize is that their choice \nof revision naming has serious side effects, some of them really \ntechnical, and limiting.\n\nI already briought this up once, and I suspect that the bzr people simply \nDID NOT UNDERSTAND the question:\n\n - how do you do the git equivalent of \"gitk --all\"\n\nwhich is just another reason why \"branch-local\" revision naming is simply \nstupid and has real _technical_ problems.\n\nI really suspect that a lot of people can't see further than their own \nfeet, and don't understand the subtle indirect problems that branch-local \nnaming causes. \n\nFor example, how long does it take to do an arbitrary \"undo\" (ie forcing a \nbranch to an earlier state) in a project with tens of thousands of \ncommits? That's actually a really important operation, and yes, \nperformance does matter. It's something that you do a lot when you do \nthings like \"bisect\" (which I used to approximate with BK by hand, and \nyes, re-weaving the branch history was apparently a big part of why it \ntook _minutes_ to do sometimes).\n\nAgain, this is something that people don't expect to have _anything_ to do \nwith revision numbering, but the fact is, it's a big part of the picture. \nIf you have branch-local revision numbering, you need to renumber all \nrevisions on events like this, and even if it is \"just\" re-creatigng the \nrevno->\"real ID\" cache, it's actually an expensive operation exactly \nbecause it's going to be at least linear in history.\n\nOne of the git design requirements was that no operation should _ever_ \nneed to be linear in history size, because it becomes a serious limiter of \nscalability at some point. We were seeing some of those issues with BK, \nwhich is why I cared.\n\nSo in git, doing things like jumping back and forth in history is O(1). \nAlways (with a really low constant cost too). Of course, checking out the \nend result is then roughly O(n), but even there \"n\" is the size of the \n_changes_, not number of revisions or number of files.\n\n(And there are obviously operations that _are_ O(revision history), the \nmost trivial one being anything that visualizes all of history - but they \ndepend on the size of history not because the operation itself gets more \nexpensive, but because the dataset increases).\n\nThe whole confusing between \"bzr pull\" and \"bzr merge\" is another \n_technical_ sign of why branch-local revision numbers are a mistake. \n\n\t\t\tLinus\n"},{"id":"29733","messageId":"200610231953.19605.jnareb@gmail.com","threadId":"5925","inReplyTo":"453CF966.7000308@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-23T17:53:17Z","receivedAt":"2006-10-23T17:53:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> James Henstridge wrote:\n\n>> Why do you continue to repeat this argument? No one is claiming that\n>> a revision number by itself, as Bazaar uses them, is a global\n>> identifier. In fact, we keep on saying that they only have meaning in\n>> the context of a branch.\n> \n> And, unlike git, Bazaar branches are all independent entities[1], and\n> they each have a URL.\n> \n> So:\n> \n> http://code.aaronbentley.com/bzrrepo/bzr.ab 1695\n> \n> is a name for\n> \n> abentley@panoramicfeedback.com-20060927202832-9795d0528e311e31\n> \n> And it does not depend on any other branch, especially not bzr.dev\n> \n> Since:\n> 1. anyone with write access to the urls can create them\n> 2. anyone with read access to the urls can read them\n> 3. the maintainers of the mainline have no control over them\n> (except as provided by 1)\n> \n> these identifiers are not centralized.\n\nIf you don't use centralized numbers (i.e. always refering to bzr.dev,\neither by using always (bzr.dev URL, revno), or by using \"merge\" for\nbzr.dev and \"pull\" for rest), the numbers are volatile. If URL vanishes,\nthen (URL, revno) to revid mapping is no longer valid. Yeah, I know,\ncool URI don't change...\n\nBesides, you need [constant] network access for this mapping.\n-- \nJakub Narebski\nPoland\n"},{"id":"29735","messageId":"Pine.LNX.4.64.0610231103460.3962@g5.osdl.org","threadId":"5925","inReplyTo":"200610231953.19605.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-23T18:04:48Z","receivedAt":"2006-10-23T18:04:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 23 Oct 2006, Jakub Narebski wrote:\n> \n> Besides, you need [constant] network access for this mapping.\n\nI _think_ that Aaron was trying to say that\n\n\tabentley@panoramicfeedback.com-20060927202832-9795d0528e311e31\n\nis always constant, so you can use that.\n\nOf course, nobody will ever do that, because in practice they're not \nshown, the same way the \"true\" BK revision names were never shown and thus \nnever really used.\n\n\t\tLinus\n"},{"id":"29736","messageId":"200610232021.55625.jnareb@gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610231103460.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-23T18:21:53Z","receivedAt":"2006-10-23T18:21:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n> \n> On Mon, 23 Oct 2006, Jakub Narebski wrote:\n>> \n>> Besides, you need [constant] network access for this mapping.\n> \n> I _think_ that Aaron was trying to say that\n> \n> \tabentley@panoramicfeedback.com-20060927202832-9795d0528e311e31\n> \n> is always constant, so you can use that.\n> \n> Of course, nobody will ever do that, because in practice they're not \n> shown, the same way the \"true\" BK revision names were never shown and thus \n> never really used.\n\nBy the way, I wonder if accidentally identical revisions\n(see example for accidental clean merge on revctrl.org)\nwould get the same revision id in bzr. In git they would.\n-- \nJakub Narebski\nPoland\n"},{"id":"29737","messageId":"1161628001.27312.8.camel@charis.lan.vernstok.nl","threadId":"5925","inReplyTo":"200610232021.55625.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Jelmer Vernooij","fromEmail":"jelmer@samba.org","sentAt":"2006-10-23T18:26:41Z","receivedAt":"2006-10-23T18:26:41Z","isPatch":false,"sender":{"key":"jelmer@samba.org","avatar":"https://avatars.githubusercontent.com/u/49032?v=4"},"body":"On Mon, 2006-10-23 at 20:21 +0200, Jakub Narebski wrote:\n> Linus Torvalds wrote:\n> > On Mon, 23 Oct 2006, Jakub Narebski wrote:\n> >> \n> >> Besides, you need [constant] network access for this mapping.\n> > \n> > I _think_ that Aaron was trying to say that\n> > \n> > \tabentley@panoramicfeedback.com-20060927202832-9795d0528e311e31\n> > \n> > is always constant, so you can use that.\n> > \n> > Of course, nobody will ever do that, because in practice they're not \n> > shown, the same way the \"true\" BK revision names were never shown and thus \n> > never really used.\n> \n> By the way, I wonder if accidentally identical revisions\n> (see example for accidental clean merge on revctrl.org)\n> would get the same revision id in bzr. In git they would.\nThey won't. The revision id is made up of the committers email address,\na timestamp and a bunch of random data. It wouldn't be hard to switch\nusing checksums as revids instead, but I don't think there are any plans\nin that direction.\n\nCheers,\n\nJelmer\n-- \nJelmer Vernooij - http://samba.org/~jelmer/\n"},{"id":"29738","messageId":"200610232031.12399.jnareb@gmail.com","threadId":"5925","inReplyTo":"1161628001.27312.8.camel@charis.lan.vernstok.nl","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-23T18:31:11Z","receivedAt":"2006-10-23T18:31:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jelmer Vernooij wrote:\n>> By the way, I wonder if accidentally identical revisions\n>> (see example for accidental clean merge on revctrl.org)\n>> would get the same revision id in bzr. In git they would.\n\n> They won't. The revision id is made up of the committers email address,\n> a timestamp and a bunch of random data. It wouldn't be hard to switch\n> using checksums as revids instead, but I don't think there are any plans\n> in that direction.\n\nThe place for timestamp and commiter info is in the revision metadata\n(in commit object in git). Not in revision id. Unless you think that\n\"accidentally the same\" doesn't happen...\n-- \nJakub Narebski\nPoland\n"},{"id":"29739","messageId":"Pine.LNX.4.64.0610231124170.3962@g5.osdl.org","threadId":"5925","inReplyTo":"200610232021.55625.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-23T18:34:18Z","receivedAt":"2006-10-23T18:34:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 23 Oct 2006, Jakub Narebski wrote:\n> \n> By the way, I wonder if accidentally identical revisions\n> (see example for accidental clean merge on revctrl.org)\n> would get the same revision id in bzr. In git they would.\n\ngit can have no \"accidentally identical revisions\". They'd have to be \npurposefully done, but yes, they'd obviously (on purpose) get the same \nrevision name if that's the case.\n\nYou may think of tree (not commit) identity, where git on purpose names \ntrees the same regardless of how you got to them. So on a _tree_ level, \nyou are always supposed to get the same result regardless of how you \nimport things (ie two people importing the same tar-ball should always get \nexactly the same tree ID).\n\nBut the actual commit names are identical only if the same people are \nclaimed to have authored (and committed) them at the same time - so it's \ndefinitely not \"accidental\" if the commits are called the same: they \nreally _are_ the same.\n\nBtw, I think you misunderstand the term \"accidental clean merge\". It means \nthat two identical changes on two branches will merge without conflicts \nbeing reported.\n\nA merge algorithm that doesn't do \"accidental clean merge\" is totally \nbroken. The accidental clean merge is a usability requirement for pretty \nmuch anything - you often have two branches doing the same thing (possibly \nfor different reasons - two people independently found the same bug that \nshowed itself in two different ways - so they may even think that they \nare fixing different issues, and may have written totally different \nchangelogs to explain the bug, but the solution is identical and should \nobviously merge cleanly).\n\nSo \"accidental clean merge\" may _sound_ like something bad, but it's \nactually a seriously good property (it's really just a special case of \n\"convergence\" - again, that's a good thing).\n\n\t\tLinus\n"},{"id":"29741","messageId":"1161629052.27312.13.camel@charis.lan.vernstok.nl","threadId":"5925","inReplyTo":"200610232031.12399.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Jelmer Vernooij","fromEmail":"jelmer@samba.org","sentAt":"2006-10-23T18:44:12Z","receivedAt":"2006-10-23T18:44:12Z","isPatch":false,"sender":{"key":"jelmer@samba.org","avatar":"https://avatars.githubusercontent.com/u/49032?v=4"},"body":"On Mon, 2006-10-23 at 20:31 +0200, Jakub Narebski wrote:\n> Jelmer Vernooij wrote:\n> >> By the way, I wonder if accidentally identical revisions\n> >> (see example for accidental clean merge on revctrl.org)\n> >> would get the same revision id in bzr. In git they would.\n> \n> > They won't. The revision id is made up of the committers email address,\n> > a timestamp and a bunch of random data. It wouldn't be hard to switch\n> > using checksums as revids instead, but I don't think there are any plans\n> > in that direction.\n> The place for timestamp and commiter info is in the revision metadata\n> (in commit object in git). Not in revision id. Unless you think that\n> \"accidentally the same\" doesn't happen...\nThe revision id isn't parsed by bzr. It's just a unique identifier that\nis generated at commit-time and is currently created by concatenating\nthose three fields. It can be anything you like. The bzr-svn plugin for\nexample creates revision ids in the form\nsvn:REVNUM@REPOS_UUID-BRANCHPATH and bzr-git uses git:GITREVID. Nothing\nwill break if bzr would start using a different format.\n\nCheers,\n\nJelmer\n\n-- \nJelmer Vernooij - http://samba.org/~jelmer/\n"},{"id":"29742","messageId":"Pine.LNX.4.64.0610231134450.3962@g5.osdl.org","threadId":"5925","inReplyTo":"200610232031.12399.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-23T18:45:13Z","receivedAt":"2006-10-23T18:45:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 23 Oct 2006, Jakub Narebski wrote:\n> \n> The place for timestamp and commiter info is in the revision metadata\n> (in commit object in git). Not in revision id. Unless you think that\n> \"accidentally the same\" doesn't happen...\n\nWell, git and bzr really do share the same \"stable\" revision naming, \nalthough in git it's more indirect, and thus \"covers\" more.\n\nIn git, the revision name indirectly includes the commit comments too (and \ngit obviously also distinguishes between \"committer\" and \"author\", and \nthose end up being indirectly credited in the name of the commit too). But \nin a very real sense, the bzr stable (\"real\") revision name does \neffectively contain the same things as a git ID: it's just that it's a \nsmall subset (only committer+date+random number) of what git includes in \nits names.\n\nSo you could more easily _fake_ a commit name in bzr, and depending on how \nthings are done it might be more open to malicious attacks for that reason \n(or unintentionally - if two people apply the exact same patch from an \nemail, and take the author/date info from the email like hit does, you \nmight have clashes. But with a 64-bit random number, that's probably \nunlikely, unless you also hit some other bad luck like having the \npseudo-random sequence seeded by \"time()\", and people just _happen_ to \napply the email at the exact same second).\n\nThe git use of hashes and parenthood information make any accidental \nclashes like that a non-issue: if you have exactly the same information, \nit really _is_ the same commit, since the hash includes the parenthood \ntoo. So you're left with just malicious attacks, and those currently look \npractically impossible too, of course.\n\nSo I don't think bzr and git differ in this respect. I think you can \n_trust_ stable git names a lot more, but that's a separate issue.\n\n\t\t\tLinus\n"},{"id":"29744","messageId":"1161629801.27312.22.camel@charis.lan.vernstok.nl","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610231134450.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Jelmer Vernooij","fromEmail":"jelmer@samba.org","sentAt":"2006-10-23T18:56:41Z","receivedAt":"2006-10-23T18:56:41Z","isPatch":false,"sender":{"key":"jelmer@samba.org","avatar":"https://avatars.githubusercontent.com/u/49032?v=4"},"body":"On Mon, 2006-10-23 at 11:45 -0700, Linus Torvalds wrote:\n> On Mon, 23 Oct 2006, Jakub Narebski wrote:\n> > The place for timestamp and commiter info is in the revision metadata\n> > (in commit object in git). Not in revision id. Unless you think that\n> > \"accidentally the same\" doesn't happen...\n> Well, git and bzr really do share the same \"stable\" revision naming, \n> although in git it's more indirect, and thus \"covers\" more.\n> \n> In git, the revision name indirectly includes the commit comments too (and \n> git obviously also distinguishes between \"committer\" and \"author\", and \n> those end up being indirectly credited in the name of the commit too). But \n> in a very real sense, the bzr stable (\"real\") revision name does \n> effectively contain the same things as a git ID: it's just that it's a \n> small subset (only committer+date+random number) of what git includes in \n> its names.\nThere are no requirements on what a revid is in bzr. It's a unique\nidentifier, nothing more. It can be whatever you like, as long as it's\nunique for that specific commit. The committer+date+random\\ number is\njust what bzr uses at the moment to create those unique identifiers.\n\n> So you could more easily _fake_ a commit name in bzr, and depending on how \n> things are done it might be more open to malicious attacks for that reason \n> (or unintentionally - if two people apply the exact same patch from an \n> email, and take the author/date info from the email like hit does, you \n> might have clashes. But with a 64-bit random number, that's probably \n> unlikely, unless you also hit some other bad luck like having the \n> pseudo-random sequence seeded by \"time()\", and people just _happen_ to \n> apply the email at the exact same second).\nBzr stores a checksum of the commit separately from the revision id in\nthe metadata of a revision. The revision is not used by itself to check\nthe integrity of a revision.\n\nCheers,\n\nJelmer\n\n-- \nJelmer Vernooij - http://samba.org/~jelmer/\n"},{"id":"29745","messageId":"20061023190259.GA7845@spearce.org","threadId":"5925","inReplyTo":"1161629801.27312.22.camel@charis.lan.vernstok.nl","subject":"Re: VCS comparison table","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-23T19:02:59Z","receivedAt":"2006-10-23T19:02:59Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jelmer Vernooij wrote:\n> On Mon, 2006-10-23 at 11:45 -0700, Linus Torvalds wrote:\n> > On Mon, 23 Oct 2006, Jakub Narebski wrote:\n> > > The place for timestamp and commiter info is in the revision metadata\n> > > (in commit object in git). Not in revision id. Unless you think that\n> > > \"accidentally the same\" doesn't happen...\n> > Well, git and bzr really do share the same \"stable\" revision naming, \n> > although in git it's more indirect, and thus \"covers\" more.\n> > \n[snip]\n> > So you could more easily _fake_ a commit name in bzr, and depending on how \n> > things are done it might be more open to malicious attacks for that reason \n> > (or unintentionally - if two people apply the exact same patch from an \n> > email, and take the author/date info from the email like hit does, you \n> > might have clashes. But with a 64-bit random number, that's probably \n> > unlikely, unless you also hit some other bad luck like having the \n> > pseudo-random sequence seeded by \"time()\", and people just _happen_ to \n> > apply the email at the exact same second).\n> Bzr stores a checksum of the commit separately from the revision id in\n> the metadata of a revision. The revision is not used by itself to check\n> the integrity of a revision.\n\nI think Linus' original point here was that if you communicate the\nrevision id to another person and they fetch that revision there\nis no assurance that the commit they have received is the exact\nsame commit you had.\n\nIn Git that assurance is implicitly present as the unique\nidentification you communicated to the other person is also that\nintegrity verification. Therefore its nearly impossible to spoof.\n\n-- \nShawn.\n"},{"id":"29747","messageId":"200610232112.27066.jnareb@gmail.com","threadId":"5925","inReplyTo":"1161629801.27312.22.camel@charis.lan.vernstok.nl","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-23T19:12:26Z","receivedAt":"2006-10-23T19:12:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jelmer Vernooij wrote:\n\n> There are no requirements on what a revid is in bzr. It's a unique\n> identifier, nothing more. It can be whatever you like, as long as it's\n> unique for that specific commit. The committer+date+random_number is\n> just what bzr uses at the moment to create those unique identifiers.\n\nIn unpacked git repository commit-id is also commit address. Pack files\nadds another level of indirection via pack index file. And functions\nas checksum.\n\nP.S. I'm interested what are bzr equivalents of git different types\nof objects: commits (revision info) and what is stored in there besides\ncommit message and \"snapshot\"; trees/manifest i.e. how files are \ngathered together to form given revision; blob i.e. what is the storage \nformat and how it is divided: changeset-like of Arch or file \"buckets\" \nof Mercurial and CVS, or something yet different together. Is there \nequivalent of git tags and tags objects?\n"},{"id":"29748","messageId":"Pine.LNX.4.64.0610231206320.3962@g5.osdl.org","threadId":"5925","inReplyTo":"1161629801.27312.22.camel@charis.lan.vernstok.nl","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-23T19:18:06Z","receivedAt":"2006-10-23T19:18:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 23 Oct 2006, Jelmer Vernooij wrote:\n>\n> Bzr stores a checksum of the commit separately from the revision id in\n> the metadata of a revision. The revision is not used by itself to check\n> the integrity of a revision.\n\nThat wasn't what I was trying to aim at - the problem is that the bzr \nrevision ID isn't \"safe\" in itself. Anybody can create a revision with the \nsame names - and they may both have checksums that match their own \nrevision, but you have no idea which one is \"correct\".\n\nSo you just have to trust the person that generates the name, to use a \nproper name generation algorithm. You have to _trust_ that your 64-bit \nrandom number really is random, for example. And that nobody is trying to \nmess with your repo.\n\nThis isn't a problem in normal behaviour, but it's a problem in an attack \nschenario: imagine somebody hacking the central server, and replacing the \nrepository with something that had all the same commit names, but one of \nthe revisions was changed to introduce a nasty backhole problem. Change \nall the checksums to match too..\n\nIt would _look_ fine to somebody who fetches an update, and the maintainer \nmight not ever even notice (because he wouldn't send the _old_ revision \nagain, and _his_ tree would be fine, so he'd happily continue to to send \nout new revisions on top of the bad one on the public site, never even \nrealizing that people are fetching something that doesn't match what he is \npushing).\n\nIn contrast, in git, if you replace something in a git repository, the \nname changes, and if I were to try to push an update on top of a broken \nrepo like that, it simply wouldn't work - I couldn't fast-forward my own \nbranch, because it's no longer a proper subset of what I'm trying to send.\n\nSo in git, you can _trust_ the names. They actually self-verify. You can't \nhave maliciously made-up names that point to something else than what they \nare. \n\n[ Also, as a result, and related to this same issue: the git protocol \n actually never sends object names when sending the object itself. It \n just sends the object data, and the _recipient_ generates the name from \n that.\n\n So you can't do the _other_ kind of spoofing, and make a repository that \n _claims_ to have one name and the data would differ - because if you do \n that, anybody who pulls from the spoofed repository will re-create \n different names than you claimed, and won't even be able to pull such a \n malicious repository. ]\n\n\t\tLinus\n"},{"id":"29755","messageId":"20061023200648.GB31068@coredump.intra.peff.net","threadId":"5925","inReplyTo":"453CF966.7000308@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-23T20:06:48Z","receivedAt":"2006-10-23T20:06:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 23, 2006 at 01:18:30PM -0400, Aaron Bentley wrote:\n\n> And, unlike git, Bazaar branches are all independent entities[1], and\n[...]\n> [1] The fact that they may share storage is not important to the model.\n\nSorry, I don't understand this statement. How are git branches not\nindependent? Sure, they tend to exist in repositories with other\nbranches, but there's no need to (it simply allows the sharing of object\nstorage). There's no reason I can't move any branch from any repo into\nits own repo, or vice versa move any unrelated branch into a repo with\nother branches.\n\nIt all Just Works because there _isn't_ any branch information. It's\nsimply a pointer into the DAG, so if I have the right parts of the DAG\n(which git is careful to make sure of), I can just make a pointer, and I\nhave absolutely zero connection to wherever the DAG came from.\n\n> they each have a URL.\n\nIn cogito, branches can each have a URL, but git-clone doesn't have a\nway (that I know of) to clone only a subset of branches. It would be\nfairly trivial to implement, I think.\n\n> So:\n> \n> http://code.aaronbentley.com/bzrrepo/bzr.ab 1695\n> \n> is a name for\n> \n> abentley@panoramicfeedback.com-20060927202832-9795d0528e311e31\n\nThe git analog is of course:\n\nhttp://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v2.6.18\n\nas a name for\n\ne478bec0ba0a83a48a0f6982934b6de079e7e6b3\n\nThe difference being that Linus assigned the \"local\" name of v2.6.18\nrather than having git auto-assign it.\n\n> And it does not depend on any other branch, especially not bzr.dev\n\nOf course. For me, the above commit is actually\n\n ssh://peff.net/home/peff/git/linux-2.6 v2.6.18\n\nbut once it is in my local repository, it's indistinguishable from one I\npulled directly from kernel.org.\n\nAnd I wonder if THAT is at the root of this discussion. bzr isn't\n\"centralized\" in the sense that you have to talk to a central server, or\nrely on it for doing any operations. But you actually CARE about where\nyour commits come from, and git fundamentally doesn't.\n\n-Peff\n"},{"id":"29758","messageId":"200610232229.17426.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061023200648.GB31068@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-23T20:29:16Z","receivedAt":"2006-10-23T20:29:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 23 Oct 2006, Jeff King wrote:\n> On Mon, Oct 23, 2006 at 01:18:30PM -0400, Aaron Bentley wrote:\n> \n>> And, unlike git, Bazaar branches are all independent entities[1], and\n> [...]\n>> [1] The fact that they may share storage is not important to the model.\n\nBy the way, git repositories (remember that working area in bzr is\nassociated with branch, and in git with repository) can share storage,\neither sharing only immutable \"old history\" (part of DAG) via \n$GIT_DIR/objects/info/alternates file or GIT_ALTERNATE_OBJECT_DIRECTORIES\nenvironment variable, or via having shared commit object database\nvia symlinking $GIT_DIR/objects directory or via setting \nGIT_OBJECT_DIRECTORY variable. \n\nGit doesn't support latter fully out of the box (you must be careful\nwith prune) but on the other side bzr doesn't support cloning whole\nrepository.\n \n> It all Just Works because there _isn't_ any branch information. It's\n> simply a pointer into the DAG, so if I have the right parts of the DAG\n> (which git is careful to make sure of), I can just make a pointer, and I\n> have absolutely zero connection to wherever the DAG came from.\n\nWell, with exception of reflog, which is local to repository\n(and doesn't get propagated).\n \n>> they each have a URL.\n> \n> In cogito, branches can each have a URL, but git-clone doesn't have a\n> way (that I know of) to clone only a subset of branches. It would be\n> fairly trivial to implement, I think.\n\nOn the other side Cogito doesn't have way to clone all the branches.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"29774","messageId":"20061023222131.GB17019@over-yonder.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610231018410.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-23T22:21:31Z","receivedAt":"2006-10-23T22:21:31Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Mon, Oct 23, 2006 at 10:29:53AM -0700 I heard the voice of\nLinus Torvalds, and lo! it spake thus:\n> \n> I already briought this up once, and I suspect that the bzr people\n> simply DID NOT UNDERSTAND the question:\n> \n> - how do you do the git equivalent of \"gitk --all\"\n\nI for one simply DO NOT UNDERSTAND the question, because I don't know\nwhat that is or what I'd be trying to accomplish by doing it. The\ndocumentation helpfully tells me that it's something undocumented.\n\n\n> For example, how long does it take to do an arbitrary \"undo\" (ie\n> forcing a branch to an earlier state) [...]\n\nI don't understand the thrust of this, either. As I understand the\noperation you're talking about, it doesn't have anything to do with a\nbranch; you'd just be whipping the working tree around to different\nversions. That should be O(diff) on any modern VCS.\n\n\n> and yes, performance does matter.\n\nI agree, and I currently find a number of places bzr doesn't hit the\nlevel of performance I think it should. I'm not convinced, however,\nthat any notable proportion of that has to do with the abstract model\nbehind it. And insofar as it has to do with the physical storage\nmodel, that can easily be (and I'm confident will be, considering it's\na focus) ameliorated with later repository formats.\n\n\n> The whole confusing between \"bzr pull\" and \"bzr merge\" is another\n> _technical_ sign of why branch-local revision numbers are a mistake. \n\nI consider it a _technical_ sign of a way of thinking about branches I\nprefer 8-}\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29775","messageId":"Pine.LNX.4.63.0610231526510.7756@qynat.qvtvafvgr.pbz","threadId":"5925","inReplyTo":"20061023222131.GB17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-10-23T22:28:34Z","receivedAt":"2006-10-23T22:28:34Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Mon, 23 Oct 2006, Matthew D. Fuller wrote:\n\n>\n> I don't understand the thrust of this, either. As I understand the\n> operation you're talking about, it doesn't have anything to do with a\n> branch; you'd just be whipping the working tree around to different\n> versions. That should be O(diff) on any modern VCS.\n\non many modern VCS systems it's O(n) on the number of changes (start from where \nyou are and apply the patch to change it to rev -1, then apply the patch to \nchange it to rev -2, etc)\n\non git it's O(1) (write the new files into place)\n\nDavid Lang\n"},{"id":"29778","messageId":"Pine.LNX.4.64.0610231534010.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061023222131.GB17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-23T22:44:13Z","receivedAt":"2006-10-23T22:44:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 23 Oct 2006, Matthew D. Fuller wrote:\n\n> On Mon, Oct 23, 2006 at 10:29:53AM -0700 I heard the voice of\n> Linus Torvalds, and lo! it spake thus:\n> > \n> > I already briought this up once, and I suspect that the bzr people\n> > simply DID NOT UNDERSTAND the question:\n> > \n> > - how do you do the git equivalent of \"gitk --all\"\n> \n> I for one simply DO NOT UNDERSTAND the question, because I don't know\n> what that is or what I'd be trying to accomplish by doing it. The\n> documentation helpfully tells me that it's something undocumented.\n\ngitk (and all other logging functions) can take as its argument a set of \narbitrary revision expressions.\n\nThat means, for example, that you can give it a list of branches and tags, \nand it will generate the combined log for all of them. \"--all\" is just \nshorthand for that, but it's really just a special case of the generic \nfacility.\n\nThis is _invaluable_ when you want to actually look at how the branches \nare related. The whole _point_ of having branches is that they tend to \nhave common state.\n\nFor example, let's say that you have a branch called \"development\", and a \nbranch called \"experimental\", and a branch called \"mainline\". Now, \n_obviously_ all of these are related, but if you want to see how, what \nwould you do?\n\nIn git, one natural thing would be, for example, to do\n\n\tgitk development experimental ^mainline\n\n(where instead of \"gitk\" you can use any of the history listing \nthings - gitk is just the visually more clear one) which will show you \nwhat exists in the branches \"development\" and \"experimental\", but it will \n_subtract_ out anything in \"mainline\" (which is sensible - you may want to \nsee _just_ the stuff that is getting worked on - and the stuff in mainline \nis thus uninteresting).\n\nSee? When you visualize multiple branches together, HAVING PER-BRANCH \nREVISION NUMBERS IS INSANE! Yet, clearly, it's a valid and interesting \noperation to do.\n\nAn equally interesting thing to ask is: I've got two branches, show me the \ndifferences between them, but not the stuff in common. Again, very simple. \nIn git, you'd literally just write\n\n\tgitk a...b\n\n(where \"...\" is \"symmetric difference\"). Or, if you want to see what is in \n\"a\" but _not_ in \"b\", you'd do\n\n\tgitk b..a\n\n(now \"..\" is regular set difference, and the above is really identical to \nthe \"a ^b\" syntax).\n\nAnd trust me, these are all very valid things to do, even though you're \ntalking about different branches.\n\nTry it out. \n\n> > For example, how long does it take to do an arbitrary \"undo\" (ie\n> > forcing a branch to an earlier state) [...]\n> \n> I don't understand the thrust of this, either. As I understand the\n> operation you're talking about, it doesn't have anything to do with a\n> branch; you'd just be whipping the working tree around to different\n> versions. That should be O(diff) on any modern VCS.\n\nNo. If you \"undo\", you'd undo the whole history too. And if you undo to a \npoint that was on a branch, you'd have to re-write _all_ the revision \nID's.\n\n> I consider it a _technical_ sign of a way of thinking about branches I\n> prefer 8-}\n\nQuite frankly, I just don't think you understand what it means.\n\n\t\t\tLinus\n"},{"id":"29779","messageId":"ehjgli$lft$1@sea.gmane.org","threadId":"5925","inReplyTo":"20061023222131.GB17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-23T22:45:28Z","receivedAt":"2006-10-23T22:45:28Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthew D. Fuller wrote:\n\n> On Mon, Oct 23, 2006 at 10:29:53AM -0700 I heard the voice of\n> Linus Torvalds, and lo! it spake thus:\n>> \n>> I already briought this up once, and I suspect that the bzr people\n>> simply DID NOT UNDERSTAND the question:\n>> \n>> - how do you do the git equivalent of \"gitk --all\"\n> \n> I for one simply DO NOT UNDERSTAND the question, because I don't know\n> what that is or what I'd be trying to accomplish by doing it. The\n> documentation helpfully tells me that it's something undocumented.\n\ngitk(1)\n=======\n\nNAME\n----\ngitk - git repository browser\n\nDESCRIPTION\n-----------\nDisplays changes in a repository or a selected set of commits. This includes\nvisualizing the commit graph, showing information related to each commit, and\nthe files in the trees of each revision.\n\nHistorically, gitk was the first repository browser. It's written in tcl/tk\nand started off in a separate repository but was later merged into the main\ngit repository.\n\nOPTIONS\n-------\nTo control which revisions to shown, the command takes options applicable to\nthe git-rev-list(1) command. This manual page describes only the most\nfrequently used options.\n\n[...]\n--all::\n\n Show all branches.\n\n\nWhich means that \"gitk --all\" means show whole DAG in graphical history viewer.\n\nAs in bzr there is no command (nor plugin) to clone whole repository,\nI guess that the answer is that you can't do this. But perhaps \nI'm mistaken, and you can do this in bzr-gtk/bzrk...\n\n>> For example, how long does it take to do an arbitrary \"undo\" (ie\n>> forcing a branch to an earlier state) [...]\n> \n> I don't understand the thrust of this, either. As I understand the\n> operation you're talking about, it doesn't have anything to do with a\n> branch; you'd just be whipping the working tree around to different\n> versions. That should be O(diff) on any modern VCS.\n\nFor example if you decide to discard some changes completely, reverting\n(this action in git is called 'rewind') branch to some previous revision.\n\nAnd in git this operation is O(1), not O(diff).\n\nBTW. The following question IIRC remained unanswered: can you easily\nin bzr create branch off arbitrary revision (for example deciding that\nstable branch should start two revisions back in history from development\nbranch)?\n\n>> and yes, performance does matter.\n> \n> I agree, and I currently find a number of places bzr doesn't hit the\n> level of performance I think it should. I'm not convinced, however,\n> that any notable proportion of that has to do with the abstract model\n> behind it. And insofar as it has to do with the physical storage\n> model, that can easily be (and I'm confident will be, considering it's\n> a focus) ameliorated with later repository formats.\n\nSome of physical storage models needs specific abstract model. I think\nthat git storage model is in this class.\n\n>> The whole confusing between \"bzr pull\" and \"bzr merge\" is another\n>> _technical_ sign of why branch-local revision numbers are a mistake. \n> \n> I consider it a _technical_ sign of a way of thinking about branches I\n> prefer 8-}\n\nOr _perhaps_ just the way of thinking about branches in the way you are\nused to.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29781","messageId":"845b6e870610231614y681e64eu33bb0806f530c742@mail.gmail.com","threadId":"5925","inReplyTo":"ehjgli$lft$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-23T23:14:02Z","receivedAt":"2006-10-23T23:14:02Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"This is starting to turn into a \"my VCS it better than yours\"\ndiscussion rather then anything else. That's unfortunate....\n\n\n>\n> Which means that \"gitk --all\" means show whole DAG in graphical history viewer.\n>\n> As in bzr there is no command (nor plugin) to clone whole repository,\n\nBut it wouldn't be hard to create one...\n\n> I guess that the answer is that you can't do this. But perhaps\n> I'm mistaken, and you can do this in bzr-gtk/bzrk...\n\nAs of now there is no way to do it due to the fact that nobody has\ndone it yet. You can ofcourse clone branches into a common repo and do\noperations on that. For example, there is a plugin that allows you to\nlist heads in a repo (and not in branches). So basically, if you loose\na branch, you can still find the head in the repository and recreate\nthe branch.\n\nI don't see any problem doing a \"gitk --all\" equivalent in bzr.\nPersonally, I don't really have a need for it.\n\n> BTW. The following question IIRC remained unanswered: can you easily\n> in bzr create branch off arbitrary revision (for example deciding that\n> stable branch should start two revisions back in history from development\n> branch)?\n\nbzr branch -r-2 development stable\n(or \"bzr branch -rrevid:foobar\" to start at revision id \"foobar\")\n\nvery easy.\n\n/Erik\n\n-- \ngoogle talk/jabber. zindar@gmail.com\nSIP-phones: sip:erik_bagfors@gizmoproject.com\nsip:17476714687@proxy01.sipphone.com\n"},{"id":"29784","messageId":"Pine.LNX.4.64.0610231623340.3962@g5.osdl.org","threadId":"5925","inReplyTo":"845b6e870610231614y681e64eu33bb0806f530c742@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-23T23:24:30Z","receivedAt":"2006-10-23T23:24:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 24 Oct 2006, Erik Bågfors wrote:\n> \n> I don't see any problem doing a \"gitk --all\" equivalent in bzr.\n\nThe problem? How do you show a commit that is _common_ to two branches, \nbut has different revision names in them?\n\nDo you _finally_ see what is so wrong with this whole per-branch naming?\n\n\t\tLinus"},{"id":"29788","messageId":"20061024002622.GC17019@over-yonder.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610231534010.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-24T00:26:22Z","receivedAt":"2006-10-24T00:26:22Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Mon, Oct 23, 2006 at 03:44:13PM -0700 I heard the voice of\nLinus Torvalds, and lo! it spake thus:\n> \n> gitk (and all other logging functions) can take as its argument a\n> set of arbitrary revision expressions.\n [...]\n> And trust me, these are all very valid things to do, even though\n> you're talking about different branches.\n\nI have zero problem believing that. It seems from all accounts a\nwonderful swiss-army chainsaw, and while none of that power is useful\nto me personally in anything I'm VCS'ing at the moment, I'd feel awful\nshiny knowing it was sitting there waiting for me. All else being\nequal, I'd think more highly of a VCS with those capabilities than one\nwithout.\n\nbzr-the-program doesn't have a lot of that capability, and what it\ndoes have is rather more verbose to access. Perhaps some attribute of\nbzr-the-current-storage-model would make some bit of that\nsignificantly more expensive than it has to be (I don't know of any,\nand can't think offhand of anywhere it might hide, but that's way off\nmy turf).\n\nBut I don't understand how bzr-the-abstract-data-model makes such\nthings impossible, or even significantly different than doing so in\ngit. In git, you're just chopping off one DAG where another one\nintersects it (or similar operations). To do it in bzr, you'd do...\nexactly the same thing. The revnos, or the mainline, are completely\nuseless in such an operation of course, but they don't hurt it; the\ntool would just just ignore them like it does the SHA-1 of files in\nthe revision.\n\n\n> See? When you visualize multiple branches together, HAVING\n> PER-BRANCH REVISION NUMBERS IS INSANE! Yet, clearly, it's a valid\n> and interesting operation to do.\n\nI wouldn't be so absolutist about it, but certainly they're of\nextremely limited utility if of any at all in such cases. And yes, it\ncan be an interesting operation. But what does that have to do with\nusing revnos in other cases? You keep saying \"having\" where I would\nsay \"using\".\n\n\n> No. If you \"undo\", you'd undo the whole history too. And if you undo\n> to a point that was on a branch, you'd have to re-write _all_ the\n> revision ID's.\n\nWell, I guess in this particular case I still don't see why you'd\ngenerally undo big hunks of a branch versus just flipping your working\ntree to different versions. But contrived examples are still\nexamples, and even if so, truncate()'ing a list of numbers is a\nconstant time operation. And even if you had to renumber totally...\nmy $DEITY, I'd expect my old 200MHz PPro to renumber a hundred\nthousand rev long mainline in half a second.\n\n\n> > I consider it a _technical_ sign of a way of thinking about\n> > branches I prefer 8-}\n> \n> Quite frankly, I just don't think you understand what it means.\n\nQuite frankly, I just don't think you understand that I WANT to care\nabout first parents. No, really. Seriously. I really really really\nwant to. If my VCS didn't give me numbers along the mainline, I'd\nstill care out it. If the revisions were all named SHA-1 hashes, I'd\nstill care about it. If I had a metric quidnillion ways to\ncross-section and compare branches, I'd still care about it.\n\nThis comes with costs. Chief among them is a restriction of my\nactions; I can't fast-forward branches where I care about the\nmainline. That's a cost. That means I have to take some care about\nwhat operations I perform. I *GLEEFULLY* pony up that cost.\n\nBecause I care about the mainline, revnos can be useful. I like\nrevnos. It has to cost SOMETHING to come up with them (though there\nseems to be disagreement about the size of that cost), since doing\n'x+y' will always cost more than doing 'x'. I've never seen a case\nwhere that cost even appeared MEASURABLE, much less significant\n(things have to be pretty expensive to compare to the cost of starting\nup python and loading a bunch of files into it ;). So far, I've not\nseen the slightest hint of a cost that would make it even worth asking\nthe question of whether the cost is worth it to me.\n\n\nI care about that first parent line. Therefore, I require my tool to\nat least _pretend_ to care. I'm not aware of any way in which the\nfundamental bzr structures care, but the UI is chock full of\npretending. A necessary part of that pretending is not changing my\nmainline unless I specifically ask for it, and that means a\nmerge-vs-pull distinction needs to be there. That's a _technical_\nsign that the tool is ready to work with me the way I want to work. A\nlack of it is a _technical_ sign that it's not suitable.\n\nYou, by your own words, don't care about the first parent line. Your\ntool naturally reflects this. From that perspective, *ANY* cost for\nmaintaining such a thing is Bad And Wrong, and so you condemn it.\nThose condemnations will keep failing to carry any weight with me,\nthough, as long as I care about that mainline and value the benefits I\nfind in it.\n\n\nMaybe I won't always. 2 years ago, I could maybe see some benefits in\nDVCS, but I couldn't imagine what possible use they could ever be to\nme in anything I do. Today, I'm using one (if lightly by the\nstandards of a lot of people in this discussion), and chafing at every\ncentralized system I have to deal with. In 5 years, I may be standing\nbeside you slugging it out at those lunatics and hacks who keep\nbegging to pay these whopper costs, just to be able to do extra work\nto maintain an ordering of parents that doesn't matter for crap.\nCould be. I've changed my mind about far more momentous things in my\nlife.\n\nMaybe someday I'll still care, but the OTHER advantages of a system\n(like git) that doesn't over all the ones that do will outweigh the\nadvantages I gain from that distinction. Someday I might need such\nultra-expressive ways of comparing branches, and bzr won't have grown\nthem yet. Someday I might reach a point where bzr's performance due\nto the choice of storage structures or implementation language or\ndeveloper habits or whatever else just doesn't cut the mustard, and\ngit's does. Someday, some set of other advantages may make it\nworthwhile for me to give up my preciouss mainline no matter how much\nI might still crave it.\n\nBut I can only work from today. Today, I do care. Today, it's well\nworth whatever I give up to get it. And I like that my tool makes\nthat caring easy for me.\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29789","messageId":"20061024002657.GD17019@over-yonder.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610231623340.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-24T00:26:57Z","receivedAt":"2006-10-24T00:26:57Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Mon, Oct 23, 2006 at 04:24:30PM -0700 I heard the voice of\nLinus Torvalds, and lo! it spake thus:\n> \n> The problem? How do you show a commit that is _common_ to two\n> branches, but has different revision names in them?\n\nWhy would you?\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29790","messageId":"20061024003834.GE17019@over-yonder.net","threadId":"5925","inReplyTo":"20061024002657.GD17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-24T00:38:34Z","receivedAt":"2006-10-24T00:38:34Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Mon, Oct 23, 2006 at 07:26:57PM -0500 I heard the voice of\nMatthew D. Fuller, and lo! it spake thus:\n> On Mon, Oct 23, 2006 at 04:24:30PM -0700 I heard the voice of\n> Linus Torvalds, and lo! it spake thus:\n> > \n> > The problem? How do you show a commit that is _common_ to two\n> > branches, but has different revision names in them?\n> \n> Why would you?\n\nI beg your pardon; that was awful ambiguous of me. I meant \"In such a\ncase, where the whole purpose of what you're doing is to you're look\nat multiple branches to see relationships between them, why WOULD you\nbe using branch-local identifiers for revisions at all?\"\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29792","messageId":"46a038f90610231739x5beffc90u33c6a81f461974ec@mail.gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610231623340.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-10-24T00:39:29Z","receivedAt":"2006-10-24T00:39:29Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/24/06, Linus Torvalds wrote:\n> On Tue, 24 Oct 2006, Erik Bågfors wrote:\n> >\n> > I don't see any problem doing a \"gitk --all\" equivalent in bzr.\n>\n> The problem? How do you show a commit that is _common_ to two branches,\n> but has different revision names in them?\n\nEric,\n\ncoming from an Arch background, I understand the whole per-branch\ncommitids approach. After using GIT for a while, you start realising\nthat it tries to pin down things in the wrong place.\n\nThis is specially visible if you run `gitk --all` before and after a\nmerge. Or on a project with many merges (if you can, get a checkout of\ngit itself, and browse its history with gitk).\n\nBefore the merge, you see\n\n --o--o--o--o\n \\\n \\--o--o\n\nand after\n\n --o--o--o--o\n \\ \\\n \\--o--o--o\n\nNow, after it's merged somewhere, both commits are part of its\nhistory, regardless of where they come from. And it is very clear if\ntwo branches have been merging and remerging.\n\nWhere a commit originated does not matter. And fancy\nrepo-and-branch-centric names get in the way. A lot. And they re\nmostly meaningless as soon as you put what matters in the commit\nmessage. Which means that that bit of metadata that you are hoping\nthat the revno keeps \"indirectly\" isn't lost on cherry picking.\n\nI guess that's where I used to find revnos useful as they contained\nsome basic metadata. With bzr it seems to be author-repo-branch where\nbranch is hopefully \"line of work\" but all of that can be (and should\nbe) in the commit message.\n\nYou can see similar info in the first part of the commit message for\nmost git-hosted projects. It'll say something like\n\n cvsserver: fix the frobnicator to be sequential\n\nwhich means that at that point, you could be working in a branch\ncalled fix-this-fscking-thing-attempt524\" and no-one would know ;-)\n\nAnd in a few years (even months) time, that bit of metadata you were\nhoping to keep is totally irrelevant. What you have in the commit\nmessage remains relevant and useful.\n\ncheers,\n\n\nmartin\n"},{"id":"29793","messageId":"87y7r6zgic.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"20061024002657.GD17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-24T00:47:39Z","receivedAt":"2006-10-24T00:47:39Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 23 Oct 2006 19:26:57 -0500, \"Matthew D. Fuller\" wrote:\n>\n> On Mon, Oct 23, 2006 at 04:24:30PM -0700 I heard the voice of\n> Linus Torvalds, and lo! it spake thus:\n> >\n> > The problem? How do you show a commit that is _common_ to two\n> > branches, but has different revision names in them?\n>\n> Why would you?\n\nAssume you've got two long-lived branches and one periodically gets\nmerged into the other one. The combined history might look as follows\n(more recent commits first):\n\n f g\n | |\n d e\n |\\ /\n b c\n |/\n a\n\nThe point is that it is extremely nice to be able to visualize things\nthat way. Say I've got a \"dev\" branch that points at f and a \"stable\"\nbranch that points at g. With this, a command like:\n\n\tgitk dev stable\n\nwould result in a picture just like the above. Can a similar figure be\nmade with bzr? Or only the following two separate pictures:\n\n f g\n | |\n d e\n |\\ |\n b c c\n |/ |\n a a\n\n-Carl\n"},{"id":"29801","messageId":"1161660291.22276.209.camel@zepto.home.zettazebra.com","threadId":"5925","inReplyTo":"200610231454.06355.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"David Clymer","fromEmail":"david@zettazebra.com","sentAt":"2006-10-24T03:24:51Z","receivedAt":"2006-10-24T03:24:51Z","isPatch":false,"sender":{"key":"david@zettazebra.com","avatar":"https://gravatar.com/avatar/cdcfe06796c2f046978e5667e21c2e6567f8db8c91d8eb81d7eb86f3f6bc77b7?d=mp&s=160"},"body":"On Mon, 2006-10-23 at 14:54 +0200, Jakub Narebski wrote:\n> On Mon, Oct 23, 2006 David Clymer wrote:\n> > On Sun, 2006-10-22 at 22:06 +0200, Jakub Narebski wrote:\n> >> David Clymer wrote:\n> \n> >>> 2. bzr does not support fully distributed development because revnos\n> >>> \"don't work\" as stated in #1.\n> >>\n> >> Bazaar is biased towards centralized/star-topology development if we\n> >> want to use revnos. In fully distributed configuration there is no\n> >> \"simple namespace\".\n> > \n> > So revnos aren't globally meaningful in fully distributed settings. So\n> > what? I don't see how this translates into bias. There is a lot of\n> > functionality provided by bazaar that doesn't really apply to my use\n> > case, but it doesn't mean that it is indicative of some bias in bazaar.\n> \n> First, bzr is biased towards using revnos: bzr commands uses revnos\n> by default to provide revision (you have to use revid: prefix/operator\n> to use revision identifiers), bzr commands outputs revids only when\n> requested, examples of usage uses revision numbers.\n\nAgreed. Of course, I want the simplest case to be the simplest. When\nworking on my own branch, regardless if it is a standalone project or\npart of a distributed one, I don't want to have to type SHA hashes or\nrevids. Numbers serve my purposes best in this case. When I communicate\nwith other distributed developers, I can and should use revids.\n\n> \n> In order to use revnos as _global_ identifiers in distributed development,\n> you need central \"branch\", mainline, to provide those revnos. You have\n> either to have access to this \"revno server\" and refer to revisions by\n> \"revno server\" URL and revision number, or designate one branch as holding\n> revision numbers (\"revno server\") and preserve revnos on \"revno server\"\n> by using bzr \"merge\", while copying revnos when fetching by using bzr \"pull\"\n> for leaf branches. In short: for revnos to be global identifiers you need\n> star-topology.\n\nOk. Let's not repeat this again. I think I said this once, and you've\nsaid it in two following emails. It's a given. Assume that we all know\nit.\n\n> \n> Even if you use revnos only locally, you need to know which revisions are\n> \"yours\", i.e. beside branch as DAG of history of given revision you need\n> \"ordered series of revisions\" (to quote Bazaar-NG wiki Glossary), or path\n> through this diagram from given revision to one of the roots (initial,\n> parentless revisions). Because bzr does that by preserving mentioned path\n> as first-parent path (treating first parent specially), i.e. storing local\n> information in a DAG (which is shared), to preserve revnos you need to\n> use \"merge\" instead of \"pull\", which means that you get empty-merge in\n> clearly fast-forward case. This means \"local changes bias\", which some\n> might take as not being fully distributed.\n\n\"local changes bias\" I can buy that. I even like it. I don't even care\nif that makes bazaar \"not fully distributed.\" I don't think the\ndistinction between \"fully\" and \"almost, except for some technicality\"\ndistributed is one that has much practical value.\n\n-davidc\n-- \ngpg-key: http://www.zettazebra.com/files/key.gpg\n"},{"id":"29807","messageId":"Pine.LNX.4.64.0610232239220.3962@g5.osdl.org","threadId":"5925","inReplyTo":"20061024003834.GE17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-24T05:42:23Z","receivedAt":"2006-10-24T05:42:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 23 Oct 2006, Matthew D. Fuller wrote:\n\n> On Mon, Oct 23, 2006 at 07:26:57PM -0500 I heard the voice of\n> Matthew D. Fuller, and lo! it spake thus:\n> > On Mon, Oct 23, 2006 at 04:24:30PM -0700 I heard the voice of\n> > Linus Torvalds, and lo! it spake thus:\n> > > \n> > > The problem? How do you show a commit that is _common_ to two\n> > > branches, but has different revision names in them?\n> > \n> > Why would you?\n> \n> I beg your pardon; that was awful ambiguous of me. I meant \"In such a\n> case, where the whole purpose of what you're doing is to you're look\n> at multiple branches to see relationships between them, why WOULD you\n> be using branch-local identifiers for revisions at all?\"\n\nWell, I would use the globally unique ones, certainly. It's the only thing \nthat makes sense.\n\nHowever, I'd also argue that once you start doing that, _mixing_ the \nglobally unique and stable ones and the \"simple\" ones is a mistake: you'd \nbe better off having told your users to use the global ones from the very \nbeginning, and trying to make _those_ as simple to use as possible.\n\nBecause once you start using both, you're just going to confuse your users \nhorribly, and they'll consider the globally unique one really irritating, \nbecause they're used to using something totally different in most other \ncontexts.\n\nUsing the _same_ names everywhere is just better. \n\n\t\tLinus\n"},{"id":"29810","messageId":"20061024054712.GC9724@spearce.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610232239220.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-24T05:47:12Z","receivedAt":"2006-10-24T05:47:12Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> Using the _same_ names everywhere is just better. \n\nI find that it is simpler too. :-)\n"},{"id":"29812","messageId":"453DAC87.8050203@research.canon.com.au","threadId":"5925","inReplyTo":"vpq4ptz2uh8.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Lachlan Patrick","fromEmail":"loki@research.canon.com.au","sentAt":"2006-10-24T06:02:47Z","receivedAt":"2006-10-24T06:02:47Z","isPatch":false,"sender":{"key":"loki@research.canon.com.au","avatar":null},"body":"Matthieu Moy wrote:\n> Sean writes:\n>> We don't need plugins to extend features, we just add the feature to\n>> the source. The example I asked about earlier is a case in point. \n>> Apparently in bzr \"bisect\" was implemented as a plugin, yet in Git it\n>> was implemented as a command without any issue at all,\n> \n> I'd compare bzr's plugins to Firefox extensions.\n\nSo, bzr's plug-in architecture provides a 'protocol' for communicating\nwith bzr? Or is it functionally the same as a Python module which is\nloaded after being named on the bzr command-line (or placed in a special\nfolder) then executed along with all the other plug-ins? I'm trying to\nunderstand if writing a plug-in is any simpler than understanding the\nbzr source code.\n\nCan I ask the git folks what Sean meant in the above about a 'command'.\nAre you talking about shell scripts? Is 'git' the only program you need?\n\nAFAIK, 'bzr' is the sole program in Bazaar, and everything is done with\ncommand line options to bzr. Is that true of git? To what extent is git\ntied to a [programmable] shell? I've heard someone say there's no\nWindows version of git for some reason, can someone elaborate?\n\nTa,\nLoki\n"},{"id":"29813","messageId":"20061024062348.GA9947@spearce.org","threadId":"5925","inReplyTo":"453DAC87.8050203@research.canon.com.au","subject":"Re: VCS comparison table","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-24T06:23:48Z","receivedAt":"2006-10-24T06:23:48Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Lachlan Patrick wrote:\n> Can I ask the git folks what Sean meant in the above about a 'command'.\n> Are you talking about shell scripts? Is 'git' the only program you need?\n\n'git' is actually two things:\n\n 1) Its a wrapper command which executes 'git-foo' if you call it\n with 'foo' as its first parameter. It searches for 'git-foo'\n in the GIT_EXEC_PATH environment variable, which has a default\n set at compile time, usually to the directory you are going to\n install Git into.\n\n 2) Its most of the core Git plumbing. There are currently around 48\n 'builtin' commands. These are things which 'git' knows how to do\n without executing another program. If you look at the installation\n these 48 builtin commands are just hardlinks back to 'git'. For\n example 'git-update-index' is really just a hardlink back to 'git'\n and 'git' knows to perform the update index logic when its called\n as either 'git-update-index' or as 'git update-index'.\n\nWe're moving more towards #2, but there are still a large number\nof commands which fall into #1.\n \n> AFAIK, 'bzr' is the sole program in Bazaar, and everything is done with\n> command line options to bzr. Is that true of git?\n\nNo. In Git at least half of the things Git can do are not builtin to\n'git' and thus require exec()'ing an external program (e.g. git-fetch).\nHowever these often appear as though they are command line options to\n'git' as 'git fetch' just means exec 'git-fetch' (by #1 above).\n\nOn the other hand there are a wide range of tools which are more or\nless the same thing, just with different options applied to them.\nAll of the diff programs, log, whatchanged, show - these are all\njust variations on a theme. Their individual implementations are\nvery tiny as they all use the same library code.\n\n> To what extent is git\n> tied to a [programmable] shell?\n\nGit is still very much tied to a shell. For example 'git commit'\nis really the shell script 'git-commit'. This is a rather long\nshell script and it does a lot of things for the user; not having\nit would make Git useless to for most people. It also has not been\nrewritten in C. There is a roadmap however to convert it to C to\nhelp remove the programmable shell requirement and people have been\nslowly performing the (rather tedious) conversion work.\n\n> I've heard someone say there's no\n> Windows version of git for some reason, can someone elaborate?\n\nGit runs on Cygwin. But there's no native Win32 (without Cygwin)\nversion of Git because:\n\n - Git uses POSIX APIs and expects POSIX behavior from the OS its\n running on. Without a compatability layer to make Windows act\n like UNIX Git won't run. Cygwin happens to be a really good\n compatability layer.\n\n - Git requires a Bourne shell for many of its important tools,\n such as 'git commit'. Windows lacks such a program, at least\n out of the box, but its in Cygwin.\n\n - Git relies on a helper program called 'merge' to perform three\n way file merges. This tool may or may not be ported to native\n Win32 (I don't know) but it is in Cygwin.\n\n - Git requires some libraries for certain features, such as libexpat\n or libcurl. I don't know if these are available for native Win32\n but they are available on Cygwin.\n\n - Windows isn't the primary target platform for many of the Git\n contributors. Some consider the fact that it even runs there\n at all a minor miracle, and that's only possible due to the hard\n work the Cygwin folks have done.\n\n - ... I'm sure there's other reasons ...\n\n-- \nShawn.\n"},{"id":"29815","messageId":"Pine.LNX.4.64.0610232318200.3962@g5.osdl.org","threadId":"5925","inReplyTo":"453DAC87.8050203@research.canon.com.au","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-24T06:31:06Z","receivedAt":"2006-10-24T06:31:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 24 Oct 2006, Lachlan Patrick wrote:\n> \n> Can I ask the git folks what Sean meant in the above about a 'command'.\n> Are you talking about shell scripts? Is 'git' the only program you need?\n\nHistorically, \"git\" was _only_ a wrapper program. When you did\n\n\tgit log\n\nit just executed the real program called \"git-log\", which was often a \nshell-script. That was just so that things could easily be extended, and \nyou could use shell-script for simple one-liner things, and native C for \nmore \"core\" stuff.\n\nFor example, \"git log\" used to be a one-line shell-script that just did\n\n\tgit-rev-list --pretty HEAD | LESS=-S ${PAGER:-less}\n\nbut it ended up being a lot more capable, and eventually just rewritten \nas an internal command..\n\nThese days, most of the simple things like \"git log\" are all built into \nthe \"git\" program, although for anything not built in, it still acts as \njust a wrapper, which allows not only random functionality to still be \nwritten in shell (or sometimes perl), but also ends up being the simplest \npossible plug-in mechanism: you can define your own commands by just \nwriting a shell-script thing, calling it \"git-mycommand\", installing it in \nthe proper place, and it ends up being accessible as \"git mycommand\".\n\nThat allows for easy prototyping in your language of choice.\n\n> AFAIK, 'bzr' is the sole program in Bazaar, and everything is done with\n> command line options to bzr. Is that true of git? To what extent is git\n> tied to a [programmable] shell? I've heard someone say there's no\n> Windows version of git for some reason, can someone elaborate?\n\nAlmost all of \"core\" git is pure C, which unlike something like python or \nperl obviously tends to have a fair amount of system issues. That said, \nmuch of it really is fairly portable, so doing the built-in git stuff \nshould _largely_ work even natively under Windows with some effort.\n\nThe problem ends up being that few enough people seem to develop under \nWindows, and the cygwin port works better (because it handles a number of \nthe portability issues and also handles the scripts that are still shell). \nThose two issues seem to mean that not a lot of effort has been put into \naiming for a native windows binary (or into moving away from shell \nscripts).\n\nMost of the shell scripts really are fairly simple. So if somebody \n_really_ wanted to, it would probably not be hard to spend some effort to \neither just write them as C and turn them into built-ins, or porting them \nto some other scripting language.\n\nOf course, most Windows users don't seem to really want a command line \ninterface at all. IDE integration would appear to be more interesting to \nsome people.\n\n\t\tLinus\n"},{"id":"29818","messageId":"Pine.LNX.4.64N.0610232336010.30334@attu2.cs.washington.edu","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610232318200.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"David Rientjes","fromEmail":"rientjes@cs.washington.edu","sentAt":"2006-10-24T06:45:58Z","receivedAt":"2006-10-24T06:45:58Z","isPatch":false,"sender":{"key":"rientjes@cs.washington.edu","avatar":null},"body":"On Mon, 23 Oct 2006, Linus Torvalds wrote:\n\n> Historically, \"git\" was _only_ a wrapper program. When you did\n> \n> \tgit log\n> \n> it just executed the real program called \"git-log\", which was often a \n> shell-script. That was just so that things could easily be extended, and \n> you could use shell-script for simple one-liner things, and native C for \n> more \"core\" stuff.\n> \n> For example, \"git log\" used to be a one-line shell-script that just did\n> \n> \tgit-rev-list --pretty HEAD | LESS=-S ${PAGER:-less}\n> \n> but it ended up being a lot more capable, and eventually just rewritten \n> as an internal command..\n> \n\nSome of the internal commands that have been coded in C are actually much \nbetter handled by the shell in the first place. It's much simpler to \nwrite and extend as well as being much more traceable for runtime \nproblems. The shell commands that would be used for most of these git\nroutines have options for requesting it to be more verbose so the user \nactually has a lot more power over reporting and/or logging. In addition \nit tends to be more portable and the amount of code is drastically reduced \nin a script style of programming. The criticisms against such use of \nshell scripting tends to be a matter of personal taste. People believe, \nfor some reason or another, that it is a lower-class type of programming \nthat is less robust and is harder to understand. Seldom have there been \ncogent arguments for coding such features in C as opposed to shell \nscripting, especially in the case of git where the shell becomes a very \npowerful ally.\n\n\t\tDavid\n"},{"id":"29825","messageId":"845b6e870610240031x66c6b942u54ee0d357725fae1@mail.gmail.com","threadId":"5925","inReplyTo":"87y7r6zgic.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-24T07:31:07Z","receivedAt":"2006-10-24T07:31:07Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"On 10/24/06, Carl Worth wrote:\n> On Mon, 23 Oct 2006 19:26:57 -0500, \"Matthew D. Fuller\" wrote:\n> >\n> > On Mon, Oct 23, 2006 at 04:24:30PM -0700 I heard the voice of\n> > Linus Torvalds, and lo! it spake thus:\n> > >\n> > > The problem? How do you show a commit that is _common_ to two\n> > > branches, but has different revision names in them?\n> >\n> > Why would you?\n>\n> Assume you've got two long-lived branches and one periodically gets\n> merged into the other one. The combined history might look as follows\n> (more recent commits first):\n>\n> f g\n> | |\n> d e\n> |\\ /\n> b c\n> |/\n> a\n>\n> The point is that it is extremely nice to be able to visualize things\n> that way. Say I've got a \"dev\" branch that points at f and a \"stable\"\n> branch that points at g. With this, a command like:\n>\n> gitk dev stable\n>\n> would result in a picture just like the above. Can a similar figure be\n> made with bzr? Or only the following two separate pictures:\n\nThe above picture can easily be created with bzr if you have a\nutility/plugin that does it. There is none that does it yet, but there\nare no problems doing one.\n\nOf course, in such a context revision numbers have no use. But see,\nrevision numbers is not mandatory in bzr, so that's not a problem.\n\nI haven't really had a need for such a tool, but I do see where it can\nbe very useful to have.\n\n> f g\n> | |\n> d e\n> |\\ |\n> b c c\n> |/ |\n> a a\n>\n\nThis is what you would get if you visualize the two separate branches,\nand not the common repository.\n\n/Erik\n"},{"id":"29824","messageId":"845b6e870610240052l70ad72f4ma30065f151828dfd@mail.gmail.com","threadId":"5925","inReplyTo":"46a038f90610231739x5beffc90u33c6a81f461974ec@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-24T07:52:36Z","receivedAt":"2006-10-24T07:52:36Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"On 10/24/06, Martin Langhoff wrote:\n> On 10/24/06, Linus Torvalds wrote:\n> > On Tue, 24 Oct 2006, Erik Bågfors wrote:\n> > >\n> > > I don't see any problem doing a \"gitk --all\" equivalent in bzr.\n> >\n> > The problem? How do you show a commit that is _common_ to two branches,\n> > but has different revision names in them?\n>\n> Eric,\n\nIt's Erik :)\n\n> coming from an Arch background, I understand the whole per-branch\n> commitids approach. After using GIT for a while, you start realising\n> that it tries to pin down things in the wrong place.\n>\n> This is specially visible if you run `gitk --all` before and after a\n> merge. Or on a project with many merges (if you can, get a checkout of\n> git itself, and browse its history with gitk).\n>\n> Before the merge, you see\n>\n> --o--o--o--o\n> \\\n> \\--o--o\n>\n> and after\n>\n> --o--o--o--o\n> \\ \\\n> \\--o--o--o\n>\n> Now, after it's merged somewhere, both commits are part of its\n> history, regardless of where they come from. And it is very clear if\n> two branches have been merging and remerging.\n>\n> Where a commit originated does not matter. And fancy\n> repo-and-branch-centric names get in the way. A lot. And they re\n> mostly meaningless as soon as you put what matters in the commit\n> message. Which means that that bit of metadata that you are hoping\n> that the revno keeps \"indirectly\" isn't lost on cherry picking.\n\nLet's make one thing clear. Revnos are NOT stored with the revision,\nthey are not \"names\" of the revision. They are basically just\nshortcuts to specific revisions, that only makes sence in the context\nof a branch.\n\nAs human beings this is something we are very used to in everyday\nlife. I don't always call my friends with firstname and surname, I\njust use first name or even \"mate\". As long as it's clear who I'm\ntalking about in that contect. If there are multiple people with the\nsame first name, then we might have to use the surname as well.\n\nSame with bzr. In the context of a branch, revnos works as shortcuts\nto the revision id. In the context of multiple branches, they don't.\n\nI think they do serve a good purpose but I don't really think that we\nabsolutely need them either.\n\n> I guess that's where I used to find revnos useful as they contained\n> some basic metadata. With bzr it seems to be author-repo-branch where\n> branch is hopefully \"line of work\" but all of that can be (and should\n> be) in the commit message.\n>\n> You can see similar info in the first part of the commit message for\n> most git-hosted projects. It'll say something like\n>\n> cvsserver: fix the frobnicator to be sequential\n>\n> which means that at that point, you could be working in a branch\n> called fix-this-fscking-thing-attempt524\" and no-one would know ;-)\n>\n> And in a few years (even months) time, that bit of metadata you were\n> hoping to keep is totally irrelevant. What you have in the commit\n> message remains relevant and useful.\n\nI'm not even going to try to understand the argument here as they are\nabout a totally different thing and doesn't make any sense to me.\n\nI think this disussion is getting out of hand.\n\nThere are a few things that are being discussed\n1. Revnos are bad/good\n2. treating \"leftmost\" parrent special is bad/good\n3. plugins are useless/useful\n4. And now, storing branch information should be done manually (if\nwanted) and not automatically.\n\n1. I don't really care, I haven't seen any confusion based on it, but\nI don't have a very strong opinion about it either.\n2. This is something I do care about. For me, this is the only\nlogical way of doing it. It might be because I am used to it now, but\nwhen I started to look at bzr/hg/git/darcs/etc, I just got a so much\nmore clear view of the history when running a standard log command,\nthat it was one of the first things that attracted me to bzr. This is\njust a user talking.\nThere might be technical reasons why it's better to not do it, but for\nme it works the way I expect, therefore I'm happy\n3. This is just silly\n4. No comment.\n\n/Erik\n"},{"id":"29827","messageId":"200610241037.11001.jnareb@gmail.com","threadId":"5925","inReplyTo":"845b6e870610240052l70ad72f4ma30065f151828dfd@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-24T08:37:10Z","receivedAt":"2006-10-24T08:37:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Erik Bågfors wrote:\n> I think this disussion is getting out of hand.\n> \n> There are a few things that are being discussed\n> 1. Revnos are bad/good\n> 2. treating \"leftmost\" parrent special is bad/good\n> 3. plugins are useless/useful\n> 4. And now, storing branch information should be done manually (if\n> wanted) and not automatically.\n> \n> 1. I don't really care, I haven't seen any confusion based on it, but\n> I don't have a very strong opinion about it either.\n\nTo use revnos[*1*] you have to have branch as path through DAG. Bzr does\nthat by treating first parent special, which leads to empty merges\nin fast-forward case.\n\nUsing revnos as implemented in bzr leads to some (perhaps unforeseen)\nconsequences.\n\n[*1*] Meaning that revnos won't change on you.\n\n> 2. This is something I do care about.  For me, this is the only\n> logical way of doing it. It might be because I am used to it now, but\n> when I started to look at bzr/hg/git/darcs/etc, I just got a so much\n> more clear view of the history when running a standard log command,\n> that it was one of the first things that attracted me to bzr. This is\n> just a user talking.\n\nGit has reflog for when you are interested in branch tip history\n(which also stores \"reason\" for branch tip change: pull, amending\na commit, rebase,...). Git doesn't unfortunately have git-ref-log\ncommand (or --ref option to git-log) to display reflog in user friendly \nformat.\n\nGit users are used to use graphical history viewers (mainly gitk and \nqgit, but there is also gitview, tig and git-browser) more to have \nclear view of history, view that log cannot provide.\n\nThat said I _thing_ that caring about \"branch identity\" is just \nsomething you are used to, perhaps because bzr doesn't have wonderfull \ngit log limiting specifiers aka. builtin git log searching (a..b, \na...b, --max-count, -- , --committer, --grep etc.).\n\n> There might be technical reasons why it's better to not do it, but for\n> me it works the way I expect, therefore I'm happy\n\nI think it would be better to maintain \"branch identity\" separately and \nnot in DAG, but that might have other problems I have not seen.\n\n> 3. This is just silly\n\nI think the discussion/arguments were twofold. \n\nFirst, Bazaar-NG has plugin infrastructure \"for free\" because it is \nwritten in Python, which allows modules loading and monkey-patching. \nGit core is written in C, and git is not yet fully libified.\n\nSecond, all that can be done with plugins except for core changes can be \ndone in Git writing scripts (this also allows for fast prototyping). \nAll except core changes can be done writing few lines in C, but you \nhave to compile against some version of Git, and don't have advantages \nof bultin command; git is OSS project.\n\n> 4. No comment.\n\nStoring branch information could be done automatically on demand ;-)\n-- \nJakub Narebski\nPoland\n"},{"id":"29837","messageId":"20061024093033.GA23906@rhonwyn.vernstok.nl","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610231623340.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Jelmer Vernooij","fromEmail":"jelmer@samba.org","sentAt":"2006-10-24T09:30:33Z","receivedAt":"2006-10-24T09:30:33Z","isPatch":false,"sender":{"key":"jelmer@samba.org","avatar":"https://avatars.githubusercontent.com/u/49032?v=4"},"body":"On Mon, Oct 23, 2006 at 04:24:30PM -0700, Linus Torvalds wrote:\n> On Tue, 24 Oct 2006, Erik B?gfors wrote:\n> > I don't see any problem doing a \"gitk --all\" equivalent in bzr.\n> The problem? How do you show a commit that is _common_ to two branches, \n> but has different revision names in them?\nIt'll have the same revision name. The revision no's will be\ndifferent, sure, but that's not a problem.\n\n> Do you _finally_ see what is so wrong with this whole per-branch naming?\nrevnos are the only naming bit that is branch-specific.\n\nI guess one way of looking at revnos is to regard them completely as a \ncommand-line ui thing. They're not explicitly stored anywhere on\ndisk but just an easy way for users to refer to revisions on a\nper-branch basis. \n\nThe graphical frontends to bzr, for example, don't know about revno's but \nonly about revids.\n\nCheers,\n\nJelmer\n\n-- \nJelmer Vernooij - http://jelmer.vernstok.nl/\nCurrently playing: \n"},{"id":"29841","messageId":"vpq64eakpnh.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"20061023222131.GB17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-24T09:51:30Z","receivedAt":"2006-10-24T09:51:30Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Matthew D. Fuller\" writes:\n\n>> For example, how long does it take to do an arbitrary \"undo\" (ie\n>> forcing a branch to an earlier state) [...]\n>\n> I don't understand the thrust of this, either. As I understand the\n> operation you're talking about, it doesn't have anything to do with a\n> branch; you'd just be whipping the working tree around to different\n> versions. That should be O(diff) on any modern VCS.\n\nThere are two things to do:\n\n* Mark the tree as corresponding to a different revision in the past.\n This is roughly \"echo 'revision@id-123' > .bzr/checkout/last-revision\"\n in bzr. Obviously, writting the file is O(1), but computing the\n revision identifier if you say \"bzr switch -r 42\" (I'm not sure\n switch accepts this BTW), you have to load the revision history.\n Indeed, bzr would load it anyway to make sure that the revision you\n switch to is in the revision history.\n\n In bzr, you have .bzr/branch/revision-history for each branch, which\n is a newline-separated list of revision-identifiers. In the case of\n bzr.dev, for example, this file is 112KB as of now. This is\n O(history), with \"history\" being the length of the path from HEAD to\n the initial commit, following the leftmost ancestor (i.e. number of\n revisions in a centralized workflow, and less than this otherwise).\n That said, the constant factor is very small. For example, on\n bzr.dev, I did \"grep -n some-rev-id\" (which does revid-to-revno), it\n takes 0.004 seconds (Vs 0.003 seconds to grep in /dev/null\n instead ;-) ), so you'd need many orders of magnitude before this\n becomes a limitation.\n\n Linus's point AIUI is that this will _never_ be a limitation of git.\n\n* Then, do the \"merge\" to make your tree up to date. You can hardly do\n faster than git and its unpacked format, but this is at the cost of\n disk space. But as you say, in almost any modern VCS, that's\n O(diff). In a space-efficient format, that's just the tradeoff you\n make between full copies of a file and delta-compression.\n\n-- \nMatthieu\n"},{"id":"29842","messageId":"46a038f90610240311n29d0561ek7dc52dc3d34c2f76@mail.gmail.com","threadId":"5925","inReplyTo":"845b6e870610240052l70ad72f4ma30065f151828dfd@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-10-24T10:11:32Z","receivedAt":"2006-10-24T10:11:32Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/24/06, Erik Bågfors wrote:\n> It's Erik :)\n\nSorry Erik!\n\n> Let's make one thing clear. Revnos are NOT stored with the revision,\n> they are not \"names\" of the revision. They are basically just\n> shortcuts to specific revisions, that only makes sence in the context\n> of a branch.\n\nMy bad. The revnos examples discussed looked quite Arch-like. As Arch\ntook them seriously, I thought bzr did too.\n\nProbably quite a few people here thought as much, and got hot under\nthe t-shirt about it ;-)\n\nNow, the thing about they shorthand is that we have quite a few means\nof using shorthand in GIT that don't rely on revnos. We have the whole\n^branchname stuff. And when you are looking at gitk it's pretty\nobvious which are your recent \"local\" commits.\n\n\n...\n\n\n> 2. treating \"leftmost\" parrent special is bad/good\n\n> 2. This is something I do care about. For me, this is the only\n> logical way of doing it. It might be because I am used to it now, but\n> when I started to look at bzr/hg/git/darcs/etc, I just got a so much\n> more clear view of the history when running a standard log command,\n> that it was one of the first things that attracted me to bzr. This is\n> just a user talking.\n> There might be technical reasons why it's better to not do it, but for\n> me it works the way I expect, therefore I'm happy\n\nCan you give us a quick example of why you got such a clearer picture?\n\n> 3. plugins are useless/useful\n\nHmmmm. It's more of a unix/C/pipes tradition vs dynamically typed &\ncompiled scripting language tradition.\n\n> 4. And now, storing branch information should be done manually (if\n> wanted) and not automatically.\n\n> 4. No comment.\n\nProbably not. But if someone is using branchnames to identify \"lines\nof work\" and hoping that metadata will remain attached there, it's\nprobably a bad long-term approach.\n\nBut following what you said earlier about that info being transient\nand \"local\", then I was 200% wrong, and thinking of Arch/Bazaar usage\npatterns.\n\ncheers,\n\n\nmartin\n"},{"id":"29845","messageId":"ehkpos$ga1$1@sea.gmane.org","threadId":"5925","inReplyTo":"vpq64eakpnh.fsf@ecrins.imag.fr","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-24T10:27:03Z","receivedAt":"2006-10-24T10:27:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthieu Moy wrote:\n> \"Matthew D. Fuller\" writes:\n> \n>>> For example, how long does it take to do an arbitrary \"undo\" (ie\n>>> forcing a branch to an earlier state) [...]\n>>\n>> I don't understand the thrust of this, either.  As I understand the\n>> operation you're talking about, it doesn't have anything to do with a\n>> branch; you'd just be whipping the working tree around to different\n>> versions.  That should be O(diff) on any modern VCS.\n\n> There are two things to do:\n>\n> * Mark the tree as corresponding to a different revision in the past.\n[...]\n> * Then, do the \"merge\" to make your tree up to date. You can hardly do\n>   faster than git and its unpacked format, but this is at the cost of\n>   disk space. But as you say, in almost any modern VCS, that's\n>   O(diff). In a space-efficient format, that's just the tradeoff you\n>   make between full copies of a file and delta-compression.\n\nActually, this would be \"checkout\" (in git terminology), i.e. overwriting\nthe files which differ in current revision, and the revision we rewind (do\nundo) to. (That's of course simplification omitting for example removing\nand creating files.) Which would be O(changed files) which is lower bound\nand cannot be faster. Finding which files changed is also O(changed files),\nwith a little bit of O(directory depth) in git, with very small constant.\n\nAnd even in the case of packed format, it wouldn't be O(diff)/O(history),\nbut O(delta length) where delta length is maximum length of delta chain\nin pack, by default set to 10. Well, constant is a bit larges because git\nadditionally gzip-compresses (even in loose, i.e. unpacked format).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29865","messageId":"Pine.LNX.4.64.0610240812410.3962@g5.osdl.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64N.0610232336010.30334@attu2.cs.washington.edu","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-24T15:15:05Z","receivedAt":"2006-10-24T15:15:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 23 Oct 2006, David Rientjes wrote:\n> \n> Some of the internal commands that have been coded in C are actually much \n> better handled by the shell in the first place. It's much simpler to \n> write and extend as well as being much more traceable for runtime \n> problems.\n\nYes. However, from a portability (to Windows) standpoint, shell is just \nabout the worst choice.\n\nNot that perl/python/etc really help - unless the _whole_ program is one \nperl/python thing. Windows just doesn't like pipelines etc very much.\n\nSo I'd like all the _common_ programs to be built-ins..\n\n\t\tLinus\n"},{"id":"29868","messageId":"Pine.LNX.4.63.0610240853160.10841@qynat.qvtvafvgr.pbz","threadId":"5925","inReplyTo":"20061024002622.GC17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-10-24T15:58:56Z","receivedAt":"2006-10-24T15:58:56Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Mon, 23 Oct 2006, Matthew D. Fuller wrote:\n\n> But I don't understand how bzr-the-abstract-data-model makes such\n> things impossible, or even significantly different than doing so in\n> git. In git, you're just chopping off one DAG where another one\n> intersects it (or similar operations). To do it in bzr, you'd do...\n> exactly the same thing. The revnos, or the mainline, are completely\n> useless in such an operation of course, but they don't hurt it; the\n> tool would just just ignore them like it does the SHA-1 of files in\n> the revision.\n\none key difference is that with bzr you have to do this chopping by creating the \nbranches at the time changes are done, with git you do this chopping after the \nfact when you are displaying the results.\n\nAs such you can chop and compare things in ways that were never contemplated by \nanyone at the time changes are made.\n\n>\n>> See? When you visualize multiple branches together, HAVING\n>> PER-BRANCH REVISION NUMBERS IS INSANE! Yet, clearly, it's a valid\n>> and interesting operation to do.\n>\n> I wouldn't be so absolutist about it, but certainly they're of\n> extremely limited utility if of any at all in such cases. And yes, it\n> can be an interesting operation. But what does that have to do with\n> using revnos in other cases? You keep saying \"having\" where I would\n> say \"using\".\n\nand the bzr tools strongly encourage the use of these numbers\n\n> I care about that first parent line. Therefore, I require my tool to\n> at least _pretend_ to care. I'm not aware of any way in which the\n> fundamental bzr structures care, but the UI is chock full of\n> pretending. A necessary part of that pretending is not changing my\n> mainline unless I specifically ask for it, and that means a\n> merge-vs-pull distinction needs to be there. That's a _technical_\n> sign that the tool is ready to work with me the way I want to work. A\n> lack of it is a _technical_ sign that it's not suitable.\n\nnobody is saying that the bzr approach is invalid for your workflow.\n\nwhat people are saying is that it doesn't easily support a truely distributed \nworkflow. this is a very different statement.\n\nyour workflow isn't truely distributed so you bzr's model works well for you. no \nproblem, just don't claim that becouse you haven't run into any problems with \nyour workflow that there are no problems with bzr with other workflows.\n\nDavid Lang\n"},{"id":"29869","messageId":"20061024163458.GH17019@over-yonder.net","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610240853160.10841@qynat.qvtvafvgr.pbz","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-24T16:34:58Z","receivedAt":"2006-10-24T16:34:58Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Tue, Oct 24, 2006 at 08:58:56AM -0700 I heard the voice of\nDavid Lang, and lo! it spake thus:\n> \n> one key difference is that with bzr you have to do this chopping by\n> creating the branches at the time changes are done,\n\nHUH? Why on earth do you think that?\n\nTo do this in a git data model, you point at 2 (or 3, or 4, or...)\nrevisions, anywhere in the revision-space universe. You derive back a\nDAG of the history from each of them by recursing over parent links.\nYou figure out where (if anywhere) those DAG's intersect. And based\non that, you alter what and how you display; including or excluding\ncertain revs, changing the angles of lines or columnation of dots in a\ngraph, etc.\n\nTo do it in a bzr data model, you would follow *EXACTLY* the same\nsteps. As in, you do EXACTLY (a), then EXACTLY (b), then...\n\n\n> what people are saying is that it doesn't easily support a truely\n> distributed workflow. this is a very different statement.\n\nAnd it's one that carries around a lot of unstated assumptions about\nwhat \"truely distributed\" means, which *I*'m certainly not\nunderstanding, because any meaning I can apply to the term doesn't\nlead me to the conclusions it does you. Certainly, depending on your\nworkflow, certain parts of the UI are of lesser utility than they are\nin mine, down to and including zero. And it's probably certain that\nsome parts of the UI aren't up to handling various workflows, too,\nincluding OUR workflow. That's kinda what \"in development\" means...\n\nBut that's a very different statement from the claim that they CAN'T\nbe without changes to the conceptual model underneath. Just because a\nUI is built around maintaining the fiction of a mainline doesn't mean\nthe system requires it. All you'd have to do to abandon it is write a\ndifferent log formatter that didn't show revnos and didn't nest merge\ncommits, and change (or add an option to) 'merge' to fast-forward if\npossible. The difference between the views on how the pieces should\nfit together really IS just that fine.\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29870","messageId":"20061024164606.GI17019@over-yonder.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610232239220.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-24T16:46:06Z","receivedAt":"2006-10-24T16:46:06Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Mon, Oct 23, 2006 at 10:42:23PM -0700 I heard the voice of\nLinus Torvalds, and lo! it spake thus:\n> \n> Well, I would use the globally unique ones, certainly. It's the only\n> thing that makes sense.\n\nSo would I, and it is.\n\n\n> Using the _same_ names everywhere is just better. \n\nThis is just where we split on it. All else being equal, sure, but\nall else is never equal. Most of my time is spent working forward\nalong one branch (different branches at different times, of course,\nbut at any given moment I'm almost certainly only concerned about one\nbranch), and having a different and advantageous localized naming\nscheme there is a benefit I celebrate. If most of my time were\ninstead spent comparing and contrasting and intersecting and\ncross-breeding branches, it would probably be as worthless to me as it\napparently is to you.\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n On the Internet, nobody can hear you scream.\n"},{"id":"29879","messageId":"Pine.LNX.4.63.0610241038060.10841@qynat.qvtvafvgr.pbz","threadId":"5925","inReplyTo":"20061024163458.GH17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-10-24T18:03:20Z","receivedAt":"2006-10-24T18:03:20Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Tue, 24 Oct 2006, Matthew D. Fuller wrote:\n\n> On Tue, Oct 24, 2006 at 08:58:56AM -0700 I heard the voice of\n> David Lang, and lo! it spake thus:\n>>\n>> one key difference is that with bzr you have to do this chopping by\n>> creating the branches at the time changes are done,\n>\n> HUH? Why on earth do you think that?\n>\n> To do this in a git data model, you point at 2 (or 3, or 4, or...)\n> revisions, anywhere in the revision-space universe. You derive back a\n> DAG of the history from each of them by recursing over parent links.\n> You figure out where (if anywhere) those DAG's intersect. And based\n> on that, you alter what and how you display; including or excluding\n> certain revs, changing the angles of lines or columnation of dots in a\n> graph, etc.\n>\n> To do it in a bzr data model, you would follow *EXACTLY* the same\n> steps. As in, you do EXACTLY (a), then EXACTLY (b), then...\n\nit sounded like you were saying that the way to get the slices of the DAG was to \nuse branches in bzr. to do this you need to create the branches with the correct \ninfo on each branch. this is only practical if the branches are created as the \nchanges are made, if you try to do this after the fact you need to create the \nchanges in the branch before you do the slicing.\n\nwith git you can look at the DAG and pick any arbatrary points in it as points \nto use for the slicing at display time.\n\n>> what people are saying is that it doesn't easily support a truely\n>> distributed workflow. this is a very different statement.\n>\n> And it's one that carries around a lot of unstated assumptions about\n> what \"truely distributed\" means, which *I*'m certainly not\n> understanding, because any meaning I can apply to the term doesn't\n> lead me to the conclusions it does you. Certainly, depending on your\n> workflow, certain parts of the UI are of lesser utility than they are\n> in mine, down to and including zero. And it's probably certain that\n> some parts of the UI aren't up to handling various workflows, too,\n> including OUR workflow. That's kinda what \"in development\" means...\n>\n> But that's a very different statement from the claim that they CAN'T\n> be without changes to the conceptual model underneath. Just because a\n> UI is built around maintaining the fiction of a mainline doesn't mean\n> the system requires it. All you'd have to do to abandon it is write a\n> different log formatter that didn't show revnos and didn't nest merge\n> commits, and change (or add an option to) 'merge' to fast-forward if\n> possible. The difference between the views on how the pieces should\n> fit together really IS just that fine.\n\nthe claim isn't that bzr can't be modified to support these other workflows (it \nsounds as if just changing to tools to use the internal refid's rather then the \ncurrent refno's would come very close to solving this problem), it's that the \ncurrent refno's (use of which is strongly encouraged by the current UI) cannot \nsupport some workflows, and therefor the claim that it supports fully \ndistributed workflows as well as git is false\n\nremember that this entire thing started with a feature comparison checklist, \nthe definitions of some of the items on the checklist is being questioned.\n\nafter that there's the issue of if the VCS in question has the feature.\n\nthis discussion started with two topologies\n\n1. Centralized: all commits must go to one repository, connectivity required to check-in \n2. Distributed: everything else\n\nsince then one additional topology has been defined, and one has been redefined\n\n1. Centralized: all commits must go to one repository, connectivity required to check-in\n\n2. Star: one repository is 'special' or 'primary' and all other repositories \nsync to this, but development can take place against local repositories, \nconnectivity is only requred when syncing the repositories. as updates take \nplace the history is defined by the primary repository, and can overwrite or \nchange the history as defined by local repositories.\n\n3. Distributed: all repositories are equal (any definition of 'primary' is a \nmatter of convention, not a requirement of the tool) development can take place \nagainst local repositories, connectivity is only required when syncing the \nrepositories. repositories with no development takeing place can sync back and \nforth with no side effects. History displays the same thing no matter what \nrepository is looked at (allowing for the fact that some repositories may not \nhave the full history)\n\neveryone agrees that bzr supports the Star topology. Most people (including bzr \npeople) seem to agree that currently bzr does not support the Distributed \ntopology.\n\nit's just fine for bzr to not support all possible topologies, the only reason \nfor discussing these issues (besides everyone understanding each other) is the \nfeature checklist that started this entire thread, and what is appropriate there \nfor each VCS (see the early part of this discussion to see how that worked with \ngit's rename support)\n\nDavid Lang\n"},{"id":"29880","messageId":"ehllqj$bee$1@sea.gmane.org","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610241038060.10841@qynat.qvtvafvgr.pbz","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-24T18:25:53Z","receivedAt":"2006-10-24T18:25:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David Lang wrote:\n\n> 1. Centralized: all commits must go to one repository, connectivity\n> required to check-in \n\nBazaar-NG \"light checkouts\" implements this. Git doesn't support this\ntopology, and probably wouldn't.\n\n1.5. Disconnected centralized. Like centralized, but you can work (perhaps\nlimited to what you can do) even without connection to central server.\nMinimally you have to be able to commit changes locally, if central server\nis not available. Bzr \"normal/heavyweight checkouts\" are [roughly] abot\nthis. Git \"lazy clone\" proposal is about similar thing; you can get git to\nsupport this model (although without space savings) with full \nclone + hooks.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"297383","messageId":"20061024192707.GG20017@pasky.or.cz","threadId":"5925","inReplyTo":"ehllqj$bee$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-24T19:27:07Z","receivedAt":"2006-10-24T19:27:07Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Oct 24, 2006 at 08:25:53PM CEST, I got a letter\nwhere Jakub Narebski said that...\n> David Lang wrote:\n> \n> > 1. Centralized: all commits must go to one repository, connectivity\n> > required to check-in \n> \n> Bazaar-NG \"light checkouts\" implements this. Git doesn't support this\n> topology, and probably wouldn't.\n> \n> 1.5. Disconnected centralized. Like centralized, but you can work (perhaps\n> limited to what you can do) even without connection to central server.\n> Minimally you have to be able to commit changes locally, if central server\n> is not available. Bzr \"normal/heavyweight checkouts\" are [roughly] abot\n> this. Git \"lazy clone\" proposal is about similar thing; you can get git to\n> support this model (although without space savings) with full \n> clone + hooks.\n\nCogito can do it now out of the box, having support for cg-commit --push\nand cg-update preserving uncommitted local changes.\n\nNot that you probably should use it. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Yes. However, from a portability (to Windows) standpoint, shell is just \n> about the worst choice.\n> \n> Not that perl/python/etc really help - unless the _whole_ program is one \n> perl/python thing. Windows just doesn't like pipelines etc very much.\n> \n> So I'd like all the _common_ programs to be built-ins..\n> \n\nAnd I would prefer the opposite because we're talking about git. As an \ninformation manager, it should be seen and not heard. Nobody is going to \nspend their time to become a git or CVS or perforce expert. As an \nindividual primarily interested in development, I should not be required \nto learn command lines for dozens of different git-specific commands to do \nmy job quickly and effectively. I would opt for a much more simpler \napproach and deal with shell scripting for many of these commands because \nI'm familiar with them and I can pipe any command with the options I \nalready know and have used before to any other command.\n\nAs a developer on Linux based systems, I should not need to deal with \ncode in a revision control system that is longer and less traceable \nbecause the authors of that system decided they wanted to support Windows \ntoo. Moving away from the functionality that the shell provides is a \nmistake for a system such as git where it could be so advantageous because \nof the inherent nature of git as an information manager.\n\nThis is the reason why I was a fan of git long ago and used it for my own \nneeds before tons of unnecessary features and unneeded complexity was \nadded on.\n\n\t\tDavid\n\n\n\n"},{"id":"295855","messageId":"ehlt09$ard$1@sea.gmane.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64N.0610241300450.8112@attu4.cs.washington.edu","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-24T20:28:24Z","receivedAt":"2006-10-24T20:28:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David Rientjes wrote:\n\n> This is the reason why I was a fan of git long ago and used it for my own \n> needs before tons of unnecessary features and unneeded complexity was \n> added on.\n\nBut you can still use git as you used it long time ago. The plumbing\ncommands didn't vanish. Git got rich in porcelanish commands, true, but old\ncore remains. And GIT_TRACE (quite new addition) certainly helps.\n\nI think git profit very much from being created bottom-up, from main idea of\nSCM, through repository format and structure, through plumbing commands,\nthrough porcelain done with scripts, to having many new plumbing commands,\nto having many commands builtin, in the future to libification perhaps.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294823","messageId":"845b6e870610241451x578efe9n77017f3a9404e81c@mail.gmail.com","threadId":"5925","inReplyTo":"87y7r6zgic.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-24T21:51:22Z","receivedAt":"2006-10-24T21:51:22Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"Sorry for going back to an old mail... but....\n\nOn 10/24/06, Carl Worth wrote:\n> On Mon, 23 Oct 2006 19:26:57 -0500, \"Matthew D. Fuller\" wrote:\n> >\n> > On Mon, Oct 23, 2006 at 04:24:30PM -0700 I heard the voice of\n> > Linus Torvalds, and lo! it spake thus:\n> > >\n> > > The problem? How do you show a commit that is _common_ to two\n> > > branches, but has different revision names in them?\n> >\n> > Why would you?\n>\n> Assume you've got two long-lived branches and one periodically gets\n> merged into the other one. The combined history might look as follows\n> (more recent commits first):\n>\n> f g\n> | |\n> d e\n> |\\ /\n> b c\n> |/\n> a\n>\n> The point is that it is extremely nice to be able to visualize things\n> that way. Say I've got a \"dev\" branch that points at f and a \"stable\"\n> branch that points at g. With this, a command like:\n>\n> gitk dev stable\n>\n> would result in a picture just like the above. Can a similar figure be\n> made with bzr? Or only the following two separate pictures:\n\nI wanted to test how hard it is. So I created a small plugin that will\nshow the relationsships between revisions... The following commands\n\nbzr init-repo repo --trees\nbzr init repo/branchA\ncd repo/branchA\nbzr whoami --branch \"Test Devel 1 \"\nbzr ci --unchanged -m a1\nbzr ci --unchanged -m a2\nbzr branch . ../branchB\nbzr ci --unchanged -m a3\nbzr ci --unchanged -m a4\ncd ../branchB\nbzr whoami --branch \"Test Devel 2 \"\nbzr ci --unchanged -m b1\nbzr ci --unchanged -m b2\nbzr merge ../branchA\nbzr ci -m merge\nbzr ci --unchanged -m b3\nbzr ci --unchanged -m b4\ncd ../branchA\nbzr merge ../branchB\nbzr ci -m merge\nbzr ci --unchanged -m a5\ncd ../branchB\nbzr ci --unchanged -m b5\ncd ..\nbzr dotrepo > test.dot\ndot -Tpng test.dot > dotrepo.png\n\nCreates the picture you can see at\nhttp://erik.bagfors.nu/bzr-plugins/dotrepo.png\n\nPlease remember that this is a 15 min implementation and as such might\nsuck (the output is not perfect for example, it's slow, etc). This\njust brings in every revision in the entire repo, but to expand it to\njust take the branches on the command line, is perfectly possible.\n\nBut still.. there is no problem to create this.\n\n/Erik\nps. the plugin can be bzr branched from\nhttp://erik.bagfors.nu/bzr-plugins/dotrepo/\n-- \ngoogle talk/jabber. zindar@gmail.com\nSIP-phones: sip:erik_bagfors@gizmoproject.com\n"},{"id":"296065","messageId":"20061025002713.GN17019@over-yonder.net","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610241038060.10841@qynat.qvtvafvgr.pbz","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-25T00:27:13Z","receivedAt":"2006-10-25T00:27:13Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Tue, Oct 24, 2006 at 11:03:20AM -0700 I heard the voice of\nDavid Lang, and lo! it spake thus:\n> \n> it sounded like you were saying that the way to get the slices of\n> the DAG was to use branches in bzr. [...]\n\nI'm not entirely sure I understand what you mean here, but I think\nyou're saying \"Nobody's written the code in bzr to show arbitrary\nslices of the DAG\", which is true TTBOMK.\n\n\n> everyone agrees that bzr supports the Star topology. Most people\n> (including bzr people) seem to agree that currently bzr does not\n> support the Distributed topology.\n\nI think this statement arouses so much grumbling because (a) bzr does\nsupport such a lot better than often seems implied, (b) where it\ndoesn't, the changes needed to do so are relatively minor (often\nmerely cosmetic), and (c) disagreement over whether some of the\nqualifications included for 'distributed' are really fundamental.\n\n\n> it's just fine for bzr to not support all possible topologies,\n\nI think there's a real intent for bzr TO support at least all common\ntopologies. I'll buy that current development has focused more on\n[relatively] simple topologies than the more wildly complex ones. I\nlook forward to more addressing of the less common cases as the tool\nmatures, and I think a lot of this thread will be good material to\nwork with as that happens. It's just the suggestion that providing\nfruit for simple topologies _necessarily_ prejudices against complex\nones that I find so onerous.\n\n\n> (besides everyone understanding each other)\n\nThat's a good enough reason for me. Before this thread, I wasn't\ninterested in using git. I'm still not, but now I understand much\nbetter /why/ I'm not. And when (I'm sure it'll happen sooner or\nlater) some project I follow picks up using git, I'll have enough\ngrounding in the tool's mental model to work with it when I have to.\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n"},{"id":"295523","messageId":"20061025084810.GA26618@coredump.intra.peff.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64N.0610241300450.8112@attu4.cs.washington.edu","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-25T08:48:10Z","receivedAt":"2006-10-25T08:48:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 24, 2006 at 01:12:52PM -0700, David Rientjes wrote:\n\n> And I would prefer the opposite because we're talking about git. As an \n> information manager, it should be seen and not heard. Nobody is going to \n> spend their time to become a git or CVS or perforce expert. As an \n> individual primarily interested in development, I should not be required \n> to learn command lines for dozens of different git-specific commands to do \n> my job quickly and effectively. I would opt for a much more simpler \n> approach and deal with shell scripting for many of these commands because \n> I'm familiar with them and I can pipe any command with the options I \n> already know and have used before to any other command.\n\nI don't understand how converting shell scripts to C has any impact\nwhatsoever on the usage of git. The plumbing shell scripts didn't go\naway; you can still call them and they behave identically.\n\nIs there some specific change in functionality that you're lamenting?\n\n> As a developer on Linux based systems, I should not need to deal with \n> code in a revision control system that is longer and less traceable \n> because the authors of that system decided they wanted to support Windows \n> too. Moving away from the functionality that the shell provides is a \n> mistake for a system such as git where it could be so advantageous because \n> of the inherent nature of git as an information manager.\n\nSome C->shell conversions may have made the code \"longer and less\ntraceable.\" However, many of those conversions caused the code to be\nshorter (because communication between C functions is simpler than going\nover pipes, and because anything involving a data structure more complex\nthan a string is difficult in the shell) and more robust (fewer\nopportunities for quoting/parsing errors, and none of the shell gotchas\nlike missing the error code in \"foo | bar\").\n\nDo you have any specific reason to believe that the git code is of worse\nquality now than it was before?\n\n> This is the reason why I was a fan of git long ago and used it for my own \n> needs before tons of unnecessary features and unneeded complexity was \n> added on.\n\nIs there something you used to do with git that you no longer can? Is\nthere a reason you can't ignore the newer commands?\n\n"},{"id":"294319","messageId":"Pine.LNX.4.64N.0610250157470.3467@attu1.cs.washington.edu","threadId":"5925","inReplyTo":"20061025084810.GA26618@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"David Rientjes","fromEmail":"rientjes@cs.washington.edu","sentAt":"2006-10-25T09:19:15Z","receivedAt":"2006-10-25T09:19:15Z","isPatch":false,"sender":{"key":"rientjes@cs.washington.edu","avatar":null},"body":"On Wed, 25 Oct 2006, Jeff King wrote:\n\n> I don't understand how converting shell scripts to C has any impact\n> whatsoever on the usage of git. The plumbing shell scripts didn't go\n> away; you can still call them and they behave identically.\n> \n> Is there some specific change in functionality that you're lamenting?\n> \n\nNo, my criticism is against the added complexity which makes the \nmodification of git increasingly difficult with every new release. It's a \npretty limited use case of the entire package, I'm sure, but one of the \nmajor advantages that I saw in git early on was the ability to tailor it \nto your own personal needs very easily with some simple shell knowledge \nand enough C that was required at the time.\n\n> Some C->shell conversions may have made the code \"longer and less\n> traceable.\" However, many of those conversions caused the code to be\n> shorter (because communication between C functions is simpler than going\n> over pipes, and because anything involving a data structure more complex\n> than a string is difficult in the shell) and more robust (fewer\n> opportunities for quoting/parsing errors, and none of the shell gotchas\n> like missing the error code in \"foo | bar\").\n> \n\nYou're ignoring the advantageous nature of the shell with regard to git. \nThe shell is so much better prepared to deal with information managers by \nnature than the C programming language. It's not a matter of shorter \ncode, per se, it's about the developer's ability to make small changes to \nthe operation of the information manager on demand to tailor to his or her \n_current_ needs. For any experienced shell programmer it is so much \neasier to go in and change an option or pipe to a different command or \ncomment out a simple shell command in a .sh file than editing the C code. \nAnd sometimes it's necessary to have several different variations of that \ncommand which is very easy with slightly renamed .sh files instead of \nadding on more and more flags to commands that have become so complex at \nthis point that it's difficult to know the basics of how to manage a \nproject.\n\nThis all became very obvious when the tutorials came out on \"how to use \ngit in 20 commands or less\" effectively. These tutorials shouldn't need \nto exist with an information manager that started as a quick, efficient, \nand _simple_ project. You're treating git development in the same light \nas you treat Linux development; let's be honest and say that 99% of the \nnecessary git functionality was there almost a year ago and ever since \nnothing of absolute necessity has been added that serious developers care \nabout in a revision control system. Look at LKML, nobody is waiting on \nthese new releases and upgrading to them when they're announced. And this \nis the community that git has _targeted_. Most other projects don't care \nabout the syntactics of sign-off lines and acked-by lines and format-patch \nlike the git community does.\n\n> Do you have any specific reason to believe that the git code is of worse\n> quality now than it was before?\n> \n\nAbsolutely. I think I've actually documented that fairly well. Back in \nthe day git was a very concise, well-written package. Today, a tour \nthrough the source code for the latest release leaves a lot to be desired \nfor any serious C programmer.\n\n> Is there something you used to do with git that you no longer can? Is\n> there a reason you can't ignore the newer commands?\n> \n\nFunctionality wise, no. But in terms of being able to _customize_ my \nversion of git depending on how I want to use it, I've lost hope on the \nwhole idea. It's a shame too because it appears as though the original \nvision was one of efficiency and simplicity. I would say that git-1.2.4 \nis my package of preference with some slight tweaking in the branching \ndepartment.\n\nI really do miss the old git.\n\n"},{"id":"297854","messageId":"ehnauq$ou8$1@sea.gmane.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64N.0610250157470.3467@attu1.cs.washington.edu","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-25T09:32:44Z","receivedAt":"2006-10-25T09:32:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David Rientjes wrote:\n\n> On Wed, 25 Oct 2006, Jeff King wrote:\n> \n>> I don't understand how converting shell scripts to C has any impact\n>> whatsoever on the usage of git. The plumbing shell scripts didn't go\n>> away; you can still call them and they behave identically.\n>> \n>> Is there some specific change in functionality that you're lamenting?\n>> \n> \n> No, my criticism is against the added complexity which makes the \n> modification of git increasingly difficult with every new release. It's a \n> pretty limited use case of the entire package, I'm sure, but one of the \n> major advantages that I saw in git early on was the ability to tailor it \n> to your own personal needs very easily with some simple shell knowledge \n> and enough C that was required at the time.\n> \n[...]\n>> Is there something you used to do with git that you no longer can? Is\n>> there a reason you can't ignore the newer commands?\n> \n> Functionality wise, no. But in terms of being able to _customize_ my \n> version of git depending on how I want to use it, I've lost hope on the \n> whole idea. It's a shame too because it appears as though the original \n> vision was one of efficiency and simplicity. I would say that git-1.2.4 \n> is my package of preference with some slight tweaking in the branching \n> department.\n\nAhah! So you miss the old script version of git commands, which you could\neasily modify, tailoring it to your needs, isn't it? Well, if you don't mind\nkeeping your clone of git repository lying around somewhere, you can always\nresurrect old shell version of some git command, e.g.\n $ git cat-file -p v1.2.4:git-prune.sh > $(git --exec-path)/git-prune.sh\nchange its name and modify as you used to do.\n\nAre there any old commands which stopped working?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297790","messageId":"453F2FF8.2080903@op5.se","threadId":"5925","inReplyTo":"20061021130111.GL75501@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-25T09:35:52Z","receivedAt":"2006-10-25T09:35:52Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthew D. Fuller wrote:\n> On Fri, Oct 20, 2006 at 02:48:52PM -0700 I heard the voice of\n> Carl Worth, and lo! it spake thus:\n> \n>> (since pull seems the only way to synch up without infinite new\n>> merge commits being added back and forth).\n> \n> The infinite-merge-commits case doesn't happen in bzr-land because we\n> generally don't merge other branches except when the branch owner says\n> \"Hey, I've got something for you to merge\". If you were to setup a\n> script to merge two branches back and forth until they were 'equal',\n> yes, it'd churn away until you filled up your disk with the N bytes of\n> metadata every new revision uses up.\n> \n\nThis is new to me. At work, we merge our toy repositories back and forth \nbetween devs only. There is no central repo at all. Does this mean that \neach merge would add one extra commit per time the one I'm merging with \nhas merged with me?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"297778","messageId":"200610251146.06116.jnareb@gmail.com","threadId":"5925","inReplyTo":"453F2FF8.2080903@op5.se","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-25T09:46:05Z","receivedAt":"2006-10-25T09:46:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson wrote:\n> Matthew D. Fuller wrote:\n>> On Fri, Oct 20, 2006 at 02:48:52PM -0700 I heard the voice of\n>> Carl Worth, and lo! it spake thus:\n>> \n>>> (since pull seems the only way to synch up without infinite new\n>>> merge commits being added back and forth).\n>> \n>> The infinite-merge-commits case doesn't happen in bzr-land because we\n>> generally don't merge other branches except when the branch owner says\n>> \"Hey, I've got something for you to merge\". If you were to setup a\n>> script to merge two branches back and forth until they were 'equal',\n>> yes, it'd churn away until you filled up your disk with the N bytes of\n>> metadata every new revision uses up.\n> \n> This is new to me. At work, we merge our toy repositories back and forth \n> between devs only. There is no central repo at all. Does this mean that \n> each merge would add one extra commit per time the one I'm merging with \n> has merged with me?\n\nFrom what I understand, \"bzr merge\" will create one extra commit to\npreserve the \"first parent is my branch\" feature. \"bzr pull\" will do\nfast-forward if your DAG is proper subset of pulled branch/repository\nDAG, but at the cost that it would change your revno to revision mapping\nto those of the pulled repository.\n\nThat's a consequence of preserving branch as \"my work\" i.e. as path\nthrough \"branch DAG\" in the DAG using first parent as special, instead\nof saving it outside DAG.\n\n-- \nJakub Narebski\n"},{"id":"298896","messageId":"20061025094900.GA26989@coredump.intra.peff.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64N.0610250157470.3467@attu1.cs.washington.edu","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-25T09:49:00Z","receivedAt":"2006-10-25T09:49:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 25, 2006 at 02:19:15AM -0700, David Rientjes wrote:\n\n> No, my criticism is against the added complexity which makes the \n> modification of git increasingly difficult with every new release. It's a \n\nOK, you seemed to imply problems for end users in your first paragraph,\nwhich is what I was responding to.\n\n> _current_ needs. For any experienced shell programmer it is so much \n> easier to go in and change an option or pipe to a different command or \n> comment out a simple shell command in a .sh file than editing the C code. \n\nYes, it's true that some operations might be easier to play with in the\nshell. However, does it actually come up that you want to modify\nexisting git programs? The more common usage seems to be gluing the\nplumbing together in interesting ways, and that is still very much\nsupported.\n\n> And sometimes it's necessary to have several different variations of that \n> command which is very easy with slightly renamed .sh files instead of \n> adding on more and more flags to commands that have become so complex at \n> this point that it's difficult to know the basics of how to manage a \n> project.\n\nYou can do the same thing in C. In fact, look at how similar\ngit-whatchanged, git-log, and git-diff are.\n\nI don't understand how a C->shell conversion has anything to do with\noptions being added. If you look at all of the conversions, they\nreplicate the interface _exactly_.\n\n> This all became very obvious when the tutorials came out on \"how to use \n> git in 20 commands or less\" effectively. These tutorials shouldn't need \n> to exist with an information manager that started as a quick, efficient, \n> and _simple_ project. You're treating git development in the same light \n\nSorry, I don't see how this is related to the programming language _at\nall_. Are you arguing that the interface of git should be simplified so\nthat such tutorials aren't necessary? If so, then please elaborate, as\nI'm sure many here would like to hear proposals for improvements. If\nyou're arguing that git now has too many features, then which features\ndo you consider extraneous?\n\n> as you treat Linux development; let's be honest and say that 99% of the \n> necessary git functionality was there almost a year ago and ever since \n> nothing of absolute necessity has been added that serious developers care \n> about in a revision control system. Look at LKML, nobody is waiting on \n\nI don't agree with this. There are tons of enhancements that I find\nuseful (e.g., '...' rev syntax, rebasing with 3-way merge, etc) that I\nthink other developers ARE using. There are scalability and performance\nimprovements. And there are new things on the way (Junio's pickaxe work)\nthat will hopefully make git even more useful than it already is.\n\nIf you don't think recent git versions are worthwhile, then why don't\nyou run an old version? You can even use git to cherry-pick patches onto\nyour personal branch.\n\n> Absolutely. I think I've actually documented that fairly well. Back in \n\nWhere?\n\n> the day git was a very concise, well-written package. Today, a tour \n> through the source code for the latest release leaves a lot to be desired \n> for any serious C programmer.\n\nI don't agree, but since you haven't provided anything specific enough\nto discuss, there's not much to say.\n\n> Functionality wise, no. But in terms of being able to _customize_ my \n> version of git depending on how I want to use it, I've lost hope on the \n> whole idea. It's a shame too because it appears as though the original \n\nCan you name one customization that you would like to perform now that\nyou feel can't be easily done (and presumably that would have been\neasier in the past)?\n\n-Peff\n\n\n\n"},{"id":"297043","messageId":"453F33E4.2000708@op5.se","threadId":"5925","inReplyTo":"8764ed1b7z.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-25T09:52:36Z","receivedAt":"2006-10-25T09:52:36Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Carl Worth wrote:\n> On Sat, 21 Oct 2006 19:42:47 -0400, Jeff Licquia wrote:\n>> I don't think so. Recently, I've been trying to track a particular\n>> patch in the kernel. It was done as a series of commits, and probably\n>> would have been its own branch in bzr, but when I was trying to group\n>> the commits together to analyze them as a group, the easiest way to do\n>> that was by the original committer's name.\n> \n> As far as \"its own branch in bzr\" would such a branch remain available\n> indefinitely even after being merged in to the main tree?\n> \n>> Now, there's probably a better way to hunt that stuff down, but in this\n>> case hunting the user down worked for me. (It may have made a\n>> difference that I was using gitweb instead of a local clone.)\n> \n> Vast, huge, gaping, cosmic difference.\n> \n> Almost none of the power of git is exposed by gitweb. It's really not\n> worth comparing. (Now a gitweb-alike that provided all the kinds of\n> very easy browsing and filtering of the history like gitk and git\n> might be nice to have.)\n> \n\nThere was one, but it got discontinued due to performance issues. Shame \nthat, because it would have been nice to have to show \"foreign\" visitors \nhow gitk/qgit works. It would especially show the way git thinks about \nbranches and stuff like that.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"298343","messageId":"vpqd58g3eh0.fsf@ecrins.imag.fr","threadId":"5925","inReplyTo":"453F2FF8.2080903@op5.se","subject":"Re: VCS comparison table","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2006-10-25T09:57:15Z","receivedAt":"2006-10-25T09:57:15Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Andreas Ericsson writes:\n\n> This is new to me. At work, we merge our toy repositories back and\n> forth between devs only. There is no central repo at all. Does this\n> mean that each merge would add one extra commit per time the one I'm\n> merging with has merged with me?\n\nTwo things differ in bzr and git, here:\n\n* bzr doesn't do \"autocommit\" after a merge. So, new revisions are\n created only if you use\"commit\".\n\n* bzr has two commands, \"pull\" and \"merge\". \"pull\" just does what the\n git people call \"fast-forward\", and only this (it refuses to do\n anything if the branches diverged). In particular, you never have to\n commit after a pull (well, except if you had some local, uncommited\n changes). \"merge\" changes your working directory, and you have to\n commit after. \"merge\" will never do fast-forward, it will never\n change the revision to which your working tree revfers to, and it's\n your option to commit or not after (if you see that it introduces no\n changes, you might not want to commit).\n\nThe final rule in bzr would be \"you create an extra commit each time\nyou commit\" ;-).\n\nAs a side-note, it could be interesting to have a git-like merge\ncommand (chosing automatically between merge and pull), probably not\nin the core, but as a plugin.\n\n-- \n"},{"id":"298899","messageId":"a7e835d40610250308v5d577482m139742e7fe1db185@mail.gmail.com","threadId":"5925","inReplyTo":"200610251146.06116.jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"James Henstridge","fromEmail":"james@jamesh.id.au","sentAt":"2006-10-25T10:08:22Z","receivedAt":"2006-10-25T10:08:22Z","isPatch":false,"sender":{"key":"james@jamesh.id.au","avatar":"https://gravatar.com/avatar/3007d1d261c8d1edc4e388f53ea5e53ab40fd5f8334748472ba0e2037b76e4aa?d=mp&s=160"},"body":"On 25/10/06, Jakub Narebski wrote:\n> Andreas Ericsson wrote:\n> > This is new to me. At work, we merge our toy repositories back and forth\n> > between devs only. There is no central repo at all. Does this mean that\n> > each merge would add one extra commit per time the one I'm merging with\n> > has merged with me?\n>\n> From what I understand, \"bzr merge\" will create one extra commit to\n> preserve the \"first parent is my branch\" feature. \"bzr pull\" will do\n> fast-forward if your DAG is proper subset of pulled branch/repository\n> DAG, but at the cost that it would change your revno to revision mapping\n> to those of the pulled repository.\n\nActually, \"bzr merge\" does not create any commits on the branch -- you\nneed to run \"bzr commit\" afterwards (possibly after resolving\nconflicts). The control files for the working tree record a pending\nmerge, which gets recorded when you get round to the commit.\n\nSo you can easily check if there were any tree changes resulting from the merge.\n\nIf there aren't, or you made the merge by mistake, you can make a call\nto \"bzr revert\" to clean things up without ever having created a new\nrevision.\n\nJames.\n\n\n\n"},{"id":"298912","messageId":"453F41DE.6090405@op5.se","threadId":"5925","inReplyTo":"20061023222131.GB17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-25T10:52:14Z","receivedAt":"2006-10-25T10:52:14Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthew D. Fuller wrote:\n> On Mon, Oct 23, 2006 at 10:29:53AM -0700 I heard the voice of\n> Linus Torvalds, and lo! it spake thus:\n>> I already briought this up once, and I suspect that the bzr people\n>> simply DID NOT UNDERSTAND the question:\n>>\n>> - how do you do the git equivalent of \"gitk --all\"\n> \n> I for one simply DO NOT UNDERSTAND the question, because I don't know\n> what that is or what I'd be trying to accomplish by doing it. The\n> documentation helpfully tells me that it's something undocumented.\n> \n\nSee the attached screenshot. This is from qgit --all on the git \nrepository, but the DAG output is identical to that of gitk. Note in \nparticular the 'pu' and 'next' branches. By scrolling down, I can easily \nsee the branch-point of any of them.\n\nTo those that do not appreciate or allow email-attachments, I apologize. \nI think however that it was necessary to provide a view for the bazaar \npeople of what Linus is talking about without having to download and \ninstall git and a git repository.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"295055","messageId":"453F5B73.2050504@op5.se","threadId":"5925","inReplyTo":"845b6e870610241451x578efe9n77017f3a9404e81c@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-25T12:41:23Z","receivedAt":"2006-10-25T12:41:23Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Erik Bågfors wrote:\n> \n> Creates the picture you can see at\n> http://erik.bagfors.nu/bzr-plugins/dotrepo.png\n> \n\nLooking at this picture, I found a very annoying thing with bzr's \nrevids: For commits from the same author on the same day, they don't \ndiffer in the beginning, making all of them, at a glance, look the same. \nI got a headache just trying to figure out how to read them. It might be \nworth looking into in the future, especially if you decide to show them \nto the users.\n\nPerhaps it's just my git eyes being used to seeing the first 4 chars \n(which is all I normally look at) being different for each different \ncommit, but having to look up the near-end of the string to find the \nactual difference in bzr's revids was actually a quite painful experience.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"297872","messageId":"845b6e870610250615t713ebeaewcab3050446fc25a6@mail.gmail.com","threadId":"5925","inReplyTo":"453F5B73.2050504@op5.se","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-25T13:15:44Z","receivedAt":"2006-10-25T13:15:44Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"On 10/25/06, Andreas Ericsson wrote:\n> Erik Bågfors wrote:\n> >\n> > Creates the picture you can see at\n> > http://erik.bagfors.nu/bzr-plugins/dotrepo.png\n> >\n>\n> Looking at this picture, I found a very annoying thing with bzr's\n> revids: For commits from the same author on the same day, they don't\n> differ in the beginning, making all of them, at a glance, look the same.\n> I got a headache just trying to figure out how to read them. It might be\n> worth looking into in the future, especially if you decide to show them\n> to the users.\n>\n> Perhaps it's just my git eyes being used to seeing the first 4 chars\n> (which is all I normally look at) being different for each different\n> commit, but having to look up the near-end of the string to find the\n> actual difference in bzr's revids was actually a quite painful experience.\n\nI agree, and new formats for how the revisions should look are being\ndiscussed on the mailinglist right now. It's not set in stone.\n\n/Erik\n\n-- \ngoogle talk/jabber. zindar@gmail.com\nSIP-phones: sip:erik_bagfors@gizmoproject.com\n"},{"id":"298897","messageId":"453F6B7A.60805@op5.se","threadId":"5925","inReplyTo":"20061025094900.GA26989@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-25T13:49:46Z","receivedAt":"2006-10-25T13:49:46Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jeff King wrote:\n> On Wed, Oct 25, 2006 at 02:19:15AM -0700, David Rientjes wrote:\n> \n>> No, my criticism is against the added complexity which makes the \n>> modification of git increasingly difficult with every new release. It's a \n> \n> OK, you seemed to imply problems for end users in your first paragraph,\n> which is what I was responding to.\n> \n>> _current_ needs. For any experienced shell programmer it is so much \n>> easier to go in and change an option or pipe to a different command or \n>> comment out a simple shell command in a .sh file than editing the C code. \n> \n> Yes, it's true that some operations might be easier to play with in the\n> shell. However, does it actually come up that you want to modify\n> existing git programs? The more common usage seems to be gluing the\n> plumbing together in interesting ways, and that is still very much\n> supported.\n> \n\nIndeed. I still use my old git-send-patch script whenever I want to send \npatches, simply because I don't like git-send-email and its defaults \nmuch. The interface hasn't changed one bit since I wrote it. That's \npretty stable, since send-patch was created couple of hours before git.c \nwas submitted to the list, as I wrote the \"send-patch\" script to send \nthe patch that did the rewriting.\n\nI'm personally all for a rewrite of the necessary commands in C \n(\"commit\" comes to mind), but as many others, I have no personal \ninterest in doing the actual work. I'm fairly certain that once we get \nit working natively on windows with some decent performance, windows \nhackers will pick up the ball and write \"wingit\", which will be a log \nviewer and GUI thing for \nfetching/merging/committing/reverting/rebasing/sending patches and \nwhatnot. Possibly it will have hooks to Visual C++ or some other IDE. I \ndon't know how that sort of thing works, but I'm sure someone clever and \nbored enough will want to investigate the possibilities.\n\n\n"},{"id":"294352","messageId":"87slhcz8zh.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"a7e835d40610250308v5d577482m139742e7fe1db185@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-10-25T15:54:42Z","receivedAt":"2006-10-25T15:54:42Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 25 Oct 2006 18:08:22 +0800, \"James Henstridge\" wrote:\n> If there aren't, or you made the merge by mistake, you can make a call\n> to \"bzr revert\" to clean things up without ever having created a new\n> revision.\n\nOne result of this approach is that developers of different trees\ndon't necessarily have common revision IDs to compare. Imagine a\nquestion like:\n\n\tWhen you ran that test did you have the same code I've got?\n\nIn git, the answer would be determined by comparing revision IDs.\n\nIn bzr, the only answer I'm hearing is attempting a merge to see if it\nintroduces any changes. (I'm deliberately avoiding \"pull\" since we're\ntalking about distributed cases here).\n\nAnd to comment on something mentioned earlier in the thread, there's\nno need for \"wildly complex\" distributed scenarios. All of these\nissues are present with developers working together as peers, (and\neach considering their own repository as canonical).\n\nA harder question (for bzr) is:\n\n\tDo you have all of the history I've got?\n\n(The problem being that when one developer is missing some history and\nmerges it in, she necessarily creates new history, so there's never a\nstable point for both sides to agree on.)\n\n-Carl\n"},{"id":"295546","messageId":"Pine.LNX.4.64N.0610250954380.31053@attu2.cs.washington.edu","threadId":"5925","inReplyTo":"20061025094900.GA26989@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"David Rientjes","fromEmail":"rientjes@cs.washington.edu","sentAt":"2006-10-25T17:21:42Z","receivedAt":"2006-10-25T17:21:42Z","isPatch":false,"sender":{"key":"rientjes@cs.washington.edu","avatar":null},"body":"On Wed, 25 Oct 2006, Jeff King wrote:\n\n> Yes, it's true that some operations might be easier to play with in the\n> shell. However, does it actually come up that you want to modify\n> existing git programs? The more common usage seems to be gluing the\n> plumbing together in interesting ways, and that is still very much\n> supported.\n> \n\nYes, it does. I'll give you an example from six months ago: there was a \nneed for the group that I work with to support a faster type of hashing \nfunction for whatever reason. This would have been simple with previous \nversions of git, but if you've ever looked at the SHA1 code in git, you'll \nrealize that you're probably better off never trying to touch it. There \nis absolutely _no_ abstraction of it at all and the code is so deeply \ncoupled in the source that abstracting it away is a pain.\n\nLikewise, there is always room for personal or organizational tweaks on \nthe part of the developer. Things like distributed pulling and \nmerging should actually be pretty simple to implement if the complexity \nwasn't so high in the merge-* family. This is something I implemented \nafter an enormous headache because we were dealing with very large \nprojects: yes, larger than the Linux kernel. And this is _exactly_ where \npiping would help; we have implementations of distributed grep over very \nlarge datasets (on the order of terabytes).\n\n> You can do the same thing in C. In fact, look at how similar\n> git-whatchanged, git-log, and git-diff are.\n> \n\nNo you can't. Making a one line addition, commenting out a line, or \nchanging a simple flag in a shell script is much easier. And like I \nalready said, you can save multiple versions for your common use if you \nwork on a specific project much of the time and change how it operates \ndepending on the needs of that one project so you never need to do it \nagain or you can _distribute_ that shell file to your colleagues so that \neverybody is doing their work via the same method. This makes it so you \ncan just say \"type X, then type Y, then type Z\" and everybody is operating \ntogether without training them on how to use git.\n\n> > This all became very obvious when the tutorials came out on \"how to use \n> > git in 20 commands or less\" effectively. These tutorials shouldn't need \n> > to exist with an information manager that started as a quick, efficient, \n> > and _simple_ project. You're treating git development in the same light \n> \n> Sorry, I don't see how this is related to the programming language _at\n> all_. Are you arguing that the interface of git should be simplified so\n> that such tutorials aren't necessary? If so, then please elaborate, as\n> I'm sure many here would like to hear proposals for improvements. If\n> you're arguing that git now has too many features, then which features\n> do you consider extraneous?\n> \n\nIt's not, it's related to the original vision of git which was meant for \nefficiency and simplicity. A year ago it was very easy to pick up the \npackage and start using it effectively within a couple hours. Keep in \nmind that this was without tutorials, it was just reading man pages. \nToday it would be very difficult to know what the essential commands are \nand how to use them simply to get the job done, unless you use the \ntutorials. This _inherently_ goes against the approach of trying to \nprovide something that is simple to the developer.\n\nRevision control is something that should exist in the background that \ndoes it's simple job very efficiently. Unfortunately git has tried to \nmove its presence into the foreground and requiring developers to spend \nmore time on learning the system.\n\nHave you never tried to show other people git without giving them a \ntutorial on the most common uses? Try it and you'll see the confusion. \nThat _specifically_ illustrates the ever-increasing lack of simplicity \nthat git has acquired.\n\n> I don't agree with this. There are tons of enhancements that I find\n> useful (e.g., '...' rev syntax, rebasing with 3-way merge, etc) that I\n> think other developers ARE using. There are scalability and performance\n> improvements. And there are new things on the way (Junio's pickaxe work)\n> that will hopefully make git even more useful than it already is.\n> \n\nThere are _not_ scalability improvements. There may be some slight \nperformance improvements, but definitely not scalability. If you have \never tried to use git to manage terabytes of data, you will see this \nbecomes very clear. And \"rebasing with 3-way merge\" is not something \noften used in industry anyway if you've followed the more common models \nfor revision control within large companies with thousands of engineers. \nTypically they all work off mainline.\n\n> If you don't think recent git versions are worthwhile, then why don't\n> you run an old version? You can even use git to cherry-pick patches onto\n> your personal branch.\n> \n\nI do. And that's why I would recommend to any serious developer to use \n1.2.4; this same version that I used for kernel development at Google.\n\n> Where?\n> \n\nFew months back here on the mailing list. When I tried cleaning up even \none program, I got the response back from the original author \"why fix a \nnon-problem?\" because his argument was that since it worked the code \ndoesn't matter.\n\n\thttp://marc.theaimsgroup.com/?l=git&m=115589472706036\n\nAnd that is simply one thread of larger conversations that have taken \nplace off-list and aren't archived.\n\n> I don't agree, but since you haven't provided anything specific enough\n> to discuss, there's not much to say.\n> \n\nIf there's a question about some of the sloppiness in the git source code \nas it stands today, that's a much bigger issue than the sloppiness. My \nadvice would be to pick up a copy of K&R's 2nd edition C programming \nlanguage book, read it, and then take a tour of the source code.\n\n> Can you name one customization that you would like to perform now that\n> you feel can't be easily done (and presumably that would have been\n> easier in the past)?\n> \n\nYes, those mentioned above.\n\n"},{"id":"295963","messageId":"453FAFC1.2040801@utoronto.ca","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610231623340.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-25T18:41:05Z","receivedAt":"2006-10-25T18:41:05Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nLinus Torvalds wrote:\n> \n> On Tue, 24 Oct 2006, Erik Bågfors wrote:\n> \n>>I don't see any problem doing a \"gitk --all\" equivalent in bzr.\n> \n> \n> The problem? How do you show a commit that is _common_ to two branches, \n> but has different revision names in them?\n\nIf you're talking about the old-style single-integer revnos, each\nrevision only has one of those, because that revision dictates the path\nyou must take to the origin when determining its revno. Many others may\nshare that revno, but each revision has only one.\n\nThe new-style dotted-series-of-ints revnos, I agree, will change.\nThey're not something I use.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFP6/B0F+nu1YWqI0RAs76AJ9nE4BnL2tLDPQwqjQvCi6okDTdpQCdFQ9V\nGoL1BWO+L2FxjLjRrCjKtuY=\n=yQ6t\n"},{"id":"295977","messageId":"7v4ptsp3yi.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"453F41DE.6090405@op5.se","subject":"Re: VCS comparison table","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-25T19:53:25Z","receivedAt":"2006-10-25T19:53:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> See the attached screenshot. This is from qgit --all on the git\n> repository, but the DAG output is identical to that of gitk. Note in\n> particular the 'pu' and 'next' branches. By scrolling down, I can\n> easily see the branch-point of any of them.\n\nLooking at this picture I noticed the lack of circles or\nrectangles on six commits near the tip of \"pu\" branch. Nobody\nshould be doing an Octopus so it might be a non-issue, but\nsomehow it looks fishy.\n\n"},{"id":"294911","messageId":"20061025210306.GA29550@coredump.intra.peff.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64N.0610250954380.31053@attu2.cs.washington.edu","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-25T21:03:06Z","receivedAt":"2006-10-25T21:03:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 25, 2006 at 10:21:42AM -0700, David Rientjes wrote:\n\n> Yes, it does. I'll give you an example from six months ago: there was a \n\nFirst off, thanks for giving examples. I was having trouble seeing where\nyou were coming from.\n\n> need for the group that I work with to support a faster type of hashing \n> function for whatever reason. This would have been simple with previous \n> versions of git, but if you've ever looked at the SHA1 code in git, you'll \n> realize that you're probably better off never trying to touch it. There \n> is absolutely _no_ abstraction of it at all and the code is so deeply \n> coupled in the source that abstracting it away is a pain.\n\nIs this really an artifact of the C code versus the shell code? A lot of\nparts of the system need to touch SHA1 hashes, and I think it has been\nsprinkled throughout the code from the beginning. In fact, I think the\nlibification of git-rev-list has made the code a lot _cleaner_ (and\nshorter), in that the C programs can all use the same nice interface.\nThe external interface is still there, but now there is consistency\namong programs when using rev syntax (ISTR issues in the distant past\nwhere program X didn't understand syntax because the parsing was all\ndone ad-hoc).\n\n> Likewise, there is always room for personal or organizational tweaks on \n> the part of the developer. Things like distributed pulling and \n> merging should actually be pretty simple to implement if the complexity \n> wasn't so high in the merge-* family. This is something I implemented \n> after an enormous headache because we were dealing with very large \n> projects: yes, larger than the Linux kernel. And this is _exactly_ where \n> piping would help; we have implementations of distributed grep over very \n> large datasets (on the order of terabytes).\n\nI guess I don't see how this was ever any easier. Do you mean that when\nwe called an external grep, it was easier to plug in your distributed\ngrep?\n\n> > You can do the same thing in C. In fact, look at how similar\n> > git-whatchanged, git-log, and git-diff are.\n> No you can't.\n\n\nThe \"same thing\" I referred to was changing behavior trivially based on\nthe program name. So yes, you can.\n\n> Making a one line addition, commenting out a line, or changing a\n> simple flag in a shell script is much easier. And like I already\n\nSure, shell can be easier to modify (though in well-written C, you're\nlikely just commenting out a few lines or a function call -- maybe you\ncan argue whether or not git is well-written). However, I remain\nunconvinced that this is a common use case, or that it is something that\nshould weigh heavily when compared with portability, efficiency, or\nrobustness concerns.\n\n> It's not, it's related to the original vision of git which was meant for \n> efficiency and simplicity.\n\n\nSimplicity is fine if all you want is plumbing. But normal people want\nto _use_ git without hacking their own shell scripts, so it makes sense\nto provide the scripts that other people have hacked together (as shell,\nperl, C, or whatever). Do I want to use git-send-email? Hell no, the\ninterface is terrible to me. But do the plumbing commands still exist so\nthat I can use the scripts I hacked together? Absolutely. I can take\nwhat I want and leave the rest.\n\n> A year ago it was very easy to pick up the package and start using it\n> effectively within a couple hours. Keep in mind that this was without\n\nWas it? The most common complaint I've heard about git, starting a year\nago, was the lack of documentation and tutorials and the complexity of\nuse.\n\n> tutorials, it was just reading man pages. Today it would be very\n> difficult to know what the essential commands are and how to use them\n> simply to get the job done, unless you use the tutorials. This\n\nI think this has been the case for a long time. It's just that there\n_weren't_ tutorials back then.\n\n> Have you never tried to show other people git without giving them a \n> tutorial on the most common uses? Try it and you'll see the confusion. \n> That _specifically_ illustrates the ever-increasing lack of simplicity \n> that git has acquired.\n\nNo, it illustrates a lack of simplicity that currently exists; it says\n_nothing_ about the change in simplicity over time.\n\n> There are _not_ scalability improvements. There may be some slight \n> performance improvements, but definitely not scalability. If you have \n> ever tried to use git to manage terabytes of data, you will see this \n\nThere has been work on scaling to larger repositories (e.g., mozilla and\nxorg prompting work/discussion on cvs importing, subproject/superproject\nsupport, shallow clones, etc), but not on terabyte scales. I realize\nthat might not help you, but it is helping a lot of people. Quite\nhonestly, git is focused on SOURCE CODE MANAGEMENT, not terabytes of\ndata. Perhaps that is your true complaint: git is developing tools for\nworking with source code, potentially at the loss of some generality\n(though I tend to think it hasn't lost generality, but rather it hasn't\ngained).\n\n> becomes very clear. And \"rebasing with 3-way merge\" is not something \n> often used in industry anyway if you've followed the more common models \n> for revision control within large companies with thousands of engineers. \n> Typically they all work off mainline.\n\nMy point isn't that every feature is useful to every developer. My point\nis that just because features aren't useful to _you_ doesn't mean\nthey're not useful at all.\n\nAnd if you want to talk about industry standard, didn't the discussion\nstart off with your complaint about porting to Windows? An\nindustry-standard SCM needs to be cross-platform across the major\noperating systems.\n\n> Few months back here on the mailing list. When I tried cleaning up even \n> one program, I got the response back from the original author \"why fix a \n> non-problem?\" because his argument was that since it worked the code \n> doesn't matter.\n\nI remember a big discussion about the order of arguments in relational\nexpressions. Git may have problems, but I just don't see coding style\nnitpicks as a priority.\n\nAbstracting the hashing might be worthwhile, but the list consensus was\nthat it's not worth the work unless we're actually going to _do_\nsomething with the abstraction. Your argument seems to be that you\n_are_ doing something with the abstraction on your own. If you want to\nconvince the git developers that this is a worthwhile direction, then\nshow some code which uses it.\n\n> \thttp://marc.theaimsgroup.com/?l=git&m=115589472706036\n\nOK, I remember this particular discussion. And I just read through to\nthe end of the thread; it looks like Junio ended up with \"this code is\nugly; fix it\" and Johannes did.\n\nIt sounds like your real beef was that you want to use some alternate\n\"mv\" command that handles your data set better, and having git-mv as a\nshell-script would make that simpler for you. Well, it isn't a shell\nscript and it never was. If you want to write it as one, I imagine it\nwould be considered for inclusion (though I expect the C version may\nhave some advantages, such as atomicity of file movement and index\nupdating).\n\n"},{"id":"298898","messageId":"7v3b9cnlx7.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"20061025084810.GA26618@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-25T21:08:20Z","receivedAt":"2006-10-25T21:08:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Oct 24, 2006 at 01:12:52PM -0700, David Rientjes wrote:\n>\n>> And I would prefer the opposite because we're talking about git. As an \n>> information manager, it should be seen and not heard. Nobody is going to \n>> spend their time to become a git or CVS or perforce expert. As an \n>> individual primarily interested in development, I should not be required \n>> to learn command lines for dozens of different git-specific commands to do \n>> my job quickly and effectively. I would opt for a much more simpler \n>> approach and deal with shell scripting for many of these commands because \n>> I'm familiar with them and I can pipe any command with the options I \n>> already know and have used before to any other command.\n>\n> I don't understand how converting shell scripts to C has any impact\n> whatsoever on the usage of git. The plumbing shell scripts didn't go\n> away; you can still call them and they behave identically.\n>\n> Is there some specific change in functionality that you're lamenting?\n\nThat's also I wondered, but I also can understand where David is\ncoming from, and I agree with him to a certain degree.\n\nWhen I learned git, I learned a lot from trying to piece my own\nplumbing together, since there weren't much Porcelain to speak\nof back then. Then we had many usability enhancements before\nthe 1.0 release to add Porcelainish done as shell scripts.\n\nThis had two positive effects, aside from adding usability.\nInterested people had more shell scripts to learn from. The\nscripts were easy to adjust to feature requests from the list,\nand as we learned from user experience based on these scripts it\nwas definitely quicker to codify the best current practice\nworkflow in them than if they were written in C. It would have\ntaken us a lot more effort to add \"git commit -o paths\" vs \"git\ncommit -i paths\" if it were already converted to C, for example.\nThis continued and our Porcelainish scripts matured quickly.\n\nThen 1.3 series started to move some of the mature ones into C.\nAs many people already have pointed out, being written in C and\nnot doing pipe() has two advantages (better portability to\nplatforms with awkward pipe support and one less process usually\nmean better performance). git-log family with path limiting had\na real boost in performance because the path limiting can be\ndone in the revision traversal side not diff-tree that used to\nbe on the downstream side of the pipe. So this in overall was a\nright thing to do.\n\nOne thing we lost during the process, however, is a ready access\nto the pool of \"sample scripts\" when people would want to\nscratch their own itches. Linus's original tutorial talked\nabout \"this pattern of pipe is so useful that we have a three\nliner shell script wrapper that is called git-foo\", and\ninterested people can easily look at how the plumbing commands\nfit together.\n\nThe plumbing is still there, and I and people who already know\ngit would still script around git-rev-list when we need to (by\nthe way, scripting around git-log is a wrong thing to do -- it\nis for human consumption and scripting should be done with\nplumbing). But when we rewrote mature ones in C (and I keep\nstressing \"mature\" because another thing I agree with David is\nthat shell is definitely easier to futz with), we did not leave\nthe older shell implementation around as reference. People\ncoming to git after 1.3 series certainly do have harder time to\nlearn how plumbing would fit together than when git old-timers\nlearned it, if that is the area they are interested in, as\nopposed to just using git as a revision tracking system.\n\nWe could probably do two things to address this issue:\n\n - Create examples/ hierarchy in the source tree to house these\n historical implementations as a reference material, or an\n entirely different branch or repository to house them.\n\n - Learn the itches David and other people have, that the\n current git Porcelain-ish does not scratch well, and enrich\n Documentation/technical with real-world working scripts built\n around plumbing.\n\n\n\n\n\n"},{"id":"295968","messageId":"20061025211618.GA30121@coredump.intra.peff.net","threadId":"5925","inReplyTo":"7v3b9cnlx7.fsf@assigned-by-dhcp.cox.net","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-25T21:16:18Z","receivedAt":"2006-10-25T21:16:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 25, 2006 at 02:08:20PM -0700, Junio C Hamano wrote:\n\n> the older shell implementation around as reference. People\n> coming to git after 1.3 series certainly do have harder time to\n> learn how plumbing would fit together than when git old-timers\n> learned it, if that is the area they are interested in, as\n> opposed to just using git as a revision tracking system.\n\nI think this is part of the complication of discussion I'm having with\nDavid. There are really two sets of users for git: people who want to\nhack scripts based on plumbing, and people who want everything to \"just\nwork.\" I think it's a good point that as the system matures (movement\nto C and growth of complexity), it might become less easy to hack.\n\n> - Create examples/ hierarchy in the source tree to house these\n> historical implementations as a reference material, or an\n> entirely different branch or repository to house them.\n\nHousing historical implementations seems like it would just lead to\nout-of-date and non-functional examples.\n\n> - Learn the itches David and other people have, that the\n> current git Porcelain-ish does not scratch well, and enrich\n> Documentation/technical with real-world working scripts built\n> around plumbing.\n\nI think this is a better approach. I think it also makes sense to\nlet people know that it's an acceptable approach to start new features\nas shell and then have them mature to C (looking at the current\ncodebase, and some of Dscho's rantings, one might get the impression\nthat git isn't accepting new shell scripts).\n\n"},{"id":"294555","messageId":"7vslhcm682.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"20061025211618.GA30121@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-25T21:32:45Z","receivedAt":"2006-10-25T21:32:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Housing historical implementations seems like it would just lead to\n> out-of-date and non-functional examples.\n\nI agree. Although that ought to be rare in principle, given\nthat one advertised feature of git is that the plumbing is\nsupposed to be stable, we occasionally had to have to subtly\nbreak things to improve plumbing and at the same time run around\nto make sure that all the script users (both in-tree and\nout-of-tree like Cogito, gitweb and StGIT) are updated.\n\n>> - Learn the itches David and other people have, that the\n>> current git Porcelain-ish does not scratch well, and enrich\n>> Documentation/technical with real-world working scripts built\n>> around plumbing.\n>\n> I think this is a better approach. I think it also makes sense to\n> let people know that it's an acceptable approach to start new features\n> as shell and then have them mature to C (looking at the current\n> codebase, and some of Dscho's rantings, one might get the impression\n> that git isn't accepting new shell scripts).\n\nNew commands like pickaxe and for-each-ref were easier to code\nin C, and cherry rewrite in C was really about how crufty the\nshell script version was from the beginning (and there weren't\nin-tree users of it left so it was not maintained at all but\nthanks to plumbing being stable it just kept working perhaps\ncorrectly but still horribly).\n"},{"id":"294718","messageId":"7viri8m5ea.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"7v3b9cnlx7.fsf@assigned-by-dhcp.cox.net","subject":"Re: VCS comparison table","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-25T21:50:37Z","receivedAt":"2006-10-25T21:50:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> - Learn the itches David and other people have, that the\n> current git Porcelain-ish does not scratch well, and enrich\n> Documentation/technical with real-world working scripts built\n> around plumbing.\n\nI meant \"Documentation/howto\"; sorry for the noise.\n"},{"id":"296164","messageId":"Pine.LNX.4.63.0610251450040.1754@qynat.qvtvafvgr.pbz","threadId":"5925","inReplyTo":"453F6B7A.60805@op5.se","subject":"Re: VCS comparison table","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-10-25T21:51:30Z","receivedAt":"2006-10-25T21:51:30Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"a quick lesson on program nameing\n\nOn Wed, 25 Oct 2006, Andreas Ericsson wrote:\n\n> I'm personally all for a rewrite of the necessary commands in C (\"commit\" \n> comes to mind), but as many others, I have no personal interest in doing the \n> actual work. I'm fairly certain that once we get it working natively on \n> windows with some decent performance, windows hackers will pick up the ball \n> and write \"wingit\", which will be a log viewer and GUI thing for\n ^^^^^^\n\nhow many other people read this as 'wing it' rather then 'win git'? ;-)\n\nDavid Lang\n"},{"id":"295128","messageId":"20061025221531.GB10140@spearce.org","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610251450040.1754@qynat.qvtvafvgr.pbz","subject":"Re: VCS comparison table","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-25T22:15:31Z","receivedAt":"2006-10-25T22:15:31Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"David Lang wrote:\n> a quick lesson on program nameing\n> \n> On Wed, 25 Oct 2006, Andreas Ericsson wrote:\n> \n> >I'm personally all for a rewrite of the necessary commands in C (\"commit\" \n> >comes to mind), but as many others, I have no personal interest in doing \n> >the actual work. I'm fairly certain that once we get it working natively \n> >on windows with some decent performance, windows hackers will pick up the \n> >ball and write \"wingit\", which will be a log viewer and GUI thing for\n> ^^^^^^\n> \n> how many other people read this as 'wing it' rather then 'win git'? ;-)\n\nYes, that's certainly a less than optimal name...\n\nWhat about gitk? Is it \"gi tk\" or \"git k\" ? This has actually\nbeen the source of much local debate. :-)\n\n-- \n"},{"id":"294534","messageId":"ehooeo$1g6$2@sea.gmane.org","threadId":"5925","inReplyTo":"20061025221531.GB10140@spearce.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-25T22:29:17Z","receivedAt":"2006-10-25T22:29:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Shawn Pearce wrote:\n\n> David Lang wrote:\n>> a quick lesson on program nameing\n>> \n>> On Wed, 25 Oct 2006, Andreas Ericsson wrote:\n>> \n>> >I'm personally all for a rewrite of the necessary commands in C (\"commit\" \n>> >comes to mind), but as many others, I have no personal interest in doing \n>> >the actual work. I'm fairly certain that once we get it working natively \n>> >on windows with some decent performance, windows hackers will pick up the \n>> >ball and write \"wingit\", which will be a log viewer and GUI thing for\n>> ^^^^^^\n>> \n>> how many other people read this as 'wing it' rather then 'win git'? ;-)\n> \n> Yes, that's certainly a less than optimal name...\n> \n> What about gitk? Is it \"gi tk\" or \"git k\" ? This has actually\n> been the source of much local debate. :-)\n\nYou can always use CamelCase, i.e. WinGit or WinGIT (or wgit,\nbut this is also silly).\n\nCute names are taken: CoGITo, gitk, qgit (GTK+ history viewer is gitview,\nnot ggit, curiously ;-) and tig.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296567","messageId":"Pine.LNX.4.63.0610251459160.1754@qynat.qvtvafvgr.pbz","threadId":"5925","inReplyTo":"20061025002713.GN17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-10-25T22:40:00Z","receivedAt":"2006-10-25T22:40:00Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Tue, 24 Oct 2006, Matthew D. Fuller wrote:\n\n> On Tue, Oct 24, 2006 at 11:03:20AM -0700 I heard the voice of\n> David Lang, and lo! it spake thus:\n>>\n>> it sounded like you were saying that the way to get the slices of\n>> the DAG was to use branches in bzr. [...]\n>\n> I'm not entirely sure I understand what you mean here, but I think\n> you're saying \"Nobody's written the code in bzr to show arbitrary\n> slices of the DAG\", which is true TTBOMK.\n\nI think we are talking past each other here.\n\nwhat I think was said was\n\nG 'one feature of git is that you can view arbatrary slices trivially'\n\nB 'bzr can do this too, you just use branches to define the slices'\n\nG 'but this limits you becouse branches are defined as code is developed, git \nlets you define slices at viewing time'\n\nby the way, I think it's more then just saying 'well, the code could be written \nto do this in $VCS' some decisions and standard ways of doing things can impact \nhow hard it is to implement a feature, and some decisions can make it \nimpossible (without doing unexpected things).\n\n>\n>> everyone agrees that bzr supports the Star topology. Most people\n>> (including bzr people) seem to agree that currently bzr does not\n>> support the Distributed topology.\n>\n> I think this statement arouses so much grumbling because (a) bzr does\n> support such a lot better than often seems implied, (b) where it\n> doesn't, the changes needed to do so are relatively minor (often\n> merely cosmetic), and (c) disagreement over whether some of the\n> qualifications included for 'distributed' are really fundamental.\n>\n>\n>> it's just fine for bzr to not support all possible topologies,\n>\n> I think there's a real intent for bzr TO support at least all common\n> topologies. I'll buy that current development has focused more on\n> [relatively] simple topologies than the more wildly complex ones. I\n> look forward to more addressing of the less common cases as the tool\n> matures, and I think a lot of this thread will be good material to\n> work with as that happens. It's just the suggestion that providing\n> fruit for simple topologies _necessarily_ prejudices against complex\n> ones that I find so onerous.\n\none concern that the git people are voicing is that the things that work for \nsimple topologies (revno's) can't be used with the more complex ones (where you \nneed the refid's). especially the fact that users need to do things \nsignificantly different when there are fairly subtle changes to the topology.\n\nthe scenerio that came up elsewhere today where you have\n\n Master\n / \\\ndev1 dev2\n\nand then dev1 and dev2 both start working on the same thing (without knowing \nit), then discover they are working on the same thing. they now have threeB \noptions\n\n1. merge their stuff up to the master so that they can both pull it down.\n but this puts broken, experimental stuff up in the master\n\n2. declare one of the dev trees to be the master\n\nthis changes the topology to\n\nMaster--dev1--dev2\n\n3. pull from each other frequently to keep in sync.\n\nthis changes the topology to\n\n Master\n / \\\ndev1--dev2\n\nif they do this with bzr then the revno's break, they each get extra commits \nshowing up (so they can never show the same history).\n\nin git this is a non-issue, they can pull back and forth and the only new \nhistory to show up will be changes.\n\nthis is the situation that the kernel developers are in frequently. it sounds as \nif you haven't needed to do this yet, so you haven't encountered the problems.\n\nDavid Lang\n"},{"id":"298512","messageId":"Pine.LNX.4.63.0610251540340.1754@qynat.qvtvafvgr.pbz","threadId":"5925","inReplyTo":"20061025221531.GB10140@spearce.org","subject":"Re: VCS comparison table","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-10-25T22:41:24Z","receivedAt":"2006-10-25T22:41:24Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Wed, 25 Oct 2006, Shawn Pearce wrote:\n\n> David Lang wrote:\n>> a quick lesson on program nameing\n>>\n>> On Wed, 25 Oct 2006, Andreas Ericsson wrote:\n>>\n>>> I'm personally all for a rewrite of the necessary commands in C (\"commit\"\n>>> comes to mind), but as many others, I have no personal interest in doing\n>>> the actual work. I'm fairly certain that once we get it working natively\n>>> on windows with some decent performance, windows hackers will pick up the\n>>> ball and write \"wingit\", which will be a log viewer and GUI thing for\n>> ^^^^^^\n>>\n>> how many other people read this as 'wing it' rather then 'win git'? ;-)\n>\n> Yes, that's certainly a less than optimal name...\n>\n> What about gitk? Is it \"gi tk\" or \"git k\" ? This has actually\n> been the source of much local debate. :-)\n\nin this case I think it's both, (or technicaly git tk with the double t's \ncombined to save typeing)\n\n"},{"id":"296481","messageId":"20061025224428.GN20017@pasky.or.cz","threadId":"5925","inReplyTo":"ehooeo$1g6$2@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-25T22:44:28Z","receivedAt":"2006-10-25T22:44:28Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Oct 26, 2006 at 12:29:17AM CEST, I got a letter\nwhere Jakub Narebski said that...\n> Cute names are taken: CoGITo, gitk, qgit (GTK+ history viewer is gitview,\n> not ggit, curiously ;-) and tig.\n\nwit?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Dear diary, on Thu, Oct 26, 2006 at 12:29:17AM CEST, I got a letter\n> where Jakub Narebski said that...\n>> Cute names are taken: CoGITo, gitk, qgit (GTK+ history viewer is gitview,\n>> not ggit, curiously ;-) and tig.\n> \n> wit?\n\nTaken.\n\nwit ? a Python web interface to git maintained by Christian Meder.\nExample site on http://www.grmso.net:8090/ . It uses PATH_INFO\nmuch more than gitweb (which uses CGI parameters mostly, but also\nsupports multiple projects).\n\nWell, not maintained if http://www.absolutegiganten.org/wit/\nis indicator\n\n wit-0.0.4.tar.gz 08-Sep-2005\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"293800","messageId":"20061025235306.GD17019@over-yonder.net","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610251459160.1754@qynat.qvtvafvgr.pbz","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-25T23:53:06Z","receivedAt":"2006-10-25T23:53:06Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Wed, Oct 25, 2006 at 03:40:00PM -0700 I heard the voice of\nDavid Lang, and lo! it spake thus:\n> \n> I think we are talking past each other here.\n> \n> what I think was said was\n> \n> G 'one feature of git is that you can view arbatrary slices\n> trivially'\n> \n> B 'bzr can do this too, you just use branches to define the slices'\n\nAh. This is more like \"bzr [mostly] only does this now in terms of a\nsingle branch (or some point back along it)\". The slices that go\nbetween branches are very limited ('missing' gives you one view;\n'branch:' and 'ancestor:' revision specifications give you another).\nbzrk/'visualize' gives an interface similar to gitk, but also only in\nthe context of a single branch/head looking backward through its\nprevious tree AFAIK. Any random DAG-slicing of what you have in the\nrevision store can be done, somebody would just have to write the code\nfor it. Nothing about 'the workflow preserves parents' would make\nthat any harder than writing the code for git was.\n\nMuch of this is probably a result of the 'branch'-centric (rather than\n'repository'-centric) view of the world; similarly to the fact that\nbranches are referred to by location (local ../otherbranch, or remote\nhttp/sftp/etc) rather than by a name. This is one of the bits of bzr\nI'm personally somewhat ambivalent about.\n\n\n> they now have threeB options\n\nThose certainly aren't the only choices, but to stay OT:\n\n> 3. pull from each other frequently to keep in sync.\n> \n> this changes the topology to\n> \n> Master\n> / \\\n> dev1--dev2\n> \n> if they do this with bzr then the revno's break, they each get extra\n> commits showing up (so they can never show the same history).\n\nThese two are either/or, not and; either they pull (in which case\ntheir old mainline is no longer meaningful), or they merge (in which\ncase they get the 'extra' merge commits).\n\n\n> in git this is a non-issue, they can pull back and forth and the\n> only new history to show up will be changes.\n\nIn git, this is a non-issue because you don't get to CHOOSE which way\nto work. You always (if you can) pull and obliterate your local\nmainline. In bzr, it's only an 'issue' because you CAN choose, and\nCAN maintain your local mainline. You CAN choose, right now, to do a\ngit and pull back and forth and only new history show up as changed by\ncreating a 'bzr-pull' shell script that does a 'bzr pull || bzr merge'\n(though you'd be a lot better off adding a '--fast-forward-if-you-can'\noption to merge and aliasing that over).\n\nMore basically, though, I don't think that \"histories become exactly\nequivalent\" is a necessary pass-word to enter the Hallowed City of\nTruely Distributed Development. And I certainly see no reason to\nbelieve we'll agree on it this time any more than We (in broad) have\nthe last 6 times it came up in the thread.\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n"},{"id":"294831","messageId":"Pine.LNX.4.64.0610251912220.3962@g5.osdl.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64N.0610232336010.30334@attu2.cs.washington.edu","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-26T02:29:05Z","receivedAt":"2006-10-26T02:29:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 23 Oct 2006, David Rientjes wrote:\n> \n> Some of the internal commands that have been coded in C are actually much \n> better handled by the shell in the first place.\n\nOthers have answered this, but the thing is, it was a _wonderful_ way to \nprototype things, and to add obvious (and nice) early UI issues that made \ngit much more usable.\n\nBut no, things are not better handled in shell.\n\nShell tends to make some things really _hard_ to do. A fair chunk of the \nrewrite was because core functionality made things easier. For example, \nthe whole internal revision partsing library is really actually a lot more \ncapable than we could easily expose as a simple pipeline: the original \n\"git log\" pipeline worked very well, and you can actually still use those \nkinds of pipelines for a lot of work, but at the same time, some things \nreally just work better when you have \"deeper\" interfaces.\n\nFor example, the revision parsing library not only makes \"git log\" trivial \nas C, it's also needed for an efficient \"git annotate/blame/pickaxe\" kind \nof thing. There are also things that are just ludicrously hard to do in \nshell-script, like exclusive and atomic file operations.\n\nWe used perl and python for some things, but finding people who know them \ntends to be problematic, and python in particular was also a dependency \nproblem too, so the fact that the default recursive merge was python \nwasn't wonderful.\n\nSo I think the shell-scripts are great (and some of them quite likely will \nremain around for the forseeable future) for prototyping, but for core \nfunctionality they were not wonderful. \n\nThey are sometimes good examples of how powerful a scripting language git \ncan be, though. Scripting is still very important, even though a lot of \nthe core stuff doesn't necessarily depend on being scripts itself. \n\nBut error handling in scripting is very hard or inconvenient, especially \nin pipelines. So some things were actively problematic (ie \"git-rev-list \n--all --objects | git-pack-objects\") and moving it to use the internal \nlibrary interface was simply technically the right thing to do.\n\nOthers had real performance issues, eg the new merge in C is a lot faster. \nIt was fast before, it's much faster still.\n\n"},{"id":"295327","messageId":"a7e835d40610260152k658aeaf0hb900cb63870c04e4@mail.gmail.com","threadId":"5925","inReplyTo":"87slhcz8zh.wl%cworth@cworth.org","subject":"Re: VCS comparison table","fromName":"James Henstridge","fromEmail":"james@jamesh.id.au","sentAt":"2006-10-26T08:52:39Z","receivedAt":"2006-10-26T08:52:39Z","isPatch":false,"sender":{"key":"james@jamesh.id.au","avatar":"https://gravatar.com/avatar/3007d1d261c8d1edc4e388f53ea5e53ab40fd5f8334748472ba0e2037b76e4aa?d=mp&s=160"},"body":"On 25/10/06, Carl Worth wrote:\n> On Wed, 25 Oct 2006 18:08:22 +0800, \"James Henstridge\" wrote:\n> > If there aren't, or you made the merge by mistake, you can make a call\n> > to \"bzr revert\" to clean things up without ever having created a new\n> > revision.\n>\n> One result of this approach is that developers of different trees\n> don't necessarily have common revision IDs to compare. Imagine a\n> question like:\n>\n> When you ran that test did you have the same code I've got?\n>\n> In git, the answer would be determined by comparing revision IDs.\n\nCan you really just rely on equal revision IDs meaning you have the\nsame code though?\n\nLets say that I clone your git repository, and then we both merge the\nsame diverged branch. Will our head revision IDs match? From a quick\nlook at the logs of cairo, it seems that the commits generated for\nsuch a merge include the date and author, so the two commits would\nhave different SHA1 sums (and hence different revision IDs).\n\nSo I'd have a revision you don't have and vice versa, even though the\ntrees are identical.\n\n\n> In bzr, the only answer I'm hearing is attempting a merge to see if it\n> introduces any changes. (I'm deliberately avoiding \"pull\" since we're\n> talking about distributed cases here).\n\nOr run \"bzr missing\". If the sole missing revision is a merge (and\nnot the revisions introduced by the merge), you could assume that you\nhave the same tree state.\n\n\n> And to comment on something mentioned earlier in the thread, there's\n> no need for \"wildly complex\" distributed scenarios. All of these\n> issues are present with developers working together as peers, (and\n> each considering their own repository as canonical).\n>\n> A harder question (for bzr) is:\n>\n> Do you have all of the history I've got?\n>\n> (The problem being that when one developer is missing some history and\n> merges it in, she necessarily creates new history, so there's never a\n> stable point for both sides to agree on.)\n\nWhy does it matter if they create a new revision? They can still tell\nif they've got all the history you had.\n\n"},{"id":"294130","messageId":"7vu01ro20b.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"a7e835d40610260152k658aeaf0hb900cb63870c04e4@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-26T09:33:08Z","receivedAt":"2006-10-26T09:33:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"James Henstridge\" writes:\n\n> Can you really just rely on equal revision IDs meaning you have the\n> same code though?\n\nIf you two have the same commit that is a guarantee that you two\nhave identical trees. The reverse is not true as logic 101\nwould teach ;-).\n\nDoing fast-forward instead of doing a \"useless\" merges helps\nsomewhat but not in cases like two people merging the same\nbranches the same way or two people applying the same patch on\ntop of the same commit. You need to compare tree object IDs for\nthat.\n\n>> In bzr, the only answer I'm hearing is attempting a merge to see if it\n>> introduces any changes. (I'm deliberately avoiding \"pull\" since we're\n>> talking about distributed cases here).\n>\n> Or run \"bzr missing\". If the sole missing revision is a merge (and\n> not the revisions introduced by the merge), you could assume that you\n> have the same tree state.\n\nIs it \"you could assume\" or \"it is guaranteed\"? If former, what\nkind of corner cases could invalidate that assumption?\n\n"},{"id":"295218","messageId":"454084EE.90006@op5.se","threadId":"5925","inReplyTo":"a7e835d40610260152k658aeaf0hb900cb63870c04e4@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-26T09:50:38Z","receivedAt":"2006-10-26T09:50:38Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"James Henstridge wrote:\n> On 25/10/06, Carl Worth wrote:\n>> On Wed, 25 Oct 2006 18:08:22 +0800, \"James Henstridge\" wrote:\n>> > If there aren't, or you made the merge by mistake, you can make a call\n>> > to \"bzr revert\" to clean things up without ever having created a new\n>> > revision.\n>>\n>> One result of this approach is that developers of different trees\n>> don't necessarily have common revision IDs to compare. Imagine a\n>> question like:\n>>\n>> When you ran that test did you have the same code I've got?\n>>\n>> In git, the answer would be determined by comparing revision IDs.\n> \n> Can you really just rely on equal revision IDs meaning you have the\n> same code though?\n> \n\nYes. Because each commit contains parent revision id's, which in turn \ncontain *their* parent revision id's, which in turn..., you know you \nhave exactly the same revision, code, and history leading up to that \nrevision. You may have other revisions on top or on other branches, but \nall commits, including merge-points and whatnot, leading to that \nparticular revision id are EXACTLY identical.\n\n> Lets say that I clone your git repository, and then we both merge the\n> same diverged branch. Will our head revision IDs match? From a quick\n> look at the logs of cairo, it seems that the commits generated for\n> such a merge include the date and author, so the two commits would\n> have different SHA1 sums (and hence different revision IDs).\n> \n> So I'd have a revision you don't have and vice versa, even though the\n> trees are identical.\n> \n\nMerges preserve author and commit info. You may need to create a new \nbranch (a git branch, the cheap kind which is a 41-byte file) and fetch \n\"his\" into \"yours\". This will be very cheap if you both have the same \ncode but not the same history, as everything but a few commit-objects \nwill be shared. A more likely scenario though is this;\n\nBob writes a feature that doesn't work as per spec. He doesn't know why.\nHe asks Alice to have a look, so he communicates the commits to her by \n\"please pull this branch from here\", or by sending patches and telling \nAlice the branch-point revision to apply them to.\nAlice creates the \"bobs-bugs/nr1232\" at the branch-point and fetches \nBobs branch into that or applies the patches on top of that (in the \nfetch scenario she wouldn't need to know the branch point, since git \nwould figure this out for her).\nShe knows this should create a revision named 00123989aaddeddad39, so if \nit doesn't, she doesn't have the same code.\n\n\nI imagine this works roughly the same in bazaar, although the original \ncase where tests have already been done and the testers wanted to know \nif they had the exact same revision Just Works in git.\n\n> \n>> In bzr, the only answer I'm hearing is attempting a merge to see if it\n>> introduces any changes. (I'm deliberately avoiding \"pull\" since we're\n>> talking about distributed cases here).\n> \n> Or run \"bzr missing\". If the sole missing revision is a merge (and\n> not the revisions introduced by the merge), you could assume that you\n> have the same tree state.\n> \n\n\"assume\" != \"know\", or was that just sloppy phrasing?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"298197","messageId":"a7e835d40610260257r5f05ea4gc934f1c1cc267977@mail.gmail.com","threadId":"5925","inReplyTo":"7vu01ro20b.fsf@assigned-by-dhcp.cox.net","subject":"Re: VCS comparison table","fromName":"James Henstridge","fromEmail":"james@jamesh.id.au","sentAt":"2006-10-26T09:57:20Z","receivedAt":"2006-10-26T09:57:20Z","isPatch":false,"sender":{"key":"james@jamesh.id.au","avatar":"https://gravatar.com/avatar/3007d1d261c8d1edc4e388f53ea5e53ab40fd5f8334748472ba0e2037b76e4aa?d=mp&s=160"},"body":"On 26/10/06, Junio C Hamano wrote:\n> \"James Henstridge\" writes:\n>\n> > Can you really just rely on equal revision IDs meaning you have the\n> > same code though?\n>\n> If you two have the same commit that is a guarantee that you two\n> have identical trees. The reverse is not true as logic 101\n> would teach ;-).\n\nThat was the point I was trying to make. Carl asserted that in git\nyou could tell if you had the same tree as someone else based on\nrevision IDs, which doesn't seem to be the case all the time.\n\nThe reverse assertion (that if you have the same revision ID, you have\nthe same tree) seems to hold equally in git and Bazaar.\n\n\n> Doing fast-forward instead of doing a \"useless\" merges helps\n> somewhat but not in cases like two people merging the same\n> branches the same way or two people applying the same patch on\n> top of the same commit. You need to compare tree object IDs for\n> that.\n\nSure, you can do the same in Bazaar by comparing the inventories for\nthe two revisions.\n\n>\n> >> In bzr, the only answer I'm hearing is attempting a merge to see if it\n> >> introduces any changes. (I'm deliberately avoiding \"pull\" since we're\n> >> talking about distributed cases here).\n> >\n> > Or run \"bzr missing\". If the sole missing revision is a merge (and\n> > not the revisions introduced by the merge), you could assume that you\n> > have the same tree state.\n>\n> Is it \"you could assume\" or \"it is guaranteed\"? If former, what\n> kind of corner cases could invalidate that assumption?\n\nThe merge revision will also include any manual conflict resolution.\nIf the other person resolved the conflicts differently.\n\n"},{"id":"294480","messageId":"20061026101038.GA13310@coredump.intra.peff.net","threadId":"5925","inReplyTo":"a7e835d40610260257r5f05ea4gc934f1c1cc267977@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-26T10:10:38Z","receivedAt":"2006-10-26T10:10:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 26, 2006 at 05:57:20PM +0800, James Henstridge wrote:\n\n> >If you two have the same commit that is a guarantee that you two\n> >have identical trees. The reverse is not true as logic 101\n> >would teach ;-).\n> \n> That was the point I was trying to make. Carl asserted that in git\n> you could tell if you had the same tree as someone else based on\n> revision IDs, which doesn't seem to be the case all the time.\n\nIf you have the same revision (commit IDs), you have the same tree (at\nthe same time, by the same committer, etc).\n\nIf you have a different revision (commit), you may or may not have the\nsame tree. You can then check the tree id, which will either be the same\n(you have the same tree) or differ (you don't).\n\nThus, in the converse, if you have the same tree, you _will_ have the\nsame tree id. You may or may not have the same commit id.\n\n"},{"id":"298913","messageId":"45408A53.10400@op5.se","threadId":"5925","inReplyTo":"20061025235306.GD17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-26T10:13:39Z","receivedAt":"2006-10-26T10:13:39Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthew D. Fuller wrote:\n> \n>> 3. pull from each other frequently to keep in sync.\n>>\n>> this changes the topology to\n>>\n>> Master\n>> / \\\n>> dev1--dev2\n>>\n>> if they do this with bzr then the revno's break, they each get extra\n>> commits showing up (so they can never show the same history).\n> \n> These two are either/or, not and; either they pull (in which case\n> their old mainline is no longer meaningful), or they merge (in which\n> case they get the 'extra' merge commits).\n> \n> \n>> in git this is a non-issue, they can pull back and forth and the\n>> only new history to show up will be changes.\n> \n> In git, this is a non-issue because you don't get to CHOOSE which way\n> to work.\n\nYes they do. They can (and in this case probably will) create a \ntopic-branch named \"the-other-dev/featureX\" and keep it solely for \ntracking the other peers changes, keeping their own topic-branch for \ntheir own changes, and another branch where they merge both changes in, \nor cherry-pick from each branch to get to the desired result fast. This \nworks easily because in git\na) branches are as cheap as I can ever imagine an SCM making them.\nb) the \"slice the DAG and view anything you like from any branch you \nlike any time you like and mix them however you want\" approach of the \nvisualizers makes it trivial for a 10-year old fledgling programmer to \nsee what changes what, and where, and by whom, and why.\n\nThe \"b\" above was a feature I didn't know I needed until it became \navailable to me. Thanks to Paul Mackerras (spelling?) for creating the \nwonderful gitk tool, and to Marco Costalba for making a faster and, imo, \nmore capable version of it.\n\n> You always (if you can) pull and obliterate your local\n> mainline. In bzr, it's only an 'issue' because you CAN choose, and\n> CAN maintain your local mainline.\n\nGit puts emphasis on code. Bazaar puts emphasis on developers and \nbranch-structure. Depending on your preferrence, I imagine one suits \nsome people better. I really, really, really don't care if my branch-tip \ngets moved because I hadn't made any changes to it while the other dev \nhacked away or if it causes a merge because we had decided to work on \ndifferent parts of the feature. Perhaps this is a result of the insanely \ngood visualizers (kudos again to Paul and Marco) that easily lets me see \nwho did what when and where anyways. What I *do* care about is being \nable to easily make sure all the devs have the same code to work and \ntest with.\n\n> You CAN choose, right now, to do a\n> git and pull back and forth and only new history show up as changed by\n> creating a 'bzr-pull' shell script that does a 'bzr pull || bzr merge'\n> (though you'd be a lot better off adding a '--fast-forward-if-you-can'\n> option to merge and aliasing that over).\n> \n> More basically, though, I don't think that \"histories become exactly\n> equivalent\" is a necessary pass-word to enter the Hallowed City of\n> Truely Distributed Development.\n\nThe only issue I have with bzr's revno's and truly distributed setup is \nthat, by looking at the table, it seems to claim that you have found \nsome miraculous way to make revnos work without a central server. Since \neveryone agrees that they don't, this should IMO be listed as mutually \nexclusive features.\n\nOn a side-note, git has made my life easier, so I childishly want to \ndefend it and see it on top of every list in the world. Something I'm \nsure I share with more people on this list and with some of the bazaar \nusers/devs. ;-)\n\n\n"},{"id":"295178","messageId":"845b6e870610260345l7d36bf56j85d49e9a09ee2760@mail.gmail.com","threadId":"5925","inReplyTo":"45408A53.10400@op5.se","subject":"Re: VCS comparison table","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-10-26T10:45:43Z","receivedAt":"2006-10-26T10:45:43Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"> On a side-note, git has made my life easier, so I childishly want to\n> defend it and see it on top of every list in the world. Something I'm\n> sure I share with more people on this list and with some of the bazaar\n> users/devs. ;-)\n\nHaha, I feel the same way about bzr. Some of the features that bazaar\nhas, such as how it preservs the leftmost parent and treats that\nspecially in some cases, are things that I REALLY love and don't want\nto live without.\n\nAll in all, I feel that git and bazaar and both excellent products,\nwhat will happen in the future will be interesting to see.\n\n/Erik\n-- \ngoogle talk/jabber. zindar@gmail.com\nSIP-phones: sip:erik_bagfors@gizmoproject.com\n"},{"id":"295525","messageId":"877iyne4dm.fsf@alplog.fr","threadId":"5925","inReplyTo":"20061026101038.GA13310@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"Vincent Ladeuil","fromEmail":"v.ladeuil@alplog.fr","sentAt":"2006-10-26T10:52:05Z","receivedAt":"2006-10-26T10:52:05Z","isPatch":false,"sender":{"key":"v.ladeuil@alplog.fr","avatar":null},"body":">>>>> \"Jeff\" == Jeff King writes:\n\n Jeff> On Thu, Oct 26, 2006 at 05:57:20PM +0800, James Henstridge wrote:\n >> >If you two have the same commit that is a guarantee that you two\n >> >have identical trees. The reverse is not true as logic 101\n >> >would teach ;-).\n >> \n >> That was the point I was trying to make. Carl asserted that in git\n >> you could tell if you had the same tree as someone else based on\n >> revision IDs, which doesn't seem to be the case all the time.\n\n Jeff> If you have the same revision (commit IDs), you have\n Jeff> the same tree (at the same time, by the same committer,\n Jeff> etc).\n\n Jeff> If you have a different revision (commit), you may or\n Jeff> may not have the same tree. You can then check the tree\n Jeff> id, which will either be the same (you have the same\n Jeff> tree) or differ (you don't).\n\n Jeff> Thus, in the converse, if you have the same tree, you\n Jeff> _will_ have the same tree id. You may or may not have\n Jeff> the same commit id.\n\nOk, so git make a distinction between the commit (code created by\nsomeone) and the tree (code only).\n\nCommits are defined by their parents.\n\nTrees are defined by their content only ?\n\nIf that's the case, how do you proceed ? \n\nCalculate a sha1 representing the content (or the content of the\ndiff from parent) of all the files and dirs in the tree ? Or\nfrom the sha1s of the files and dirs themselves recursively based\non sha1s of the files and dirs they contain ?\n\nI ask because the later seems to provide some nice effects\nsimilar to what makes BDD\n(http://en.wikipedia.org/wiki/Binary_decision_diagram) so\nefficient: you can compare graphs of any complexity or size in\nO(1) by just comparing their signatures.\n\n Vincent\n\n\n"},{"id":"294910","messageId":"20061026111338.GA15179@coredump.intra.peff.net","threadId":"5925","inReplyTo":"877iyne4dm.fsf@alplog.fr","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-26T11:13:39Z","receivedAt":"2006-10-26T11:13:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 26, 2006 at 12:52:05PM +0200, Vincent Ladeuil wrote:\n\n> Ok, so git make a distinction between the commit (code created by\n> someone) and the tree (code only).\n\nYes (a commit is a tree, zero or more parents, commit message, and\nauthor/committer info).\n\n> Commits are defined by their parents.\n\nPartially, yes.\n\n> Trees are defined by their content only ?\n\nYes.\n\n> Calculate a sha1 representing the content (or the content of the\n> diff from parent) of all the files and dirs in the tree ? Or\n> from the sha1s of the files and dirs themselves recursively based\n> on sha1s of the files and dirs they contain ?\n\nRecursively. Each tree is an ordered list of 4-tuples: pathname, type,\nsha1, mode. If the type is \"blob\" then the sha1 is the hash of the file\ncontents. If the type is \"tree\" then the sha1 is the id of a sub-tree.\nThe id of a tree is the sha1 hash of the data structure.\n\n> I ask because the later seems to provide some nice effects\n> similar to what makes BDD\n> (http://en.wikipedia.org/wiki/Binary_decision_diagram) so\n> efficient: you can compare graphs of any complexity or size in\n> O(1) by just comparing their signatures.\n\nYes, if two trees' hashes compare equal, they contain the same data. I\nbelieve we are not currently using this optimization to find merge\ndifferences, but there was some discussion earlier this week about doing\nso.\n\n"},{"id":"295449","messageId":"20061026111549.GA15211@coredump.intra.peff.net","threadId":"5925","inReplyTo":"20061026111338.GA15179@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-26T11:15:49Z","receivedAt":"2006-10-26T11:15:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 26, 2006 at 07:13:39AM -0400, Jeff King wrote:\n\n> Yes (a commit is a tree, zero or more parents, commit message, and\n> author/committer info).\n\nSorry, I should clarify: a commit is a _tree id_, zero or more _parent\nids_, commit message, etc.\n\n"},{"id":"297636","messageId":"454098EC.8040406@op5.se","threadId":"5925","inReplyTo":"Pine.LNX.4.64N.0610250954380.31053@attu2.cs.washington.edu","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-26T11:15:56Z","receivedAt":"2006-10-26T11:15:56Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"David Rientjes wrote:\n> On Wed, 25 Oct 2006, Jeff King wrote:\n> \n>>> This all became very obvious when the tutorials came out on \"how to use \n>>> git in 20 commands or less\" effectively. These tutorials shouldn't need \n>>> to exist with an information manager that started as a quick, efficient, \n>>> and _simple_ project. You're treating git development in the same light \n>> Sorry, I don't see how this is related to the programming language _at\n>> all_. Are you arguing that the interface of git should be simplified so\n>> that such tutorials aren't necessary? If so, then please elaborate, as\n>> I'm sure many here would like to hear proposals for improvements. If\n>> you're arguing that git now has too many features, then which features\n>> do you consider extraneous?\n>>\n> \n> It's not, it's related to the original vision of git which was meant for \n> efficiency and simplicity.\n\nCompared to todays version, original git was neither efficient nor \nsimple. Unless you mean \"some random version along the way where git had \neverything *I* need and not the useless cruft that other people use\", in \nwhich case it's simply a very egotistical view of things.\n\n> A year ago it was very easy to pick up the \n> package and start using it effectively within a couple hours. Keep in\n> mind that this was without tutorials, it was just reading man pages. \n> Today it would be very difficult to know what the essential commands are \n> and how to use them simply to get the job done, unless you use the \n> tutorials.\n\nHave you tried \"git --help\"? It shows the most common commands and a \nshort description of what they do. It's a very good pointer to which \nman-pages you need to read, and I imagine this would actually be one of \nthe very first commands that new git users try. If they don't but just \nexpect things to work according to some premade mental model they have \nof scm's, I'd say they'd be screwed no matter which software they tried.\n\n\n> This _inherently_ goes against the approach of trying to \n> provide something that is simple to the developer.\n> \n> Revision control is something that should exist in the background that \n> does it's simple job very efficiently. Unfortunately git has tried to \n> move its presence into the foreground and requiring developers to spend \n> more time on learning the system.\n> \n\nNo it hasn't. The ten or so commands that Linus first introduced when \nannouncing git still work pretty much the same. Nobody in their right \nmind would ever claim that those ten commands made up anything that even \nremotely resembled a complete scm, but they were something to build on \nby anyone who wanted to extend it. So far, ~220 people have wanted to \nextend it in ways that others thought useful, because their patches are \napparently in the git tree.\n\n> Have you never tried to show other people git without giving them a \n> tutorial on the most common uses? Try it and you'll see the confusion. \n> That _specifically_ illustrates the ever-increasing lack of simplicity \n> that git has acquired.\n> \n\nWell, my head hurt when I tried to learn CVS without a tutorial, and \nmercurial and darcs and svn as well. I didn't pick up the functionality \nof the 'ls' command completely without reading the man-page for it. If \nyou want something that works for everyone without having to read any \ndocumentation what so ever, buy Lego, cause computers ain't for you, my \nfriend.\n\n>> I don't agree with this. There are tons of enhancements that I find\n>> useful (e.g., '...' rev syntax, rebasing with 3-way merge, etc) that I\n>> think other developers ARE using. There are scalability and performance\n>> improvements. And there are new things on the way (Junio's pickaxe work)\n>> that will hopefully make git even more useful than it already is.\n>>\n> \n> There are _not_ scalability improvements. There may be some slight \n> performance improvements, but definitely not scalability. If you have \n> ever tried to use git to manage terabytes of data, you will see this \n> becomes very clear. And \"rebasing with 3-way merge\" is not something \n> often used in industry anyway if you've followed the more common models \n> for revision control within large companies with thousands of engineers. \n> Typically they all work off mainline.\n> \n\nActually, I don't see why git shouldn't be perfectly capable of handling \na repo containing several terabytes of data, provided you don't expect \nit to turn up the full history for the project in a couple of seconds \nand you don't actually *change* that amount of data in each revision. If \nyou want a vcs that handles that amount with any kind of speed, I think \nyou'll find rsync and raw rvs a suitable solution.\n\nOn the other hand, you fellas at google don't really use git to store \nthe data from the search database, do you? I mean, it's written for \nsource control management. People that tried to keep their mboxes in git \nfailed miserably, because large files that constantly change just \ndoesn't work well with git.\n\n>> If you don't think recent git versions are worthwhile, then why don't\n>> you run an old version? You can even use git to cherry-pick patches onto\n>> your personal branch.\n>>\n> \n> I do. And that's why I would recommend to any serious developer to use \n> 1.2.4; this same version that I used for kernel development at Google.\n> \n>> Where?\n>>\n> \n> Few months back here on the mailing list. When I tried cleaning up even \n> one program, I got the response back from the original author \"why fix a \n> non-problem?\" because his argument was that since it worked the code \n> doesn't matter.\n> \n> \thttp://marc.theaimsgroup.com/?l=git&m=115589472706036\n> \n> And that is simply one thread of larger conversations that have taken \n> place off-list and aren't archived.\n> \n\nFirst off, the code got changed as per Junio's desires. He's the \nmaintainer and gets to choose about coding style and readability vs \nmicrooptimizations.\n\nSecond, why keep discussions about git development off-list?\n\nThird, if you still have issues with it, why not provide a patch and see \nif Junio accepts it? Cleaner and faster code will, in my experience, \nalways get accepted. Code that is cleaner from one devs point of view \nbut doesn't actually provide any other benefits will be dropped to the \nfloor, and rightly so.\n\n\n>> I don't agree, but since you haven't provided anything specific enough\n>> to discuss, there's not much to say.\n>>\n> \n> If there's a question about some of the sloppiness in the git source code \n> as it stands today, that's a much bigger issue than the sloppiness. My \n> advice would be to pick up a copy of K&R's 2nd edition C programming \n> language book, read it, and then take a tour of the source code.\n> \n\nThe first sentence doesn't make sense. The second one is just rude, and \nformed by your own opinion on how code should be written. But again, \nsubmit patches and see if Junio accepts them. If he doesn't, and you \nreally, really *really* can't stand the changes he and the rest of the \ngit community wants in, fork your own version and hack away til your \nheart's content. Git makes it easy for you, whichever version you use.\n\n>> Can you name one customization that you would like to perform now that\n>> you feel can't be easily done (and presumably that would have been\n>> easier in the past)?\n>>\n> \n> Yes, those mentioned above.\n> \n\nWhich ones? The git-mv changes you submitted were applied (although in a \ndifferent shape), so there must be other ones. Rewriting C builtins as \nshell-scripts is not really an option, because portability and \nperformance *does* matter.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"297499","messageId":"ehq5g9$7jr$1@sea.gmane.org","threadId":"5925","inReplyTo":"877iyne4dm.fsf@alplog.fr","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-26T11:18:09Z","receivedAt":"2006-10-26T11:18:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Vincent Ladeuil wrote:\n\n> Ok, so git make a distinction between the commit (code created by\n> someone) and the tree (code only).\n> \n> Commits are defined by their parents.\n> \n> Trees are defined by their content only ?\n\nTrees are collections of tuples: (mode, type, sha1, name), where mode\nis simplified mode of a file or directory (only if it is symlink, directory,\nfile or executable file is tracked), type is blob (file) or tree\n(directory), sha1 is sha1 of contents of given entry, and name is filename\nof given entry.\n \n> If that's the case, how do you proceed ? \n> \n> Calculate a sha1 representing the content (or the content of the\n> diff from parent) of all the files and dirs in the tree ?  Or\n> from the sha1s of the files and dirs themselves recursively based\n> on sha1s of the files and dirs they contain ?\n \nsha1 of object is sha1 of type+contents if I remember correctly. So the sha1\nof tree is based on sha1 of the files and dirs it contain.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297733","messageId":"45409B47.8090402@op5.se","threadId":"5925","inReplyTo":"7v3b9cnlx7.fsf@assigned-by-dhcp.cox.net","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-26T11:25:59Z","receivedAt":"2006-10-26T11:25:59Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> - Learn the itches David and other people have, that the\n> current git Porcelain-ish does not scratch well, and enrich\n> Documentation/technical with real-world working scripts built\n> around plumbing.\n> \n\nIsn't this how git has been developed since day one, more or less? If a \ncommand is missing, it gets added as a shell-script. I agree with you on \nthe \"pipes from this sent here does this, and look how useful it is\" \nlectures are gone since many commands were rewritten. Otoh, they're gone \nbecause they now instead provide examples on how to interface with the \nlibified parts of git, so it's not a loss per se, just a switch in what \nit teaches.\n\nI also agree with David that shell is much more fun to muck around with \nand prototype in, because you see results to much faster. However, since \nour plumbing is so rock-solid (and getting extended with --stdin options \nto more and more commands), I see no reason why we shouldn't have a \"how \nto extend git\" with the old shell-based porcelain scripts up somewhere \nat the web. Perhaps it would kill two birds with one stone and increase \nthe addition of new utilities to git, while at the same time keeping the \nalready rewritten commands in C.\n\nBtw, the old shell-versions still work with the new plumbing (well, \nmostly anyways). They just have problems with filenames and revisions \nwith spaces and special chars and things like that, same as they've \nalways had.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"298914","messageId":"ehq78n$ec7$1@sea.gmane.org","threadId":"5925","inReplyTo":"45408A53.10400@op5.se","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-26T11:48:15Z","receivedAt":"2006-10-26T11:48:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson wrote:\n\n> On a side-note, git has made my life easier, so I childishly want to \n> defend it and see it on top of every list in the world. Something I'm \n> sure I share with more people on this list and with some of the bazaar \n> users/devs. ;-)\n\nLet's then us review what started this thread, namely comparison chart\nbetween source control systems\n http://bazaar-vcs.org/RcsComparisons\n\n1. Decentralized. O.K.\n\n2. Disconnected Ops. O.K.\n\n3. Simple Namespace. Should be named \"Simple Rev Names\" instead, Bazaar\nshould have note that revnos work only for specific workflows\n(star-topology); for Git it should be perhaps \"Somewhat\" here, as ~\n(or @{} if reflog is enabled) _are_ simple (if volatile for branch\n). $(git-merge-base ), usually \"hidden\" in\n.. or ... shortcut is also I think simple. There\nwas huge discussion here about revnos, revids, workflows (development\ntopology), fast-forwards, empty merges etc. Bazaar-NG and Git puts\nemphasisis on other things. Additionally tags supports removes some of\nperceived revnos advantages; tags are simple.\n\n4. Supports Renames. I could agree with \"Somewhat\" because of not yet\nimplemented --follow option to git-rev-list (and therefore all porcelain).\nPerhaps it would be closer to truth to leave the marker (background color)\nas for \"Somewhat\" and write \"N/A\" with note that Git has contents and\npathname based heuristic detection of renames, or just put \"Detect\" or\n\"Detection\" here.\n\nI would certainly change description of what means that SCM doesn't \"Support\nRenames\" or has it implemented partially. Current explanation relies\nheavily on _implementation_. The correct wording of current definition\nwould be that SCM doesn't support renames if history of a file \"as visible\nto SCM\" is broken into before rename and after rename part, and that SCM\nsupport it partially if you can track history of renamed file from\npost-rename name but there is left in void history of pre-rename file.\nBut with this definition Git _does_ \"Supports Renames\".\n\nI'd rather split \"Supports Renames\" into engine part (does SCM\nremember/detect that rename took place _as_ rename, not remember/detect it\nas copiying+deletion; something other than rename) and user interface part:\ncan user easily deal with renames (this includes merging and viewing file\nhistory).\n\n5 and 6. Needs Repository/Supports Repository. The name is very, very\nunclean and stems from branch-centricness of Bazaar. Git should probably\nhave \"Yes\" here, as for Git branch is just reference to its tip in\nrevisions DAG (plus optionally branch tip history in reflog). On the other\nhand Git _can_ share object database like branches can be gathered together\nto share data into repository. You can have one-branch repositories, you\ncan clone whole repositories (perhaps Bazaar should have \"Somewhat\" for\nSupports Repository as it doesn't support cloning of whole repository...\nbzt, wrong, there is example plugin for that), and you can clone (using\nCogito) only one branch of repository and you can fetch only selected\nbranches of repository.\n\nThinking more about it those items should probably read \"Support Individual\nBranches\" (as: can you get only the branch you are interested in, can SCM\nsupport one-branch workflow) and \"Support Branch Grouping\" or \"Support Data\nSharing\" (as: can you share DAG between branches, can you share DAG between\nrepositories).\n\n7. Checkouts (as a noun). This probably read \"Support Centralized and\nDisconnected Centralized Workflow\" but that is perhaps too wordy. Git would\nhave \"No\" for \"Centralized\" and \"Somewhat\" for \"Disconnected Centralized\"\nmeaning that you can set up Git repository to be equivalent of heavyweight\ncheckout, and push changes to some given repository on commit.\n\n8. Partial Checkouts (as a verb). Here Git should have perhaps \"Minimal\", as\nyou can have partial checkouts but only with care (and you still need whole\nrepository). \"No?\" is also correct (?).\n\n9. Atomic Commits. O.K. You have to remember that there are consequences\nof having Atomic Commits on the details of Partial Checkouts.\n\n10. Cheap Branching Anywhere. Git should probably have \"Yes! Yes! Yes!\"\nhere ;-)\n\n11. Smart Merge. O.K. Should probably be explained what constitutes smart\nmerging. Perhaps instead of \"Yes\" there should be name of default/smartest\nmerge strategy used?\n\n12. Cherrypicks. What constitutes \"Yes\" here? Why \"Somewhat\" for Git?\nIt does have git-cherry-pick command for cherry picking...\n\n13. Plugins. I would put \"Somewhat\" here, or \"Scriptable\" in the \"Somewhat\"\nor \"?\" background color for Git. And add note that it is easy to script up\nporcelanish command, and to add another merge strategy. There also was\nexample plugin infrastructure for Cogito, so I'd opt for \"Someahwt\"\nmarking.\n\n14. Has Special Server. O.K.\n\n15. Req. Dedicated Server. O.K.\n\n16. Good Windows support. I'd put \"Cygwin\" instead of \"No\" for Git, although\nwith the same marking. And perhaps add note that Git relies heavily on\nPOSIX.\n\n17 and 18. Fast Local Performance and Fast Network Performance. O.K.\n\n19. Ease of Use. Hmmm... I don't know for Git. I personally find it very\neasy to use, but I have not much experiences with other SCM. I wonder why\nBazaar has \"No\" there...\n\n\nToo much rewriting to correct the page...\n\n"},{"id":"298921","messageId":"4540A1FE.4050300@ableton.com","threadId":"5925","inReplyTo":"ehq78n$ec7$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Nicholas Allen","fromEmail":"allen@ableton.com","sentAt":"2006-10-26T11:54:38Z","receivedAt":"2006-10-26T11:54:38Z","isPatch":false,"sender":{"key":"allen@ableton.com","avatar":null},"body":"\n> \n> 4. Supports Renames. I could agree with \"Somewhat\" because of not yet\n> implemented --follow option to git-rev-list (and therefore all porcelain).\n> Perhaps it would be closer to truth to leave the marker (background color)\n> as for \"Somewhat\" and write \"N/A\" with note that Git has contents and\n> pathname based heuristic detection of renames, or just put \"Detect\" or\n> \"Detection\" here.\n> \n> I would certainly change description of what means that SCM doesn't \"Support\n> Renames\" or has it implemented partially. Current explanation relies\n> heavily on _implementation_. The correct wording of current definition\n> would be that SCM doesn't support renames if history of a file \"as visible\n> to SCM\" is broken into before rename and after rename part, and that SCM\n> support it partially if you can track history of renamed file from\n> post-rename name but there is left in void history of pre-rename file.\n> But with this definition Git _does_ \"Supports Renames\".\n\nI would have thought that supports renames would also involve flagging a \nconflict when merging a file that has been renamed on 2 separate \nbranches. ie 2 branches rename the file to different names and then one \nbranch is merged into the other. In this situation, the user should be \ntold of a rename conflict. Bzr supports this as far as I know. Not sure \nabout git though as I have never used it.\n\n\n\n"},{"id":"295278","messageId":"20061026121253.GE17019@over-yonder.net","threadId":"5925","inReplyTo":"45408A53.10400@op5.se","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-26T12:12:53Z","receivedAt":"2006-10-26T12:12:53Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Thu, Oct 26, 2006 at 12:13:39PM +0200 I heard the voice of\nAndreas Ericsson, and lo! it spake thus:\n> Matthew D. Fuller wrote:\n> >\n> >In git, this is a non-issue because you don't get to CHOOSE which\n> >way to work.\n> \n> Yes they do.\n\nNot where I was going with that section of the mail; I was looking at\njust the merge vs fast-forward distinction. In git, you don't get to\nchoose; in bzr you do.\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n"},{"id":"294733","messageId":"200610261413.36445.jnareb@gmail.com","threadId":"5925","inReplyTo":"4540A1FE.4050300@ableton.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-26T12:13:35Z","receivedAt":"2006-10-26T12:13:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicholas Allen wrote:\n> Jakub Narebski wrote:\n>> \n>> 4. Supports Renames. I could agree with \"Somewhat\" because of not yet\n>> implemented --follow option to git-rev-list (and therefore all porcelain).\n>> Perhaps it would be closer to truth to leave the marker (background color)\n>> as for \"Somewhat\" and write \"N/A\" with note that Git has contents and\n>> pathname based heuristic detection of renames, or just put \"Detect\" or\n>> \"Detection\" here.\n>> \n>> I would certainly change description of what means that SCM doesn't \"Support\n>> Renames\" or has it implemented partially. Current explanation relies\n>> heavily on _implementation_. The correct wording of current definition\n>> would be that SCM doesn't support renames if history of a file \"as visible\n>> to SCM\" is broken into before rename and after rename part, and that SCM\n>> support it partially if you can track history of renamed file from\n>> post-rename name but there is left in void history of pre-rename file.\n>> But with this definition Git _does_ \"Supports Renames\".\n> \n> I would have thought that supports renames would also involve flagging a \n> conflict when merging a file that has been renamed on 2 separate \n> branches. ie 2 branches rename the file to different names and then one \n> branch is merged into the other. In this situation, the user should be \n> told of a rename conflict. Bzr supports this as far as I know. Not sure \n> about git though as I have never used it.\n\nIf I remember correctly Git usually resolves such conflict. If it cannot\nresolve it, it tells user of rename conflict (add/add conflict or rename/add\nconflict).\n\nUnfortunately Git tutorial part 3 on merges is not yer written.\n-- \nJakub Narebski\n"},{"id":"294607","messageId":"ehq924$llq$1@sea.gmane.org","threadId":"5925","inReplyTo":"20061026121253.GE17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-26T12:18:53Z","receivedAt":"2006-10-26T12:18:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthew D. Fuller wrote:\n\n> On Thu, Oct 26, 2006 at 12:13:39PM +0200 I heard the voice of\n> Andreas Ericsson, and lo! it spake thus:\n>> Matthew D. Fuller wrote:\n>>>\n>>>In git, this is a non-issue because you don't get to CHOOSE which\n>>>way to work.\n>> \n>> Yes they do.\n> \n> Not where I was going with that section of the mail; I was looking at\n> just the merge vs fast-forward distinction. In git, you don't get to\n> choose; in bzr you do.\n\nYou can get similar workflow in git using 'origin'/'master' pair, I think.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298900","messageId":"87u01r9rz7.fsf@alplog.fr","threadId":"5925","inReplyTo":"20061026111338.GA15179@coredump.intra.peff.net","subject":"Re: VCS comparison table","fromName":"Vincent Ladeuil","fromEmail":"v.ladeuil@alplog.fr","sentAt":"2006-10-26T12:33:32Z","receivedAt":"2006-10-26T12:33:32Z","isPatch":false,"sender":{"key":"v.ladeuil@alplog.fr","avatar":null},"body":">>>>> \"Jeff\" == Jeff King writes:\n\n Jeff> On Thu, Oct 26, 2006 at 12:52:05PM +0200, Vincent Ladeuil wrote:\n >> Ok, so git make a distinction between the commit (code created by\n >> someone) and the tree (code only).\n\n Jeff> Yes (a commit is a tree, zero or more parents, commit message, and\n Jeff> author/committer info).\n\nThe parents of a tree are also trees or can/must they be commits ?\n\n >> Commits are defined by their parents.\n\n Jeff> Partially, yes.\n\nI buy that this \"partially\" means \"the other parts are irrelevant\nto this discussion\".\n\n >> Trees are defined by their content only ?\n\n Jeff> Yes.\n\nSo it is possible that : starting from a tree T,\n\n- I make a patch A,\n- you make the patch B,\n- A and B are equal (stop watching above my shoulder please, or what is me ?),\n- we both commit,\n- we pull changes from each other repository.\n\nWe will end up with a tree T2 with a hash corresponding to both\nT+A and T+B, but each of us will have a different commit id CA\nand CB both pointing to T2, did I get it ?\n\n Vincent\n\n\n\n\n\n\n"},{"id":"298074","messageId":"4540B4CA.2050502@dawes.za.net","threadId":"5925","inReplyTo":"87u01r9rz7.fsf@alplog.fr","subject":"Re: VCS comparison table","fromName":"Rogan Dawes","fromEmail":"discard@dawes.za.net","sentAt":"2006-10-26T13:14:50Z","receivedAt":"2006-10-26T13:14:50Z","isPatch":false,"sender":{"key":"discard@dawes.za.net","avatar":null},"body":"Vincent Ladeuil wrote:\n>>>>>> \"Jeff\" == Jeff King writes:\n> \n> Jeff> On Thu, Oct 26, 2006 at 12:52:05PM +0200, Vincent Ladeuil wrote:\n> >> Ok, so git make a distinction between the commit (code created by\n> >> someone) and the tree (code only).\n> \n> Jeff> Yes (a commit is a tree, zero or more parents, commit message, and\n> Jeff> author/committer info).\n> \n> The parents of a tree are also trees or can/must they be commits ?\n\nThis refers to the parents of a _commit_, not of a tree, and the parents \nmust be _commits_. The parents allow us to determine what changed \nbetween the previous commit(s), and the current one. If there are more \nthan one parent, then we have a merge commit.\n\nSo, a commit refers to a tree representing the state of the code at the \ntime of the commit, as well as to any parent commit(s). If there are no \nparent commits, then the commit is an \"initial commit\" (i.e. the first \ncheckin). A project can have multiple \"initial commits\", typically where \ntwo previously independent projects are merged together, c.f. gitk and git.\n\n> \n> >> Commits are defined by their parents.\n> \n> Jeff> Partially, yes.\n> \n> I buy that this \"partially\" means \"the other parts are irrelevant\n> to this discussion\".\n\nYes.\n\n> >> Trees are defined by their content only ?\n> \n> Jeff> Yes.\n> \n> So it is possible that : starting from a tree T,\n> \n> - I make a patch A,\n> - you make the patch B,\n> - A and B are equal (stop watching above my shoulder please, or what is me ?),\n> - we both commit,\n> - we pull changes from each other repository.\n> \n> We will end up with a tree T2 with a hash corresponding to both\n> T+A and T+B, but each of us will have a different commit id CA\n> and CB both pointing to T2, did I get it ?\n> \n> Vincent\n\nYes. That is exactly right.\n\n From there, we can either trivially merge CA and CB with a new merge \ncommit referring to T2, but citing both CA and CB as parents, or simply \ndiscard one of the lines of development, depending on how much \nsubsequent development cited CA or CB as parents.\n\n"},{"id":"295729","messageId":"4540BC6B.1050009@utoronto.ca","threadId":"5925","inReplyTo":"45408A53.10400@op5.se","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-26T13:47:23Z","receivedAt":"2006-10-26T13:47:23Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nAndreas Ericsson wrote:\n> The only issue I have with bzr's revno's and truly distributed setup is\n> that, by looking at the table, it seems to claim that you have found\n> some miraculous way to make revnos work without a central server. Since\n> everyone agrees that they don't, this should IMO be listed as mutually\n> exclusive features.\n\nThe \"simple namespace\" is both a URL and a revno.\n\nAnd therefore, it's just as distributed and decentralized as the web.\n\nThere is very little difference between this:\n\nhttp://example.com/mywebpage#5\n\nAnd this:\n\nhttp://example.com/mybranch 5\n\nIn fact, we've been planning to unify them into one identifier.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFQLxr0F+nu1YWqI0RAiVrAJ9rb+uylIuxqMo2VMelI3Qm6oNQOwCfeTAb\nkOkp9kOkRl1YEVEP+G3y2SU=\n=Zgsg\n"},{"id":"297440","messageId":"ehqeja$d5j$1@sea.gmane.org","threadId":"5925","inReplyTo":"4540BC6B.1050009@utoronto.ca","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-26T13:53:23Z","receivedAt":"2006-10-26T13:53:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n\n> Andreas Ericsson wrote:\n\n>> The only issue I have with bzr's revno's and truly distributed setup is\n>> that, by looking at the table, it seems to claim that you have found\n>> some miraculous way to make revnos work without a central server. Since\n>> everyone agrees that they don't, this should IMO be listed as mutually\n>> exclusive features.\n> \n> The \"simple namespace\" is both a URL and a revno.\n> \n> And therefore, it's just as distributed and decentralized as the web.\n> \n> There is very little difference between this:\n> \n> http://example.com/mywebpage#5\n> \n> And this:\n> \n> http://example.com/mybranch 5\n> \n> In fact, we've been planning to unify them into one identifier.\n\nWell, then it is not much simpler than 8-chars sha1. And sha1 is more\ndecentralized, because you can use it when you don't have access to net,\nand when the _central_ revno server is down.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295514","messageId":"Pine.LNX.4.64.0610260753090.3962@g5.osdl.org","threadId":"5925","inReplyTo":"877iyne4dm.fsf@alplog.fr","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-26T15:05:36Z","receivedAt":"2006-10-26T15:05:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 26 Oct 2006, Vincent Ladeuil wrote:\n> \n> Ok, so git make a distinction between the commit (code created by\n> someone) and the tree (code only).\n> \n> Commits are defined by their parents.\n\nCommits are defined by a _combination_ of:\n - the tree they commit (which is recursive, so the commit name indirectly \n includes information EVERY SINGLE BIT in the whole tree, in every \n single file)\n - the parent(s) if any (which is also recursive, so the commit name \n indirectly includes information about EVERY SINGLE BIT in not just the \n current tree, but every tree in the history, and every commit that is \n reachable from it)\n - the author, committer, and dates of each (and committer is actually \n very often different from author)\n - the actual commit message\n\nSo a commit really names - uniquely and authoratively - not just the \ncommit itself, but everything ever associated with it.\n\n> Trees are defined by their content only ?\n\nWhere \"contents\" does include names and permissions/types (eg execute bit \nand symlink etc).\n\n> If that's the case, how do you proceed ? \n\nIf you compare the commit name, and they are equal, you automatically know\n - the trees are 100% identical\n - the histories are 100% identical\n\nIf you only care about the actual tree, you compare the tree name for \nequality, ie you can do\n\n\tgit-rev-parse commit1^{tree} commit2^{tree}\n\nand compare the two: if and only if they are equal are the actual contents \n100% equal.\n\n> Calculate a sha1 representing the content (or the content of the\n> diff from parent) of all the files and dirs in the tree ? Or\n> from the sha1s of the files and dirs themselves recursively based\n> on sha1s of the files and dirs they contain ?\n\nThe latter. \n\n> I ask because the later seems to provide some nice effects\n> similar to what makes BDD\n> (http://en.wikipedia.org/wiki/Binary_decision_diagram) so\n> efficient: you can compare graphs of any complexity or size in\n> O(1) by just comparing their signatures.\n\nThis is exactly what git does. You can compare entire trees (and \nsubdirectories are just other trees) by just comparing 20 bytes of \ninformation.\n\nHow do you think we can do a diff between two arbitrary kernel revisions \nso fast? Why do you think we can afford to do a \n\n\tgit log drivers/usb include/linux/usb*\n\nthat literally picks out the history (by comparing state) for every commit \nin the tree?\n\nI can do the above log-generation in less than ten _seconds_ for the last \nyear and a half of the kernel. That's 20k+ lines of logs of commits that \nonly touch those files and directories. And I _need_ it to be fast, \nbecause that's literally one of the most common operations I do.\n\nAnd the reason it's fast is that we can compare 20,000 files (names, \ncontents, permissions) by just comparing a _single_ 20-byte SHA1.\n\nIn git, revision names (and _everything_ has a revision name: commits, \ntrees, blobs, tags) really have meaning. They're not just random noise.\n\n"},{"id":"296875","messageId":"20061026150655.GG17019@over-yonder.net","threadId":"5925","inReplyTo":"ehq924$llq$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-26T15:06:55Z","receivedAt":"2006-10-26T15:06:55Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Thu, Oct 26, 2006 at 02:18:53PM +0200 I heard the voice of\nJakub Narebski, and lo! it spake thus:\n> \n> You can get similar workflow in git using 'origin'/'master' pair, I\n> think.\n\nNot the same, because as soon as your 'git pull' _can_ fast-foward, it\nwill. You can't merge a set of changes from another branch that's a\nstrict superset of yours in, without it fast-forwarding them.\n\nI suppose you could take great care to ensure that the other branch is\nnever in a position to be fast-forwarded onto yours, most simply just\nby making forced commits before you do a pull, but that's revolting.\n\n\n-- \nMatthew Fuller (MF4839) | fullermd@over-yonder.net\nSystems/Network Administrator | http://www.over-yonder.net/~fullermd/\n"},{"id":"294288","messageId":"4540D0A7.90706@utoronto.ca","threadId":"5925","inReplyTo":"ehqeja$d5j$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-26T15:13:43Z","receivedAt":"2006-10-26T15:13:43Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJakub Narebski wrote:\n> Aaron Bentley wrote:\n>>There is very little difference between this:\n>>\n>>http://example.com/mywebpage#5\n>>\n>>And this:\n>>\n>>http://example.com/mybranch 5\n>>\n>>In fact, we've been planning to unify them into one identifier.\n> \n> \n> Well, then it is not much simpler than 8-chars sha1. And sha1 is more\n> decentralized, because you can use it when you don't have access to net,\n> and when the _central_ revno server is down.\n\nWhat do you mean by _central_ revno server? example.com? Does that\nalso apply to google.com?\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFQNCc0F+nu1YWqI0RAlslAJ0XJ8Fezxyn5Ty1oAcgAo4LdQEAvQCfbWk+\nvVTmHwIuhyd7lhAxMm2uMZ8=\n=c4pE\n"},{"id":"297817","messageId":"4540D2BA.5060106@utoronto.ca","threadId":"5925","inReplyTo":"20061024093033.GA23906@rhonwyn.vernstok.nl","subject":"Re: VCS comparison table","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-10-26T15:22:34Z","receivedAt":"2006-10-26T15:22:34Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJelmer Vernooij wrote:\n\n> The graphical frontends to bzr, for example, don't know about revno's but \n> only about revids.\n\nGannotate shows revnos where appropriate. Not sure about others.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFQNK60F+nu1YWqI0RAiGiAJ45IG/nHsl3/5rP23nxYLduopVj/QCfUX+9\nE01mr0edaZld9aKMASRbo+o=\n=YavT\n"},{"id":"296160","messageId":"87k62n5ahp.fsf@alplog.fr","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610260753090.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Vincent Ladeuil","fromEmail":"v.ladeuil+lp@free.fr","sentAt":"2006-10-26T16:04:50Z","receivedAt":"2006-10-26T16:04:50Z","isPatch":false,"sender":{"key":"v.ladeuil+lp@free.fr","avatar":null},"body":">>>>> \"Linus\" == Linus Torvalds writes:\n\n Linus> On Thu, 26 Oct 2006, Vincent Ladeuil wrote:\n >> \n >> Ok, so git make a distinction between the commit (code created by\n >> someone) and the tree (code only).\n >> \n >> Commits are defined by their parents.\n\n Linus> Commits are defined by a _combination_ of:\n\n Linus> - the tree they commit (which is recursive, so the\n Linus> commit name indirectly includes information EVERY\n Linus> SINGLE BIT in the whole tree, in every single file)\n\nAnd here you keep that separate from any SCM related info,\nright ?\n\n Linus> - the parent(s) if any (which is also recursive, so\n Linus> the commit name indirectly includes information about\n Linus> EVERY SINGLE BIT in not just the current tree, but\n Linus> every tree in the history, and every commit that is\n Linus> reachable from it)\n\n Linus> - the author, committer, and dates of each (and\n Linus> committer is actually very often different from\n Linus> author)\n\n Linus> - the actual commit message\n\n Linus> So a commit really names - uniquely and authoratively\n Linus> - not just the commit itself, but everything ever\n Linus> associated with it.\n\nThanks for the clarification. But no need to shout about EVERY\nSINGLE BIT, the pointer to BDDs was already talking a bit about\nbits :) \n\nBut I agree, this is the important point that may be missed.\n\n >> Trees are defined by their content only ?\n\n Linus> Where \"contents\" does include names and\n Linus> permissions/types (eg execute bit and symlink etc).\n\nWhich can also be expressed as: \"Everything the user can\nmanipulate outside the SCM context\", right ?\n\n >> If that's the case, how do you proceed ? \n\n Linus> If you compare the commit name, and they are equal,\n Linus> you automatically know\n\n Linus> - the trees are 100% identical\n Linus> - the histories are 100% identical\n\nAnd that's the only info you can get, no ordering here. (Just\npointing the obvious, as soon as you try to put more info into\nthe signature, the equality will vanish).\n\nBut for various optimizations this equality property is the only\nneeded one.\n\nDo we agree ?\n\n Linus> If you only care about the actual tree, you compare\n Linus> the tree name for equality, ie you can do\n\n Linus> \tgit-rev-parse commit1^{tree} commit2^{tree}\n\n Linus> and compare the two: if and only if they are equal are\n Linus> the actual contents 100% equal.\n\nActually, that's backwards:\n\n\"their actual contents are equal\" implies \"their signatures are\nequal\".\n\nBut, two totally different trees can have the same signature.\n\nMy god ! What an horror ! Not. I even wonder if I will live so\nlong as to see it occurs... So we *can* pretend that:\n\n\"theirs signatures are equal\" is equivalent to \"their contents\nare equal\"\n\nAnd that's all we care :)\n\nBut I digressed, the question was about a detail on your tree\ndefinition, once the signature is defined to be unique (as in\ncanonical), the property of comparing the signatures as if they\nwere the objects themselves follows. Thanks for the confirmation.\n\n >> Calculate a sha1 representing the content (or the content\n >> of the diff from parent) of all the files and dirs in the\n >> tree ? Or from the sha1s of the files and dirs themselves\n >> recursively based on sha1s of the files and dirs they\n >> contain ?\n\n Linus> The latter. \n\nThanks for providing the clarification. So of course, finding the\ndifferences between the trees is quick, you can prune anywhere\nthe signatures equality is verified.\n\n >> I ask because the later seems to provide some nice effects\n >> similar to what makes BDD\n >> (http://en.wikipedia.org/wiki/Binary_decision_diagram) so\n >> efficient: you can compare graphs of any complexity or size in\n >> O(1) by just comparing their signatures.\n\n Linus> This is exactly what git does. You can compare entire\n Linus> trees (and subdirectories are just other trees) by\n Linus> just comparing 20 bytes of information.\n\nI understand that, years ago even. I have a bit of practice with\nBDDs and I am accustomed to that so lovely property. But without\nthat practice, I think most people will just wonder...\n\n\n\n Linus> And the reason it's fast is that we can compare 20,000\n Linus> files (names, contents, permissions) by just comparing\n Linus> a _single_ 20-byte SHA1.\n\nYeah, let's go further ! We can compare gazillions of files and\ntheir history since epoch by comparing _two_ signatures ! :-)\n\n Linus> In git, revision names (and _everything_ has a\n Linus> revision name: commits, trees, blobs, tags) really\n Linus> have meaning. They're not just random noise.\n\nI know that effect, but I understand people complaining that they\n*look* like noise. \n\nI'm still searching a parallel in nature, but the best I could\nfind is DNA, ever look at a DNA ? \n\nLooks like noise no ? No ordering either between parents and\nchildren... But there is a way to identify a parent from the DNA\nof a children...\n\n"},{"id":"297654","messageId":"Pine.LNX.4.64.0610260912250.3962@g5.osdl.org","threadId":"5925","inReplyTo":"87k62n5ahp.fsf@alplog.fr","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-26T16:21:34Z","receivedAt":"2006-10-26T16:21:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 26 Oct 2006, Vincent Ladeuil wrote:\n\n> >>>>> \"Linus\" == Linus Torvalds writes:\n> \n> Linus> Commits are defined by a _combination_ of:\n> \n> Linus> - the tree they commit (which is recursive, so the\n> Linus> commit name indirectly includes information EVERY\n> Linus> SINGLE BIT in the whole tree, in every single file)\n> \n> And here you keep that separate from any SCM related info,\n> right ?\n\nI don't understand that question.\n\nThe commits contain the tree information. A raw commit in git (this is the \ntrue contents of the current top commit in my kernel tree, just added \nindentation and an empty line between the command I used to generate it \nand the output, to make it stand out better in the email) looks something \nlike this:\n\n [torvalds@g5 linux]$ git-cat-file commit HEAD\n\n tree ba1ed8c744654ca91ee2b71b7cdee149c8edbef1\n parent 2a4f739dfc59edd52eaa37d63af1bd830ea42318\n parent 012d64ff68f304df1c35ce5902f5023dc14b643f\n author Linus Torvalds 1161873881 -0700\n committer Linus Torvalds 1161873881 -0700\n \n Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6\n \n * master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:\n [SPARC64]: Fix memory corruption in pci_4u_free_consistent().\n [SPARC64]: Fix central/FHC bus handling on Ex000 systems.\n\nwhere the _name_ of the commit is \n\n [torvalds@g5 linux]$ git-rev-parse HEAD\n\n e80391500078b524083ba51c3df01bbaaecc94bb\n\nie the commit itself contains the exact tree name (and the name of the \nparents), and the name of the commit is literally the SHA1 of the contents \nof the commit (plus a git-specific header).\n\n> >> Trees are defined by their content only ?\n> \n> Linus> Where \"contents\" does include names and\n> Linus> permissions/types (eg execute bit and symlink etc).\n> \n> Which can also be expressed as: \"Everything the user can\n> manipulate outside the SCM context\", right ?\n\nAgain, I'm not sure what you mean by that. The SCM does not track \n_everything_. It does not track user names and inode numbers, so in a \nsense a developer can change things that the SCM simply doesn't _care_ \nabout and never tracks. But yes, the tree contents uniquely identify the \nexact contents that the user cares about.\n\n> Linus> If you compare the commit name, and they are equal,\n> Linus> you automatically know\n> \n> Linus> - the trees are 100% identical\n> Linus> - the histories are 100% identical\n> \n> And that's the only info you can get, no ordering here.\n\nNo, there is ordering there too. But yes, the ordering is not in the name \nitself, you have to go look at the actual commit history to see it.\n\nThe name is just an identifier.\n\n> Linus> If you only care about the actual tree, you compare\n> Linus> the tree name for equality, ie you can do\n> \n> Linus> \tgit-rev-parse commit1^{tree} commit2^{tree}\n> \n> Linus> and compare the two: if and only if they are equal are\n> Linus> the actual contents 100% equal.\n> \n> Actually, that's backwards:\n> \n> \"their actual contents are equal\" implies \"their signatures are\n> equal\".\n\nNo. \n\nIf the signatures are equal, the contents are equal, and vice versa. It \nreally is a two-way thing.\n\n> But, two totally different trees can have the same signature.\n\nNo. Don't even think that way. That just confuses you. The hash is \ncryptographic, and large enough, that you really can equate the contents \nwith the hash. Anything else is just not even interesting.\n\n"},{"id":"296774","messageId":"Pine.LNX.4.63.0610260929040.2424@qynat.qvtvafvgr.pbz","threadId":"5925","inReplyTo":"454098EC.8040406@op5.se","subject":"Re: VCS comparison table","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-10-26T16:30:52Z","receivedAt":"2006-10-26T16:30:52Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Thu, 26 Oct 2006, Andreas Ericsson wrote:\n\n>> \n>> There are _not_ scalability improvements. There may be some slight \n>> performance improvements, but definitely not scalability. If you have ever \n>> tried to use git to manage terabytes of data, you will see this becomes \n>> very clear. And \"rebasing with 3-way merge\" is not something often used in \n>> industry anyway if you've followed the more common models for revision \n>> control within large companies with thousands of engineers. Typically they \n>> all work off mainline.\n>> \n>\n> Actually, I don't see why git shouldn't be perfectly capable of handling a \n> repo containing several terabytes of data, provided you don't expect it to \n> turn up the full history for the project in a couple of seconds and you don't \n> actually *change* that amount of data in each revision. If you want a vcs \n> that handles that amount with any kind of speed, I think you'll find rsync \n> and raw rvs a suitable solution.\n\nactually, there are some real problems in this area. the git pack format can't \nbe larger then 4G, and I wouldn't be surprised if there were other issues with \nfiles larger then 4G (these all boil down to 32 bit limits). once these limits \nare dealt with then you will be right.\n\n"},{"id":"297036","messageId":"Pine.LNX.4.64.0610261247420.12418@xanadu.home","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610260929040.2424@qynat.qvtvafvgr.pbz","subject":"Re: VCS comparison table","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-10-26T17:03:49Z","receivedAt":"2006-10-26T17:03:49Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 26 Oct 2006, David Lang wrote:\n\n> On Thu, 26 Oct 2006, Andreas Ericsson wrote:\n> \n> > > \n> > > There are _not_ scalability improvements. There may be some slight\n> > > performance improvements, but definitely not scalability. If you have\n> > > ever tried to use git to manage terabytes of data, you will see this\n> > > becomes very clear. And \"rebasing with 3-way merge\" is not something\n> > > often used in industry anyway if you've followed the more common models\n> > > for revision control within large companies with thousands of engineers.\n> > > Typically they all work off mainline.\n> > > \n> >\n> > Actually, I don't see why git shouldn't be perfectly capable of handling a\n> > repo containing several terabytes of data, provided you don't expect it to\n> > turn up the full history for the project in a couple of seconds and you\n> > don't actually *change* that amount of data in each revision. If you want a\n> > vcs that handles that amount with any kind of speed, I think you'll find\n> > rsync and raw rvs a suitable solution.\n> \n> actually, there are some real problems in this area. the git pack format can't\n> be larger then 4G, and I wouldn't be surprised if there were other issues with\n> files larger then 4G (these all boil down to 32 bit limits). once these limits\n> are dealt with then you will be right.\n\nThere is no such limit on the pack format. A pack itself can be as \nlarge as you want. The 4G limit is in the tool not the format.\n\nThe actual pack limits are as follows:\n\n\t- a pack can have infinite size\n\n\t- a pack cannot have more than 4294967296 objects\n\n\t- each non-delta objects can be of infinite size\n\n\t- delta objects can be of infinite size themselves but...\n\n\t- current delta encoding can use base objects no larger than 4G\n\nThe _code_ is currently limited to 4G though, especially on 32-bit \narchitectures. The delta issue could be resolved in a backward \ncompatible way but it hasn't been formalized yet.\n\nThe pack index is actually limited to 32-bits meaning it can cope with \npacks no larger than 4G. But the pack index is a local matter and not \npart of the protocol so this is not a big issue to define a new index \nformat and automatically convert existing indexes at that point.\n\n\n"},{"id":"296779","messageId":"Pine.LNX.4.63.0610261003290.2424@qynat.qvtvafvgr.pbz","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610261247420.12418@xanadu.home","subject":"Re: VCS comparison table","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-10-26T17:04:34Z","receivedAt":"2006-10-26T17:04:34Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Thu, 26 Oct 2006, Nicolas Pitre wrote:\n\n> On Thu, 26 Oct 2006, David Lang wrote:\n>\n>> On Thu, 26 Oct 2006, Andreas Ericsson wrote:\n>>\n>>>>\n>>>> There are _not_ scalability improvements. There may be some slight\n>>>> performance improvements, but definitely not scalability. If you have\n>>>> ever tried to use git to manage terabytes of data, you will see this\n>>>> becomes very clear. And \"rebasing with 3-way merge\" is not something\n>>>> often used in industry anyway if you've followed the more common models\n>>>> for revision control within large companies with thousands of engineers.\n>>>> Typically they all work off mainline.\n>>>>\n>>>\n>>> Actually, I don't see why git shouldn't be perfectly capable of handling a\n>>> repo containing several terabytes of data, provided you don't expect it to\n>>> turn up the full history for the project in a couple of seconds and you\n>>> don't actually *change* that amount of data in each revision. If you want a\n>>> vcs that handles that amount with any kind of speed, I think you'll find\n>>> rsync and raw rvs a suitable solution.\n>>\n>> actually, there are some real problems in this area. the git pack format can't\n>> be larger then 4G, and I wouldn't be surprised if there were other issues with\n>> files larger then 4G (these all boil down to 32 bit limits). once these limits\n>> are dealt with then you will be right.\n>\n> There is no such limit on the pack format. A pack itself can be as\n> large as you want. The 4G limit is in the tool not the format.\n>\n> The actual pack limits are as follows:\n>\n> \t- a pack can have infinite size\n>\n> \t- a pack cannot have more than 4294967296 objects\n>\n> \t- each non-delta objects can be of infinite size\n>\n> \t- delta objects can be of infinite size themselves but...\n>\n> \t- current delta encoding can use base objects no larger than 4G\n>\n> The _code_ is currently limited to 4G though, especially on 32-bit\n> architectures. The delta issue could be resolved in a backward\n> compatible way but it hasn't been formalized yet.\n>\n> The pack index is actually limited to 32-bits meaning it can cope with\n> packs no larger than 4G. But the pack index is a local matter and not\n> part of the protocol so this is not a big issue to define a new index\n> format and automatically convert existing indexes at that point.\n\nthe offset within a pack for the starting location of an object cannot be larger \nthen 4G.\n\n"},{"id":"296523","messageId":"Pine.LNX.4.64.0610261012090.3962@g5.osdl.org","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610261003290.2424@qynat.qvtvafvgr.pbz","subject":"Re: VCS comparison table","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-26T17:16:36Z","receivedAt":"2006-10-26T17:16:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 26 Oct 2006, David Lang wrote:\n> \n> the offset within a pack for the starting location of an object cannot be\n> larger then 4G.\n\nWell, strictly speaking, even that isn't actually a limit on the _pack_ \nformat itself. It's really just the (totally separate) index that \ncurrently uses 32-bit offsets.\n\nFor example, you can actually use the pack-file to transfer more than 4GB \nof data over the network. You'd not need to change the format at all. Only \nthe local _index_ of the result needs to change - but we never transfer \nthat at all (it's always generated locally), so that's really a separate \nissue.\n\nIt's not even hard to fix. It's just that right now, the biggest \nrepository that we know about (mozilla) is not even close to the limit. \nAnd it took them ten years to get there. So if the mozilla people switch \nto git, and keep going at the same rate, we have about 70 years left \nbefore we need to fix the indexing ;)\n\n(Of course, other projects, like the kernel, seem to grow faster, so it \nmight be \"only\" a decade or two - but since the index format is a local \nthing, even that won't be too painful, since we don't really need a global \nflag-day once we decide to start supporting larger offsets in the index)\n\n"},{"id":"297828","messageId":"Pine.LNX.4.64.0610261320080.12418@xanadu.home","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610261003290.2424@qynat.qvtvafvgr.pbz","subject":"Re: VCS comparison table","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-10-26T17:24:44Z","receivedAt":"2006-10-26T17:24:44Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 26 Oct 2006, David Lang wrote:\n\n> On Thu, 26 Oct 2006, Nicolas Pitre wrote:\n> \n> > The pack index is actually limited to 32-bits meaning it can cope with\n> > packs no larger than 4G.\n> \n> the offset within a pack for the starting location of an object cannot be\n> larger then 4G.\n\nTo be more exact, yes. But I don't think we'll ever consider use \nscenarios with packs > 4G with the current index format. There is \nsimply no point.\n\n\n"},{"id":"297662","messageId":"ehqs6c$co1$2@sea.gmane.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610261247420.12418@xanadu.home","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-26T17:45:27Z","receivedAt":"2006-10-26T17:45:27Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre wrote:\n\n> On Thu, 26 Oct 2006, David Lang wrote:\n> \n>> actually, there are some real problems in this area. the git pack format can't\n>> be larger then 4G, and I wouldn't be surprised if there were other issues with\n>> files larger then 4G (these all boil down to 32 bit limits). once these limits\n>> are dealt with then you will be right.\n> \n> There is no such limit on the pack format. A pack itself can be as \n> large as you want. The 4G limit is in the tool not the format.\n[...]\n> The _code_ is currently limited to 4G though, especially on 32-bit \n> architectures. The delta issue could be resolved in a backward \n> compatible way but it hasn't been formalized yet.\n> \n> The pack index is actually limited to 32-bits meaning it can cope with \n> packs no larger than 4G. But the pack index is a local matter and not \n> part of the protocol so this is not a big issue to define a new index \n> format and automatically convert existing indexes at that point.\n\nIf I remember correctly those issues are under development:\n1. There is work on 64-bit index\n2. There is work that would allow to have multiple packs, repack only one\n of packs and treat the rest as 'archive packs' (which can be more\n aggresively packed). This solution is to split pack into multiple packs.\n3. There is work on mmaping only part of pack, which would avoid 4G limit\n even on 32-bit machines, if I understand it correctly.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"293814","messageId":"20061026212531.GB15941@coredump.intra.peff.net","threadId":"5925","inReplyTo":"4540A1FE.4050300@ableton.com","subject":"Re: VCS comparison table","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-10-26T21:25:31Z","receivedAt":"2006-10-26T21:25:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 26, 2006 at 01:54:38PM +0200, Nicholas Allen wrote:\n\n> I would have thought that supports renames would also involve flagging a \n> conflict when merging a file that has been renamed on 2 separate \n> branches. ie 2 branches rename the file to different names and then one \n> branch is merged into the other. In this situation, the user should be \n> told of a rename conflict. Bzr supports this as far as I know. Not sure \n> about git though as I have never used it.\n\nIt works as you expect:\n\n$ git-init-db\n$ touch foo\n$ git-add foo\n$ git-commit -m foo\nCommitting initial tree 4d5fcadc293a348e88f777dc0920f11e7d71441c\n$ git-checkout -b other\n$ git-mv foo bar\n$ git-commit -m bar\n$ git-checkout master\n$ git-mv foo baz\n$ git-commit -m baz$a\n$ git-pull . other\nTrying really trivial in-index merge...\nfatal: Merge requires file-level merging\nNope.\nMerging HEAD with 5a1dfd32c56a24d0ef06f0e71d731fcd49d5dc6e\nMerging:\n76ac76ee3ce890d43648ebc009d278dc81a327e0 baz\n5a1dfd32c56a24d0ef06f0e71d731fcd49d5dc6e bar\nfound 1 common ancestor(s):\nc9e7e95de6fdbb2af06ea44cc60d1ac1a63eaad6 foo\nCONFLICT (rename/rename): Rename foo->baz in branch HEAD rename foo->bar\nin 5a1dfd32c56a24d0ef06f0e71d731fcd49d5dc6e\nAutomatic merge failed; fix conflicts and then commit the result.\n\n"},{"id":"297433","messageId":"20061027045137.GB3179@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610211353070.3962@g5.osdl.org","subject":"Re: VCS comparison table","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-27T04:51:37Z","receivedAt":"2006-10-27T04:51:37Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sat, Oct 21, 2006 at 02:04:56PM -0700, Linus Torvalds wrote:\n> On Sat, 21 Oct 2006, Erik B?gfors wrote:\n> > bzr is a fully decentralized VCS. I've read this thread for quite some\n> > time now and I really cannot understand why people come to this\n> > conclusion.\n> \n> Even the bzr people agree, so what's not to understand?\n> \n> The revision numbers are totally unstable in a distributed environment \n> _unless_ you use a certain work-flow. And that work-flow is definitely not \n> \"distributed\" it's much closer to \"disconnected centralized\".\n> \n> Now, you could be truly distributed: BK used the same revision numbering \n> thing, but was distributed. But BK didn't even try to claim that their \n> revision numbers were \"simple\" and that fast-forwarding is sometimes the \n> wrong thing to do.\n> \n> So BK always fast-forwarded, and the revision numbers were just randomly \n> changing numbers. They weren't stable, they weren't simple, and nobody \n> claimed they were.\n> \n> So bzr can bite the bullet and say: \"revision numbers are changing and \n> meaningless, and we should just fast-forward on merges\", or you should \n> just admit that bzr is really more about \"disconnected operation\" than \n> truly distributed.\n> \n> You can't have your cake and eat it too. Truly distributed _cannot_ be \n> done with a stable dotted numbering scheme (unless the \"dotted numbering \n> scheme\" is just a way to show a hash like git does - so the numbering has \n> no _sequential_ meaning).\n> \n> Btw, this isn't just an \"opinion\". This is a _fact_. It's something they \n> teach in any good introductory course to distributed algorithms. Usually \n> it's talked about in the context of \"global clock\". \n> \n> Anybody who thinks that there exists a globally ticking clock in the \n> system (and stably increasing dotted numbers are just one such thing) is \n> talking about some fantasy-world that doesn't exist, or a world that has \n> nothing to do with \"distributed\".\n> \n> \t\t\tLinus\n\nActually bzr used to have slightly different numbering scheme not long\nago. There was a revision-history in each branch listing the revisions\nin order in which they were commited or merged in. Some time ago it was\nchanged to numbering along the leftmost parent, which was, IIRC, deemed\nsimpler and a little more logical. But in the light of these arguments,\nmaybe the former system was better -- it was more dependent on the\nactual location, but on the other hand it allowed (or could allow --\nIIRC there was some problem with it) to fast-forward merge while\n_locally_ keeping the meaning of old revision numbers. In fact, the\nrevision-history used to be almost exactly the same as git reflog,\nexcept it only stored the revids, not the times.\n\n--------------------------------------------------------------------------------\n"},{"id":"298261","messageId":"200610281338.40111.jnareb@gmail.com","threadId":"5925","inReplyTo":"20061027045137.GB3179@artax.karlin.mff.cuni.cz","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-28T11:38:39Z","receivedAt":"2006-10-28T11:38:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jan Hudec wrote:\n> Actually bzr used to have slightly different numbering scheme not long\n> ago. There was a revision-history in each branch listing the revisions\n> in order in which they were commited or merged in. Some time ago it was\n> changed to numbering along the leftmost parent, which was, IIRC, deemed\n> simpler and a little more logical. But in the light of these arguments,\n> maybe the former system was better -- it was more dependent on the\n> actual location, but on the other hand it allowed (or could allow --\n> IIRC there was some problem with it) to fast-forward merge while\n> _locally_ keeping the meaning of old revision numbers. In fact, the\n> revision-history used to be almost exactly the same as git reflog,\n> except it only stored the revids, not the times.\n\nWhich is very fine if you don't modify the history (amending commits,\nrewinding history to earlier point, rebasing the branch, merging branch\nin and starting it anew aka. dovetail approach if I remember correctly),\nand if you are not concerned with performance when fetching larger\nnumber of commits into branch (as you have to assign number to them).\n\nWhich was perhaps why bzr changed from revnolog to leftmost/first parent\nas a way to keep branch-as-path/assing revision numbers to revisions.\nWhich has it's own disadvantages as enumerated multiple times here\non the list.\n-- \nJakub Narebski\n"},{"id":"294987","messageId":"20061030214630.GA14916@artax.karlin.mff.cuni.cz","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0610251459160.1754@qynat.qvtvafvgr.pbz","subject":"Re: VCS comparison table","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-30T21:46:30Z","receivedAt":"2006-10-30T21:46:30Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Oct 25, 2006 at 03:40:00PM -0700, David Lang wrote:\n> On Tue, 24 Oct 2006, Matthew D. Fuller wrote:\n> >On Tue, Oct 24, 2006 at 11:03:20AM -0700 I heard the voice of\n> >David Lang, and lo! it spake thus:\n> >>\n> >>it sounded like you were saying that the way to get the slices of\n> >>the DAG was to use branches in bzr. [...]\n> >\n> >I'm not entirely sure I understand what you mean here, but I think\n> >you're saying \"Nobody's written the code in bzr to show arbitrary\n> >slices of the DAG\", which is true TTBOMK.\n> \n> I think we are talking past each other here.\n> \n> what I think was said was\n> \n> G 'one feature of git is that you can view arbatrary slices trivially'\n> \n> B 'bzr can do this too, you just use branches to define the slices'\n> \n> G 'but this limits you becouse branches are defined as code is developed, \n> git lets you define slices at viewing time'\n> \n> by the way, I think it's more then just saying 'well, the code could be \n> written to do this in $VCS' some decisions and standard ways of doing \n> things can impact how hard it is to implement a feature, and some decisions \n> can make it impossible (without doing unexpected things).\n\nSince bzr branch is, and is ONLY, a pointer to a revision, I don't see\nany design decision that would make this harder in bzr. The UI was only\nimplemented to take the revisions as branches.\n\n> >>everyone agrees that bzr supports the Star topology. Most people\n> >>(including bzr people) seem to agree that currently bzr does not\n> >>support the Distributed topology.\n> >\n> >I think this statement arouses so much grumbling because (a) bzr does\n> >support such a lot better than often seems implied, (b) where it\n> >doesn't, the changes needed to do so are relatively minor (often\n> >merely cosmetic), and (c) disagreement over whether some of the\n> >qualifications included for 'distributed' are really fundamental.\n\nThe more I read this thread I actually think bzr does support\ndistributed topology as well as git.\n\nThe whole difference is that bzr makes a distinction between the first\nand other parents of a revision, while git does not. This distinction is\ndone in two places:\n\n1. The log shows the first parent and than, as indented subsection the\n ancestry of other parents until the point where the ancestries meet\n again. This actually captures a pattern people usually use. When you\n merge, you usually put in the log something along the lines:\n\n \"merged X, which bars and fixes foo.\"\n\n when you actually merge M, which you consider a \"mainline\" and\n therefore not worth mentioning and X. Linus does it this way too --\n he actually posted a log message as an example, that showed exactly\n this.\n\n2. Assigns revision aliases in this same order (except the \"major\"\n number for the subsection is based on the common ancestor, not on the\n merge point). They are not special thing that is generated at commit\n time; they are infered from the shape of the DAG (and cached for\n performance reasons).\n\nAnd the only issue I think is, that the bzr UI and documentation pushes\nforward these aliases (revnos) more than appropriate for fully\ndistributed case and hides the real revision names (revids) too much for\nthat case.\n\n> >>it's just fine for bzr to not support all possible topologies,\n> >\n> >I think there's a real intent for bzr TO support at least all common\n> >topologies. I'll buy that current development has focused more on\n> >[relatively] simple topologies than the more wildly complex ones. I\n> >look forward to more addressing of the less common cases as the tool\n> >matures, and I think a lot of this thread will be good material to\n> >work with as that happens. It's just the suggestion that providing\n> >fruit for simple topologies _necessarily_ prejudices against complex\n> >ones that I find so onerous.\n> \n> one concern that the git people are voicing is that the things that work \n> for simple topologies (revno's) can't be used with the more complex ones \n> (where you need the refid's). especially the fact that users need to do \n> things significantly different when there are fairly subtle changes to the \n> topology.\n> \n> the scenerio that came up elsewhere today where you have\n> \n> Master\n> / \\\n> dev1 dev2\n> \n> and then dev1 and dev2 both start working on the same thing (without \n> knowing it), then discover they are working on the same thing. they now \n> have threeB options\n> \n> 1. merge their stuff up to the master so that they can both pull it down.\n> but this puts broken, experimental stuff up in the master\n> \n> 2. declare one of the dev trees to be the master\n> \n> this changes the topology to\n> \n> Master--dev1--dev2\n> \n> 3. pull from each other frequently to keep in sync.\n> \n> this changes the topology to\n> \n> Master\n> / \\\n> dev1--dev2\n> \n> if they do this with bzr then the revno's break, they each get extra \n> commits showing up (so they can never show the same history).\n\nThat's a deficiency of merge not telling that a merge is pointless.\nActually I think than bzr merge *should* reduce to pull in all cases:\n\n- If the common ancestor is on the leftmost path of the other branch,\n than the existing revnos as seen on this branch will not change in any\n case, only more than one is added. I think it's safe for merge to\n reduce to pull in this case and consider it a bug in bzr that it does\n not.\n- If the common ancestor is not on the leftmost path on the other\n branch, than it is because the branch was merged with some other\n deemed \"more important\" (ie. the \"Master\" above). In this case\n reducing to pull will change the old revids, but IMO it's correct\n thing to do, because it's now up-to-date with latest revision of\n \"Master\" and it's revnos should take precedence. Personally I'd just\n like merge to reduce to pull in this case as well, but maybe it'd be\n better to have it error out and request user to either \"pull\" or\n \"merge --pointless\".\n\n> in git this is a non-issue, they can pull back and forth and the only new \n> history to show up will be changes.\n> \n> this is the situation that the kernel developers are in frequently. it \n> sounds as if you haven't needed to do this yet, so you haven't encountered \n> the problems.\n\nGiven that bzr is considerably smaller project than the Linux kernel,\nthat's quite likely. And it's likely a reason why it was not thoroughly\ndiscussed in bzr yet (or at least I don't know about that it was).\n\n--------------------------------------------------------------------------------\n"},{"id":"297744","messageId":"20061103034348.GB27189@evofed.localdomain","threadId":"5925","inReplyTo":"9e4733910610201115g1790b5am55105bf0c662a0da@mail.gmail.com","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Matthew Hannigan","fromEmail":"mlh@zip.com.au","sentAt":"2006-11-03T03:43:48Z","receivedAt":"2006-11-03T03:43:48Z","isPatch":false,"sender":{"key":"mlh@zip.com.au","avatar":null},"body":"On Fri, Oct 20, 2006 at 02:15:15PM -0400, Jon Smirl wrote:\n> [ ... ] \n> You could have a file of macro substitutions that is applied/expanded\n> when files go in/out of git. The macros would replace the copyright\n> notices improving the move/rename tracking and the reducing repository\n> size. The macros could be recorded out of band to eliminate the need\n> for escaping the file contents. Even simpler, the only valid place for\n> the macro could be the beginning of the file.\n\nThat probably belongs in the class of transformations\nbest done outside the VCS such as the permissions \nand system config file idea Linus outlined earlier.\n\n\nMatt\n"},{"id":"296484","messageId":"46a038f90611022236q6392a4d3ue261c935506b5ea1@mail.gmail.com","threadId":"5925","inReplyTo":"200610212121.58245.jnareb@gmail.com","subject":"Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-11-03T06:36:04Z","receivedAt":"2006-11-03T06:36:04Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/22/06, Jakub Narebski wrote:\n> Lack of --follow is not a big issue because you can do this \"by hand\";\n> you can use git-diff-tree -M at the end of file history to check if\n> [git considers] it was moved from somewhere.\n\nThis 'by hand' can be done in shell. cg-log has a half-complete\nimplementation of it. Seems to be disabled now :-(\n\ncheers,\n\n\n"},{"id":"297458","messageId":"456B7C6A.80104@webdrake.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0610260753090.3962@g5.osdl.org","subject":"git and bzr","fromName":"Joseph Wakeling","fromEmail":"joseph.wakeling@webdrake.net","sentAt":"2006-11-28T00:01:46Z","receivedAt":"2006-11-28T00:01:46Z","isPatch":false,"sender":{"key":"joseph.wakeling@webdrake.net","avatar":null},"body":"Hello all,\n\nFollowing the very interesting debate about the differences between bzr\nand git, I thought it was about time I tried to learn properly about git\nand how to use it. I've been using bzr for a good while now, although\nsince I'm not a serious developer I only use it for simple purposes,\nkeeping track of code I write on my own for academic projects.\n\nSo, a few questions about differences I don't understand...\n\nFirst off a really dumb one: how do I identify myself to git, i.e. give\nit a name and email address? Currently it uses my system identity,\nMy Name . I haven't found any equivalent of\nthe bzr whoami command.\n\nNow to more serious business. One of the main operational differences I\nsee as a new user is that bzr defaults to setting up branches in\ndifferent locations, whereas git by default creates a repository where\nbranches are different versions of the directory contents and switching\nbranches *changes* the directory contents. bzr branch seems to be\ncloser to git-clone than git-branch (N.B. I have never used bzr repos so\nmight not be making a fair comparison).\n\nWith this in mind, is there any significance to the \"master\" branch (is\nit intended e.g. to indicate a git repository's \"stable\" version\naccording to the owner?), or is this just a convenient default name?\nCould I delete or rename it? Using bzr I would normally give the\ncentral branch(*) the name of the project.\n\n(* Central or main on my own system. Not intended to be central in the\nsense of a CVS-style version control setup:-)\n\nAny other useful comments that can be made to a bzr user about working\nwith this difference, positive or negative aspects of it?\n\nNext question ... one of the reasons I started seriously thinking about\ngit was that in the VCS comparison discussion, it was noted that git is\na lot more flexible than bzr in terms of how it can track data (e.g. the\ngit pickaxe command, although I understand that's not in the released\nversion [1.4.4.1] yet?). A frustration with bzr is that pulling or\nmerging patches from another branch or repo requires them to share the\nsame HEAD. Is this a requirement in git or can I say, \"Hey, I like that\nparticular function in project XXX, I'm going to pull that individual\nbit of code and its development history into project YYY\"?\n\nLast off (for now, I'm sure I'll think of more): is there any easy (or\ndifficult) way to effectively import version history from a bzr\nrepository, and vice versa?\n\nThanks in advance for any comments,\n\n -- Joe\n"},{"id":"295877","messageId":"ekg0c5$b43$1@sea.gmane.org","threadId":"5925","inReplyTo":"456B7C6A.80104@webdrake.net","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-28T00:39:14Z","receivedAt":"2006-11-28T00:39:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Joseph Wakeling wrote:\n\n> Hello all,\n> \n> Following the very interesting debate about the differences between bzr\n> and git, I thought it was about time I tried to learn properly about git\n> and how to use it. I've been using bzr for a good while now, although\n> since I'm not a serious developer I only use it for simple purposes,\n> keeping track of code I write on my own for academic projects.\n> \n> So, a few questions about differences I don't understand...\n> \n> First off a really dumb one: how do I identify myself to git, i.e. give\n> it a name and email address? Currently it uses my system identity,\n> My Name . I haven't found any equivalent of\n> the bzr whoami command.\n\ngit repo-config user.name \"Joseph Wakeling\"\ngit repo-config user.email joseph.wakeling@webdrake.net\n\nYou might add --global option if you want your identity to be saved\nin ~/.gitconfig file, and not per repository (one might want to use\ndifferent identities for different repositories).\n\n\"git repo-config --list\" or \"git var -l\" to list all config. There is no\ndirect equivalent of \"bzr whoami\" (the equivalent would be:\n\n echo \"$(git repo-config --get user.name) <$(git repo-config --get user.email)>\"\n \n> Now to more serious business. One of the main operational differences I\n> see as a new user is that bzr defaults to setting up branches in\n> different locations, whereas git by default creates a repository where\n> branches are different versions of the directory contents and switching\n> branches *changes* the directory contents. bzr branch seems to be\n> closer to git-clone than git-branch (N.B. I have never used bzr repos so\n> might not be making a fair comparison).\n\nThe rough equivalent of bzr repos would be a set of git repos which share\nobject database, either via symlink, or via GIT_OBJECT_DIRECTORY, or via\nalternates mechanism.\n\nBut it is a fact that in bzr working area is associated with branch, while\nin git it is associated with repository.\n\n> With this in mind, is there any significance to the \"master\" branch (is\n> it intended e.g. to indicate a git repository's \"stable\" version\n> according to the owner?), or is this just a convenient default name?\n> Could I delete or rename it? Using bzr I would normally give the\n> central branch(*) the name of the project.\n\nOf course you can rename 'master' branch. But please remember that names\nof branches in git are local matter. Well, except the fact that you usually\npreserve them in a fashion.\n\nBut equivalent of giving central branch the name of the project would\nbe naming the directory with working area and .git directory the name\nof project, or in the case of bare repository giving $GIT_DIR for a project\nname project.git.\n\n> Any other useful comments that can be made to a bzr user about working\n> with this difference, positive or negative aspects of it?\n\nBy the way, 'master' is by no means special. It is default in a few cases\n(init-db, clone), but that's all.\n \n> Next question ... one of the reasons I started seriously thinking about\n> git was that in the VCS comparison discussion, it was noted that git is\n> a lot more flexible than bzr in terms of how it can track data (e.g. the\n> git pickaxe command, although I understand that's not in the released\n> version [1.4.4.1] yet?). A frustration with bzr is that pulling or\n> merging patches from another branch or repo requires them to share the\n> same HEAD. Is this a requirement in git or can I say, \"Hey, I like that\n> particular function in project XXX, I'm going to pull that individual\n> bit of code and its development history into project YYY\"?\n\nIn git repository can have unrelated branches. So you can fetch unrelated\nrepository into your repository, and merge/cherry-pick from there\nif needed.\n\nIn defence of Bazaar-NG, you can probably get the same or very similar with\nbzr repos. \n\n> Last off (for now, I'm sure I'll think of more): is there any easy (or\n> difficult) way to effectively import version history from a bzr\n> repository, and vice versa?\n\nTry git-archimport, or Tailor tool.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296759","messageId":"20061127194049.8ac68b1c.seanlkml__10154.9762803645$1164674480$gmane$org@sympatico.ca","threadId":"5925","inReplyTo":"456B7C6A.80104@webdrake.net","subject":"Re: git and bzr","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-11-28T00:40:49Z","receivedAt":"2006-11-28T00:40:49Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 28 Nov 2006 01:01:46 +0100\nJoseph Wakeling wrote:\n\n> First off a really dumb one: how do I identify myself to git, i.e. give\n> it a name and email address? Currently it uses my system identity,\n> My Name . I haven't found any equivalent of\n> the bzr whoami command.\n\nAssuming you have a recent version of git, then:\n\n$ git repo-config --global user.email \"you@email.com\"\n$ git repo-config --global user.name \"Your Name\"\n\nWill setup a ~/.gitconfig in your home directory; these settings\nwill apply in any repo you use. Drop the \"--global\" to set them\nper repo.\n\n> With this in mind, is there any significance to the \"master\" branch (is\n> it intended e.g. to indicate a git repository's \"stable\" version\n> according to the owner?), or is this just a convenient default name?\n> Could I delete or rename it? Using bzr I would normally give the\n> central branch(*) the name of the project.\n\nIt's just a common convention and carries no special significance;\nrename away!\n\n> Any other useful comments that can be made to a bzr user about working\n> with this difference, positive or negative aspects of it?\n\nDon't be afraid to git-clone your local repo, especially with the -l\nand -s options. That will get you a separate repo/working directory\nwhile not taking up much extra disk space (objects from your first\nrepo will be shared with the second).\n\nOnce you get comfortable with multiple branches in a single repo/\nworking directory, it often is much better than the alternatives.\nBut the above gives you the option to work either way.\n\n> Next question ... one of the reasons I started seriously thinking about\n> git was that in the VCS comparison discussion, it was noted that git is\n> a lot more flexible than bzr in terms of how it can track data (e.g. the\n> git pickaxe command, although I understand that's not in the released\n> version [1.4.4.1] yet?). A frustration with bzr is that pulling or\n> merging patches from another branch or repo requires them to share the\n> same HEAD. Is this a requirement in git or can I say, \"Hey, I like that\n> particular function in project XXX, I'm going to pull that individual\n> bit of code and its development history into project YYY\"?\n\nThe Git cherry-pick command lets you grab specific commits from\nother branches in your repo. But cherry-pick works at the commit\nlevel, there is no easy way to grab a single function for instance\nand merge just its history into another branch.\n\nHowever, you can merge an entire separate project into yours even\nthough they don't share a base commit. This has been done several\ntimes in the history of Git itself. For instance you can see two\nseparate \"initial\" commits in the Git repo with a command like\n\"gitk README gitk\" which gives a graphical history of the \"gitk\"\nand \"README\" files and shows each started life in a separate\ninitial commit. Use \"git show 5569b\" to see Linus bragging on\nthis first separate-project-merge and give some more details.\n \n> Last off (for now, I'm sure I'll think of more): is there any easy (or\n> difficult) way to effectively import version history from a bzr\n> repository, and vice versa?\n\nDon't think a direct bridge between the two has been written yet.\n\nCheers,\n"},{"id":"298901","messageId":"BAYC1-PASMTP03D791B2FF9E3AE0397A3CAEE50@CEZ.ICE","threadId":"5925","inReplyTo":"456B7C6A.80104@webdrake.net","subject":"Re: git and bzr","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-11-28T00:40:49Z","receivedAt":"2006-11-28T00:40:49Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 28 Nov 2006 01:01:46 +0100\nJoseph Wakeling wrote:\n\n> First off a really dumb one: how do I identify myself to git, i.e. give\n> it a name and email address? Currently it uses my system identity,\n> My Name . I haven't found any equivalent of\n> the bzr whoami command.\n\nAssuming you have a recent version of git, then:\n\n$ git repo-config --global user.email \"you@email.com\"\n$ git repo-config --global user.name \"Your Name\"\n\nWill setup a ~/.gitconfig in your home directory; these settings\nwill apply in any repo you use. Drop the \"--global\" to set them\nper repo.\n\n> With this in mind, is there any significance to the \"master\" branch (is\n> it intended e.g. to indicate a git repository's \"stable\" version\n> according to the owner?), or is this just a convenient default name?\n> Could I delete or rename it? Using bzr I would normally give the\n> central branch(*) the name of the project.\n\nIt's just a common convention and carries no special significance;\nrename away!\n\n> Any other useful comments that can be made to a bzr user about working\n> with this difference, positive or negative aspects of it?\n\nDon't be afraid to git-clone your local repo, especially with the -l\nand -s options. That will get you a separate repo/working directory\nwhile not taking up much extra disk space (objects from your first\nrepo will be shared with the second).\n\nOnce you get comfortable with multiple branches in a single repo/\nworking directory, it often is much better than the alternatives.\nBut the above gives you the option to work either way.\n\n> Next question ... one of the reasons I started seriously thinking about\n> git was that in the VCS comparison discussion, it was noted that git is\n> a lot more flexible than bzr in terms of how it can track data (e.g. the\n> git pickaxe command, although I understand that's not in the released\n> version [1.4.4.1] yet?). A frustration with bzr is that pulling or\n> merging patches from another branch or repo requires them to share the\n> same HEAD. Is this a requirement in git or can I say, \"Hey, I like that\n> particular function in project XXX, I'm going to pull that individual\n> bit of code and its development history into project YYY\"?\n\nThe Git cherry-pick command lets you grab specific commits from\nother branches in your repo. But cherry-pick works at the commit\nlevel, there is no easy way to grab a single function for instance\nand merge just its history into another branch.\n\nHowever, you can merge an entire separate project into yours even\nthough they don't share a base commit. This has been done several\ntimes in the history of Git itself. For instance you can see two\nseparate \"initial\" commits in the Git repo with a command like\n\"gitk README gitk\" which gives a graphical history of the \"gitk\"\nand \"README\" files and shows each started life in a separate\ninitial commit. Use \"git show 5569b\" to see Linus bragging on\nthis first separate-project-merge and give some more details.\n \n> Last off (for now, I'm sure I'll think of more): is there any easy (or\n> difficult) way to effectively import version history from a bzr\n> repository, and vice versa?\n\nDon't think a direct bridge between the two has been written yet.\n\nCheers,\nSean\n\n\n\n"},{"id":"298902","messageId":"Pine.LNX.4.64.0611271834090.30076@woody.osdl.org","threadId":"5925","inReplyTo":"456B7C6A.80104@webdrake.net","subject":"Re: git and bzr","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-28T02:57:03Z","receivedAt":"2006-11-28T02:57:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Nov 2006, Joseph Wakeling wrote:\n>\n> First off a really dumb one: how do I identify myself to git, i.e. give\n> it a name and email address? Currently it uses my system identity,\n> My Name . I haven't found any equivalent of\n> the bzr whoami command.\n\nDepending on whether you like editing config files by hand or not, you \nwould either just edit your ~/.gitconfig file and add a section like:\n\n\t[user]\n\t\tname = My Name Goes Here\n\t\temail = myemail@work.com\n\nor you would use \"git repo-config\" to do it for you. Personally, I find it \neasier to just edit the .gitconfig file directly, since the config file \nsyntax is actually rather pleasant, but if you want to do it with a git \ncommand, you'd do\n\n\tgit repo-config --global user.name \"Joseph Wakeling\"\n\tgit repo-config --global user.email joseph.wakeling@webdrake.net\n\n(where the \"--global\" just tells repo-config to use the user-global \n~/.gitconfig file - you can also do this on a per-repository basis in the \nrepository .git/config file if you want to have different identities for \ndifferent repositories).\n\n> Now to more serious business. One of the main operational differences I\n> see as a new user is that bzr defaults to setting up branches in\n> different locations, whereas git by default creates a repository where\n> branches are different versions of the directory contents and switching\n> branches *changes* the directory contents. bzr branch seems to be\n> closer to git-clone than git-branch (N.B. I have never used bzr repos so\n> might not be making a fair comparison).\n\nYou can do either, it's almost purely a matter of taste.\n\nUsing a local branch and switching between them in place has some \nadvantages once you get used to it: most notably you can trivially use git \ncommands that work on data from different branches at the same time. So \nwith that kind of setup it's very natural to do things like \"show me \neverything that is in branch 'x', but _not_ in branch 'y'\", and once you \nget used to that, you really appreaciate it.\n\nBut at the same time, if you want to actually keep several branches \nchecked out at the same time, and prefer to work on them that way, just \nuse \"git clone\" to create the other branch instead. It really is just a \nmatter of taste.\n\nI suspect that most people tend to end up using the \"multiple branches in \nthe same directory and switching between them\" approach after a time, but \nthat's really just an unsubstantiated feeling, and it certainly isn't \nsomething that git forces on you. \n\n> With this in mind, is there any significance to the \"master\" branch (is\n> it intended e.g. to indicate a git repository's \"stable\" version\n> according to the owner?), or is this just a convenient default name?\n> Could I delete or rename it? Using bzr I would normally give the\n> central branch(*) the name of the project.\n\nIt's just a convenient default name, and it has no real meaning otherwise. \nFeel free to rename it any way you want (just make sure to edit HEAD to \npoint to the new name is you rename it by hand).\n\n> Any other useful comments that can be made to a bzr user about working\n> with this difference, positive or negative aspects of it?\n\nThere should be no difference, although since everybody seems to use \n\"master\" by default, the documentation is probably geared towards it, and \nwho knows, maybe you'll hit a bug that nobody else noticed just because \neverybody else had a \"master\" branch, and some silly script had it \nhardcoded.\n\n> Next question ... one of the reasons I started seriously thinking about\n> git was that in the VCS comparison discussion, it was noted that git is\n> a lot more flexible than bzr in terms of how it can track data (e.g. the\n> git pickaxe command, although I understand that's not in the released\n> version [1.4.4.1] yet?).\n\npickaxe wasn't in the released version back when the discussions were \nraging, but it's there now. Except it's really called \"git blame\" these \ndays (and \"git annotate\") since it's taken over both of those duties.\n\nHowever...\n\n> A frustration with bzr is that pulling or\n> merging patches from another branch or repo requires them to share the\n> same HEAD. Is this a requirement in git or can I say, \"Hey, I like that\n> particular function in project XXX, I'm going to pull that individual\n> bit of code and its development history into project YYY\"?\n\n... it's not _quite_ that smart. It will only look for sources to new \nfunctions from existing sources in the tree that preceded the commit that \nadded the function, so it will _not_ see it coming from another branch or \nanother project entirely.\n\nSo when you ask for code annotations (use the \"-C\" flag to see code moved \nacross from other files), it will still limit itself to just a particular \ninput set, and not go gallivating over all possible branches and projects \nyou might have in your repository.\n\nIt wouldn't be theoretically impossible to do, but it would be \nprohibitively expensive (where do you draw the line for what to look at). \n\nSo git won't do quite what you ask for.\n\n> Last off (for now, I'm sure I'll think of more): is there any easy (or\n> difficult) way to effectively import version history from a bzr\n> repository, and vice versa?\n\nThere's a \"archimport\", but I assume bzr has long since broken \ncompatibility with arch (and/or just extended things so much as to not be \nimportable with that any more), regardless of any origin. But it might be \na good starting point, at least.\n\n\t\t\tLinus\n\n\n\n"},{"id":"297388","messageId":"845b6e870611280410j58bdcd99nc05d0f67489293e4@mail.gmail.com","threadId":"5925","inReplyTo":"456B7C6A.80104@webdrake.net","subject":"Re: git and bzr","fromName":"Erik Bågfors","fromEmail":"zindar@gmail.com","sentAt":"2006-11-28T12:10:21Z","receivedAt":"2006-11-28T12:10:21Z","isPatch":false,"sender":{"key":"zindar@gmail.com","avatar":null},"body":"> Next question ... one of the reasons I started seriously thinking about\n> git was that in the VCS comparison discussion, it was noted that git is\n> a lot more flexible than bzr in terms of how it can track data (e.g. the\n> git pickaxe command, although I understand that's not in the released\n> version [1.4.4.1] yet?).\n\n\nIf this is blame/annotate, this exists in bzr as well...\n\n: [bagfors@zyrgelkwyt]$ ; bzr help blame\nusage: bzr annotate FILENAME\naliases: ann, blame, praise\n\nShow the origin of each line in a file.\n\n\n"},{"id":"297249","messageId":"ekhaeg$etk$1@sea.gmane.org","threadId":"5925","inReplyTo":"845b6e870611280410j58bdcd99nc05d0f67489293e4@mail.gmail.com","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-28T12:37:17Z","receivedAt":"2006-11-28T12:37:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Erik B?gfors wrote:\n\n>> Next question ... one of the reasons I started seriously thinking about\n>> git was that in the VCS comparison discussion, it was noted that git is\n>> a lot more flexible than bzr in terms of how it can track data (e.g. the\n>> git pickaxe command, although I understand that's not in the released\n>> version [1.4.4.1] yet?).\n> \n> If this is blame/annotate, this exists in bzr as well...\n> \n> : [bagfors@zyrgelkwyt]$ ; bzr help blame\n> usage: bzr annotate FILENAME\n> aliases: ann, blame, praise\n> \n> Show the origin of each line in a file.\n\nThat doesn't change the fact that \"git pickaxe\" abilities in \"git blame\"\nis more than just equivalent of \"cvs annotate\".\n\n----\nbzr annotate FILENAME\n Show the origin of each line in a file.\n\n----\ngit-blame [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S ]\n [-M] [-C] [-C] [--since=] [] [--] \n\nAnnotates each line in the given file with information from the revision\nwhich last modified the line. Optionally, start annotating from the given\nrevision.\n\nAlso it can limit the range of lines annotated.\n[...]\nAlso you can use regular expression to specify the line range.\n git blame -L '/^sub hello {/,/^}$/' foo\nwould limit the annotation to the body of hello subroutine.\n\nWhen you are not interested in changes older than the version v2.6.18, or\nchanges older than 3 weeks, you can use revision range specifiers similar\nto git-rev-list:\n git blame v2.6.18.. -- foo\n git blame --since=3.weeks -- foo\n\nhttp://kernel.org/pub/software/scm/git/docs/git-blame.html\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296798","messageId":"Pine.LNX.4.63.0611281433270.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"ekhaeg$etk$1@sea.gmane.org","subject":"Re: git and bzr","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-28T13:35:12Z","receivedAt":"2006-11-28T13:35:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 28 Nov 2006, Jakub Narebski wrote:\n\n> [... some reasons why git-annotate is not just your regular annotate ...]\n\nYou should also mention that git-annotate can follow code movements \nthrough file renames.\n\nI know, because I was already rightfully blamed for code which was moved \nby somebody else.\n\nCiao,\nDscho\n"},{"id":"297908","messageId":"Pine.LNX.4.64.0611280754050.30076@woody.osdl.org","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0611281433270.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git and bzr","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-28T16:08:36Z","receivedAt":"2006-11-28T16:08:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Nov 2006, Johannes Schindelin wrote:\n> \n> On Tue, 28 Nov 2006, Jakub Narebski wrote:\n> \n> > [... some reasons why git-annotate is not just your regular annotate ...]\n> \n> You should also mention that git-annotate can follow code movements \n> through file renames.\n\n.. and within the same file, and _copied_ from other files.\n\nA good example of this is still just doing a\n\n\tgit blame -C revision.c\n\nbecause that \"revision.c\" file was created by splitting the old \n\"rev-list.c\" into two files (revision.c and rev-list.c). And the fact that \n\"git blame\" catches it and shows it in a very natural format is really \nquite nice.\n\n(rev-list.c has since been renamed to \"builtin-rev-list.c\", so if you want \nto see the \"other\" side of the split, just do\n\n\tgit blame -C builtin-rev-list.c\n\nin order to realize how well git blame follows both renames _and_ pure \ndata movement).\n\nThe reason this is a good example is simply the fact that it should \ntotally silence anybody who still thinks that tracking file identities is \na good thing. It explains well why tracking file identities is just \n_stupid_.\n\nYou simply couldn't have done that kind of split sanely with file identity \ntracking (well, that one only had a single copy, so you could argue that a \nfile identity tracker with copies could have done it, but the fact is that \n(a) they never do and (b) \"git blame\" can equally well track stuff that \ncomes from _multiple_ different \"file iddentities\").\n\nSuch a \"multiple sources\" case can actually be found by doing\n\n\tgit blame -C tree-walk.c\n\nwhich (correctly) figures out that the code comes from both merge-tree.c \n(the \"entry compare/extract\" functions)_and_ from sha1_name.c (the \n\"find_tree_entry()\" function). \n\nSo yes, \"git blame\" is a _hell_ of a lot more powerful than anybody elses \n\"annotate\", as far as I know. I literally suspect that nobody else comes \neven close.\n\n"},{"id":"298903","messageId":"456C6CBB.70702@utoronto.ca","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611280754050.30076@woody.osdl.org","subject":"Re: git and bzr","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-11-28T17:07:07Z","receivedAt":"2006-11-28T17:07:07Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nLinus Torvalds wrote:\n> in order to realize how well git blame follows both renames _and_ pure \n> data movement).\n> \n> The reason this is a good example is simply the fact that it should \n> totally silence anybody who still thinks that tracking file identities is \n> a good thing. It explains well why tracking file identities is just \n> _stupid_.\n\nNo need to be aggressive about this. Yes, it's true that file identity\ndoesn't directly solve this problem, but it doesn't prove that an\nidentity-based approach is wrong.\n\nIn the end, everything comes down to identity of some kind. Because if\nyou're going to apply someone else's changes, you must apply them to the\nsame thing that they changed.\n\nGit determines identity based on content, while bzr has the user\nindicate it. Both approaches work.\n\nBzr supports merging based on line identity (our weave merge, not our\nknit merge). At the moment, our concept of line identity is based on\nfile identity, but there's no reason it has to stay that way.\n\n> You simply couldn't have done that kind of split sanely with file identity \n> tracking (well, that one only had a single copy, so you could argue that a \n> file identity tracker with copies could have done it, but the fact is that \n> (a) they never do and (b) \"git blame\" can equally well track stuff that \n> comes from _multiple_ different \"file iddentities\").\n\nI think you're wrong about that. There's nothing stopping bzr from\ninferring a file split, or even explicitly recording it. bzr doesn't\nrecord copies, because we think there are no sane merge semantics across\ncopies.\n\n> So yes, \"git blame\" is a _hell_ of a lot more powerful than anybody elses \n> \"annotate\", as far as I know. I literally suspect that nobody else comes \n> even close.\n\nI notice that blame has an option to limit the annotation to recent\nhistory. I can only assume that is for performance reasons. bzr\nannotate doesn't need a feature like that, because annotations are\nexplicit in bzr's storage format. I expect that even if we were to\nextend annotate to track content across files, it would still be so fast\nthat we wouldn't need it.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFbGy70F+nu1YWqI0RAt75AKCAy0ALi0IKzqZpgnavJrx97+lhDgCfaMSe\nfs4Lt77k1/OXC82aFbh5pKg=\n=/OiA\n-----END PGP SIGNATURE-----\n\n\n\n"},{"id":"298904","messageId":"ekhrhi$g6t$1@sea.gmane.org","threadId":"5925","inReplyTo":"456C6CBB.70702@utoronto.ca","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-28T17:29:04Z","receivedAt":"2006-11-28T17:29:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n\n> Linus Torvalds wrote:\n\n>> So yes, \"git blame\" is a _hell_ of a lot more powerful than anybody elses \n>> \"annotate\", as far as I know. I literally suspect that nobody else comes \n>> even close.\n\nWell without the content based detection of contents copying and moving\nwhich git-blame wouldn't work as well as it work now.\n \n> I notice that blame has an option to limit the annotation to recent\n> history. I can only assume that is for performance reasons. bzr\n> annotate doesn't need a feature like that, because annotations are\n> explicit in bzr's storage format. \n\nBut you don't have content movement tracking.\n\n> \n> I expect that even if we were to \n> extend annotate to track content across files, it would still be so fast\n> that we wouldn't need it.\n\nI think not.\n\n\nThe first example:\n\n$ time git blame -C revision.c >/dev/null\n\nreal 0m7.577s\nuser 0m7.248s\nsys 0m0.020s\n\nwhile without content copying and moving detection we have\n\n$ time git blame revision.c >/dev/null\n\nreal 0m2.108s\nuser 0m2.044s\nsys 0m0.024s\n\n(on 2000 BogoMIPS CPU).\n\n"},{"id":"294696","messageId":"456C7592.6020700@ableton.com","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611280754050.30076@woody.osdl.org","subject":"Re: git and bzr","fromName":"Nicholas Allen","fromEmail":"allen@ableton.com","sentAt":"2006-11-28T17:44:50Z","receivedAt":"2006-11-28T17:44:50Z","isPatch":false,"sender":{"key":"allen@ableton.com","avatar":null},"body":"\n>\n> The reason this is a good example is simply the fact that it should \n> totally silence anybody who still thinks that tracking file identities is \n> a good thing. It explains well why tracking file identities is just \n> _stupid_.\nI'm unfamiliar with git so I could be totally wrong here!\n\nI know that bzr supports file renames/moves very effectively and I \nunderstood that git doesn't support this to the same extent (correct me \nif I am wrong as I have not used git at all!).\n\nIf that is the case, could that be because bzr gives each file its own \nid and can detect this easily but git's content based approach can't? If \nso then claiming file identifiers is *stupid* seems a bit extreme. So I \nwould have thought *both* file identifiers and line/content identifiers \nare needed for tracking changes made to the files and to their contents \nrespectively. When a file is copied then the contents are copied and it \nis given a new file identifier. When a file is moved it keeps the same \nidentifier. So don't you need file identifiers as well as line/content \nidentifiers?\n\n"},{"id":"298905","messageId":"Pine.LNX.4.64.0611280944580.4244@woody.osdl.org","threadId":"5925","inReplyTo":"456C6CBB.70702@utoronto.ca","subject":"Re: git and bzr","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-28T18:00:45Z","receivedAt":"2006-11-28T18:00:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Nov 2006, Aaron Bentley wrote:\n> \n> I notice that blame has an option to limit the annotation to recent\n> history. I can only assume that is for performance reasons.\n\nYou'd assume wrong.\n\nTrust me, if you talk about performance, bzr will lose. I can pretty much \nguarantee you that you perform worse. The mozilla discussion pointed to a \nperformance test between hg and bzr, and hg in that test tended to perform \nbetter by a factor of 2-10. And git tends to be another factor faster than \n_that_.\n\nPerformance is important to git, but it's important not in the sense of \n\"let's not do it because it performs badly\", but in the sense of \"things \nshould be so fast that people don't even realize that they are done\". You \nguys may count commit times in seconds. I still want to commit multiple \npatches _per_second_ to the kernel tree. THAT is performance.\n\nSo no, performance wasn't the reason.\n\nThe reason is simple: be logical. The original blame/annotate semantics \nwere\n\n\tgit blame filename\n\nwhich is what people traditionally use, but then to specify which version \nto _start_ with (in case you wanted to go backwards in time), you had an \noptional revision argument at the end.\n\nWhich is totally against how all the other git programs work, and I \ncomplained, because I had actually wanted to see the blame at a particular \nrelease version, and what my fingers typed didn't work. I want to be able \nto do\n\n\tgit blame [revno] [--] filename\n\nthe same way I can ask for a git log, git whatchanged, gitk, and any \nother such history tool.\n\nAnd once you do the same command line parsin as the other log-related \ncommands, you pretty much automatically get the revision limiting. So now \nyou can do\n\n\tgit blame v2.6.17..v2.6.18 filename\n\non the kernel archive to see who is to blame for certain lines in a \ncertain _range_ of commits. It just fell out of using the same syntax \neverywhere.\n\nIt's also happens to be useful. Quite often, you know something broke \nafter a particular known-good release, so you're interested in the blame, \nbut anything older than that known-good release is simply noise, and \nactually takes AWAY from the information, by just making things more \ncluttered.\n\n\t\t\tLinus\n\n\n\n"},{"id":"295817","messageId":"ekhtnt$rkk$1@sea.gmane.org","threadId":"5925","inReplyTo":"456C7592.6020700@ableton.com","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-28T18:06:27Z","receivedAt":"2006-11-28T18:06:27Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicholas Allen wrote:\n\n>> The reason this is a good example is simply the fact that it should \n>> totally silence anybody who still thinks that tracking file identities is \n>> a good thing. It explains well why tracking file identities is just \n>> _stupid_.\n>\n> I'm unfamiliar with git so I could be totally wrong here!\n> \n> I know that bzr supports file renames/moves very effectively and I \n\nThis means: _usually_ works, doesn't it? Emphasisis on \"usually\"?\n\n> understood that git doesn't support this to the same extent (correct me \n> if I am wrong as I have not used git at all!).\n\nGit supports renames/moves in different way. Instead of recording renames\n(which has trouble on it's own, for example rename via applying patch)\nin the repository it _detect_ renames when needed.\n \n> If that is the case, could that be because bzr gives each file its own \n> id and can detect this easily but git's content based approach can't? If \n> so then claiming file identifiers is *stupid* seems a bit extreme. So I \n> would have thought *both* file identifiers and line/content identifiers \n> are needed for tracking changes made to the files and to their contents \n> respectively. When a file is copied then the contents are copied and it \n> is given a new file identifier. When a file is moved it keeps the same \n> identifier. So don't you need file identifiers as well as line/content \n> identifiers?\n\nThere are trouble with file-ids. Most common example is trouble with file\nwhich was created in two branches (two repositories) independently, then\nbranches got merged. Most (all?) file-id based rename detection has trouble\nwith repeated merging of those branches, even if there are no true\nconflicts.\n\nRead Linus post about file-id based rename detection:\n Message-ID: \n http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/18458\n\nNot that contents based rename detection doesn have it's own pitfals:\n Message-ID: <7virha4cnm.fsf@assigned-by-dhcp.cox.net>\n http://permalink.gmane.org/gmane.comp.version-control.git/31899\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294553","messageId":"456C809C.3050503@utoronto.ca","threadId":"5925","inReplyTo":"ekhrhi$g6t$1@sea.gmane.org","subject":"Re: git and bzr","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-11-28T18:31:56Z","receivedAt":"2006-11-28T18:31:56Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJakub Narebski wrote:\n>>I notice that blame has an option to limit the annotation to recent\n>>history. I can only assume that is for performance reasons. bzr\n>>annotate doesn't need a feature like that, because annotations are\n>>explicit in bzr's storage format. \n> \n> \n> But you don't have content movement tracking.\n> \n> \n>> I expect that even if we were to \n>>extend annotate to track content across files, it would still be so fast\n>>that we wouldn't need it.\n> \n> \n> I think not.\n\nThere's no question that determining content movement could involve\nopening a lot of revisions, but you wouldn't need to examine:\n\n1. revisions that didn't alter any lines being examined\n2. revisions that altered only the file in question\n3. revisions with multiple parents, because any lines attributed to that\nmerge will be the outcome of conflict resolution. (Other lines will be\nattributed to one of the parents)\n\nI'll admit though, that when I was thinking of this, I was thinking of\nannotation-based merging, a scenario in which the number of lines being\nexamined is typically extremely low.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFbICL0F+nu1YWqI0RAhaXAJ9tqw/J17oKDV0nnuPlputs1PHBIgCghs6K\nq++u4Z9OFGwziUBsnW08y0U=\n=tmqe\n"},{"id":"294060","messageId":"200611281943.40354.jnareb@gmail.com","threadId":"5925","inReplyTo":"456C809C.3050503@utoronto.ca","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-28T18:43:39Z","receivedAt":"2006-11-28T18:43:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia wtorek 28. listopada 2006 19:31, Aaron Bentley napisał:\n> Jakub Narebski wrote:\n>>>I notice that blame has an option to limit the annotation to recent\n>>>history. I can only assume that is for performance reasons. bzr\n>>>annotate doesn't need a feature like that, because annotations are\n>>>explicit in bzr's storage format.\n>>\n>> But you don't have content movement tracking.\n>>\n>>> I expect that even if we were to\n>>>extend annotate to track content across files, it would still be so fast\n>>>that we wouldn't need it.\n>>\n>>\n>> I think not.\n> \n> There's no question that determining content movement could involve\n> opening a lot of revisions, but you wouldn't need to examine:\n> \n> 1. revisions that didn't alter any lines being examined\n> 2. revisions that altered only the file in question\n> 3. revisions with multiple parents, because any lines attributed to that\n> merge will be the outcome of conflict resolution. (Other lines will be\n> attributed to one of the parents)\n> \n> I'll admit though, that when I was thinking of this, I was thinking of\n> annotation-based merging, a scenario in which the number of lines being\n> examined is typically extremely low.\n\nWell, I gues that with \"annotate friendly\" (weave or knit) storage\nannotate/blame would be faster. But fast annotate was not one of the\ndesign goals of git.\n\nHow fast is \"bzr annotate\"?\n-- \nJakub Narebski\n"},{"id":"293983","messageId":"456C86E3.50902@ableton.com","threadId":"5925","inReplyTo":"ekhtnt$rkk$1@sea.gmane.org","subject":"Re: git and bzr","fromName":"Nicholas Allen","fromEmail":"allen@ableton.com","sentAt":"2006-11-28T18:58:43Z","receivedAt":"2006-11-28T18:58:43Z","isPatch":false,"sender":{"key":"allen@ableton.com","avatar":null},"body":"\n> There are trouble with file-ids. Most common example is trouble with file\n> which was created in two branches (two repositories) independently, then\n> branches got merged. Most (all?) file-id based rename detection has trouble\n> with repeated merging of those branches, even if there are no true\n> conflicts.\n\nDo you mean if the 2 files should be merged into 1 file? If they should \nbe 2 files with different names there is no problem using file \nidentifiers but if they should be merged into one file then I can see \nthat this would cause problems. You would have to delete one of the \nfiles and copy its changes into the other which would create conflicts \nwhen that file is modified in the other branch. This is a problem if you \n*only* have file identifiers.\n\nBut if you tracked both file identifiers *and* content identifiers (as I \nwas trying to say in my first post) this wouldn't be a problem would it? \nWhen content is changed you use the content identifiers but when files \nare changed by renaming or deleting you use file identifiers. To me at \nleast it doesn't seem like it's a choice of one or the other or that one \nis stupid and the other isn't but that you need them both. bzr uses file \nids and git uses content ids. It would be nice if there were an RCS \nthat used both - then you get the best of both worlds don't you?\n\nSo I don't think you want to use file identifiers to track changes to \ncontent (as bzr would do in this case) and you don't want to use content \nidentifiers to track changes to files (as git does, to my understanding, \nwhen a file is renamed).\n\nNick\n"},{"id":"296696","messageId":"456C89E7.8080404@ableton.com","threadId":"5925","inReplyTo":"ekhtnt$rkk$1@sea.gmane.org","subject":"Re: git and bzr","fromName":"Nicholas Allen","fromEmail":"allen@ableton.com","sentAt":"2006-11-28T19:11:35Z","receivedAt":"2006-11-28T19:11:35Z","isPatch":false,"sender":{"key":"allen@ableton.com","avatar":null},"body":"Jakub Narebski wrote:\n> Nicholas Allen wrote:\n>\n> \n>>> The reason this is a good example is simply the fact that it should \n>>> totally silence anybody who still thinks that tracking file identities is \n>>> a good thing. It explains well why tracking file identities is just \n>>> _stupid_.\n>>> \n>> I'm unfamiliar with git so I could be totally wrong here!\n>>\n>> I know that bzr supports file renames/moves very effectively and I \n>> \n>\n> This means: _usually_ works, doesn't it? Emphasisis on \"usually\"?\n>\n> \n>> understood that git doesn't support this to the same extent (correct me \n>> if I am wrong as I have not used git at all!).\n>> \n>\n> Git supports renames/moves in different way. Instead of recording renames\n> (which has trouble on it's own, for example rename via applying patch)\n> in the repository it _detect_ renames when needed.\n> \nThis can't be fail safe though. I would prefer to also have the option \nto be able to *explicitly* tell the RCS that a file was renamed and not \nhave it try to detect from the content which is bound to have corner \ncases that fail. When I know I renamed a file why can't I explicitly \ntell the RCS and it records the change with the *file identifier*. If I \nchange the content then the change is not recorded with the file \nidentifier but with the line/content identifier.\n\n"},{"id":"294437","messageId":"200611281940.40139.andyparkins@gmail.com","threadId":"5925","inReplyTo":"456C89E7.8080404@ableton.com","subject":"Re: git and bzr","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-28T19:40:38Z","receivedAt":"2006-11-28T19:40:38Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2006, November 28 19:11, Nicholas Allen wrote:\n\n> This can't be fail safe though. I would prefer to also have the option\n> to be able to *explicitly* tell the RCS that a file was renamed and not\n> have it try to detect from the content which is bound to have corner\n> cases that fail. When I know I renamed a file why can't I explicitly\n\nYou want to tell git about a rename that will never fail to be detected? No \nproblem.\n\n$ git mv oldname newname\n$ git commit\n\nThe corner cases you speak about are when you rename and edit.\n\nFor me, I prefer that to be detected as at least the detection algorithm can \nbe tuned - there is no fixing it if the VCS was forced to consider it a \nrename.\n\nWhen I started using git I was worried about the lack of a rename, but now I \nrealise that it's not needed - it's pointless. The VCS is snapshotting \nmoments in time, that's it. Then by making cleverer and cleverer \ninterpreters of those snapshots you have the potential to do stuff that is \nfar more useful than \"just\" rename recording.\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"297468","messageId":"eki4b1$ivt$1@sea.gmane.org","threadId":"5925","inReplyTo":"200611281940.40139.andyparkins@gmail.com","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-28T19:59:12Z","receivedAt":"2006-11-28T19:59:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\n> On Tuesday 2006, November 28 19:11, Nicholas Allen wrote:\n> \n>> This can't be fail safe though. I would prefer to also have the option\n>> to be able to *explicitly* tell the RCS that a file was renamed and not\n>> have it try to detect from the content which is bound to have corner\n>> cases that fail. When I know I renamed a file why can't I explicitly\n> \n> You want to tell git about a rename that will never fail to be detected? No \n> problem.\n> \n> $ git mv oldname newname\n> $ git commit\n> \n> The corner cases you speak about are when you rename and edit.\n> \n> For me, I prefer that to be detected as at least the detection algorithm can \n> be tuned - there is no fixing it if the VCS was forced to consider it a \n> rename.\n> \n> When I started using git I was worried about the lack of a rename, but now I \n> realise that it's not needed - it's pointless. The VCS is snapshotting \n> moments in time, that's it. Then by making cleverer and cleverer \n> interpreters of those snapshots you have the potential to do stuff that is \n> far more useful than \"just\" rename recording.\n\nWell, there are two cases where this might be not enough.\n\nOn is following file renames for history tracking. git-blame does that,\nbut git-log and friends does not; the is just revision limiter.\nThere is an idea of --follow option to git-log (and friends), to be\nimplemented.\n\nSecond is rename detection for 3way merges: only ancestor and final\nstates are considered, so the above would not help. And rename detection\nmight fail if ancestor is not similar enough to end states; well, the\nmerge has low chance of being without conflict then.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297551","messageId":"456C9DFF.1040407@onlinehome.de","threadId":"5925","inReplyTo":"ekhtnt$rkk$1@sea.gmane.org","subject":"Re: git and bzr","fromName":"Nicholas Allen","fromEmail":"nick.allen@onlinehome.de","sentAt":"2006-11-28T20:37:19Z","receivedAt":"2006-11-28T20:37:19Z","isPatch":false,"sender":{"key":"nick.allen@onlinehome.de","avatar":null},"body":"Jakub Narebski wrote:\n> Nicholas Allen wrote:\n> \n>>> The reason this is a good example is simply the fact that it should \n>>> totally silence anybody who still thinks that tracking file identities is \n>>> a good thing. It explains well why tracking file identities is just \n>>> _stupid_.\n>> I'm unfamiliar with git so I could be totally wrong here!\n>>\n>> I know that bzr supports file renames/moves very effectively and I \n> \n> This means: _usually_ works, doesn't it? Emphasisis on \"usually\"?\n\nHaving not used git I can't really say whether git is better than bzr or\nnot in this regard. I know in the kind of development I do the case\nwhere a file with the same name has been added independantly in 2\ndifferent branches is a pretty rare one. Usually, when it has happened\nthe files should have been 2 separate files with different names anyway\n- so bzr would have no problem with this.\n\nHowever, renaming a file is pretty common and I would rather be explicit\nabout it and have file name changes easily visible/searchable in my log.\n\nJust out of curiosity: How does git handle the case where one file is\nrenamed differently in 2 branches and then the branches are repeatably\nmerged? I know that bzr handles this very well and in various tests I\ndid there were absolutely no repeated conflicts. Would git behave as\nwell in this scenario?\n\n"},{"id":"294580","messageId":"456CA981.4010808@onlinehome.de","threadId":"5925","inReplyTo":"456C9DFF.1040407@onlinehome.de","subject":"Re: git and bzr","fromName":"Nicholas Allen","fromEmail":"nick.allen@onlinehome.de","sentAt":"2006-11-28T21:26:25Z","receivedAt":"2006-11-28T21:26:25Z","isPatch":false,"sender":{"key":"nick.allen@onlinehome.de","avatar":null},"body":"> \n> Just out of curiosity: How does git handle the case where one file is\n> renamed differently in 2 branches and then the branches are repeatably\n> merged? I know that bzr handles this very well and in various tests I\n> did there were absolutely no repeated conflicts. Would git behave as\n> well in this scenario?\n> \n\nOk - I got curious and decided to install git and try this myself.\n\nIn this test I had a file hello.txt that got renamed to hello1.txt in\none branch and hello2.txt in another. Then I merged the changes between\nthe 2 branches.\n\nHere is how it looked after the merge in bzr:\n\n bzr status\nrenamed:\n hello2.txt => hello1.txt\nconflicts:\n Path conflict: hello2.txt / hello1.txt\npending merges:\n Nicholas Allen 2006-11-28 Renamed hello to hello1\n\n\nand here's how it looked in git:\ngit status\n#\n# Changed but not updated:\n# (use git-update-index to mark for commit)\n#\n# unmerged: hello.txt\n# unmerged: hello1.txt\n# unmerged: hello2.txt\n# modified: hello2.txt\n#\nnothing to commit\n\nSo git is not telling me that I have a conflict due to the same file\nbeing renamed differently in 2 branches - well at least not in a way I\ncan comprehend anyway! Whereas bzr made this very clear. Also, in git I\nended up with 2 files:\n\n ls\nhello1.txt hello2.txt\n\nwhereas in bzr there was only one file and I just had to decide which\nname it was to be given to resolve the conflict.\n\nI'm not sure how I should resolve the conflict in git but that's\nprobably just because I am not familiar with it yet and the message it\ngave was not comprehensible or helpful to me in the slightest. In bzr it\nwas very easy and repeatably merging caused no trouble at all - the name\nconflict had to be resolved only once.\n\nWhile it was good that git detected my file rename (although this was\nnot hard as the contents did not change at all) the process in bzr was\n*much* smoother and more user friendly than it was it git. When you have\nconflicts I think it's especially important that the RCS inform you of\nwhat is really happening so you do not make mistakes. Bzr was much more\ninformative than git was and told me exactly why there was a conflict\nand made it easy to resolve it.\n\nThis situation is a pretty common one and it seems to me that git's\ncontent based approach is not as useful in this case as the file\nidentity approach that bzr uses.\n\n\nNick\n"},{"id":"294725","messageId":"46a038f90611281340u521fb5fct745ebe1ded9a630e@mail.gmail.com","threadId":"5925","inReplyTo":"456C9DFF.1040407@onlinehome.de","subject":"Re: git and bzr","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-11-28T21:40:06Z","receivedAt":"2006-11-28T21:40:06Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/29/06, Nicholas Allen wrote:\n> Having not used git I can't really say whether git is better than bzr or\n> not in this regard. I know in the kind of development I do the case\n> where a file with the same name has been added independantly in 2\n> different branches is a pretty rare one. Usually, when it has happened\n> the files should have been 2 separate files with different names anyway\n> - so bzr would have no problem with this.\n\nNot so rare in a true DSCM scenario where people submit patches via\nemail or a bug tracker. Say two developers apply the same patch to\ntheir trees, and one of them tweaks it a bit. While I don't personally\ndo kernel development, I understand that's reasonably common in the\nlinux dev team.\n\nIt also happens quite a bit if you cherry pick across branches patches\nthat create files.\n\nIn such cases, I find GIT does the right thing 99% of the time,\nincluding spotting situations where the file got added at different\npatchlevels in different branches.\n\ncheers,\n\n\n\n"},{"id":"295157","messageId":"ekiaed$9v1$1@sea.gmane.org","threadId":"5925","inReplyTo":"456CA981.4010808@onlinehome.de","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-28T21:43:24Z","receivedAt":"2006-11-28T21:43:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicholas Allen wrote:\n\n>> Just out of curiosity: How does git handle the case where one file is\n>> renamed differently in 2 branches and then the branches are repeatably\n>> merged? I know that bzr handles this very well and in various tests I\n>> did there were absolutely no repeated conflicts. Would git behave as\n>> well in this scenario?\n>> \n> \n> Ok - I got curious and decided to install git and try this myself.\n> \n> In this test I had a file hello.txt that got renamed to hello1.txt in\n> one branch and hello2.txt in another. Then I merged the changes between\n> the 2 branches.\n> \n> Here is how it looked after the merge in bzr:\n> \n> bzr status\n> renamed:\n> hello2.txt => hello1.txt\n> conflicts:\n> Path conflict: hello2.txt / hello1.txt\n> pending merges:\n> Nicholas Allen 2006-11-28 Renamed hello to hello1\n> \n> \n> and here's how it looked in git:\n> git status\n> #\n> # Changed but not updated:\n> # (use git-update-index to mark for commit)\n> #\n> # unmerged: hello.txt\n> # unmerged: hello1.txt\n> # unmerged: hello2.txt\n> # modified: hello2.txt\n> #\n> nothing to commit\n\nEr? What about merge printed?\n\n $ git pull . branch\n Trying really trivial in-index merge...\n fatal: Merge requires file-level merging\n Nope.\n Merging HEAD with c59706ee42aa7b6b2b203d4219210a684f5581f2\n Merging:\n 8f43c37 Moved hello.txt to hello_master.txt\n c59706e Moved hello.txt to hello_branch.txt\n found 1 common ancestor(s):\n b7d5f1a Initial commit\n CONFLICT (rename/rename): Rename hello.txt->hello_master.txt in branch \n HEAD rename hello.txt->hello_branch.txt in c59706e\n Automatic merge failed; fix conflicts and then commit the result.\n\nI agree that git-status output could be more helpful in the case of\nmerges. Well, you can always check \"git ls-files --stage\"\n\n $ git ls-files --stage --abbrev\n 100644 18249f3 1 hello.txt\n 100644 18249f3 3 hello_branch.txt\n 100644 18249f3 2 hello_master.txt\n\n> So git is not telling me that I have a conflict due to the same file\n> being renamed differently in 2 branches - well at least not in a way I\n> can comprehend anyway! Whereas bzr made this very clear. Also, in git I\n> ended up with 2 files:\n> \n> ls\n> hello1.txt hello2.txt\n> \n> whereas in bzr there was only one file and I just had to decide which\n> name it was to be given to resolve the conflict.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297045","messageId":"Pine.LNX.4.64.0611281346490.4244@woody.osdl.org","threadId":"5925","inReplyTo":"456CA981.4010808@onlinehome.de","subject":"Re: git and bzr","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-28T21:49:43Z","receivedAt":"2006-11-28T21:49:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Nov 2006, Nicholas Allen wrote:\n> \n> and here's how it looked in git:\n> git status\n\nEhh. It told you exactly what happened when you actually did the merge, \ndidn't it?\n\nYeah, \"git status\" won't tell you _why_ it results in unmerged paths, but \nthe merge will have told you. You must have seen that, but decided to \njust ignore it and not post it, because it didn't support the conclusion \nyou wanted to get, did it?\n\nThere are lots of reasons why \"git status\" may tell you that something \nisn't merged. The most common one by far being an actual data conflict, \nnot a name conflict. The reason for why something conflicts is always told \nat merge-time.\n\n"},{"id":"294145","messageId":"20061128215332.GK28337@spearce.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611281346490.4244@woody.osdl.org","subject":"Re: git and bzr","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-28T21:53:32Z","receivedAt":"2006-11-28T21:53:32Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> There are lots of reasons why \"git status\" may tell you that something \n> isn't merged. The most common one by far being an actual data conflict, \n> not a name conflict. The reason for why something conflicts is always told \n> at merge-time.\n\nExcept when you are doing a large merge, your terminal scrollback\nis really short, and there's a lot of conflicts. Then you can't\nsee what merge said about any given file. :-(\n\nFortunately its easy to back out of the merge and redo it with\nlarge enough scrollback, or redirecting it to a file for later\nreview, but its annoying that we don't save that information off\nfor later review.\n\n-- \n"},{"id":"296170","messageId":"456CB13D.6090407@utoronto.ca","threadId":"5925","inReplyTo":"200611281943.40354.jnareb@gmail.com","subject":"Re: git and bzr","fromName":"Aaron Bentley","fromEmail":"aaron.bentley@utoronto.ca","sentAt":"2006-11-28T21:59:25Z","receivedAt":"2006-11-28T21:59:25Z","isPatch":false,"sender":{"key":"aaron.bentley@utoronto.ca","avatar":"https://gravatar.com/avatar/36553401731241ca7a18125e0011a6b8dfa875fccb1b21163b8544cf34d75e81?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJakub Narebski wrote:\n> Well, I gues that with \"annotate friendly\" (weave or knit) storage\n> annotate/blame would be faster. But fast annotate was not one of the\n> design goals of git.\n> \n> How fast is \"bzr annotate\"?\n\n$ time bzr annotate builtins.py > /dev/null\n\nreal 0m1.479s\nuser 0m1.430s\nsys 0m0.030s\n\nbuiltins.py has 953 ancestor revisions (i.e. revisions that modified it)\nand 3016 lines.\n\nThat's on a machine with 4141.87 Bogomips. I did optimize annotate\nslightly, but I'm submitting the optimization for our 0.14.0 release.\n\nAaron\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.1 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFFbLE90F+nu1YWqI0RAlkdAJ99Ca4ITlwx+TuGvBmux0HPDpx28QCfTY0h\nlJYpnpcpWs8SpAP31x48NF4=\n=EDXr\n"},{"id":"294051","messageId":"456CB197.2030201@onlinehome.de","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611281346490.4244@woody.osdl.org","subject":"Re: git and bzr","fromName":"Nicholas Allen","fromEmail":"nick.allen@onlinehome.de","sentAt":"2006-11-28T22:00:55Z","receivedAt":"2006-11-28T22:00:55Z","isPatch":false,"sender":{"key":"nick.allen@onlinehome.de","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Tue, 28 Nov 2006, Nicholas Allen wrote:\n>> and here's how it looked in git:\n>> git status\n> \n> Ehh. It told you exactly what happened when you actually did the merge, \n> didn't it?\n> \n> Yeah, \"git status\" won't tell you _why_ it results in unmerged paths, but \n> the merge will have told you. You must have seen that, but decided to \n> just ignore it and not post it, because it didn't support the conclusion \n> you wanted to get, did it?\n\nI didn't do this deliberately - it's just because merge spewed out a\nwhole load of stuff at me that I didn't understand and therefore\noverlooked the conflict message in it. I wasn't expecting to see it here\nanyway and was hoping for a short and informative summary that I would\nunderstand when I did a status.\n\nAlso what happens if I loose the messages because they scrolled off\nscreen or the power goes down, I need to reboot for some reason, or I\ndon't have time and want to shutdown my computer restart another day and\nresolve the conflicts then? All useful conflict status is lost isn't it?\nThat's why I expected git status to tell me this in some understandable\nmanner and was not even expecting it to only be in the merge output....\n\n"},{"id":"298282","messageId":"Pine.LNX.4.64.0611281355480.4244@woody.osdl.org","threadId":"5925","inReplyTo":"20061128215332.GK28337@spearce.org","subject":"Re: git and bzr","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-28T22:13:12Z","receivedAt":"2006-11-28T22:13:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Nov 2006, Shawn Pearce wrote:\n> \n> Except when you are doing a large merge, your terminal scrollback\n> is really short, and there's a lot of conflicts. Then you can't\n> see what merge said about any given file. :-(\n\nHeh. Which is partly why I just do \"git diff\", which usually tells me what \nis up, or \"git log --stat --merge\", which is usually even better. I've \nnever actually had to scroll up.\n\n[ But I'll also admit that I used to have a \"xterm*savedlines=5000\" in my \n .Xdefaults, and it might be worth it for some people. I haven't actually \n needed it with git, because the _real_ reason for it used to be applying \n patch-sets, and I've made sure that the git patch-application is so \n robust that I never need to go back and look for reasons for conflicts - \n if something conflicts, it just _stops_ and undoes the whole patch \n instead of continuing to apply the rest or leave the already-applied \n part applied. ]\n\nAlthough I agree that we could probably also improve \"git status\" output, \nespecially as I doubt it has been tested much.\n\nPeople don't tend to use \"git status\" very much, I suspect - the most \ncommon usage is not in \"git status\" itself, but simply as the commit \nmessage template, and that one obviously cannot have any unmerged stuff at \nall (since then we'd refuse to even go as far as asking for a commit \nmessage in the first place).\n\nFiguring out that the reason for a conflict is a name clash is not \nnecessarily possible after the merge, though: it's really up to the merge \npolicy to decide to merge a file cleanly or not, and the \"Why\" part of why \nsome particular merge policy decided not the resolve a file is really \ninternal to the policy, and not externally visible in the tree itself.\n\n(But we can certainly see whether it was a pure content conflict or \nwhether it had some component of a name clash by just looking at what \nstages we have for a name: so we could at least separate out the causes \nfor merge failures at least _partially_ in \"git status\")\n\n> Fortunately its easy to back out of the merge and redo it with\n> large enough scrollback, or redirecting it to a file for later\n> review, but its annoying that we don't save that information off\n> for later review.\n\nI personally find \"git log --merge\" to be a huge timesaver. But I have to \nsay, I don't think I've seen more than one or two name conflicts ever, and \nalmost all of the true issues tend to be just regular data conflicts. So \nthat's what I personally care about most.\n\n[ For the non-git users, \"git log --merge\" is just shorthand for a much \n more complicated git revision parsing expression which boils down to: \n \"show all commits as they pertain to any remaining unmerged pathnames, \n and only within the symmetrical set difference between the two branches \n you merged\". You could write it out as\n\n\tgit log ORIG_HEAD...MERGE_HEAD -- $(git ls-files --unmerged)\n\n but that \"git log --merge\" is a much simpler shorthand for that thing. \n\n It's not that merge conflicts are necessarily common, but when they do \n happen, that's where you _really_ want the SCM to support you in \n figuring out what happened ]\n\nSo with \"git diff\" showing a three-way diff for anything unmerged, and \n\"git log --merge\" showing the commits that caused the problems, I don't \nthink I've ever really needed to go back and say \"ok, so why did that \nfail\". \n\nIt's just that \"git status\" was never what I'd have used in the first \nplace. I guess it's been long enough since I used CVS that \"git status\" \ndoesn't even enter my mind all that much on a merge failure.\n\n"},{"id":"295076","messageId":"46a038f90611281414y165ed376r80e3dbc3c7888985@mail.gmail.com","threadId":"5925","inReplyTo":"456CADE9.7060503@onlinehome.de","subject":"Re: git and bzr","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-11-28T22:14:22Z","receivedAt":"2006-11-28T22:14:22Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/29/06, Nicholas Allen wrote:\n> yes I can see if you just use plain patches. In bzr though there are\n> bundles that store extra data along with the patch and if you use this\n> instead of a simple patch this will never be a problem as bzr can then\n> notice the same bundle being merged into 2 branches.\n\nWell, there you start depending on everyone using bzr and providing\nmetadata-added patches. Git is really good at dealing with scenarios\nwhere not everyone is using Git.. so the\ncontent-is-kind-and-metadata-be-damned pays off handsomely.\n\nAnd the \"scenarios where not everyone is using Git\" are everytime that\nwe are tracking a project that uses a different SCM. For me, the\n\"killer-app\" of git is that, as it does not rely on magic metadata, it\nis perfectly useful on projects that I track that use CVS or SVN.\n\nI submit or commit patches upstream and git spots the commits being\nechoed back in just right because it does not rely on the metadata.\nOnly on the content.\n\ncheers,\n\n\nmartin\n"},{"id":"295125","messageId":"200611282316.27580.jnareb@gmail.com","threadId":"5925","inReplyTo":"456CB13D.6090407@utoronto.ca","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-28T22:16:27Z","receivedAt":"2006-11-28T22:16:27Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aaron Bentley wrote:\n> Jakub Narebski wrote:\n>> Well, I gues that with \"annotate friendly\" (weave or knit) storage\n>> annotate/blame would be faster. But fast annotate was not one of the\n>> design goals of git.\n>>\n>> How fast is \"bzr annotate\"?\n> \n> $ time bzr annotate builtins.py > /dev/null\n> \n> real 0m1.479s\n> user 0m1.430s\n> sys 0m0.030s\n> \n> builtins.py has 953 ancestor revisions (i.e. revisions that modified\n> it) and 3016 lines.\n> \n> That's on a machine with 4141.87 Bogomips. I did optimize annotate\n> slightly, but I'm submitting the optimization for our 0.14.0 release.\n\nHmmm... git-blame (without contents moving or rename detection) takes \naround 2s user+sys on 2002 BogoMIPS machine, as compared to 1.5s \nuser+sys for bzr annotate on 4141.87 BogoMIPS machine.\n\nrevision.c has 1208 lines, 62 unique commits in git-blame output, 90 \ncommits history, 102 commits full history.\n-- \nJakub Narebski\n"},{"id":"294971","messageId":"46a038f90611281419v5a5f84bfke35a32bb8c23d259@mail.gmail.com","threadId":"5925","inReplyTo":"46a038f90611281414y165ed376r80e3dbc3c7888985@mail.gmail.com","subject":"Re: git and bzr","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-11-28T22:19:05Z","receivedAt":"2006-11-28T22:19:05Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/29/06, Martin Langhoff wrote:\n> Well, there you start depending on everyone using bzr and providing\n> metadata-added patches. Git is really good at dealing with scenarios\n> where not everyone is using Git.. so the\n> content-is-kind-and-metadata-be-damned pays off handsomely.\n\ncontent-is-KING-and-metadata-be-damned :-)\n\ncheers,\n\n\n"},{"id":"296680","messageId":"ekicoi$jgk$1@sea.gmane.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611281355480.4244@woody.osdl.org","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-28T22:22:57Z","receivedAt":"2006-11-28T22:22:57Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> [ For the non-git users, \"git log --merge\" is just shorthand for a much \n>   more complicated git revision parsing expression which boils down to: \n>   \"show all commits as they pertain to any remaining unmerged pathnames, \n>   and only within the symmetrical set difference between the two branches \n>   you merged\". You could write it out as\n> \n>         git log ORIG_HEAD...MERGE_HEAD -- $(git ls-files --unmerged)\n> \n>   but that \"git log --merge\" is a much simpler shorthand for that thing. \n> \n>   It's not that merge conflicts are necessarily common, but when they do \n>   happen, that's where you _really_ want the SCM to support you in \n>   figuring out what happened ]\n\nIt would be nice if this was documented in git-log(1), and not only\n_partially_ in git-rev-list(1). And it would be nice to have this in the\nproposed \"Branches and merges\" tutorial (part 3?) as well.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295405","messageId":"Pine.LNX.4.64.0611281413310.4244@woody.osdl.org","threadId":"5925","inReplyTo":"456CB197.2030201@onlinehome.de","subject":"Re: git and bzr","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-28T22:25:11Z","receivedAt":"2006-11-28T22:25:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Nov 2006, Nicholas Allen wrote:\n> \n> Also what happens if I loose the messages because they scrolled off\n> screen or the power goes down, I need to reboot for some reason, or I\n> don't have time and want to shutdown my computer restart another day and\n> resolve the conflicts then?\n\nI'd suggest just re-doing the merge. Something like\n\n\tgit reset --hard\n\tgit merge -m \"dummy message\" MERGE_HEAD\n\nwill do it for you (that's the new \"nicer syntax\" for doing a merge, in \nreal life I'd personally just have done a re-pull or somehing)\n\n> All useful conflict status is lost isn't it?\n\nNo, it's actually there, but \"git status\" doesn't really explain it to \nyou.\n\nThe go-to command tends to be \"git diff\", which after a merge will not \nshow anything that already merged correctly (because it will have been \nupdated in the git index _and_ updated in the working tree, so there will \nbe no diff from stuff that auto-merged). So any output at all after a \nfailed merge from \"git diff\" generally tells you exactly what failed.\n\nBut since 99%+ of all merge conflicts are data-conflicts, I suspect the \noutput is mostly geared towards that.\n\nThe other useful tools to be used are \"git log --merge\" (explained in a \nseparate mail) and for people like me who like the git index and grok it \nfully, doing a\n\n\tgit ls-files --unmerged --stage\n\nis probably what I'd do (but I have to admit, that is _not_ a very \nuser-friendly interface - you need to not only have understood the index \nfile, you actually need to understand it on a very deep level).\n\n\"git status\" is really used to be just a stupid around \"git ls-files\" \n(it's now largely a built-in), but it was really _so_ stupid that it \ndoesn't really try to explain what it does - it's more like a simplified \nversion of ls-files with some of the information pruned away, and other \nparts in a slightly more palatable format ;)\n\nSo improving \"git status\" might mean that some people could avoid having \nto learn about the index file details ;)\n\n"},{"id":"294128","messageId":"456CB96B.1030504@onlinehome.de","threadId":"5925","inReplyTo":"20061128214531.GA24299@jameswestby.net","subject":"Re: git and bzr","fromName":"Nicholas Allen","fromEmail":"nick.allen@onlinehome.de","sentAt":"2006-11-28T22:34:19Z","receivedAt":"2006-11-28T22:34:19Z","isPatch":false,"sender":{"key":"nick.allen@onlinehome.de","avatar":null},"body":"Thanks for the informative response. It helped but I'm still slightly\nconfused by git - I think I need to play around with it a bit more to\nunderstand and get more familiar with the concepts...\n\nPurely from an initial usage point of view though, for me at least, the\nbzr output needed no explanation which I think is indicative of a good\nuser interface whereas the git was not so clear or obvious - there must\nbe room for improvement in git's user friendliness here surely. But that\nmight just be because I am clueless when it comes to the way git works\nand the concepts it uses ;-)\n\n"},{"id":"295825","messageId":"456CB9D3.4060900@onlinehome.de","threadId":"5925","inReplyTo":"46a038f90611281414y165ed376r80e3dbc3c7888985@mail.gmail.com","subject":"Re: git and bzr","fromName":"Nicholas Allen","fromEmail":"nick.allen@onlinehome.de","sentAt":"2006-11-28T22:36:03Z","receivedAt":"2006-11-28T22:36:03Z","isPatch":false,"sender":{"key":"nick.allen@onlinehome.de","avatar":null},"body":"Martin Langhoff wrote:\n> On 11/29/06, Nicholas Allen wrote:\n>> yes I can see if you just use plain patches. In bzr though there are\n>> bundles that store extra data along with the patch and if you use this\n>> instead of a simple patch this will never be a problem as bzr can then\n>> notice the same bundle being merged into 2 branches.\n> \n> Well, there you start depending on everyone using bzr and providing\n> metadata-added patches. Git is really good at dealing with scenarios\n> where not everyone is using Git.. so the\n> content-is-kind-and-metadata-be-damned pays off handsomely.\n> \n> And the \"scenarios where not everyone is using Git\" are everytime that\n> we are tracking a project that uses a different SCM. For me, the\n> \"killer-app\" of git is that, as it does not rely on magic metadata, it\n> is perfectly useful on projects that I track that use CVS or SVN.\n> \n> I submit or commit patches upstream and git spots the commits being\n> echoed back in just right because it does not rely on the metadata.\n> Only on the content.\n> \n> cheers,\n> \n> \n> martin\n> ps: hope you don't mind I re-added the CC to git@vger in my reply\n\nOf course not - I also added bzr mailing list back on this discussion too...\n\nI have to agree that's pretty cool!\n\nFor the kind of development we do this is not really a big deal though\nas all developers can agree on using one RCS. But if you mix git and svn\nin this way then the changes can only go one way (from svn to git) can't\nthey as svn is not so intelligent so this somewhat limits its usefulness\ndoesn't it?\n\nI know bzr it has some beta level plugin support for SVN foreign\nbranches (git, mercurial and svk ones too I think) and I believe this\nworks in both directions. So you can commit to bzr, push that to an svn\nrepository and also pull changes from svn. Merge branches in bzr and\ncommit back to svn with log messages and history intact. So bzr still\nallows the use of multiple RCS systems...\n\n"},{"id":"296336","messageId":"Pine.LNX.4.64.0611281432300.4244@woody.osdl.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611281413310.4244@woody.osdl.org","subject":"Re: git and bzr","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-28T22:41:31Z","receivedAt":"2006-11-28T22:41:31Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Nov 2006, Linus Torvalds wrote:\n> On Tue, 28 Nov 2006, Nicholas Allen wrote:\n> > \n> > All useful conflict status is lost isn't it?\n> \n> No, it's actually there, but \"git status\" doesn't really explain it to \n> you.\n\nSide note, to clarify: in the _simple_ cases it's all actually there.\n\nI can well imagine that in more complex cases, involving multiple \ndifferent files, you may well want to re-do the merge and let the merge \ntell you why it refused to merge something.\n\nSo the index, for example, contains just a \"final end result\" of what the \nmerge gave up on, and while for a simple rename conflict like your example \nyou could certainly see that directly from the index state (and thus we \ncould, for example, have a \"git status\" that talks about it being a \nfilename conflict), if you have a criss-cross rename, the index itself \ndoesn't really tell you _why_, and it could look superficially like a data \nconflict. \n\nIn such a case, you'd really have to either go back to the merge itself to \nsee what happened, or you'd use the \"git log\" thing and just work it out \nfrom there (ie you can ask \"git log\" to tell you about any renames as they \nhappened etc).\n\nI don't think I've actually hit a complex enough merge to need this yet, \nbut the graphical tools should help too, ie \"gitk --merge\" should give you \neverything that \"git log --merge\" gives you (ie just the commits that \naren't common, and simplified to just the ones that matter for the \nunmerged filenames in the end result). I can well imagine that being \nuseful too.\n\nSo the tools are certainly there. \"git status\" just isn't necessarily the \nbest one (or the best that it could be, for that matter)..\n\n"},{"id":"296997","messageId":"456CBC3D.8020409@onlinehome.de","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611281413310.4244@woody.osdl.org","subject":"Re: git and bzr","fromName":"Nicholas Allen","fromEmail":"nick.allen@onlinehome.de","sentAt":"2006-11-28T22:46:21Z","receivedAt":"2006-11-28T22:46:21Z","isPatch":false,"sender":{"key":"nick.allen@onlinehome.de","avatar":null},"body":"\n> \n> The other useful tools to be used are \"git log --merge\" (explained in a \n> separate mail) and for people like me who like the git index and grok it \n> fully, doing a\n> \n> \tgit ls-files --unmerged --stage\n> \n> is probably what I'd do (but I have to admit, that is _not_ a very \n> user-friendly interface - you need to not only have understood the index \n> file, you actually need to understand it on a very deep level).\n> \n> \"git status\" is really used to be just a stupid around \"git ls-files\" \n> (it's now largely a built-in), but it was really _so_ stupid that it \n> doesn't really try to explain what it does - it's more like a simplified \n> version of ls-files with some of the information pruned away, and other \n> parts in a slightly more palatable format ;)\n> \n> So improving \"git status\" might mean that some people could avoid having \n> to learn about the index file details ;)\n\nThat sounds good. Better output on status would be nice ;-)\n\n"},{"id":"298265","messageId":"46a038f90611281447j66ea97f2j9ecbe9af0edcc620@mail.gmail.com","threadId":"5925","inReplyTo":"456CB9D3.4060900@onlinehome.de","subject":"Re: git and bzr","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-11-28T22:47:38Z","receivedAt":"2006-11-28T22:47:38Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/29/06, Nicholas Allen wrote:\n> > ps: hope you don't mind I re-added the CC to git@vger in my reply\n>\n> Of course not - I also added bzr mailing list back on this discussion too...\n\nCool\n\n> For the kind of development we do this is not really a big deal though\n> as all developers can agree on using one RCS. But if you mix git and svn\n> in this way then the changes can only go one way (from svn to git) can't\n> they as svn is not so intelligent so this somewhat limits its usefulness\n> doesn't it?\n\nWell, if you look in the git toolset, you'll find things like git-svn\nwhich is geared to make it almost transparent to use git to work on a\nproject where the upstream is using svn and push patches into SVN (if\nyou have write access, naturally). And git-cvsexportcommit which is a\nlot less useful but helps me push series of patches from git into cvs\neasily and with the certaintly that I am not messing up the content.\n\n> I know bzr it has some beta level plugin support for SVN foreign\n> branches (git, mercurial and svk ones too I think) and I believe this\n> works in both directions. So you can commit to bzr, push that to an svn\n> repository and also pull changes from svn. Merge branches in bzr and\n> commit back to svn with log messages and history intact. So bzr still\n> allows the use of multiple RCS systems...\n\nSounds roughly like git-svn ;-)\n\nconverge, ye DSCMs\n\n\n"},{"id":"298906","messageId":"456CBCD5.3050505@onlinehome.de","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611281432300.4244@woody.osdl.org","subject":"Re: git and bzr","fromName":"Nicholas Allen","fromEmail":"nick.allen@onlinehome.de","sentAt":"2006-11-28T22:48:53Z","receivedAt":"2006-11-28T22:48:53Z","isPatch":false,"sender":{"key":"nick.allen@onlinehome.de","avatar":null},"body":"\n> \n> So the tools are certainly there. \"git status\" just isn't necessarily the \n> best one (or the best that it could be, for that matter)..\n\nI guess I hit a limitation in the output of status as opposed to a\nlimitation in what git can do ;-)\n\nNick\n\n\n\n"},{"id":"297298","messageId":"456CEF31.8080600@webdrake.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611271834090.30076@woody.osdl.org","subject":"Re: git and bzr","fromName":"Joseph Wakeling","fromEmail":"joseph.wakeling@webdrake.net","sentAt":"2006-11-29T02:23:45Z","receivedAt":"2006-11-29T02:23:45Z","isPatch":false,"sender":{"key":"joseph.wakeling@webdrake.net","avatar":null},"body":"Thanks to everyone for your very detailed responses. :-)\n\nOn the subject of blame and pulling patches from unrelated branches,\n\nJakub Narebski wrote:\n> In git repository can have unrelated branches. So you can fetch unrelated\n> repository into your repository, and merge/cherry-pick from there\n> if needed.\n\nSean wrote:\n> The Git cherry-pick command lets you grab specific commits from\n> other branches in your repo. But cherry-pick works at the commit\n> level, there is no easy way to grab a single function for instance\n> and merge just its history into another branch.\n\nLinus Torvalds wrote:\n> pickaxe wasn't in the released version back when the discussions were \n> raging, but it's there now. Except it's really called \"git blame\" these \n> days (and \"git annotate\") since it's taken over both of those duties.\n> \n> However...\n> \n>> A frustration with bzr is that pulling or\n>> merging patches from another branch or repo requires them to share the\n>> same HEAD. Is this a requirement in git or can I say, \"Hey, I like that\n>> particular function in project XXX, I'm going to pull that individual\n>> bit of code and its development history into project YYY\"?\n> \n> ... it's not _quite_ that smart. It will only look for sources to new \n> functions from existing sources in the tree that preceded the commit that \n> added the function, so it will _not_ see it coming from another branch or \n> another project entirely.\n> \n> So when you ask for code annotations (use the \"-C\" flag to see code moved \n> across from other files), it will still limit itself to just a particular \n> input set, and not go gallivating over all possible branches and projects \n> you might have in your repository.\n\nSo ... if I understand correctly, I can get patches from somewhere else,\nbut in the branch history, I will not be able to tell the difference\nfrom having simply newly created them?\n\nWith regards to git blame/pickaxe/annotate, the idea of tracking *code*\nrather than files was one thing that really excited me when I read about\nit in the earlier discussion, and is probably the main reason I'm trying\nout git. I'd like to understand this properly so is there a simple\nexercise I can do to demonstrate its capabilities? I tried an\nexperiment where I created one file with two lines, then cut one of the\nlines, pasted it into a new file, and committed both changes at the same\ntime. But git blame -C on the second file just gives me the\ntime/date/sha1 of its creation, and no indication that the line was\ntaken from elsewhere.\n\nBack to the more basic queries ... one more difference I've observed\nfrom bzr, after playing around for a while, involves the commands to\nundo changes and commits. It looks like git reset combines the\ncapabilities of both bzr uncommit and bzr revert: I can undo changes\nsince the last commit by resetting to HEAD, and I can undo commits by\nresetting to HEAD^ or earlier.\n\nSome things here I'm not quite sure about:\n(1) the difference between git reset --soft and git reset --mixed,\nprobably because I don't understand the way the index works, the\ndifference between changed, updated and committed.\n(2) How to remove changes made to an individual file since the last commit.\n\nLast, could someone explain the git merge command? git pull seems to do\nmany things which I would need to use bzr merge for---I can \"pull\"\nbetween branches which have diverged, for example. I don't understand\nquite what git merge does that's different, and when to use one or the\nother.\n\nMany thanks again to everyone,\n\n"},{"id":"294976","messageId":"Pine.LNX.4.64.0611281906520.3395@woody.osdl.org","threadId":"5925","inReplyTo":"456CEF31.8080600@webdrake.net","subject":"Re: git and bzr","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-29T03:51:19Z","receivedAt":"2006-11-29T03:51:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 29 Nov 2006, Joseph Wakeling wrote:\n> \n> So ... if I understand correctly, I can get patches from somewhere else,\n> but in the branch history, I will not be able to tell the difference\n> from having simply newly created them?\n\nThink of it this way: if the _patch_ looks like it's a code movement, then \n\"git blame\" will show it as a code movement. Ie, if the patch (to a human) \nlooks like it's moving a function from one file into another (which in a \npatch will obviously be a question of removing it from one file, and \nadding it to another), then git will also see it that way, and then \"git \nblame\" will also follow its history as it moved.\n\nBut if somebody sends you a patch that just adds a new function that \ndidn't exist in that context at all, then \"git blame\" won't ever realize \nthat that new function was taken from another branch entirely.\n\n> With regards to git blame/pickaxe/annotate, the idea of tracking *code*\n> rather than files was one thing that really excited me when I read about\n> it in the earlier discussion, and is probably the main reason I'm trying\n> out git. I'd like to understand this properly so is there a simple\n> exercise I can do to demonstrate its capabilities? I tried an\n> experiment where I created one file with two lines, then cut one of the\n> lines, pasted it into a new file, and committed both changes at the same\n> time. But git blame -C on the second file just gives me the\n> time/date/sha1 of its creation, and no indication that the line was\n> taken from elsewhere.\n\nActually, I think you found a bug.\n\nNow, with small changes, \"git blame -C\" will just ignore copies entirely, \nso your particular test might not have even been supposed to work, but \ntrying with a new git repo with two bigger files checked in at the initial \ncommit, I'm actually not seeing \"git blame -C\" do the right thing even for \nreal code movement.\n\nAnd the problem seems to go to the \"root commit\": if the file existed in \nthe root, the logic in \"git blame\" to diff against the (nonexistent) \nparent of the root commit won't do the right thing, and that just confuses \ngit blame entirely.\n\nI think Junio screwed up at some point. I'll send him a bug-report once \nI've triaged this a bit more, but I can recreate your breakage if I start \na new git database and create two files in the root, and move data between \nthem in the second commit (but if I instead create the second file in the \nsecond commit, and do the movement in the third commit, git blame -C works \nagain ;).\n\n> Back to the more basic queries ... one more difference I've observed\n> from bzr, after playing around for a while, involves the commands to\n> undo changes and commits. It looks like git reset combines the\n> capabilities of both bzr uncommit and bzr revert: I can undo changes\n> since the last commit by resetting to HEAD, and I can undo commits by\n> resetting to HEAD^ or earlier.\n\nI'm not quite sure what \"bzr revert\" does. Git does have a \"revert\" too, \nbut it will append a _new_ commit that actually undoes the commit you're \nasking to revert. If you want to just \"undo history\" (whether it's one \ncommit or many - I don't see why it would be different) then yes, \"git \nreset\" is the thing to use.\n\nI _suspect_ that bzr people use \"uncommit\" to undo a commit in order to \nfix it up. In git, you could do that with \"git reset\" and a new commit, \nbut the normal thing to do is just to fix it up, and then do \n\n\tgit commit --amend\n\ninstead (which amends the last commit to include whatever fixups you did).\n\n> Some things here I'm not quite sure about:\n> (1) the difference between git reset --soft and git reset --mixed,\n> probably because I don't understand the way the index works, the\n> difference between changed, updated and committed.\n\nYou'd generally not want to use \"--soft\" unless you know what the index \nreally is. Once you do know about all the index issues, you'll know why \nit's different from \"--mixed\", but in general, no normal person would ever \nuse _either_ --soft (because not changing the index is too confusing if \nyou don't know about it) or --mixed (because it's the default).\n\nSo in reality, you should use\n\n\tgit reset\n\nto reset everything but the actual working tree (and it will talk about \nthe files that no longer match the state you are resetting _to_, if any \nsuch files exist), or\n\n\tgit reset --hard\n\nto reset everything.\n\nAny other usage is strictly for hardcore people only, and if you don't \nknow you want to use it, you shouldn't even consider it.\n\nIn fact, I'm pretty hardcore, and I don't think I've ever really used \n\"--soft\". It's largely been replaced by \"git commit --amend\", because \namending a commit used to be the only reason to use \"--soft\", really.\n\nSo it might even be worthwhile just dropping \"--soft\" and \"--mixed\" \naltogether, but in the meantime, you might as well just ignore them.\n\n> (2) How to remove changes made to an individual file since the last commit.\n\n\"git checkout file\"\n\n\n> Last, could someone explain the git merge command?\n\nI argued that we should never teach people to use it at all (because \"git \npull\" really does everything it can do), but people on the git list said \npeople are used to merging, so it exists, and these days the syntax is \nmore usable than it used to be.\n\n> git pull seems to do many things which I would need to use bzr merge \n> for---I can \"pull\" between branches which have diverged, for example. \n> I don't understand quite what git merge does that's different, and when \n> to use one or the other.\n\nHeh. I'm with you. I'm in the \"don't use 'git merge' at all\" camp, but it \nwas argued that people coming from non-git backgrounds would find it \ntoo confusing to just use \"git pull\" for merging ;)\n\n"},{"id":"294878","messageId":"7v8xhusmk5.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611281906520.3395@woody.osdl.org","subject":"Re: git and bzr","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-29T08:07:38Z","receivedAt":"2006-11-29T08:07:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> And the problem seems to go to the \"root commit\": if the file existed in \n> the root, the logic in \"git blame\" to diff against the (nonexistent) \n> parent of the root commit won't do the right thing, and that just confuses \n> git blame entirely.\n>\n> I think Junio screwed up at some point. I'll send him a bug-report once \n> I've triaged this a bit more, but I can recreate your breakage if I start \n> a new git database and create two files in the root, and move data between \n> them in the second commit (but if I instead create the second file in the \n> second commit, and do the movement in the third commit, git blame -C works \n> again ;).\n\nIs it safe to assume that the \"automatically turning --show-name\non\" fixes this issue and it does not have anything to do with\nthe root commit? Given the way the \"passing the blame\"\nalgorithm works, there should not be anything special about the\nroot commit --- if some blame remains in a commit:path pair, and\nif the commit does not have parents, it takes the blame right\naway without needing to run any diff.\n\n> In fact, I'm pretty hardcore, and I don't think I've ever really used \n> \"--soft\". It's largely been replaced by \"git commit --amend\", because \n> amending a commit used to be the only reason to use \"--soft\", really.\n> So it might even be worthwhile just dropping \"--soft\" and \"--mixed\" \n> altogether, but in the meantime, you might as well just ignore them.\n\nEverything in the above paragraph is correct.\n\n>> git pull seems to do many things which I would need to use bzr merge \n>> for---I can \"pull\" between branches which have diverged, for example. \n>> I don't understand quite what git merge does that's different, and when \n>> to use one or the other.\n>\n> Heh. I'm with you. I'm in the \"don't use 'git merge' at all\" camp, but it \n> was argued that people coming from non-git backgrounds would find it \n> too confusing to just use \"git pull\" for merging ;)\n\nInteresting. I had exactly the same response as yours when I\nread Joseph's message ;-).\n"},{"id":"294265","messageId":"Pine.LNX.4.63.0611291145510.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"456CBCD5.3050505@onlinehome.de","subject":"Re: git and bzr","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-29T10:49:19Z","receivedAt":"2006-11-29T10:49:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 28 Nov 2006, Nicholas Allen wrote:\n\n> [Linus wrote...]\n> > \n> > So the tools are certainly there. \"git status\" just isn't necessarily the \n> > best one (or the best that it could be, for that matter)..\n> \n> I guess I hit a limitation in the output of status as opposed to a\n> limitation in what git can do ;-)\n\nI think it is something different altogether: you learnt how to use CVS, \nand you learnt how to use bzr, and you are now biased towards using the \nsame names for the same operations in git.\n\nI actually use git-status quite often, just before committing, to know \nwhat I changed. But I will probable retrain my mind to use \"git diff\" or \neven \"git diff --stat\", because it is more informative.\n\nAs for your scenario: There really should be a \"what to do when my merge \nscrewed up?\" document.\n\nCiao,\nDscho\n"},{"id":"298908","messageId":"Pine.LNX.4.63.0611291149440.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611281413310.4244@woody.osdl.org","subject":"Re: git and bzr","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-29T10:52:22Z","receivedAt":"2006-11-29T10:52:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 28 Nov 2006, Linus Torvalds wrote:\n\n> On Tue, 28 Nov 2006, Nicholas Allen wrote:\n> > \n> > All useful conflict status is lost isn't it?\n> \n> No, it's actually there, but \"git status\" doesn't really explain it to \n> you.\n> \n> The go-to command tends to be \"git diff\", which after a merge will not \n> show anything that already merged correctly (because it will have been \n> updated in the git index _and_ updated in the working tree, so there will \n> be no diff from stuff that auto-merged).\n\nThis is actually the most meaningful argument for not hiding the index. \nUsually I explain it to people as a \"staging area\" standing between your \nworking directory, and the next committed state.\n\nBut I will start explaining the index with \"what if your merge failed?\".\n\nCiao,\nDscho\n\n\n\n\n"},{"id":"298907","messageId":"200611291201.42561.jnareb@gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0611291145510.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-29T11:01:41Z","receivedAt":"2006-11-29T11:01:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Tue, 28 Nov 2006, Nicholas Allen wrote:\n> \n>> [Linus wrote...]\n>>> \n>>> So the tools are certainly there. \"git status\" just isn't necessarily the \n>>> best one (or the best that it could be, for that matter)..\n>> \n>> I guess I hit a limitation in the output of status as opposed to a\n>> limitation in what git can do ;-)\n> \n> I think it is something different altogether: you learnt how to use CVS, \n> and you learnt how to use bzr, and you are now biased towards using the \n> same names for the same operations in git.\n> \n> I actually use git-status quite often, just before committing, to know \n> what I changed. But I will probable retrain my mind to use \"git diff\" or \n> even \"git diff --stat\", because it is more informative.\n> \n> As for your scenario: There really should be a \"what to do when my merge \n> screwed up?\" document.\n\nIt would be nice to have git-resolved (or git-resolve) wrapper around\ngit-update-index similar to git-add, git-mv, git-rm which would mark\nfile as resolved, without need for git-update-index, git-add and git-rm\neven in the case of CONFLICT(rename/rename). Although I'm not sure\nif it could work in all cases in the simple form of \"git resolved \",\ne.g. in the case of CONFLICT(add/add).\n\nBy the way, I wonder if git can detect the case when the same (or nearly\nthe same) file was added in two different branches under different\nfilename...\n\n"},{"id":"297390","messageId":"456D7A76.3080605@webdrake.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611281906520.3395@woody.osdl.org","subject":"git blame [was: git and bzr]","fromName":"Joseph Wakeling","fromEmail":"joseph.wakeling@webdrake.net","sentAt":"2006-11-29T12:17:58Z","receivedAt":"2006-11-29T12:17:58Z","isPatch":false,"sender":{"key":"joseph.wakeling@webdrake.net","avatar":null},"body":"Linus Torvalds wrote:\n> Now, with small changes, \"git blame -C\" will just ignore copies entirely, \n\nObvious when I think about it, otherwise every 'int i;' in the kernel\nwould have a huge blame list ... :-O\n\n> I think Junio screwed up at some point. I'll send him a bug-report once \n> I've triaged this a bit more, but I can recreate your breakage if I start \n> a new git database and create two files in the root, and move data between \n> them in the second commit (but if I instead create the second file in the \n> second commit, and do the movement in the third commit, git blame -C works \n> again ;).\n\nActually my setup was like the latter situation you describe, so blame\nwas probably working fine and just ignoring the small change. But\nserendipity is a wonderful thing. :-)\n\n -- Joe\n"},{"id":"293896","messageId":"Pine.LNX.4.64.0611290830010.3395@woody.osdl.org","threadId":"5925","inReplyTo":"456D7A76.3080605@webdrake.net","subject":"Re: git blame [was: git and bzr]","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-29T16:39:23Z","receivedAt":"2006-11-29T16:39:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 29 Nov 2006, Joseph Wakeling wrote:\n>\n> Linus Torvalds wrote:\n> > Now, with small changes, \"git blame -C\" will just ignore copies entirely, \n> \n> Obvious when I think about it, otherwise every 'int i;' in the kernel\n> would have a huge blame list ... :-O\n\nIndeed. We didn't do that heuristic originally, and the most common \nsequence that was \"blamed\" on being copied from somewhere else was \nsomething like the string\n\n\t\"}}}\"\n\nwhich is obviously very common in C, especially when you have coding \nconventions and people follow them ;)\n\n> > them in the second commit (but if I instead create the second file in the \n> > second commit, and do the movement in the third commit, git blame -C works \n> > again ;).\n> \n> Actually my setup was like the latter situation you describe, so blame\n> was probably working fine and just ignoring the small change. But\n> serendipity is a wonderful thing. :-)\n\nYeah. As it turns out, the bug was really that \"git blame\" ended up just \nnot showing the filenames (that it had followed correctly), because it had \ndecided (incorrectly) that they weren't interesting because it all came \nfrom the same commit, and it had already shown that commit (just not that \n_file_ in that commit).\n\nSo it's fixed now, and probably would never trigger except for the stupid \nspecial case that was \"let's just show an example of this\" ;)\n\n"},{"id":"296848","messageId":"Pine.LNX.4.64.0611290922410.3513@woody.osdl.org","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0611291149440.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git and bzr","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-29T17:29:52Z","receivedAt":"2006-11-29T17:29:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 29 Nov 2006, Johannes Schindelin wrote:\n> \n> On Tue, 28 Nov 2006, Linus Torvalds wrote:\n> > \n> > The go-to command tends to be \"git diff\", which after a merge will not \n> > show anything that already merged correctly (because it will have been \n> > updated in the git index _and_ updated in the working tree, so there will \n> > be no diff from stuff that auto-merged).\n> \n> This is actually the most meaningful argument for not hiding the index. \n> Usually I explain it to people as a \"staging area\" standing between your \n> working directory, and the next committed state.\n> \n> But I will start explaining the index with \"what if your merge failed?\".\n\nThe thing is, the staging area is needed for a lot more than just merges. \nEvery single SCM has one, because even something as _trivial_ as \"commit \nall files\" actually needs it. People don't just always think about it, and \nthe git staging area is \"bigger\" than most others.\n\nMost other SCM's have a staging area that is just a list of filenames \n(nobody thinks about it, but \"commit everything\" doesn't actually commit \neverything at all - it just commits everything /in the list of files that \nthe SCM knows about/).\n\nGit's staging area is just more complete than most other SCM's. It \ncontains not just the list of filenames, but their permissions too (where \na lot of other SCM's *cough*CVS*cough don't do permissions at all), but \nalso their content, and in the case of a merge conflict, the content of \nthe base version and the two branches to be merged.\n\nSo the index really _is_ required for pretty much all operations \n(including very much \"git commit -a\", if only because of the filename \nlist), but yeah, if you start by talking about merge conflicts, maybe \npeople understand WHY it's also important to actually stage the _contents_ \nof a file too (multiple times, in fact, for a merge conflict), not just \nits name.\n\nSo most of the time, when you use git, you can ignore the index. It's \nreally important, and it's used _all_ the time, but you can still mostly \nignore it. But when handling a merge conflict, the index is really what \nsets git apart, and what really helps a LOT.\n\nI've used other systems, but the git handling of merge conflicts really is \nsuperior. Other SCM's think that the merge algorithm is interestign and \nimportant, and that's bullshit. Merge algorithms are largely trivial and \nuninteresting. The interestign and important thing is to just handle \nfailures well, and git does that _really_ well.\n\n"},{"id":"298746","messageId":"456DD76C.4010902@gmx.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611290922410.3513@woody.osdl.org","subject":"Re: git and bzr","fromName":"Marko Macek","fromEmail":"marko.macek@gmx.net","sentAt":"2006-11-29T18:54:36Z","receivedAt":"2006-11-29T18:54:36Z","isPatch":false,"sender":{"key":"marko.macek@gmx.net","avatar":null},"body":"Linus Torvalds wrote:\n> So most of the time, when you use git, you can ignore the index. It's \n> really important, and it's used _all_ the time, but you can still mostly \n> ignore it. But when handling a merge conflict, the index is really what \n> sets git apart, and what really helps a LOT.\n \nActually, people (at least me) dislike the index because in the most common\noperations (status, diff, commit), they have to know that the command doesn't actually\ndisplay all their work but just the 'indexed' part of it. \n\nFor people used to cvs, svn and other systems it would be nicer if diff -a\nand commit -a (and possibly other commands) were the default.\n\nindex is of course necessary during merging, ... and as a speed optimization\nfor applying patches when you know the working copy is clean.\n\n"},{"id":"298331","messageId":"Pine.LNX.4.63.0611292101420.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"456DD76C.4010902@gmx.net","subject":"Re: git and bzr","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-29T20:07:04Z","receivedAt":"2006-11-29T20:07:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 29 Nov 2006, Marko Macek wrote:\n\n> Linus Torvalds wrote:\n> > So most of the time, when you use git, you can ignore the index. It's \n> > really important, and it's used _all_ the time, but you can still \n> > mostly ignore it. But when handling a merge conflict, the index is \n> > really what sets git apart, and what really helps a LOT.\n> \n> Actually, people (at least me) dislike the index because in the most \n> common operations (status, diff, commit), they have to know that the \n> command doesn't actually display all their work but just the 'indexed' \n> part of it.\n\nNo. It does display all your work.\n\nHowever, as Linus pointed out, if there are automatically merged entries \nwithout conflicts, it will not display them. Which is sane!\n\nAnd yes, you can hide some modifications by putting the modified file into \nthe index. But then you did that very much on purpose.\n\n> For people used to cvs, svn and other systems it would be nicer if diff \n> -a and commit -a (and possibly other commands) were the default.\n\nAnd what exactly do you think is happening when \"cvs add\" and \"svn add\" \ndid _not_ really add the file to the repository, but only a subsequent \n\"commit\" does?\n\n> index is of course necessary during merging, ... and as a speed \n> optimization for applying patches when you know the working copy is \n> clean.\n\nI think that it is one major achievement of git to make clear and sane \ndefinitions of branches (which are really just pointers \ninto the revision graph), and the index (which is the staging area).\n\nCiao,\nDscho\n"},{"id":"296293","messageId":"1164832677.4724.60.camel@cashmere.sps.mot.com","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0611291145510.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git and bzr","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-11-29T20:37:57Z","receivedAt":"2006-11-29T20:37:57Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Wed, 2006-11-29 at 04:49, Johannes Schindelin wrote:\n\n> As for your scenario: There really should be a \"what to do when my merge \n> screwed up?\" document.\n\nI have a few examples scenarios and some notes on\ncleaning up after failed merges in my slides from\nthe presentation I did at OLS last summer.\n\nFeel free to look at it off of www.jdl.com!\n\njdl\n\n"},{"id":"293947","messageId":"Pine.LNX.4.64.0611291235590.3513@woody.osdl.org","threadId":"5925","inReplyTo":"456DD76C.4010902@gmx.net","subject":"Re: git and bzr","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-29T20:45:18Z","receivedAt":"2006-11-29T20:45:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 29 Nov 2006, Marko Macek wrote:\n> \n> Actually, people (at least me) dislike the index because in the most common\n> operations (status, diff, commit), they have to know that the command doesn't\n> actually display all their work but just the 'indexed' part of it. \n\nI don't see your point, really.\n\nNothing forces you to change the index. None of the normal operations do \nthat, for example, and you really have to _explicitly_ ask git to update \nthe index for you.\n\nSo you can really think of it as a better list of names than what CVS and \nothers maintain for you. It's exactly the same as the CVS \"Entries\" file, \nexcept it's got capabilities that CVS will never have - tracking not just \nthe filename, but the merge status, the permissions, and the actual \ncontents of an entry.\n\nAnd by default, and in the absense of any failed merges, you will _never_ \nsee any of those extra capabilities.\n\n> For people used to cvs, svn and other systems it would be nicer if diff -a\n> and commit -a (and possibly other commands) were the default.\n\nWhy? I mean really.. Why do people mind the index? If you've not done \nanything to explicitly update it, and you just write \"git commit\", it will \ntell you exactly which files are dirty, which files are untracked, and \nthen say \"nothing to commit\".\n\nMaybe we shouldn't even say \"use git-update-index to mark for commit\", we \nshould just say \"use 'git commit -a' to mark for commit\", but the point \nis, there really is no downside. So you forget to mention which files to \ncommit, what's the downside really? It tells you what is up, and you can \njust mention the files explicitly, or use \"-a\" to say \"ok, commit \neverything that is dirty\", and it doesn't really get any simpler than \nthat.\n\nAnd the ADVANTAGES of the index are legion. You may not appreciate them \ninitially, but the disadvantages people talk about really don't exist in \nreal life, and once you actually start doing merges with conflicts, and \nfix things up one file at a time (and perhaps take a break and do \nsomething else before you come back to the rest of the conflicts), the \nindex saves your sorry ass, and is a _huge_ advantage.\n\nSimilarly, it _allows_ you to do things that just a list of files never \nallows you to. You don't _have_ to use it to mark individual files as \nbeing ready to be committed, but you _can_. It's nothing that you need to \nknow or worry about if you're not aware of the index, but it's a \ncapability that is there for when you're willing to go there.\n\nSo there really isn't any true disadvantage. Most of the people who are \nafraid of the index have probably never actually used it, and have never \neven had a _reason_ to use it. They're nervous just because they know it \nexists, and don't know what it does. But you can just ignore it.\n\nSo get over your fears, and just ignore it, and things will be fine.\n\n\t\tLinus\n\n"},{"id":"298330","messageId":"200611292149.14449.jnareb@gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0611292101420.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-29T20:49:12Z","receivedAt":"2006-11-29T20:49:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> \n> On Wed, 29 Nov 2006, Marko Macek wrote:\n>>\n>> index is of course necessary during merging, ... and as a speed \n>> optimization for applying patches when you know the working copy is \n>> clean.\n> \n> I think that it is one major achievement of git to make clear and sane \n> definitions of branches (which are really just pointers \n> into the revision graph), and the index (which is the staging area).\n\nSomething resembling index is needed anyway: 1) for \"commit all changed\nfiles\" to prepare list of files to commit, excluding ignored files,\n2) to mark files as \"to be added\" or \"to be removed\" (well, git index\ncould be a little bit smarter here in marking \"intent to add\"), 3) as\na place for doing the merging. Git just doesn't hide it.\n\nI agree that git definition of branches, and git not hiding index is\nit's advantage... and disadvantage to those who learned using version\ncontrol on other SCM.\n-- \nJakub Narebski\n"},{"id":"294883","messageId":"87bqmpvlxf.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611291235590.3513@woody.osdl.org","subject":"Re: git and bzr","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-30T00:05:16Z","receivedAt":"2006-11-30T00:05:16Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 29 Nov 2006 12:45:18 -0800 (PST), Linus Torvalds wrote:\n>\n> Nothing forces you to change the index. None of the normal operations do\n> that, for example, and you really have to _explicitly_ ask git to update\n> the index for you.\n\nYes, this is goog.\n\n> Why? I mean really.. Why do people mind the index? If you've not done\n> anything to explicitly update it, and you just write \"git commit\", it will\n> tell you exactly which files are dirty, which files are untracked, and\n> then say \"nothing to commit\".\n\nTo start with, that message confuses a lot of new users. \"What do you\nmean there's nothing to commit? I just made changes. And I know you\nnoticed them because you just mentioned the names of the files with\nthe changes to me!\".\n\nSo at the very least, there's some missing guidance as to how to get\nfrom the \"nothing to commit\" stage to actually commit the files the\nuser was trying to commit when they typed \"git commit\" in the first\nplace.\n\n> Maybe we shouldn't even say \"use git-update-index to mark for commit\", we\n> should just say \"use 'git commit -a' to mark for commit\",\n\nYes, I submitted a patch for this. I don't think Junio picked it up\nbecause it got him thinking about all the other situations where \"git\nstatus\" doesn't give as much guidance as it should\n\nEven with that, the user has to go through the process of:\n\n\tgit commit\n\t\"hmm... why didn't that work\"\n\tread message\n\tgit commit -a\n\nThat's not a _huge_ problem, but it is a little road-bump that a lot of\npeople meet on their first attempt at git. In the thread on the fedora\nmailing list that prompted my first \"user-interface warts\" and the\npatch I mentioned above, the process was worse:\n\n\tgit commit\n\t\"hmm... why didn't that work\"\n\tread message\n\tgit update-index\n\tgit commit\n\t\"crap... it still didn't work even when I did what it told me to do\"\n\nHere's the original version of that report:\n\nhttps://www.redhat.com/archives/fedora-maintainers/2006-November/msg00141.html\n\n> And the ADVANTAGES of the index are legion. You may not appreciate them\n> initially, but the disadvantages people talk about really don't exist in\n> real life, and once you actually start doing merges with conflicts, and\n> fix things up one file at a time (and perhaps take a break and do\n> something else before you come back to the rest of the conflicts), the\n> index saves your sorry ass, and is a _huge_ advantage.\n\nIn none of these recent threads have I been arguing disadvantages of\nthe index. I'm really just trying to remove one small hurdle that\ndoes trip up new users, (see above). I'm not trying to introduce any\nlarge conceptual change into how git works, nor even what experienced\nusers do.\n\n> So get over your fears, and just ignore it, and things will be fine.\n\nLet's help people do exactly that by making the behavior of \"git\ncommit -a\" be the default for \"git commit\".\n\n-Carl\n"},{"id":"298909","messageId":"87ac29vlsh.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"87bqmpvlxf.wl%cworth@cworth.org","subject":"Re: git and bzr","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-30T00:08:14Z","receivedAt":"2006-11-30T00:08:14Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 29 Nov 2006 16:05:16 -0800, Carl Worth wrote:\n> On Wed, 29 Nov 2006 12:45:18 -0800 (PST), Linus Torvalds wrote:\n> >\n> > Nothing forces you to change the index. None of the normal operations do\n> > that, for example, and you really have to _explicitly_ ask git to update\n> > the index for you.\n>\n> Yes, this is goog.\n\nI meant \"good\" there for anyone confused, (I'm not sure how that\nslipped passed my spell-checker).\n\n-Carl\n"},{"id":"298543","messageId":"ekl8j5$in4$1@sea.gmane.org","threadId":"5925","inReplyTo":"87bqmpvlxf.wl%cworth@cworth.org","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-30T00:30:13Z","receivedAt":"2006-11-30T00:30:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carl Worth wrote:\n\n> In the thread on the fedora\n> mailing list that prompted my first \"user-interface warts\" and the\n> patch I mentioned above, the process was worse:\n> \n>         git commit\n>         \"hmm... why didn't that work\"\n>         read message\n>         git update-index\n>         git commit\n>         \"crap... it still didn't work even when I did what it told me to do\"\n> \n> Here's the original version of that report:\n> \n> https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00141.html\n\nFrom the SYNOPSIS of git-update-index(1) one can see that git-update-index\nneeds files to act on.\n\nBut I agree that git is not very user friendly, and has some usability\nwarts.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294088","messageId":"456E8147.9070304@gmx.net","threadId":"5925","inReplyTo":"87bqmpvlxf.wl%cworth@cworth.org","subject":"Re: git and bzr","fromName":"Raimund Bauer","fromEmail":"ray007@gmx.net","sentAt":"2006-11-30T06:59:19Z","receivedAt":"2006-11-30T06:59:19Z","isPatch":false,"sender":{"key":"ray007@gmx.net","avatar":null},"body":"* Carl Worth wrote, On 30.11.2006 01:05:\n> Let's help people do exactly that by making the behavior of \"git\n> commit -a\" be the default for \"git commit\".\n> \nMaybe we could do that _only_ if the index matches HEAD, and otherwise \nkeep current behavior?\nSo people who don't care about the index won't get tripped up, and when \nyou do have a dirty index, you get told about it?\n> -Carl\n-- \n\nbest regards\n\n Ray\n\n\n"},{"id":"297229","messageId":"87slg1tncd.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"456E8147.9070304@gmx.net","subject":"Re: git and bzr","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-30T07:17:38Z","receivedAt":"2006-11-30T07:17:38Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 30 Nov 2006 07:59:19 +0100, Raimund Bauer wrote:\n> * Carl Worth wrote, On 30.11.2006 01:05:\n> > Let's help people do exactly that by making the behavior of \"git\n> > commit -a\" be the default for \"git commit\".\n> >\n> Maybe we could do that _only_ if the index matches HEAD, and otherwise\n> keep current behavior?\n> So people who don't care about the index won't get tripped up, and when\n> you do have a dirty index, you get told about it?\n\nI thought of that tonight and almost suggested it myself. It would be\nan attempt to satisfy both \"sides\" of the debate without either side\nhaving to fight with a default they didn't like or configure it away.\n\nI did wonder if the powers that be would find it a bit too magic, (the\nproblem with magic things is that they can sometimes be quite\nconfusing when they don't do exactly what you want).\n\nBut this might just work. It wouldn't be too bad to document, (we\nalready have several commands that change slightly if the index\ndoesn't match, (often by just refusing to do anything in a dirty\ntree)).\n\nAnd, significantly this would allow for documenting the simple\nsequence of:\n\n\t# edit file\n\tgit commit\n\nin the tutorial while also allowing what Junio wanted:\n\n\tgit update-index file\n\tgit commit\n\nwith the behavior of, (\"I already said I wanted to do a staged commit\nwhen I explicitly updated the index, so don't make me say anything\nspecial again when I go to commit\").\n\nCan we really get the best of both worlds here?\n\n-Carl\n"},{"id":"296562","messageId":"200611300831.56858.alan@chandlerfamily.org.uk","threadId":"5925","inReplyTo":"456E8147.9070304@gmx.net","subject":"Re: git and bzr","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-11-30T08:31:56Z","receivedAt":"2006-11-30T08:31:56Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Thursday 30 November 2006 06:59, Raimund Bauer wrote:\n> Maybe we could do that _only_ if the index matches HEAD, and otherwise\n> keep current behavior?\n> So people who don't care about the index won't get tripped up, and when\n> you do have a dirty index, you get told about it?\n>\n\nI have been(silently) following the git commit discussion and started being \nfully on the side of git commit -a being the default, but was slowly moving \nover towards the git commit -i being the default camp.\n\nThis post seems like a Eureka moment - chew over the problem long enough and \nsomeone comes in from left field with an off the wall remark that suddenly \nclarifies everything.\n\n\n\n-- \nAlan Chandler\n"},{"id":"298655","messageId":"fcaeb9bf0611300101s51a53b75lc7e771b067ba6e33@mail.gmail.com","threadId":"5925","inReplyTo":"456E8147.9070304@gmx.net","subject":"Re: git and bzr","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-11-30T09:01:27Z","receivedAt":"2006-11-30T09:01:27Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 11/30/06, Raimund Bauer wrote:\n> * Carl Worth wrote, On 30.11.2006 01:05:\n> > Let's help people do exactly that by making the behavior of \"git\n> > commit -a\" be the default for \"git commit\".\n> >\n> Maybe we could do that _only_ if the index matches HEAD, and otherwise\n> keep current behavior?\n\nI hate the if clause. Suppose I prefer update-index way, I would have\nto check whether HEAD matches index everytime I do a commit to make\nsure it won't do the other way.\nEither -a or -i is the default, not if please.\n\nBy the way I do use the update-index way, but vote -a by default. I\ndon't mind adding \" -i\" after every commit commands.\n-- \n"},{"id":"294561","messageId":"200611300930.33537.alan@chandlerfamily.org.uk","threadId":"5925","inReplyTo":"fcaeb9bf0611300101s51a53b75lc7e771b067ba6e33@mail.gmail.com","subject":"Re: git and bzr","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-11-30T09:30:33Z","receivedAt":"2006-11-30T09:30:33Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Thursday 30 November 2006 09:01, Nguyen Thai Ngoc Duy wrote:\n> On 11/30/06, Raimund Bauer wrote:\n> > * Carl Worth wrote, On 30.11.2006 01:05:\n> > > Let's help people do exactly that by making the behavior of \"git\n> > > commit -a\" be the default for \"git commit\".\n> >\n> > Maybe we could do that _only_ if the index matches HEAD, and otherwise\n> > keep current behavior?\n>\n> I hate the if clause. Suppose I prefer update-index way, I would have\n> to check whether HEAD matches index everytime I do a commit to make\n> sure it won't do the other way.\n\nNo you won't. \n\nIf you don't use update-index, then index will match HEAD and you will commit \nchanges in the working tree. That is the way for newbies\n\nAs soon as you do the first update-index the index will no longer match HEAD, \nso commit will do the same as it does now.\n\nAnd if you are not sure which you have done then presumably you do what you do \nnow, or git commit -a or git commit -i as you need.\n\n-- \nAlan Chandler\n"},{"id":"297217","messageId":"ekm8ig$usu$1@sea.gmane.org","threadId":"5925","inReplyTo":"200611300930.33537.alan@chandlerfamily.org.uk","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-30T09:35:59Z","receivedAt":"2006-11-30T09:35:59Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Alan Chandler wrote:\n\n> And if you are not sure which you have done then presumably you do what you do \n> now, or git commit -a or git commit -i as you need.\n\nBy the way, short option -i is not --index but --include (i.e. commit\nboth changes in index and files mentioned on command line). Perhaps -I?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298468","messageId":"456EA6EF.4000104@midwinter.com","threadId":"5925","inReplyTo":"200611300930.33537.alan@chandlerfamily.org.uk","subject":"Re: git and bzr","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2006-11-30T09:39:59Z","receivedAt":"2006-11-30T09:39:59Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Alan Chandler wrote:\n> No you won't. \n>\n> If you don't use update-index, then index will match HEAD and you will commit \n> changes in the working tree. That is the way for newbies\n>\n> As soon as you do the first update-index the index will no longer match HEAD, \n> so commit will do the same as it does now.\n>\n> And if you are not sure which you have done then presumably you do what you do \n> now, or git commit -a or git commit -i as you need.\n\nPlus, one assumes, the git-generated comments in the commit message will \ntell you what kind of commit it has decided to do.\n\nI like this suggestion a lot. Thinking back over my git usage recently, \nwhich has included both styles of commits (though mostly -a ones), I \nthink this would have done the right thing by default in every case.\n\n"},{"id":"295070","messageId":"7vbqmpjlsz.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"ekm8ig$usu$1@sea.gmane.org","subject":"Re: git and bzr","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-30T10:01:00Z","receivedAt":"2006-11-30T10:01:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> By the way, short option -i is not --index but --include (i.e. commit\n> both changes in index and files mentioned on command line). Perhaps -I?\n\nJust in case nobody noticed after looking at the first part of\nmy patch a few nights ago, --include happens to mean exactly\nwhat --index would mean anyway.\n\nBy default, \"git commit\" without parameter does \"make a commit\nout of the index\". With paths, it used to mean \"oh, by the way,\nI forgot to run update-index on these paths, so could you please\ndo that for me now before you make the commit\", and has been\nthat way for a long time.\n\nMuch later, people from CVS background wanted to say \"edit foo\nbar; git update-index bar; git commit foo\" to mean \"I might have\ndone something to the index, but I do not want to care about it\nnow -- please make a commit that includes only the changes to\nbar and I do not want the changes to foo included in the\ncommit\". Somehow we ended up introducing that twisted semantics\nand that was where --only came from, which unfortunately later\nbecame the default (and I already said that I realize this was a\nbig mistake).\n\nWhile we transitioned to switch the default, we first came up\nwith a name to ask for the traditional semantics (--include),\nwarned people who gave paths without either -i nor -o that the\n--include semantics is still the default but would change soon\n(which meant that -i was a no-op back then), then switched the\ndefault and we now warn that the default is now -o (so now -o is\na no-op) when people give only paths without -i nor -o.\n\nCurrently (that is, without the first part of my two patches),\n\"git commit -i\" and \"git commit -o\" without paths refuse to\nwork, saying that these modes of operation do not make sense\nwithout any path.\n\nHowever, you can think of the simplest \"commit the current\nindex\" semantics as a degenerated case of saying \"oh, by the\nway, please run update-index on these paths I forgot to do\nearlier before you make the commit\" and giving no paths.\n\nSo \"git commit -i\" without paths _could_ mean \"commit the index\nas is\" very naturally without introducing an independent switch\nwith different name. That is what the first part of my two\npatches to Carl does.\n\n\n"},{"id":"293878","messageId":"Pine.LNX.4.63.0611301111310.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"456E8147.9070304@gmx.net","subject":"Re: git and bzr","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-30T10:19:23Z","receivedAt":"2006-11-30T10:19:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 30 Nov 2006, Raimund Bauer wrote:\n\n> * Carl Worth wrote, On 30.11.2006 01:05:\n> > Let's help people do exactly that by making the behavior of \"git\n> > commit -a\" be the default for \"git commit\".\n> > \n> Maybe we could do that _only_ if the index matches HEAD, and otherwise keep\n> current behavior?\n> So people who don't care about the index won't get tripped up, and when you do\n> have a dirty index, you get told about it?\n\nSo many people spoke for it, it's time I crash the wedding.\n\nFrom a usability viewpoint, it is a horrible convention. The user has to \nremember too much of the side effects to handle the commit operation. \nThe function of the program would no longer be dependent on the command \nline arguments and your config, but _also_ on something as volatile as \nthe index.\n\nYou would literally end up asking \"did I change the index?\" _everytime_ \nbefore you commit.\n\nAnd remember, even a simple \"git add\" changes the index! (Why it does is \nbrutally clear once you grasp the concept of the staging area.)\n\nWorse, doing a \"git commit --amend\" should _not_ automatically add \"-a\" \n_even_ if the index matches the HEAD, since it is quite possible that you \nhad a typo in the message you want to fix up. And quite possibly other \noptions would not want that either.\n\nBut here's an idea: tell the user that she has to tell git-commit which \nfiles she wants committed. Yes! That's it. Just tell it the friggin' \nfiles. And if you are a lazy bum, and want to commit _all_ modified \nfiles, git has a nice shortcut for ya: \"-a\".\n\nCiao,\nDscho\n"},{"id":"297233","messageId":"fcaeb9bf0611300325r3a3fa8av141359c69d2377b5@mail.gmail.com","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0611301111310.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git and bzr","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-11-30T11:25:09Z","receivedAt":"2006-11-30T11:25:09Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 11/30/06, Johannes Schindelin wrote:\n> But here's an idea: tell the user that she has to tell git-commit which\n> files she wants committed. Yes! That's it. Just tell it the friggin'\n> files. And if you are a lazy bum, and want to commit _all_ modified\n> files, git has a nice shortcut for ya: \"-a\".\n\nIt reminds me Microsoft Office Assistant :-) Let's make \"git assistant\nmode\" that tries hard to guess user's desires and give them guidance.\nOnce they get used to git, they can disable that mode and back to\n\"plain git\".\n-- \n"},{"id":"294573","messageId":"ekmgud$oss$1@sea.gmane.org","threadId":"5925","inReplyTo":"fcaeb9bf0611300325r3a3fa8av141359c69d2377b5@mail.gmail.com","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-30T11:58:53Z","receivedAt":"2006-11-30T11:58:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n\n> On 11/30/06, Johannes Schindelin wrote:\n>> But here's an idea: tell the user that she has to tell git-commit which\n>> files she wants committed. Yes! That's it. Just tell it the friggin'\n>> files. And if you are a lazy bum, and want to commit _all_ modified\n>> files, git has a nice shortcut for ya: \"-a\".\n> \n> It reminds me Microsoft Office Assistant :-) Let's make \"git assistant\n> mode\" that tries hard to guess user's desires and give them guidance.\n> Once they get used to git, they can disable that mode and back to\n> \"plain git\".\n\nThe 'givor' (pun on Vi 'vigor') or 'gitor', or 'gator'.\n\n$ git commit\n[...]\nnothing to commit\n$ givor\n$ git commit\nGivor: You haven't marked any file for commit using \"git-update-index \"\nGivor: and you didn't provide files to commit with \"git commit \"\nGivor: so I assume that you wanted to commit all changed files\nGivor: You can use \"git commit -a\" for that (-a is for --all)\n\n;-)\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298224","messageId":"fcaeb9bf0611300414p357e2e90sc6cbd877df0f20e9@mail.gmail.com","threadId":"5925","inReplyTo":"ekmgud$oss$1@sea.gmane.org","subject":"Re: git and bzr","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-11-30T12:14:30Z","receivedAt":"2006-11-30T12:14:30Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 11/30/06, Jakub Narebski wrote:\n> Nguyen Thai Ngoc Duy wrote:\n>\n> > On 11/30/06, Johannes Schindelin wrote:\n> >> But here's an idea: tell the user that she has to tell git-commit which\n> >> files she wants committed. Yes! That's it. Just tell it the friggin'\n> >> files. And if you are a lazy bum, and want to commit _all_ modified\n> >> files, git has a nice shortcut for ya: \"-a\".\n> >\n> > It reminds me Microsoft Office Assistant :-) Let's make \"git assistant\n> > mode\" that tries hard to guess user's desires and give them guidance.\n> > Once they get used to git, they can disable that mode and back to\n> > \"plain git\".\n>\n> The 'givor' (pun on Vi 'vigor') or 'gitor', or 'gator'.\n>\n> $ git commit\n> [...]\n> nothing to commit\n> $ givor\n> $ git commit\n> Givor: You haven't marked any file for commit using \"git-update-index \"\n> Givor: and you didn't provide files to commit with \"git commit \"\n> Givor: so I assume that you wanted to commit all changed files\n> Givor: You can use \"git commit -a\" for that (-a is for --all)\n\nI am serious about that. I haven't thought of it as an independent\ncommand/program though. Can you implement givor exactly like the above\nexample?\n\n> ;-)\nOkay now joke part. This command name is better :-D\n\n$ git commit\n[...]\nnothing to commit\n$ dammit\n$ git commit\nGivor: You haven't marked any file for commit using \"git-update-index \"\nGivor: and you didn't provide files to commit with \"git commit \"\nGivor: so I assume that you wanted to commit all changed files\nGivor: You can use \"git commit -a\" for that (-a is for --all)\n\n-- \n"},{"id":"295837","messageId":"Pine.LNX.4.63.0611301322180.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"fcaeb9bf0611300325r3a3fa8av141359c69d2377b5@mail.gmail.com","subject":"Re: git and bzr","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-30T12:23:27Z","receivedAt":"2006-11-30T12:23:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 30 Nov 2006, Nguyen Thai Ngoc Duy wrote:\n\n> On 11/30/06, Johannes Schindelin wrote:\n> > But here's an idea: tell the user that she has to tell git-commit which\n> > files she wants committed. Yes! That's it. Just tell it the friggin'\n> > files. And if you are a lazy bum, and want to commit _all_ modified\n> > files, git has a nice shortcut for ya: \"-a\".\n> \n> It reminds me Microsoft Office Assistant :-) Let's make \"git assistant\n> mode\" that tries hard to guess user's desires and give them guidance.\n> Once they get used to git, they can disable that mode and back to\n> \"plain git\".\n\nSee git-gui from Shawn. It should really help new users with a graphical \nuser interface.\n\nCiao,\nDscho\n"},{"id":"298910","messageId":"456ECDAF.4050102@op5.se","threadId":"5925","inReplyTo":"456DD76C.4010902@gmx.net","subject":"Re: git and bzr","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-11-30T12:25:19Z","receivedAt":"2006-11-30T12:25:19Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Marko Macek wrote:\n> Linus Torvalds wrote:\n>> So most of the time, when you use git, you can ignore the index. It's \n>> really important, and it's used _all_ the time, but you can still \n>> mostly ignore it. But when handling a merge conflict, the index is \n>> really what sets git apart, and what really helps a LOT.\n> \n> Actually, people (at least me) dislike the index because in the most common\n> operations (status, diff, commit), they have to know that the command \n> doesn't actually\n> display all their work but just the 'indexed' part of it.\n> For people used to cvs, svn and other systems it would be nicer if diff -a\n> and commit -a (and possibly other commands) were the default.\n> \n\nUnless you do \"git update-index\" (and thus are already using the index) \non any files, \"git diff\" shows you exactly the changes between your last \ncommit and the working tree. There's nothing magic, odd or confusing \nabout it, no matter which scm you come from.\n\n\n"},{"id":"298911","messageId":"456ED047.3030102@ableton.com","threadId":"5925","inReplyTo":"456B7C6A.80104@webdrake.net","subject":"Re: git and bzr","fromName":"Nicholas Allen","fromEmail":"allen@ableton.com","sentAt":"2006-11-30T12:36:23Z","receivedAt":"2006-11-30T12:36:23Z","isPatch":false,"sender":{"key":"allen@ableton.com","avatar":null},"body":"I also have a basic question about git regarding its content tracking \nand merging.\n\nDoes this mean if I have, for example, a large C++ file with a bunch of \nmethods in it and I move one of the methods from the bottom of the file \nto the top and in another branch someone makes a change to that method \nthat when I merge their changes git will merge their changes into the \nmethod at the top of the file where I have moved it?\n\nIf so that would be really quite impressive!\n\nCheers,\n\nNick\n\nJoseph Wakeling wrote:\n> Hello all,\n>\n> Following the very interesting debate about the differences between bzr\n> and git, I thought it was about time I tried to learn properly about git\n> and how to use it. I've been using bzr for a good while now, although\n> since I'm not a serious developer I only use it for simple purposes,\n> keeping track of code I write on my own for academic projects.\n>\n> So, a few questions about differences I don't understand...\n>\n> First off a really dumb one: how do I identify myself to git, i.e. give\n> it a name and email address? Currently it uses my system identity,\n> My Name . I haven't found any equivalent of\n> the bzr whoami command.\n>\n> Now to more serious business. One of the main operational differences I\n> see as a new user is that bzr defaults to setting up branches in\n> different locations, whereas git by default creates a repository where\n> branches are different versions of the directory contents and switching\n> branches *changes* the directory contents. bzr branch seems to be\n> closer to git-clone than git-branch (N.B. I have never used bzr repos so\n> might not be making a fair comparison).\n>\n> With this in mind, is there any significance to the \"master\" branch (is\n> it intended e.g. to indicate a git repository's \"stable\" version\n> according to the owner?), or is this just a convenient default name?\n> Could I delete or rename it? Using bzr I would normally give the\n> central branch(*) the name of the project.\n>\n> (* Central or main on my own system. Not intended to be central in the\n> sense of a CVS-style version control setup:-)\n>\n> Any other useful comments that can be made to a bzr user about working\n> with this difference, positive or negative aspects of it?\n>\n> Next question ... one of the reasons I started seriously thinking about\n> git was that in the VCS comparison discussion, it was noted that git is\n> a lot more flexible than bzr in terms of how it can track data (e.g. the\n> git pickaxe command, although I understand that's not in the released\n> version [1.4.4.1] yet?). A frustration with bzr is that pulling or\n> merging patches from another branch or repo requires them to share the\n> same HEAD. Is this a requirement in git or can I say, \"Hey, I like that\n> particular function in project XXX, I'm going to pull that individual\n> bit of code and its development history into project YYY\"?\n>\n> Last off (for now, I'm sure I'll think of more): is there any easy (or\n> difficult) way to effectively import version history from a bzr\n> repository, and vice versa?\n>\n> Thanks in advance for any comments,\n>\n> -- Joe\n>\n>\n> \n\n\n\n\n"},{"id":"296750","messageId":"456ED26C.6070306@op5.se","threadId":"5925","inReplyTo":"456E8147.9070304@gmx.net","subject":"Re: git and bzr","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-11-30T12:45:32Z","receivedAt":"2006-11-30T12:45:32Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Raimund Bauer wrote:\n> * Carl Worth wrote, On 30.11.2006 01:05:\n>> Let's help people do exactly that by making the behavior of \"git\n>> commit -a\" be the default for \"git commit\".\n>> \n> Maybe we could do that _only_ if the index matches HEAD, and otherwise \n> keep current behavior?\n> So people who don't care about the index won't get tripped up, and when \n> you do have a dirty index, you get told about it?\n\nSounds sane. Especially if we couple it with a hint for the user to use \n\"commit -a\" when he/she wants to do blanket commits.\n\nSo in essence that would mean:\nIf no pathspecs are given and index matches current HEAD, print out\n\"Nothing to commit but changes in working tree. Assuming 'git commit -a'\n\nand then act accordingly. Carl, do you think that would satisfy the \ndesires of your RedHat peers? Always doing '-a' by default is terribly \nwrong for those of us who actually use partial commits a lot, and it \nwould also rob git of a lot of its power.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"294853","messageId":"Pine.LNX.4.63.0611301345170.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"456ED047.3030102@ableton.com","subject":"Re: git and bzr","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-30T12:47:15Z","receivedAt":"2006-11-30T12:47:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 30 Nov 2006, Nicholas Allen wrote:\n\n> Does this mean if I have, for example, a large C++ file with a bunch of \n> methods in it and I move one of the methods from the bottom of the file \n> to the top and in another branch someone makes a change to that method \n> that when I merge their changes git will merge their changes into the \n> method at the top of the file where I have moved it?\n\nAs for now, no, it does not. This is a shortcoming of RCS merge which does \nthe heavy-lifting.\n\nHaving said that, stay tuned for new developments: the functionality of \nmerge is being integrated in git. This opens the door to make use of the \ncode tracking support in git, to do exactly what you just proposed.\n\nCiao,\nDscho\n"},{"id":"297181","messageId":"Pine.LNX.4.64.0611300808570.3513@woody.osdl.org","threadId":"5925","inReplyTo":"456ED047.3030102@ableton.com","subject":"Re: git and bzr","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-30T16:45:42Z","receivedAt":"2006-11-30T16:45:42Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Nicholas Allen wrote:\n>\n> Does this mean if I have, for example, a large C++ file with a bunch of\n> methods in it and I move one of the methods from the bottom of the file to the\n> top and in another branch someone makes a change to that method that when I\n> merge their changes git will merge their changes into the method at the top of\n> the file where I have moved it?\n\nRight now (and in the near future), nope. \"git blame\" will track the \nchanges (so the pure movement wasn't just an addition of new code, but \nyou'll see it track it all the way down to the original), but \"git merge\" \nis still file-based.\n\nIn other words, \"git merge\" does uses a data similarity analysis that \ncould be used for smaller chunks than a whole file, but at least for now \nit does it on a file granularity only (and then passes it off to the \nstandard RCS three-way merge on a file-by-file basis).\n\nThat said, if the movement happens _within_ a file, then just about any \nSCM could do what you ask for, by just using something smarter than the \nstandard 3-way merge. So that part isn't even about tracking data across \nfiles - it's just about a per-file merge strategy.\n\nThe \"track data, not files\" thing becomes more interesting when you factor \nout a file into two or more files, and can continue to merge across such a \ncode re-filing event. Git can do it for \"annotate\", but doesn't do it for \nanything else.\n\n> If so that would be really quite impressive!\n\nIndeed, and it's one of the potential future goals that was discussed very \nearly in the git design phase. The point of _not_ doing file ID tracking \nis exactly that you can actually do better than that by just tracking the \ndata.\n\nSo some day, we may do it. And not just within one file, but even between \nfiles. Because file renames really is just a very specific special case of \ndata movement, and I don't think it's even the most common case.\n\nThat said, there are several reasons why you might not actually _ever_ \nwant it in practice, and why I say \"potential future goal\" and \"we may do \nit\". I think this is going to be both a matter of not just writing the \ncode (which we haven't done), but also deciding if it's really worth it.\n\nBecause merges are things where you may not want too much smarts:\n\n - Quite often, a failed merge that needs manual fixup may even be \n _preferable_ to a successful merge that did the merge \"technically \n correctly\", but in an unexpected way.\n\n - There's a _big_ difference between \"merging code\" and \"examining code\". \n It makes much more sense to try to track where code came from and what \n the \"deep history\" was when you examine code, because the reason you're \n doing so is generally exactly because you're looking for what went \n wrong, and who to blame.\n\n When going \"merging\", the history of the code is arguably a lot less \n important. What is the most important part is that the two branches you \n merge have been (hopefully) verified in their _current_ state. The \n history may be full of bugs, and they may have been fixed differently, \n and even trying to be really clever may not actually be a good idea at \n all.\n\n Code may have moved or may have been copied, but what is much more \n important than the original code and where it came from is the state it \n was in _after_ the move, because that's the tested working state, and \n in many ways the history of how it came to be really shouldn't matter \n as much at all.\n\nIn other words, \"annotate\" and \"merge\" have almost entirely opposite \ninterests. An annotation is supposed to find the history in order to maybe \nhelp find bugs, while a merge is supposed to use the _current_ state, and \nvery arguably, if the two current states don't match _so_ obviously that \nthere is no question about what you should do, then the merge should make \nthat very very very clear to the user.\n\nSo my personal opinion has always been that a merge should be extremely \nsimpleminded. I think all teh VCS people who concentrate on smart merging \nabsolutely have their heads up their arses, and do exactly the wrong \nthing. A merge should not do anything \"clever\" at all. It should be just \n_barely_ smart enough to do the obvious thing, and even then we all know \nthat it will still occasionally do the wrong thing.\n\nSo I actually think that a bog-standard and totally stupid three-way merge \nis simply not far from the right thing to do. And the git \"recursive\" \nthing basically repeats that stupid merge (a) in time (ie the criss-cross \nmerge thing causes a recursive three-way merge to take place) and (b) in \nthe metadata space (ie you can see the rename following basically as just \na \"3-way merge in filenames\").\n\nAnd yes, this is probably some mental deficiency and hang-up, but I think \nthat's sufficient, and that where the real \"clever\" stuff should be is to \nthen help people resolve conflicts (and maybe also help you find \nmis-merges even with the totally stupid and simple merge). Because \nconflicts _will_ happen, regardless of your merge strategy, and you do \nneed people to look at them, but you can make it _easier_ for people to \nsay \"ok, that's obviously the right merge\".\n\nSo me personally, I'd rather have the \"real merge\" be what git already \ndoes, and then have something like a graphical \"resolution helper\" \napplication that tries to resolve the remaining things with user help. And \nthat \"resolution helper\" is where I'd put all the magic code movement \nlogic, not in the merge itself.\n\nSo you could look at a failed hunk, and press a \"show me a best guess\" \nbutton, and at that point the thing would say \"that code might fit here, \ndoes that look sane to you? , , \".\n\nTHAT is what a good VCS should do, in my opinion. Not do \"smart merges\".\n\nBtw, git doesn't do the above kind of smart graphical thing, but git \n_does_ do something very much in that direction. Unlike a lot of things, \ngit doesn't just leave the \"conflict marker\" turds in the working tree. \nNo, the index will contain the three-way merge base and both of the actual \nfiles you were trying to merge, and a \"git diff\" will actually show you a \nthree-way diff of the working tree (and you can say \"git diff --ours\" to \nsee the diff just against our old head, and \"--theirs\" to see a regular \ntwo-way diff against the _other_ side that you tried to merge).\n\nSo git already very much embodies this concept of \"don't be overly smart \nwhen merging, but try to help the user out when resolving the merge\". It \nmay not be pretty GUI etc, and it mostly helps with regular bog-standard \ndata conflicts, but boy is it pleasant to use for those once you get used \nto it.\n\nSo we get NONE of those horrible \"you just get conflict turds, you figure \nit out\" things. It gives you the turds (because people, including me, are \nused to them, and you want _something_ in the working tree that shows both \nversions at the same time, of course), but then you can edit them to your \nhearts content, and even _after_ you've edited them, you can do the above \nthree-way (or two-way against either branch) diffs, and it will show what \nyou edited and its relationship to the two branches you merged.\n\nTHAT is what merging is all about. Not smart merges. Stupid merges with \ngood tools to help you do the right thing when the right thing isn't _so_ \nobvious that you can just leave it to the machine.\n\n"},{"id":"297841","messageId":"456F21D6.1060200@webdrake.net","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611290830010.3395@woody.osdl.org","subject":"Re: git blame [was: git and bzr]","fromName":"Joseph Wakeling","fromEmail":"joseph.wakeling@webdrake.net","sentAt":"2006-11-30T18:24:22Z","receivedAt":"2006-11-30T18:24:22Z","isPatch":false,"sender":{"key":"joseph.wakeling@webdrake.net","avatar":null},"body":"Linus Torvalds wrote:\n> So it's fixed now, and probably would never trigger except for the stupid \n> special case that was \"let's just show an example of this\" ;)\n\nI'm very happy my stupidity could help. ;-)\n\nOn a related note ...\n\nNicholas Allen wrote:\n> Thanks for the informative response. It helped but I'm still slightly\n> confused by git - I think I need to play around with it a bit more to\n> understand and get more familiar with the concepts...\n> \n> Purely from an initial usage point of view though, for me at least, the\n> bzr output needed no explanation which I think is indicative of a good\n> user interface whereas the git was not so clear or obvious - there must\n> be room for improvement in git's user friendliness here surely. But that\n> might just be because I am clueless when it comes to the way git works\n> and the concepts it uses ;-)\n\nI do think that bzr has quite an intuitive set of commands, and it is\neasy to learn, though at this point I don't feel git is really *that*\nmuch more difficult in itself. Although the terminal output for some\nproblems could be improved, most of my difficulties are stemming from\noverlap of command names when the commands themselves do different\nthings, and the fact that git's documentation is somewhat more technical\nthan bzr's.\n\nWhat would be nice would be to have in the documentation a whole bunch\nof stupid examples for the main commands, something where someone can\ncreate a repo from scratch, create and modify some simple files\naccording to instructions, and see the particular command in action.\nThe tutorials do this, of course, but only for a few cases, when to be\nhonest it's the more complex commands that most need such explanation.\nFor beginners, especially less technically skilled ones, it would be\ngood to have a lot more of, \"Do this, here's what git will respond, this\nis what it means, here's how to fix it....\"\n\nAs a relatively non-technical user, perhaps I should keep track of my\ndifficulties (and others') and try to write something up.\n\n"},{"id":"294670","messageId":"Pine.LNX.4.64.0611301034420.3513@woody.osdl.org","threadId":"5925","inReplyTo":"456F21D6.1060200@webdrake.net","subject":"Re: git blame [was: git and bzr]","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-30T18:44:48Z","receivedAt":"2006-11-30T18:44:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Joseph Wakeling wrote:\n> \n> What would be nice would be to have in the documentation a whole bunch\n> of stupid examples for the main commands, something where someone can\n> create a repo from scratch, create and modify some simple files\n> according to instructions, and see the particular command in action.\n\n100% agreed. A lot of the man-pages etc have been written to be about the \ntechnology, not about the _use_ of it.\n\nI encouraged people at some point to add an \"Examples\" section to some of \nthe functions to show what it all _means_, so for \"man git-log\", I think \nsome of the most useful stuff is that examples section that shows the \ncombination of revision naming and path-name limiting, for example. I \npersonally think that that is a much better way of teaching people what \nthe commands actually do than by mentioning the arguments one by one.\n\nBut that only exists for a couple of man-pages, and mostly for the simple \nones at that. And a lot of the real examples would need \"real data\" to \nwork on, so it can't easily be done as a trivial example in a man-page, it \nreally needs a tutorial to \"build up\" to the situation where you can then \nexplain with an example what to do.\n\n> The tutorials do this, of course, but only for a few cases, when to be\n> honest it's the more complex commands that most need such explanation.\n\nYeah. The git \"tutorial.txt\" should be extended, and preferably be a while \nnice set of \"follow along with the bouncing ball\" kind of web-page \nsequence.\n\nSo I absolutely agree. It's just that at least me personally, I just can't \nwrite documentation. I wrote some of the original tutorial, I've written \nsome of the original tech docs, but I just can't get into the whole \n\"document it\" mindset, especially not from a user perspective. It doesn't \nfloat my boat, and judging by a lot of the discussions, I obviously also \ndon't even see why something could _possibly_ cause confusion.\n\nTo make things worse, a lot of the docs (and by that I also mean some of \nthe error messages and helpful hints) tend to be old.\n\nThe whole fact that \"git commit\" mentions \"git update-index\" is exactly \nthat kind of thing: it's largely a legacy message. You'd almost never \nactually _use_ git-update-index itself these days, and it's much more \nconvenient to just list the files you want to commit to \"git commit\" \ndirectly (or just use the -a flag, if that is what you want to do).\n\nBut that message exists, because it was written in an earlier age.\n\n"},{"id":"298073","messageId":"87d574u2tl.wl%cworth@cworth.org","threadId":"5925","inReplyTo":"Pine.LNX.4.64.0611301034420.3513@woody.osdl.org","subject":"Re: git blame [was: git and bzr]","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-30T19:55:34Z","receivedAt":"2006-11-30T19:55:34Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 30 Nov 2006 10:44:48 -0800 (PST), Linus Torvalds wrote:\n>\n> But that only exists for a couple of man-pages, and mostly for the simple\n> ones at that. And a lot of the real examples would need \"real data\" to\n> work on, so it can't easily be done as a trivial example in a man-page, it\n> really needs a tutorial to \"build up\" to the situation where you can then\n> explain with an example what to do.\n\nHere's a crazy idea. How about a \"git tutorial\" builtin or \"git\nexample\" or something that would create a repository into some useful\nstate for demonstrating something.\n\nI know that I'm regularly putting stuff into emails like:\n\n\tmkdir gittest\n\tcd gittest\n\tgit init-db\n\techo hello > hello\n\tgit add hello\n\tgit commit -m \"add hello\"\n\tgit checkout -b other\n\techo other > other\n\tgit add other\n\tgit commit -m \"add other\"\n\tgit checkout master\n\n\t# OK, that was just setup, here's what I want to demonstrate\n\tgit pull . other\n\t...\n\nSo maybe if there was a command to setup a standard example\nrepository, (\"git boilerplate\", \"git sandbox\", \"git playground\" ?),\nthen the documentation could use that to have full-fledged examples\nwithout having to duplicate similar setup each time.\n\nAnd then there could be a way for this command to also spit out the\ncommands it is using to reach some state so it could even serve as a\nsort of self-documenting tutorial of some sort.\n\nAnyone interested in exploring something like that?\n\n-Carl\n"},{"id":"294941","messageId":"20061130200122.GD10999@thunk.org","threadId":"5925","inReplyTo":"456ECDAF.4050102@op5.se","subject":"Re: git and bzr","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2006-11-30T20:01:22Z","receivedAt":"2006-11-30T20:01:22Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Nov 30, 2006 at 01:25:19PM +0100, Andreas Ericsson wrote:\n> Unless you do \"git update-index\" (and thus are already using the index) \n> on any files, \"git diff\" shows you exactly the changes between your last \n> commit and the working tree. There's nothing magic, odd or confusing \n> about it, no matter which scm you come from.\n\nUntil you make the mistake of reading the git-diff man page, at which\npoint the novice git user runs screaming into the night...\n\n Show changes between two ents, an ent and the working tree, an\n ent and the index file, or the index file and the working\n tree. The combination of what is compared with what is\n determined by the number of ents given to the command.\n\n * When no is given, the working tree and the index file\n is compared, using git-diff-files.\n\n * When one is given, the working tree and the named tree\n is compared, using git-diff-index. The option --cached can\n be given to compare the index file and the named tree.\n\n * When two s are given, these two trees are compared using\n git-diff-tree.\n\nLooking at the man page, it does raise one interesting question ---\nSo exactly what is the difference between Treebeard and Quickbeam?\n\nAnd how many working trees do we need before we call it an Entmoot? :-)\n\n"},{"id":"296202","messageId":"ekndmb$7e9$1@sea.gmane.org","threadId":"5925","inReplyTo":"20061130200122.GD10999@thunk.org","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-30T20:09:33Z","receivedAt":"2006-11-30T20:09:33Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Theodore Tso wrote:\n\n>        * When no is given, the working tree and the index file\n>           is compared, using git-diff-files.\n\n * When no is given, the working tree and the index file are\n compared, using git-diff-files.\n\nUse more modern git.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294150","messageId":"Pine.LNX.4.63.0611302314320.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"87d574u2tl.wl%cworth@cworth.org","subject":"Re: git blame [was: git and bzr]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-30T22:17:12Z","receivedAt":"2006-11-30T22:17:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 30 Nov 2006, Carl Worth wrote:\n\n> Here's a crazy idea. How about a \"git tutorial\" builtin or \"git example\" \n> or something that would create a repository into some useful state for \n> demonstrating something.\n\nThat sounds fine! Actually, it should be very simple to turn the tutorial \ninto such a script, displaying the command with an explanation, and \nexecuting the command. It could even call gitk from time to time, so the \nuser can form a mental model of the ancestor graph.\n\nCiao,\nDscho\n"},{"id":"297774","messageId":"20061130222422.GC30922@fieldses.org","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0611302314320.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git blame [was: git and bzr]","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-11-30T22:24:22Z","receivedAt":"2006-11-30T22:24:22Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Nov 30, 2006 at 11:17:12PM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 30 Nov 2006, Carl Worth wrote:\n> \n> > Here's a crazy idea. How about a \"git tutorial\" builtin or \"git example\" \n> > or something that would create a repository into some useful state for \n> > demonstrating something.\n> \n> That sounds fine! Actually, it should be very simple to turn the tutorial \n> into such a script, displaying the command with an explanation, and \n> executing the command. It could even call gitk from time to time, so the \n> user can form a mental model of the ancestor graph.\n\nCurrently tutorial.txt doesn't work like that--there are places where it\njust tells the user to edit a file, or make a few commits, without\nlisting commands to do so. It also isn't linear. That could all be\n\"fixed\", but I think the result would just make it more tedious.\n\nBut I agree that a \"git tutorial\" command to set up a canonical example\nrepository might be fun.\n\n"},{"id":"296754","messageId":"7v64cwh86r.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0611302314320.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git blame","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-30T22:38:04Z","receivedAt":"2006-11-30T22:38:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Thu, 30 Nov 2006, Carl Worth wrote:\n>\n>> Here's a crazy idea. How about a \"git tutorial\" builtin or \"git example\" \n>> or something that would create a repository into some useful state for \n>> demonstrating something.\n>\n> That sounds fine! Actually, it should be very simple to turn the tutorial \n> into such a script, displaying the command with an explanation, and \n> executing the command. It could even call gitk from time to time, so the \n> user can form a mental model of the ancestor graph.\n\nDoesn't one of our existing t/ scripts do that?\n"},{"id":"296471","messageId":"Pine.LNX.4.63.0611302338190.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"7vbqmpjlsz.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and bzr","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-30T22:45:20Z","receivedAt":"2006-11-30T22:45:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 30 Nov 2006, Junio C Hamano wrote:\n\n> Somehow we ended up introducing that twisted semantics and that was \n> where --only came from, which unfortunately later became the default \n> (and I already said that I realize this was a big mistake).\n\nIf you are talking about \"git commit file1 file2\" ignoring the current \nindex, and building a new index just updating file1 and file2 from the \nworking directory, I disagree that it was a big mistake.\n\nActually, I was very happy to get that change (IIRC it was me requesting \nit, so blame me), because I now can say: just specify exactly what you \nwant to commit *1*.\n\nIf you want to commit just file2 (even if you added file1, but did not \ncommit it yet) do \"git commit file2\". If you want to commit all changes, \neither pass the names of all modified files, or \"-a\". IMHO this satisfies \nthe principle of least surprise.\n\nCiao,\nDscho\n\nFootnote 1: Of course, you can use commit in more ways. But this is \nsufficient to get people started.\n"},{"id":"296650","messageId":"Pine.LNX.4.63.0611302350510.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5925","inReplyTo":"7v64cwh86r.fsf@assigned-by-dhcp.cox.net","subject":"Re: git blame","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-30T22:53:28Z","receivedAt":"2006-11-30T22:53:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 30 Nov 2006, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Thu, 30 Nov 2006, Carl Worth wrote:\n> >\n> >> Here's a crazy idea. How about a \"git tutorial\" builtin or \"git example\" \n> >> or something that would create a repository into some useful state for \n> >> demonstrating something.\n> >\n> > That sounds fine! Actually, it should be very simple to turn the tutorial \n> > into such a script, displaying the command with an explanation, and \n> > executing the command. It could even call gitk from time to time, so the \n> > user can form a mental model of the ancestor graph.\n> \n> Doesn't one of our existing t/ scripts do that?\n\n;-) I did not forget... t1200-tutorial.sh\n\nBut it serves a different purpose: it makes sure that we did not break the \ncommands in the tutorial. (I fear that the script and the tutorial have \ndiverged a little bit, though).\n\ngit-tutorial should not test that, rather it should show the user what is \npossible, and encourage playing with git.\n\nCiao,\nDscho\n"},{"id":"294508","messageId":"ekno64$ekb$1@sea.gmane.org","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0611302350510.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git blame","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-30T23:08:39Z","receivedAt":"2006-11-30T23:08:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Thu, 30 Nov 2006, Junio C Hamano wrote:\n> \n>> Johannes Schindelin writes:\n>> \n>>> On Thu, 30 Nov 2006, Carl Worth wrote:\n>>>\n>>>> Here's a crazy idea. How about a \"git tutorial\" builtin or \"git example\" \n>>>> or something that would create a repository into some useful state for \n>>>> demonstrating something.\n>>>\n>>> That sounds fine! Actually, it should be very simple to turn the tutorial \n>>> into such a script, displaying the command with an explanation, and \n>>> executing the command. It could even call gitk from time to time, so the \n>>> user can form a mental model of the ancestor graph.\n>> \n>> Doesn't one of our existing t/ scripts do that?\n> \n> ;-) I did not forget... t1200-tutorial.sh\n> \n> But it serves a different purpose: it makes sure that we did not break the \n> commands in the tutorial. (I fear that the script and the tutorial have \n> diverged a little bit, though).\n> \n> git-tutorial should not test that, rather it should show the user what is \n> possible, and encourage playing with git.\n\nSomething like Cogito tutorial-script?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294010","messageId":"7vslg0ecc9.fsf@assigned-by-dhcp.cox.net","threadId":"5925","inReplyTo":"Pine.LNX.4.63.0611302338190.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git and bzr","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-30T23:36:38Z","receivedAt":"2006-11-30T23:36:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Thu, 30 Nov 2006, Junio C Hamano wrote:\n>\n>> Somehow we ended up introducing that twisted semantics and that was \n>> where --only came from, which unfortunately later became the default \n>> (and I already said that I realize this was a big mistake).\n>\n> If you are talking about \"git commit file1 file2\" ignoring the current \n> index, and building a new index just updating file1 and file2 from the \n> working directory, I disagree that it was a big mistake.\n\nWhen I wrote that paragraph, I said:\n\n Much later, people from CVS background wanted to say \"edit foo\n bar; git update-index bar; git commit foo\" to mean \"I might have\n done something to the index, but I do not want to care about it\n now -- please make a commit that includes only the changes to\n bar and I do not want the changes to foo included in the\n commit\". Somehow we ended up introducing that twisted semantics\n and that was where --only came from, which unfortunately later\n became the default (and I already said that I realize this was a\n big mistake).\n\nBut ignoring the index was not because of that command sequence,\nas you reminded me in your message I am replying to. It was to\nallow this sequence, which is natural with CVS:\n\n\t$ git-checkout ;# existing project that did not have Makefile\n\t$ edit hello.c ;# to fix wording of the message\n $ edit Makefile ;# anybody who is self respecting should have one\n\t$ git-add Makefile ;# do not forget to add it\n $ git-commit hello.c ;# the fix is important independent of Makefile\n\t... then maybe the next commit is to add Makefile ...\n\nIf you view this sequence with CVS mindset, there is nothing\nsurprising about the commit _not_ committing Makefile in this\nexample.\n\nBut if you come from the school that \"git-add\" is about adding\n\"the contents (and the path, but only because content cannot be\nadded without the path)\", and if you already understood that\n\"git-commit\" without parameters nor options is a way to make a\ncommit out of the index, it certainly is counterintuitive. \n\nGranted, parameters and options are ways to affect what the\ncommand does, but usually it does so by modifying and enhancing\nwhat the command does without breaking the basic premise. What\nthe --only does is quite different -- it bypasses the index\ncompletely.\n\nIn fact, what it does is _so_ counterintuitive that I did not\neven remember what the real motivation behind it was, and sent\nmy message with a much more implausible sequence which had an\nexplicit update-index (no sane person would do that). That\nshould tell you something.\n\nRemember, new peole will not stay \"newbies\" forever. The\noriginal \"inclusive\" semantics is a lot easier to explain once\nyou get what index does. The way to introduce \"index\" to people\nNico proposed would not have to talk about \"Ah, but there are\nthese two twists\" if we did not make the --only the default\nsemantics. What I find a big mistake is not the --only option;\nthe mistake is that it is the default.\n"},{"id":"297879","messageId":"456FFC10.7060703@op5.se","threadId":"5925","inReplyTo":"ekndmb$7e9$1@sea.gmane.org","subject":"Re: git and bzr","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-01T09:55:28Z","receivedAt":"2006-12-01T09:55:28Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> Theodore Tso wrote:\n> \n>> * When no is given, the working tree and the index file\n>> is compared, using git-diff-files.\n> \n> * When no is given, the working tree and the index file are\n> compared, using git-diff-files.\n> \n> Use more modern git.\n\nMore modern git (pull'ed 10 minutes ago) has this, at least when cut \nfrom Documentation/git-diff.txt:\n---%<---%<---%<---\nSYNOPSIS\n--------\n'git-diff' [ --diff-options ] {0,2} [...]\n\nDESCRIPTION\n-----------\nShow changes between two trees, a tree and the working tree, a\ntree and the index file, or the index file and the working tree.\nThe combination of what is compared with what is determined by\nthe number of trees given to the command.\n\n* When no is given, the working tree and the index\n file are compared, using `git-diff-files`.\n\n* When one is given, the working tree and the named\n tree are compared, using `git-diff-index`. The option\n `--index` can be given to compare the index file and\n the named tree.\n `--cached` is a deprecated alias for `--index`. It's use is\n discouraged.\n\n* When two s are given, these two trees are compared\n using `git-diff-tree`.\n---%<---%<---%<---\n\nThis needs an update, I think. I'll look into it on sunday if no-one's \nbeaten me to it.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"294140","messageId":"ekrf1q$v72$2@sea.gmane.org","threadId":"5925","inReplyTo":"456FFC10.7060703@op5.se","subject":"Re: git and bzr","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-02T08:57:22Z","receivedAt":"2006-12-02T08:57:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson wrote:\n\n> ---%<---%<---%<---\n> SYNOPSIS\n> --------\n> 'git-diff' [ --diff-options ] {0,2} [...]\n> \n> DESCRIPTION\n> -----------\n> Show changes between two trees, a tree and the working tree, a\n> tree and the index file, or the index file and the working tree.\n> The combination of what is compared with what is determined by\n> the number of trees given to the command.\n> \n> * When no is given, the working tree and the index\n> file are compared, using `git-diff-files`.\n> \n> * When one is given, the working tree and the named\n> tree are compared, using `git-diff-index`. The option\n> `--index` can be given to compare the index file and\n> the named tree.\n> `--cached` is a deprecated alias for `--index`. It's use is\n> discouraged.\n> \n> * When two s are given, these two trees are compared\n> using `git-diff-tree`.\n> ---%<---%<---%<---\n> \n> This needs an update, I think. I'll look into it on sunday if no-one's \n> beaten me to it.\n\nYou might want to use Junio proposal in\n Message-ID: <7vhcwgcf39.fsf@assigned-by-dhcp.cox.net>\n http://permalink.gmane.org/gmane.comp.version-control.git/32853\n(and perhaps also my reply to it)\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"}]}