{"thread":{"id":"43238","subject":"Re: VCS comparison table","startedAt":"2006-10-27T02:02:32Z","lastAt":"2006-10-30T15:21:09Z","messageCount":18,"participants":["Jakub Narebski","J. Bruce Fields","Matthew D. Fuller","Nicolas Pitre","Robin Rosenberg","Theodore Tso","Andreas Ericsson","Horst H. von Brand","Petr Baudis","Ilpo Nyyssönen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"298915","messageId":"200610270202.k9R22Wxf004208@laptop13.inf.utfsm.cl","threadId":"43238","inReplyTo":"jnareb@gmail.com","subject":"Re: VCS comparison table","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-10-27T02:02:32Z","receivedAt":"2006-10-27T02:02:32Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> wrote:\n\n[...]\n\n> I'd rather split \"Supports Renames\" into engine part (does SCM\n> remember/detect that rename took place _as_ rename, not remember/detect it\n> as copiying+deletion; something other than rename) and user interface part:\n> can user easily deal with renames (this includes merging and viewing file\n> history).\n\nI think that what to tool does in its guts is completely irrelevant, what\nis important is what the user sees. Sadly, it seems hard to describe\nexactly what is meant/wanted here.\n\n[...]\n\n> 7. Checkouts (as a noun). This probably read \"Support Centralized and\n> Disconnected Centralized Workflow\" but that is perhaps too wordy. Git would\n> have \"No\" for \"Centralized\"\n\nWhy? We could all agree that some repository is \"central\" and all push/pull\nthere. Or send patches by mail (or apply them via ssh). Sure, it's not CVS,\nbut...\n\n[...]\n\n> 13. Plugins. I would put \"Somewhat\" here, or \"Scriptable\" in the \"Somewhat\"\n> or \"?\" background color for Git. And add note that it is easy to script up\n> porcelanish command, and to add another merge strategy. There also was\n> example plugin infrastructure for Cogito, so I'd opt for \"Someahwt\"\n> marking.\n\nMostly an implementation detail for \"extensible\"...\n\n[...]\n\n> 19. Ease of Use. Hmmm... I don't know for Git. I personally find it very\n> easy to use, but I have not much experiences with other SCM. I wonder why\n> Bazaar has \"No\" there...\n\nExtremely subjective. Easy to learn doesn't cut it either.\n\n"},{"id":"298916","messageId":"20061027020842.GZ20017@pasky.or.cz","threadId":"43238","inReplyTo":"200610270202.k9R22Wxf004208@laptop13.inf.utfsm.cl","subject":"Re: VCS comparison table","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-27T02:08:42Z","receivedAt":"2006-10-27T02:08:42Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Oct 27, 2006 at 04:02:32AM CEST, I got a letter\nwhere \"Horst H. von Brand\" <vonbrand@inf.utfsm.cl> said that...\n> Jakub Narebski <jnareb@gmail.com> wrote:\n> > 7. Checkouts (as a noun). This probably read \"Support Centralized and\n> > Disconnected Centralized Workflow\" but that is perhaps too wordy. Git would\n> > have \"No\" for \"Centralized\"\n> \n> Why? We could all agree that some repository is \"central\" and all push/pull\n> there. Or send patches by mail (or apply them via ssh). Sure, it's not CVS,\n> but...\n\nAn ability to configure the tool so that the centralized workflow is\n_enforced_ may be important for managers. It's stupid, but it's what is\nmeant there, I think.\n\n> > 19. Ease of Use. Hmmm... I don't know for Git. I personally find it very\n> > easy to use, but I have not much experiences with other SCM. I wonder why\n> > Bazaar has \"No\" there...\n> \n> Extremely subjective. Easy to learn doesn't cut it either.\n\nI don't think this column makes sense at all. I swear I've seen\n*several* people that claimed GNU Arch was easy to learn/use for them!\n\n\n"},{"id":"297793","messageId":"4541D291.5020205@op5.se","threadId":"43238","inReplyTo":"200610270202.k9R22Wxf004208@laptop13.inf.utfsm.cl","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-27T09:34:09Z","receivedAt":"2006-10-27T09:34:09Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Horst H. von Brand wrote:\n> Jakub Narebski <jnareb@gmail.com> wrote:\n> \n> [...]\n> \n>> I'd rather split \"Supports Renames\" into engine part (does SCM\n>> remember/detect that rename took place _as_ rename, not remember/detect it\n>> as copiying+deletion; something other than rename) and user interface part:\n>> can user easily deal with renames (this includes merging and viewing file\n>> history).\n> \n> I think that what to tool does in its guts is completely irrelevant, what\n> is important is what the user sees. Sadly, it seems hard to describe\n> exactly what is meant/wanted here.\n> \n\nAgreed. I'd rather make the definition \"Can users, after a rename has \ntaken place, follow the history of the file-contents across renames?\". \nMainly because this is clearly unambiguous, doesn't involve \nimplementation details and only weighs what really counts: User-visible \ncapabilities.\n\nIMNSHO, I'd rather have all the features in the list be along the lines \nof \"Can users/admins/random-boon do X?\" and instead of \"yes/no\" list the \nnumber of commands/the amount of time required to achieve the desired \neffect. This would set a clear limit and put most terminology issues out \nof the way.\n\n> \n>> 13. Plugins. I would put \"Somewhat\" here, or \"Scriptable\" in the \"Somewhat\"\n>> or \"?\" background color for Git. And add note that it is easy to script up\n>> porcelanish command, and to add another merge strategy. There also was\n>> example plugin infrastructure for Cogito, so I'd opt for \"Someahwt\"\n>> marking.\n> \n> Mostly an implementation detail for \"extensible\"...\n> \n\nYup. Any fast-growing SCM can clearly be said to be \"extensible\", \notherwise it wouldn't be extended ;-)\n\n> [...]\n> \n>> 19. Ease of Use. Hmmm... I don't know for Git. I personally find it very\n>> easy to use, but I have not much experiences with other SCM. I wonder why\n>> Bazaar has \"No\" there...\n> \n> Extremely subjective. Easy to learn doesn't cut it either.\n\nThis one just needs to go. Could possibly be replaced with \"Has \ntutorial/documentation online\" or some such. No SCM is really intuitive \nto users that haven't experienced any of them before, so the only thing \nthat really matters is how much documentation one can find online and \nhow up-to-date it is.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\n"},{"id":"296044","messageId":"8fe92b430610270349k36a39250i7173282aa81c04e7@mail.gmail.com","threadId":"43238","inReplyTo":"4541D291.5020205@op5.se","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-27T10:49:58Z","receivedAt":"2006-10-27T10:49:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 10/27/06, Andreas Ericsson <ae@op5.se> wrote:\n> Horst H. von Brand wrote:\n>> Jakub Narebski <jnareb@gmail.com> wrote:\n>>\n>> [...]\n>>\n>>> I'd rather split \"Supports Renames\" into engine part (does SCM\n>>> remember/detect that rename took place _as_ rename, not remember/detect\n>>> it as copiying+deletion; something other than rename) and user interface\n>>> part: can user easily deal with renames (this includes merging and\nviewing file\n>>> history).\n>>\n>> I think that what to tool does in its guts is completely irrelevant, what\n>> is important is what the user sees. Sadly, it seems hard to describe\n>> exactly what is meant/wanted here.\n>\n> Agreed. I'd rather make the definition \"Can users, after a rename has\n> taken place, follow the history of the file-contents across renames?\".\n> Mainly because this is clearly unambiguous, doesn't involve\n> implementation details and only weighs what really counts: User-visible\n> capabilities.\n\nWith this definition (with this part) it would be \"Somewhat\" for Git, because\nuser can track the history of file-contents across renames, but some additional\nsteps are required... until --follow=<pathname> would get implemented, that is.\nYet \"tracking file-contents across renames\" is based on specific workflow used;\nfor example with Git you usually track [some part of] history of some subpart\nof a project, not history of single file. (I'd name it \"History Rename Support\"\nor \"Log Rename Support\").\n\nBut equally important for user is another question related to\n\"Supporting Renames\".\nNamely detection of renames during merge and detection of conflict during merge\nis what I would consider minimal \"Merge Renames Support\". Causing information\nto be lost is having no \"Merge Renames Support\". To have \"Yes\" in this\ncolumn SCM\nhave to resolve conflict at least in obvious cases, and \"Yes!\" if it\ncan remember\nresolution of merge conflict involving renames ;-).\n\n> IMNSHO, I'd rather have all the features in the list be along the lines\n> of \"Can users/admins/random-boon do X?\" and instead of \"yes/no\" list the\n> number of commands/the amount of time required to achieve the desired\n> effect. This would set a clear limit and put most terminology issues out\n> of the way.\n\nThis would make the comparison table less clear, unfortunately.\n\n>>> 13. Plugins. I would put \"Somewhat\" here, or \"Scriptable\" in the \"Somewhat\"\n>>> or \"?\" background color for Git. And add note that it is easy to script up\n>>> porcelanish command, and to add another merge strategy. There also was\n>>> example plugin infrastructure for Cogito, so I'd opt for \"Someahwt\"\n>>> marking.\n>>\n>> Mostly an implementation detail for \"extensible\"...\n>>\n>\n> Yup. Any fast-growing SCM can clearly be said to be \"extensible\",\n> otherwise it wouldn't be extended ;-)\n\nI'd put \"Easily Extensible\" here, and put \"Plugins (core+UI)\" for Bazaar-NG,\nand \"Scriptable (UI+merge)\" for Git, or something like that.\n\n>> [...]\n>>\n>>> 19. Ease of Use. Hmmm... I don't know for Git. I personally find it very\n>>> easy to use, but I have not much experiences with other SCM. I wonder why\n>>> Bazaar has \"No\" there...\n>>\n>> Extremely subjective. Easy to learn doesn't cut it either.\n>\n> This one just needs to go. Could possibly be replaced with \"Has\n> tutorial/documentation online\" or some such. No SCM is really intuitive\n> to users that haven't experienced any of them before, so the only thing\n> that really matters is how much documentation one can find online and\n> how up-to-date it is.\n\nFor example SCM can be easy to use but at the cost of simplifications\nand limited useness.\n\nOn the other side basic concept behind some SCM might be more\nor less understandable...\n-- \n"},{"id":"297915","messageId":"4541F084.2020802@op5.se","threadId":"43238","inReplyTo":"8fe92b430610270349k36a39250i7173282aa81c04e7@mail.gmail.com","subject":"Re: VCS comparison table","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-27T11:41:56Z","receivedAt":"2006-10-27T11:41:56Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> On 10/27/06, Andreas Ericsson <ae@op5.se> wrote:\n>> Horst H. von Brand wrote:\n>>> Jakub Narebski <jnareb@gmail.com> wrote:\n>>>\n>>> [...]\n>>>\n>>>> I'd rather split \"Supports Renames\" into engine part (does SCM\n>>>> remember/detect that rename took place _as_ rename, not remember/detect\n>>>> it as copiying+deletion; something other than rename) and user \n>>>> interface\n>>>> part: can user easily deal with renames (this includes merging and\n> viewing file\n>>>> history).\n>>>\n>>> I think that what to tool does in its guts is completely irrelevant, \n>>> what\n>>> is important is what the user sees. Sadly, it seems hard to describe\n>>> exactly what is meant/wanted here.\n>>\n>> Agreed. I'd rather make the definition \"Can users, after a rename has\n>> taken place, follow the history of the file-contents across renames?\".\n>> Mainly because this is clearly unambiguous, doesn't involve\n>> implementation details and only weighs what really counts: User-visible\n>> capabilities.\n> \n\n[...]\n\n> But equally important for user is another question related to\n> \"Supporting Renames\".\n> Namely detection of renames during merge and detection of conflict \n> during merge\n> is what I would consider minimal \"Merge Renames Support\". Causing \n> information\n> to be lost is having no \"Merge Renames Support\". To have \"Yes\" in this\n> column SCM\n> have to resolve conflict at least in obvious cases, and \"Yes!\" if it\n> can remember\n> resolution of merge conflict involving renames ;-).\n> \n\nTrue.\n\n>> IMNSHO, I'd rather have all the features in the list be along the lines\n>> of \"Can users/admins/random-boon do X?\" and instead of \"yes/no\" list the\n>> number of commands/the amount of time required to achieve the desired\n>> effect. This would set a clear limit and put most terminology issues out\n>> of the way.\n> \n> This would make the comparison table less clear, unfortunately.\n> \n\nTrue that. Perhaps just stick with Yes/No and have a timing table to \ncompare merge times, multi-parent merge times and stuff like that.\n\n> \n>>> [...]\n>>>\n>>>> 19. Ease of Use. Hmmm... I don't know for Git. I personally find it \n>>>> very\n>>>> easy to use, but I have not much experiences with other SCM. I \n>>>> wonder why\n>>>> Bazaar has \"No\" there...\n>>>\n>>> Extremely subjective. Easy to learn doesn't cut it either.\n>>\n>> This one just needs to go. Could possibly be replaced with \"Has\n>> tutorial/documentation online\" or some such. No SCM is really intuitive\n>> to users that haven't experienced any of them before, so the only thing\n>> that really matters is how much documentation one can find online and\n>> how up-to-date it is.\n> \n> For example SCM can be easy to use but at the cost of simplifications\n> and limited useness.\n> \n> On the other side basic concept behind some SCM might be more\n> or less understandable...\n\nYes, but it will always be based on personal opinion and that's why it \ncan never be measured in an unbiased way. It would be like playing \nTrivial Pursuit and getting the question \"Which 20'th century author \nwrote the best books?\". There's actually two problems with that \nquestion, but the important one is that it can't be answered correctly \nin this wonderful world we live in where everyone has their own opinion.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\n"},{"id":"294532","messageId":"20061027144656.GA32451@fieldses.org","threadId":"43238","inReplyTo":"4541D291.5020205@op5.se","subject":"Re: VCS comparison table","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-10-27T14:46:56Z","receivedAt":"2006-10-27T14:46:56Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Fri, Oct 27, 2006 at 11:34:09AM +0200, Andreas Ericsson wrote:\n> Horst H. von Brand wrote:\n> >Jakub Narebski <jnareb@gmail.com> wrote:\n> >>19. Ease of Use. Hmmm... I don't know for Git. I personally find it very\n> >>easy to use, but I have not much experiences with other SCM. I wonder why\n> >>Bazaar has \"No\" there...\n> >\n> >Extremely subjective. Easy to learn doesn't cut it either.\n> \n> This one just needs to go.\n\nIt's certainly a hard question to answer, and will never be answered\ncompletely, but unfortunately it's also a really *important* question.\nThe best SCM in the world isn't much use if I can't convince my\ncoworkers to learn the thing.\n\nSo I think it's helpful to attempt to find out whether we have a problem\nhere or not, even if the problem is more one of perception than reality.\nThough obviously it would be more helpful to have something more\ndetailed than just a yes or no answer to \"is git easy to use?\"\n\n> Could possibly be replaced with \"Has tutorial/documentation online\" or\n> some such. No SCM is really intuitive to users that haven't\n> experienced any of them before, so the only thing that really matters\n> is how much documentation one can find online and how up-to-date it\n> is.\n\nDocumentation helps, though sometimes extensive documentation is a sign\nof a problem--it takes a lot more documentation to explain how to manage\na branch in CVS than it does in any sensible system....\n\n"},{"id":"298922","messageId":"m3mz7gheoe.fsf@iny.iki.fi","threadId":"43238","inReplyTo":"20061027144656.GA32451@fieldses.org","subject":"Re: VCS comparison table","fromName":"Ilpo Nyyssönen","fromEmail":"iny+news@iki.fi","sentAt":"2006-10-28T11:18:09Z","receivedAt":"2006-10-28T11:18:09Z","isPatch":false,"sender":{"key":"iny+news@iki.fi","avatar":null},"body":"\"J. Bruce Fields\" <bfields@fieldses.org> writes:\n\n> Documentation helps, though sometimes extensive documentation is a sign\n> of a problem--it takes a lot more documentation to explain how to manage\n> a branch in CVS than it does in any sensible system....\n\nUsability:\n\nI have used bzr, bk for development and git very little for following\nkernel development. I have followed this discussion quite well.\n\n1. It is easier to start using something you are already familiar\nwith. (Just try to use Mac OS X with a Windows or Linux background.)\n\nG: Something totally new and so no points from here. The way of using\ngit is just so different from any other similar software.\n\nB: Quite clearly gets points from this. Normal branches work quite\nlike many other software, the checkout stuff works like CVS and SVN.\n\n2. Finding commands.\n\nG: Quite big amount of commands, some clear, but some not so. With all\nthe installed commands, it is even more confusing. What's the\ndifference between fetch and pull and which one I should use? Same for\nclone and branch.\n\nB: A bit clearer I think, but the pull and merge does cause confusion. \nAlso the checkout stuff could be better shown in the command line\nhelp. With plugins like bzrtools the amount of command raises and\nconfusion increases. Maybe better separation for plugin commands in\nthe command line help?\n\n3. Understanding output\n\nG: Speaks a language of its own, hard to understand. No progress\nreported for long lasting operations.\n\nB: Could maybe speak a bit more. Progress reporting is quite good.\n\n4. Misc stuff\n\nG: You have only one workspace and this forces you to use git more or\nto make several repositories. You can't just diff branchA/foo\nbranchB/foo. You can't just open file from old branch to check\nsomething while you are developing in some new branch. Do I have to\ncommit my changes before changing a branch in the workspace?\n\nG: What is this git repack thing and do I have to use it? If yes, why? \nNobody told me that I should run it, but I did notice Linus mentioning\nit somewhere. Definetly causing harm for usability.\n\nB: People migth misuse the revnos and so be confused when things won't\nwork like they expected.\n\nConclusion: I would say that Bazaar is more usable than git.\n\n\n"},{"id":"298917","messageId":"ehvnal$tjg$1@sea.gmane.org","threadId":"43238","inReplyTo":"m3mz7gheoe.fsf@iny.iki.fi","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-28T13:53:05Z","receivedAt":"2006-10-28T13:53:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Ilpo Nyyssönen wrote:\n\n> \"J. Bruce Fields\" <bfields@fieldses.org> writes:\n> \n>> Documentation helps, though sometimes extensive documentation is a sign\n>> of a problem--it takes a lot more documentation to explain how to manage\n>> a branch in CVS than it does in any sensible system....\n> \n> Usability:\n> \n> I have used bzr, bk for development and git very little for following\n> kernel development. I have followed this discussion quite well.\n> \n> 1. It is easier to start using something you are already familiar\n> with. (Just try to use Mac OS X with a Windows or Linux background.)\n> \n> G: Something totally new and so no points from here. The way of using\n> git is just so different from any other similar software.\n> \n> B: Quite clearly gets points from this. Normal branches work quite\n> like many other software, the checkout stuff works like CVS and SVN.\n\nI find for example concept of branches in Git extremly easy to understand.\nBazaar-NG \"branches\" is mixture of Git branch and Git repository/clone of\nrepository. In bzr \"branch\" refers to abstract SCM concept as part of DAG of\nrevisions sourced from given revision/head/tip (git branch is very close to\nit); yet another but distinct abstract SCM concept of branch as \"your\" line\nof development i.e. path in the DAG of revisions started at given\nrevision/head/tip and ending in initial/parentless revision; the physical\nrepresentation: working area, metainformation, storage or pointer to\nstorage (when branches share storage forming so called bzr \"repository\").\n\nAbout checkout: Bazaar mixes here \"CVS checkout\" model in the \"bzr checkout\"\ncommand, and SCM concept of checking-out i.e. getting files from repository\n(or branch in bzr) to working area.\n\nOn the other side breaking with traditional concepts of _centralized_ SCM\nin _distributed_ SCM (and geared towards distributed usage) is IMVHO a good\nidea. And breaking with the cruft of bad ideas of CVS is very good idea.\n\nBut I agree that in Git some terminology (and names of commands) could be\nbetter. Some of it stems from BitKeeper background, some from the way Git\nwas created: bottom-up, from repository layout to fully (or not ;-) fledged\nSCM. For example \"pull\" as \"fetch + merge\" is IIRC BitKeeper legacy, while\nthe fact that \"merge\" command is low-level (or mid-level) command fairly\npoorly usable for user (which should use \"pull .\" for merging from local\nbranch).\n\n> 2. Finding commands.\n> \n> G: Quite big amount of commands, some clear, but some not so. With all\n> the installed commands, it is even more confusing. What's the\n> difference between fetch and pull and which one I should use? Same for\n> clone and branch.\n>\n> B: A bit clearer I think, but the pull and merge does cause confusion. \n> Also the checkout stuff could be better shown in the command line\n> help. With plugins like bzrtools the amount of command raises and\n> confusion increases. Maybe better separation for plugin commands in\n> the command line help?\n\nIn Git Users Survey (http://git.or.cz/gitwiki/GitSurvey) the answer \"too\nmany commands\" was most common answer to question 6. \"What did you find\nhardest?\" in the survey (which survey was base on Mercurial survey:\nhttp://www.selenic.com/mercurial/wiki/index.cgi/UserSurvey). It would be\nperhaps better for Git to clearly divide commands between porcelanish (for\nend user), admin (whole repository level) and plumbing (for use in\nscripts).\n\nBut for example git(7) man page lists git commands clearly divided between\nlow-level commands (plumbing): manipulation commands, interrogation\ncommands, synching commands and high level commands (porcelain): main\ncommands, ancillary commands. The \"git help\" and \"git --help\" shows the\nmost commonly used git commands with short description of each command\n(\"git help -a\" show all commands). \n \nI can understand confusion between \"git pull\" and \"git fetch\"; it is\nadressed in documentation. Although I think the confusion between\n\"bzr merge\" and \"bzr pull\" is as great if not greater.\n\nI don't understand the confusion between \"git branch\" and \"git clone\"\ncommands... unless you are confused by Bazaar-NG branch-centric approach\nwhich mixes branch with repository.\n\n> 3. Understanding output\n> \n> G: Speaks a language of its own, hard to understand. No progress\n> reported for long lasting operations.\n> \n> B: Could maybe speak a bit more. Progress reporting is quite good.\n\nWhich long lasting operations lack progress bar/progress reporting?\n\"git clone\" and \"git fetch\"/\"git pull\" both have progress report\nfor both \"smart\" git://, git+ssh:// and local protocols, and \"dumb\"\nhttp://, https://, ftp://, rsync:// protocols. \"git rebase\" has\nprogress report. \"git am\" has progress report.\n\nBut I agree that Git tends to speak in its own jargon. But this jargon is\nvery clear if you are familiar with Git. BTW. some of the worst offenders\nlike <ent> (== <tree-ish>) is removed already from documentation.\n\n> 4. Misc stuff\n> \n> G: You have only one workspace and this forces you to use git more or\n> to make several repositories. \n\nThis is your confusion stemming from Bazaar-NG branch-centricness. In Git\nworking area is associated with repository, not with branch as in bzr.\nUsually you have repsoitory embedded in working area, in .git directory in\ntop level of working area. The fact that you have only one index (but you\ncan specify alternate index, or switch between index files), and only one\ncurrent branch marker namely HEAD (you can switch HEAD to other branch; if\nI remember correctly there is no way to specify current head other way)\nmakes working with multiple working areas tied to one repository more\ndifficult. But it is usually not necessary in Git.\n\nIn Bazaar-NG \"repository\" is just sharing the storage of \"branches\"; in Git\nyou can share the storage between repositories (although it is not the\ndefault mode), or share common old history between repositories (more\ncommon). \n\n> You can't just diff branchA/foo branchB/foo.\n\nYou can: either using \"git diff branchA branchB -- foo\" which means\ndifference between branches branchA and branchB limited to the differences\non branch foo (where foo can be directory name or filename), or via\n\"extended SHA1 reference\" using \"git diff branchA:foo branchB:foo\" which\nmeans compare file/directory \"foo\" at revision \"branchA\" and file/directory\n\"foo\" at revision \"branchB\".\n\nYou can even diff two different _repositories_ if they are on the same local\nfilesystem using pasky trick described in http://git.or.cz/gitwiki/GitTips.\n\n> You can't just open file from old branch to check \n> something while you are developing in some new branch.\n\nYou can view file from old branch via \"git cat-file -p old-branch:file\".\n\n> Do I have to commit my changes before changing a branch\n> in the workspace? \n\nYou have to. But we have \"git commit --amend\", so if I need to do this\nI usually do \"git commit -m 'TEMPORARY COMMIT'\" before switching to other\nbranch. Or you can save differences between working area and current branch\nto patch file. The \"git-checkpoint\" proposal adresses that... in rather\nheavy-handed fashion. There is also \"git-stash/git-unstash\" floating\nsomewhere in git mailing list archives.\n \n> G: What is this git repack thing and do I have to use it? If yes, why? \n> Nobody told me that I should run it, but I did notice Linus mentioning\n> it somewhere. Definetly causing harm for usability.\n\nHmm... perhaps \"repack -a -d\" should be shown in \"git help\" list of commonly\nused commands output.\n\nHaving two separate formats in repository: loose (but compressed) and packed\n(in one file, deltaified, compressed) has the following advantages:\n\n0. Historical, it allowed for git to be released (deployed) early,\noriginally as fast content tracker and not full SCM, and to add features\nbased on how people used it and scripted it. It also gave Git design the\nadvantage of not being tailored/based on some storage mechanism, which\nresulted in IMHO very clean design and concepts.\n\n1. Security (together with format). It secures repository against corruption\nstemming from: corruption during saving file, race condition, interruptions\nduring operation etc.; although it doesn' save against all possible errors.\nThat is what sold Keith on choosing Git as SCM for X.Org:\nhttp://keithp.com/blog/Repository_Formats_Matter.html\n\n2. Efficiency. The packed Git format is both AFAIK the densest repository\nformat from OSS SCM, and it is very fast to access any given revision.\n\n3. Net format. It allows to use _exactly_ the same format for transmission\nduring clone and fetch; well with the exception that for \"smart\" protocols\ngit can send \"thin\" pack, with some deltas without bases. The latest work\nin progress by Nicolas Pitre and others to convert thin pack to full pack\nwithout exploding it into loose objects in between.\n\n\nThere quite frequently appears suggestion for SCM based on Git, or Git\nporcelains (like Cogito) to automatically repack. Latest work on the option\nto repack to not pack only loose objects, or repack everything, but to\nrepack given pack or repack with exception of some archive packs should\nhelp with that solution.\n\n> B: People migth misuse the revnos and so be confused when things won't\n> work like they expected.\n\nRevnos work only with very specific workflows.\n\n> Conclusion: I would say that Bazaar is more usable than git.\n\nConclusion: I would say that Git is more usable than Bazaar.\n\n"},{"id":"298918","messageId":"ehvr4h$69g$1@sea.gmane.org","threadId":"43238","inReplyTo":"ehvnal$tjg$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-28T14:58:10Z","receivedAt":"2006-10-28T14:58:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n>> You can't just diff branchA/foo branchB/foo.\n> \n> You can: either using \"git diff branchA branchB -- foo\" which means\n> difference between branches branchA and branchB limited to the differences\n> on branch foo (where foo can be directory name or filename)\n\nSorry, it should be:\n\n\"limited to the differences on pathname foo (where foo can be directory name\nor filename)\"\n\n"},{"id":"295955","messageId":"200610290018.05884.robin.rosenberg.lists@dewire.com","threadId":"43238","inReplyTo":"ehvnal$tjg$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-10-28T22:18:04Z","receivedAt":"2006-10-28T22:18:04Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"lördag 28 oktober 2006 15:53 skrev Jakub Narebski:\n> But for example git(7) man page lists git commands clearly divided between\n> low-level commands (plumbing): manipulation commands, interrogation\n> commands, synching commands and high level commands (porcelain): main\n> commands, ancillary commands. The \"git help\" and \"git --help\" shows the\n> most commonly used git commands with short description of each command\n> (\"git help -a\" show all commands).\n\nI believe people tend to skim through documentation looking for pieces of \ninformation rather than read it from start to end. So they find themselves \nreading the plumbing documentation first. Simply reordering documentation to \nlist the porcelain commands before the plumbing would make the git man page \nless scary to newcomers.\n\n"},{"id":"294641","messageId":"200610290046.23514.jnareb@gmail.com","threadId":"43238","inReplyTo":"200610290018.05884.robin.rosenberg.lists@dewire.com","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-28T22:46:23Z","receivedAt":"2006-10-28T22:46:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia niedziela 29. października 2006 00:18, Robin Rosenberg napisał:\n> lördag 28 oktober 2006 15:53 skrev Jakub Narebski:\n>>\n>> But for example git(7) man page lists git commands clearly divided between\n>> low-level commands (plumbing): manipulation commands, interrogation\n>> commands, synching commands and high level commands (porcelain): main\n>> commands, ancillary commands. The \"git help\" and \"git --help\" shows the\n>> most commonly used git commands with short description of each command\n>> (\"git help -a\" show all commands).\n> \n> I believe people tend to skim through documentation looking for pieces of \n> information rather than read it from start to end. So they find themselves \n> reading the plumbing documentation first. Simply reordering documentation to \n> list the porcelain commands before the plumbing would make the git man page \n> less scary to newcomers.\n\nGood idea. Thanks.\n\nCurrent ordering in git(7) man page is probably the result of bottom-up\ngit development. First there were plumbing commands (well, first was\nrepository format AFAICT, but I digress...).\n\n-- \nJakub Narebski\n"},{"id":"298923","messageId":"m3fyd77gsn.fsf@iny.iki.fi","threadId":"43238","inReplyTo":"ehvnal$tjg$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Ilpo Nyyssönen","fromEmail":"iny+news@iki.fi","sentAt":"2006-10-29T06:54:48Z","receivedAt":"2006-10-29T06:54:48Z","isPatch":false,"sender":{"key":"iny+news@iki.fi","avatar":null},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Ilpo Nyyssönen wrote:\n>\n>> Usability:\n>> \n>> I have used bzr, bk for development and git very little for following\n>> kernel development. I have followed this discussion quite well.\n>> \n>> 1. It is easier to start using something you are already familiar\n>> with. (Just try to use Mac OS X with a Windows or Linux background.)\n>> \n>> G: Something totally new and so no points from here. The way of using\n>> git is just so different from any other similar software.\n>> \n>> B: Quite clearly gets points from this. Normal branches work quite\n>> like many other software, the checkout stuff works like CVS and SVN.\n>\n> I find for example concept of branches in Git extremly easy to understand.\n\nMight be, but the point was: Git is harder as it is not like others. \nIn other hand one can see Bazaar like other distributed SCMs and even\nlike the not distributed ones as it has the checkout stuff.\n\nYou can give Bazaar for me, a bk user, and I can understand what to do\nwith the branches that are like bk clones. (The repository stuff is\nlater development and still optional.) Switching a CVS environment to\nBazaar one can be done so that most of the users can be just told to\nuse bzr checkout and they don't have to care about pushing.\n\nBut with git, I clone some repository. Now it is totally new to\nunderstand that I didn't clone only single branch. It's like nothing\nelse and that's what I saw when I first looked at it. I might have\neven not noticed the branch stuff and just cloned it further.\n\n> On the other side breaking with traditional concepts of _centralized_ SCM\n> in _distributed_ SCM (and geared towards distributed usage) is IMVHO a good\n> idea. And breaking with the cruft of bad ideas of CVS is very good idea.\n\nBreaking concepts can be a good idea and I somewhat think that git\nneeded to do what it did. But do remember that it came with a cost:\ngit is harder to understand and use. You first have to understand that\nit is different and how it is different.\n\n> I don't understand the confusion between \"git branch\" and \"git clone\"\n> commands... unless you are confused by Bazaar-NG branch-centric approach\n> which mixes branch with repository.\n\nThose commands do so different things in different SCMs. Just look at\nthe differences bk clone, git clone, git branch and bzr branch. You\nhave both. At the point where I didn't yet understand that I cloned\nmore than a one branch, git branch is very odd looking command.\n\n> Which long lasting operations lack progress bar/progress reporting?\n> \"git clone\" and \"git fetch\"/\"git pull\" both have progress report\n\nFirst note that I didn't notice git repack until recently so things\ngot slower until that.\n\nAt least some points they just tell that they are doing something, but\nnot how much of it has been done and how much is still to do. Look at\nBazaar and you'll see the difference, it has progress bars.\n\n>> G: You have only one workspace and this forces you to use git more or\n>> to make several repositories. \n>\n> This is your confusion stemming from Bazaar-NG branch-centricness. In Git\n> working area is associated with repository, not with branch as in bzr.\n\nExactly my point.\n\n>> You can't just diff branchA/foo branchB/foo.\n>\n> You can: either using \"git diff branchA branchB -- foo\" which means\n\nExactly my point: it forces you to use git more. In Bazaar I can do\nthis without Bazaar commands. I could even do it with some Windows GUI\nstuff, take two files or directories and compare.\n\nAs you need to use git commands more than bzr commands, git has bigger\nrequirements for usability.\n\n>> You can't just open file from old branch to check \n>> something while you are developing in some new branch.\n>\n> You can view file from old branch via \"git cat-file -p old-branch:file\".\n\nSame thing here, in Bazaar, I can just open the file from the other\nbranch. I can also compile and run the other branch while I have the\nother open.\n\nEssentially I would need a separate git repository for each branch\nanyway. In Bazaar I can use the same.\n\n\n"},{"id":"294107","messageId":"ei2563$m1u$1@sea.gmane.org","threadId":"43238","inReplyTo":"m3fyd77gsn.fsf@iny.iki.fi","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-29T12:01:07Z","receivedAt":"2006-10-29T12:01:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Ilpo Nyyssönen wrote:\n\n> Jakub Narebski <jnareb@gmail.com> writes:\n> \n>> Ilpo Nyyssönen wrote:\n>>\n>>> Usability:\n>>> \n>>> I have used bzr, bk for development and git very little for following\n>>> kernel development. I have followed this discussion quite well.\n>>> \n>>> 1. It is easier to start using something you are already familiar\n>>> with. (Just try to use Mac OS X with a Windows or Linux background.)\n>>> \n>>> G: Something totally new and so no points from here. The way of using\n>>> git is just so different from any other similar software.\n>>> \n>>> B: Quite clearly gets points from this. Normal branches work quite\n>>> like many other software, the checkout stuff works like CVS and SVN.\n>>\n>> I find for example concept of branches in Git extremly easy to\n>> understand.\n> \n> Might be, but the point was: Git is harder as it is not like others. \n> In other hand one can see Bazaar like other distributed SCMs and even\n> like the not distributed ones as it has the checkout stuff.\n> \n> You can give Bazaar for me, a bk user, and I can understand what to do\n> with the branches that are like bk clones. (The repository stuff is\n> later development and still optional.) Switching a CVS environment to\n> Bazaar one can be done so that most of the users can be just told to\n> use bzr checkout and they don't have to care about pushing.\n\nThat is of course because you are familiar with branch-centric distributed\nSCM, namely BitKeeper, when trying Bazaar-NG. IMHO branch-centric view\nis somewhat limiting; you can always use repository-centric SCM with\none-live-branch-per-repository paradigm and emulate branch-centric SCM,\nwhich is not (or not always) the case for branch-centric SCM. Branch-centric\nand repo-centric SCM promote different workflows, namely parallel uncommited\nwork on few development branches for branch-centric SCM, one-change\nper-commit multiple temporary and feature branches for repo-centric SCM.\n\nBreaking from CVS update-then-commit stupid model is IMHO very, very good\nidea. On the par of breaking from CVS \"model\" of branches. In my opinion\nCVS had one very good idea (perhaps it wasn't originally CVS idea), namely\nusing merge instead of locking files for editing; well that and the fact\nthat it tried (emphasisis on tried) to treat module as a whole, allowing\nfor multi-file change commits.\n\nTake for example the case of WordProcessors: if they all would only emulate\nthe UI of leading one (most commonly used), no progress would be made.\n\n> But with git, I clone some repository. Now it is totally new to\n> understand that I didn't clone only single branch. It's like nothing\n> else and that's what I saw when I first looked at it. I might have\n> even not noticed the branch stuff and just cloned it further.\n\nThat's the shift of paradigm. Instead of one-branch-per-repository, and\none-branch-per-developer workflow which I think usually stems from that, we\nhave one-repository-per-developer (usually), and heavily nonlinear\ndevelopment.\n\n>> On the other side breaking with traditional concepts of _centralized_ SCM\n>> in _distributed_ SCM (and geared towards distributed usage) is IMVHO a\n>> good idea. And breaking with the cruft of bad ideas of CVS is very good\n>> idea. \n> \n> Breaking concepts can be a good idea and I somewhat think that git\n> needed to do what it did. But do remember that it came with a cost:\n> git is harder to understand and use. You first have to understand that\n> it is different and how it is different.\n\nThe same could be said about moving from MS-DOS or later MS Windows to the\nworld of UNIX.\n\nBut yes, I understand and agree that being different than others can be\ndisadvantage... and can be advantage.\n\n>> I don't understand the confusion between \"git branch\" and \"git clone\"\n>> commands... unless you are confused by Bazaar-NG branch-centric approach\n>> which mixes branch with repository.\n> \n> Those commands do so different things in different SCMs. Just look at\n> the differences bk clone, git clone, git branch and bzr branch. You\n> have both. At the point where I didn't yet understand that I cloned\n> more than a one branch, git branch is very odd looking command.\n\nI for example didn't understand \"bzr branch\" concept, being familiar rather\nwith \"git branch\".\n\n>> Which long lasting operations lack progress bar/progress reporting?\n>> \"git clone\" and \"git fetch\"/\"git pull\" both have progress report\n> \n> First note that I didn't notice git repack until recently so things\n> got slower until that.\n> \n> At least some points they just tell that they are doing something, but\n> not how much of it has been done and how much is still to do. Look at\n> Bazaar and you'll see the difference, it has progress bars.\n\nWell, having progress bars for operations which are usually fast and one\nstep is in my opinion stupid idea. Even if there are combinations of\noptions which makes them slow (for example using so called pickaxe, \ne.g. \"git log -S'fragment' -- file\" to find revisions which introduced\n'fragment' to 'file').\n\nI'll ask again: _which_ git commands you find lacking progress reporting?\n\n>>> You can't just diff branchA/foo branchB/foo.\n>>\n>> You can: either using \"git diff branchA branchB -- foo\" which means\n> \n> Exactly my point: it forces you to use git more. In Bazaar I can do\n> this without Bazaar commands. I could even do it with some Windows GUI\n> stuff, take two files or directories and compare.\n> \n> As you need to use git commands more than bzr commands, git has bigger\n> requirements for usability.\n\nBut git commands are more powerfull than equivalent GNU commands. git-diff\nis more powerfull than GNU diff (for example it can detect renames and\ncopying, it shows mode changes, it can show diff for merge using \"combined\ndiff\" format), git-grep is more powerfull than GNU grep (for example Linus\nfinds himself to put files in git repository to use git-grep instead of\ncombination of GNU find and GNU grep).\n \nAnd don't forget about _cost_ of doing that abovementioned way, namely\nhaving to keep two copies of working area (differing in revision, of\ncourse).\n\n>>> You can't just open file from old branch to check \n>>> something while you are developing in some new branch.\n>>\n>> You can view file from old branch via \"git cat-file -p old-branch:file\".\n\nOr you can \"git commit -a -m 'TEMP'\" to save changes, \"git checkout\n<branch>\" to switch to other branch, perhaps git-clean, hack; hack; hack;\ncommit changes, swotch back to branch, and wiether amend the commit or reset\nindex and HEAD (but not working area).\n\n> Same thing here, in Bazaar, I can just open the file from the other\n> branch. I can also compile and run the other branch while I have the\n> other open.\n\nDo you really often compile and run other branch while developing on other?\n\n> Essentially I would need a separate git repository for each branch\n> anyway. In Bazaar I can use the same.\n\nWell, that's a fact that git lacks somewhat (but not lack completly) support\nfor multiple independent workplaces for the same repository (link+separate\nindex+separate HEAD), and lacks somewhat (but not completely) support for\nsharing object database between repositories aka. bzr model (you have to be\nvery careful with pruning).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295104","messageId":"20061029182454.GT17019@over-yonder.net","threadId":"43238","inReplyTo":"ei2563$m1u$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Matthew D. Fuller","fromEmail":"fullermd@over-yonder.net","sentAt":"2006-10-29T18:24:54Z","receivedAt":"2006-10-29T18:24:54Z","isPatch":false,"sender":{"key":"fullermd@over-yonder.net","avatar":null},"body":"On Sun, Oct 29, 2006 at 01:01:07PM +0100 I heard the voice of\nJakub Narebski, and lo! it spake thus:\n> \n> Branch-centric and repo-centric SCM promote different workflows,\n> namely parallel uncommited work on few development branches for\n> branch-centric SCM, one-change per-commit multiple temporary and\n> feature branches for repo-centric SCM.\n\nI don't think that follows at all.\n\n\n> Do you really often compile and run other branch while developing on\n> other?\n\nYes.  And I do the same with older revisions along a given branch too,\nwhere is where [lightweight] checkouts come in handy.\n\n\n-- \nMatthew Fuller     (MF4839)   |  fullermd@over-yonder.net\nSystems/Network Administrator |  http://www.over-yonder.net/~fullermd/\n"},{"id":"295228","messageId":"200610291939.06270.jnareb@gmail.com","threadId":"43238","inReplyTo":"20061029182454.GT17019@over-yonder.net","subject":"Re: VCS comparison table","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-29T18:39:05Z","receivedAt":"2006-10-29T18:39:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthew D. Fuller wrote:\n> On Sun, Oct 29, 2006 at 01:01:07PM +0100 I heard the voice of\n> Jakub Narebski, and lo! it spake thus:\n>>\n>> Do you really often compile and run other branch while developing on\n>> other?\n> \n> Yes.  And I do the same with older revisions along a given branch too,\n> where is where [lightweight] checkouts come in handy.\n\nWell, if you don't _work_ on other branch, you can alwaych checkout\nthe other branch or any given revision from a separate directory\nusing\n  git --git-dir=<path to repo> tar-tree <revision> | tar xf -\nfor example.\n-- \nJakub Narebski\n"},{"id":"297050","messageId":"20061030001035.GA15753@thunk.org","threadId":"43238","inReplyTo":"ei2563$m1u$1@sea.gmane.org","subject":"Re: VCS comparison table","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2006-10-30T00:10:35Z","receivedAt":"2006-10-30T00:10:35Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Oct 29, 2006 at 01:01:07PM +0100, Jakub Narebski wrote:\n> > You can give Bazaar for me, a bk user, and I can understand what to do\n> > with the branches that are like bk clones. (The repository stuff is\n> > later development and still optional.) Switching a CVS environment to\n> > Bazaar one can be done so that most of the users can be just told to\n> > use bzr checkout and they don't have to care about pushing.\n> \n> That is of course because you are familiar with branch-centric distributed\n> SCM, namely BitKeeper, when trying Bazaar-NG. IMHO branch-centric view\n> is somewhat limiting; you can always use repository-centric SCM with\n> one-live-branch-per-repository paradigm and emulate branch-centric SCM,\n> which is not (or not always) the case for branch-centric SCM. Branch-centric\n> and repo-centric SCM promote different workflows, namely parallel uncommited\n> work on few development branches for branch-centric SCM, one-change\n> per-commit multiple temporary and feature branches for repo-centric SCM.\n\nI've got to disagree here.  Being a former bitkeeper user myself, I\nfind BZR-NG to be nothing like bk.  In particular, Bitkeeper is *not*\nbranch-centric the way that BZR is; in fact, bk is much closer to git\nand bk both in terms of how it works and its terminology.  You can\nhave a non-linear set of history without using any \"branches\" in both\nbk and mercurial, simply by creating two commits changing different\nfiles in two different repositories (using the bk, git, and hg sense\nof the word --- only bzr attaches a completely different definitoin to\nterm \"repository\"), and then pull them together.   \n\nWith bzr, the only way you can do the following is by explicitly\ncreating a separate branch and then merging the two branches together.\nIn bzr --- unlike bk, git, and hg --- when you are on a \"branch\" the\nhistory must be completely linear.  The difference between bk, and git\nand hg, is that bk enforces a restriction that there must be one\n\"head\", or \"tip\" on a particular repository (in the bk, hg, and git\nsense).  So if you start by cloning the repository A -> B, and then\nmake one or more commits in repository A, and then one or more commits\nin repository B, when you pull from repository B to A, bk will enforce\nthe creation of a merge changeset on the resulting repository --- or\nfail the merge.  (Actually, with BK there was the option to create\nmultiple tips using \"lines of development\", but it was never fully\ndeveloped or supported.)\n\nWith hg and git, you have the *option* of pulling the two lines of\ncommits together using a merge changeset *or* leaving the two \"tips\"\nor \"heads\" unmerged.  But that's only a very minor difference between\nbk and hg/git --- and if you are willing to always merge two heads\nafter pulling so that your git or hg repository only has one head/tip,\nthen conceptually the changeset history is just like bk.\n\nIn contrast, it's impossible to do this with bzr without leaving the\nnamed branches around, so in this sense it's quite different form BK.\n\n\t\t\t\t\t\t- Ted\n\nP.S.  I'm going to teaching a class entitled \"Bzr, Hg, and Git, Oh\nmy!\" at LISA conference in Washington, D.C.  It's only a half-day\ntutorial intending to cover the basics of Distributed SCM systems, so\nmost folks on this list will probably know everything I'm planning on\ndiscussing, but if you have some colleagues who need a gentle\nintroduction, please feel tell them to head on over to the LISA\nconference website at www.usenix.org.\n"},{"id":"296323","messageId":"ei4jia$vj0$1@sea.gmane.org","threadId":"43238","inReplyTo":"ehvnal$tjg$1@sea.gmane.org","subject":"Progress reporting (was: VCS comparison table)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-30T10:18:56Z","receivedAt":"2006-10-30T10:18:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n> Ilpo Nyyssönen wrote:\n\n>> 3. Understanding output\n>> \n>> G: Speaks a language of its own, hard to understand. No progress\n>> reported for long lasting operations.\n>> \n>> B: Could maybe speak a bit more. Progress reporting is quite good.\n> \n> Which long lasting operations lack progress bar/progress reporting?\n> \"git clone\" and \"git fetch\"/\"git pull\" both have progress report\n> for both \"smart\" git://, git+ssh:// and local protocols, and \"dumb\"\n> http://, https://, ftp://, rsync:// protocols. \"git rebase\" has\n> progress report. \"git am\" has progress report.\n\nI was bitten lately by git lack of progress reporting for git-push.\nWhile it nicely reports local progress (generating data) it unfortunately\nlacks wget like, \"curl -o\" like or scp like pack upload progress\nreporting. And while usually push is fast, initial push of whole\nproject to empty repository can be quite slow on low-bandwidth link\n(or busy network).\n\ngit version 1.4.3.3 on local side, git+ssh:// protocol, git version\n1.4.3.3.g9ab2 on the remote side (repo.or.cz).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295510","messageId":"Pine.LNX.4.64.0610301018310.11384@xanadu.home","threadId":"43238","inReplyTo":"ei4jia$vj0$1@sea.gmane.org","subject":"Re: Progress reporting (was: VCS comparison table)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-10-30T15:21:09Z","receivedAt":"2006-10-30T15:21:09Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 30 Oct 2006, Jakub Narebski wrote:\n\n> I was bitten lately by git lack of progress reporting for git-push.\n> While it nicely reports local progress (generating data) it unfortunately\n> lacks wget like, \"curl -o\" like or scp like pack upload progress\n> reporting. And while usually push is fast, initial push of whole\n> project to empty repository can be quite slow on low-bandwidth link\n> (or busy network).\n\nWhat about this patch?\n\ndiff --git a/builtin-pack-objects.c b/builtin-pack-objects.c\nindex 41e1e74..7f87ae8 100644\n--- a/builtin-pack-objects.c\n+++ b/builtin-pack-objects.c\n@@ -1524,6 +1524,10 @@ int cmd_pack_objects(int argc, const cha\n \t\t\tprogress = 1;\n \t\t\tcontinue;\n \t\t}\n+\t\tif (!strcmp(\"--all-progress\", arg)) {\n+\t\t\tprogress = 2;\n+\t\t\tcontinue;\n+\t\t}\n \t\tif (!strcmp(\"--incremental\", arg)) {\n \t\t\tincremental = 1;\n \t\t\tcontinue;\n@@ -1641,7 +1645,7 @@ int cmd_pack_objects(int argc, const cha\n \telse {\n \t\tif (nr_result)\n \t\t\tprepare_pack(window, depth);\n-\t\tif (progress && pack_to_stdout) {\n+\t\tif (progress == pack_to_stdout) {\n \t\t\t/* the other end usually displays progress itself */\n \t\t\tstruct itimerval v = {{0,},};\n \t\t\tsetitimer(ITIMER_REAL, &v, NULL);\ndiff --git a/send-pack.c b/send-pack.c\nindex 0e90548..9280481 100644\n--- a/send-pack.c\n+++ b/send-pack.c\n@@ -30,6 +30,7 @@ static void exec_pack_objects(void)\n {\n \tstatic const char *args[] = {\n \t\t\"pack-objects\",\n+\t\t\"--all-progress\",\n \t\t\"--stdout\",\n \t\tNULL\n"}]}