{"thread":{"id":"14163","subject":"Re: policy and mechanism for less-connected clients","startedAt":"2008-06-26T11:37:10Z","lastAt":"2016-08-14T00:43:17Z","messageCount":3,"participants":["Theodore Tso","David Jeske"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"81275","messageId":"20080626113710.GD8610@mit.edu","threadId":"14163","inReplyTo":null,"subject":"Re: policy and mechanism for less-connected clients","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-06-26T11:37:10Z","receivedAt":"2008-06-26T11:37:10Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Jun 26, 2008 at 06:08:55AM -0000, David Jeske wrote:\n> I can be better than cvs with the EXACT same workflow, by checking in their\n> local changes (git checkin;) and then doing the \"up\" (git pull;). If they\n> decide they botched their merge, they can get back to where they were before\n> the UP because I'm using a richer underlying mechanism to implement their\n> workflow.\n\nThis is a really good example of the problems involved.  One of the\nmajor problems with CVS is that CVS developers have a tendency to use\n\"cvs up\" *way* too often --- i.e., with a dirty tree.  Why do they\nhave a dirty tree?  Well, generally because they commit too rarely;\nsince CVS branches are so awful to use, they generally don't use CVS\nbranches, and so if they are in the middle of making major changes the\nsource base, they may not do a CVS checkin for weeks or months, since\nthey don't want to break the centrally visible branch until their\nproject actuall is at a stage where it can be checked into the tree\nwithout breaking core functionality.\n\n(I once supervised a programmer who didn't do a CVS checkin for two\nmonths, and then lost two months of work when his local disk died, and\nas a result he had a nervous breakdown; you just can't make up some of\nthe massive, major problems that can result from CVS-inspired\nworkflows.)\n\nSo if you are going to accomodate the broken workflow where people\nleave dirty state in their local tree for vast amounts of time, and\nthus insist on running \"cvs up\" all the time, and will try to cover\nfor it by committing their work under their noses when they do the\nequivalent of \"cvs up\" in a dirty worktree --- what does that mean?\nWell, maybe you can make it work, but it breaks other nice features of\ngit.  For example, it means that \"git bisect\" can't possibly work,\nsince there will be huge number of commits where the tree may not even\nbuild!\n\nAccomodating the CVS workflow is basically about the fact that users\ndon't want to learn about CVS branches, because they were horrible to\nuse, and even worse to merge.  But that's not true with git branches;\nso maybe it's better to teach them how to use git branches instead,\ninstead of trying to coddle them into letting them use the the same\nold broken CVS workflow that was based on branch-avoidance?\n\nI've created and taught a Usenix tutorial which covers the basics of\ndistributed source code management systems, including branches,\nrepositories, pushing and pulling between them, for git, hg, AND bzr,\nand I did it in half a day.  The concepts really aren't hard.  The\nmain problem with git is that because the UI grew organically, there\nare all sorts of exceptions and non-linearities in its CLI.  \n\nFor example, the fact that \"git checkout\" can be used both to switch\nbetween branches, and revert and editing file.  Or the fact that how\nyou specify a set of revisions in git-format-patch is different in\nterms of what happens when you specify a single commit; it's\ndocumented in the man page now, at least, and people who teach git\nafter a while learn about the things that you have to teach newbies\nthat git experts take for granted.  (Just as people who teach English\nas a second language learn about all of the exceptions to the language\nthat you have to point out that are second nature to the natives.)\nBut really, git *isn't* that hard, once you get past the somewhat\nawkard CLI.  (It's no worse, and probably much better, than the Unix\nshell/test/awk/sed/head/tail/sort/uniq/comm, etc.  You just have to\nget over the learning curve.)\n\n> git's mechanisms are really great for making a hybrid\n> central/distributed system which has the simplicity of cvs/perforce\n> and several of the benefits of git. The git interface is just too\n> complicated to be used for this.  Fortunately, building on git means\n> that power users will still be able to use git directly and people\n> can distribute the repositories as much as they want.\n\nI'd suggest that you try using git straight for a bit longer, before\nyou start drawing these conclusions.  Trust me, the concepts of git\nreally aren't that hard to explain to people; that's not what you need\nto hide from people coming from the CVS world.  The hard part is the\nfact that git's UI has all sorts of non-linearities and that git's\ndocumentation and introductory tutorials are not as good as it should\nbe.  (Although it's gotten a LOT better than just a year or two ago.)\n\nAlso, if your program when used by CVS refugees to causes the git\nrepository to be peppered with trash commits which don't build, even\nif power users are using git directly, their ability to browse the\nrepository using \"git log\" or \"gitk\", or to try to find problems using\n\"git bisect\", will be horribly, negatively affected.  So I am a bit\nworried that the result will end up destroying value for the project\nin the long-term, and that the costs will not be matched by the\nbenefits of simply teaching the CVS refugees a few bits of git and\nDSCM core concepts, which I've found is *not* the hard parts of\ngetting newbies to use git.\n\n> Good question. I'm working on a command-line wrapper for git that does it.\n> Digging into the \"plumbling\" is making it more obvious why I find git's\n> porcelain operations hard to understand.\n\nExactly.  So what I would ask you to consider is that you may find it\npersonally useful to design this system, but afterwards, before you\ninflict it on projects, and deal with some of the attendent side\neffects (like all of these trash commits causing \"git bisect\" to go\ndown the drain), that you consider whether *now* that you understand\nhow git works and why it does some of the things it does, and what the\nshortcomings of the git porcelain are from a UI perspective, whether\nCVS refugees really would be best served by this system you are\ndesigning, or whether a few wrapper scripts to hide some of the more\npointy spikes in git's CLI, plus some better tutorials, might in the\nlong run be much better for these CVS developers that you are trying\nto serve.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"81302","messageId":"32522.1654064537$1214502239@news.gmane.org","threadId":"14163","inReplyTo":"20080626113710.GD8610@mit.edu","subject":"Re: policy and mechanism for less-connected clients","fromName":"David Jeske","fromEmail":"jeske@willowmail.com","sentAt":null,"receivedAt":"2008-06-26T16:40:27Z","isPatch":false,"sender":{"key":"jeske@willowmail.com","avatar":null},"body":"\nThanks for pointing out the issue with automatically committing and bisect.\nYou're right, if I'm going to automatically commit under the covers I should\nuse stash instead. However, I don't want users to keep a dirty tree, and now\nthey don't have to.\n\nTo use your two-months-without-checkins example.. one of the big problems I\nhave with cvs/p4 is this notion that I'm not supposed to record my work every\n5-50 minutes. I checkin every time my code does something new and the tests\npass. In my own startup projects/companies this is fine, because it's my tree.\nAs soon as the group policy stops me from checking in every 5-50 minutes, I\npainfully make my own branch so I can checkin on my schedule. I'm starting to\nwitness some users solving this problem in a very libertarian way, by using git\nto manage their local changes even though they work in a code-review restricted\ncvs/p4 environment.\n\n-- Theodore Tso wrote:\n> I'd suggest that you try using git straight for a bit longer, before\n> you start drawing these conclusions. Trust me, the concepts of git\n> really aren't that hard to explain to people; that's not what you need\n> to hide from people coming from the CVS world.  The hard part is the\n> fact that git's UI has all sorts of non-linearities and that git's\n> documentation and introductory tutorials are not as good as it should\n> be.  (Although it's gotten a LOT better than just a year or two ago.)\n\nI agree 100%. I am using git straight. I think I have read more git\ndocumentation and definitely read more git source-code in trying to use it over\na couple months, than I have read of cvs/p4 in decades - just to try to\nunderstand which of the 3 ways to get from here-to-there is correct, and then\nwhen I pull back the red curtain a little further I realize I was totally\nwrong.\n\nThis started as a \"cheat sheet\" file with the combination of git commands I had\nto execute to perform each task. However, they are only valid in the context of\na git-repo that's configured in certain ways. I realized it would be simpler\n(even for just me) if I had something that grouped commands and did 'lint'\nsanity checks, with helpful tutorial responses. Thus the wrapper.\n\n> Exactly.  So what I would ask you to consider is that you may find it\n> personally useful to design this system,\n\nI see where you're going with this, and I agree...\n\n> but afterwards, before you inflict it on projects, and deal\n> with some of the attendent side effects (like all of these trash\n> commits causing \"git bisect\" to go down the drain), that you\n> consider whether *now* that you understand how git works and\n> why it does some of the things it does, and what the\n> shortcomings of the git porcelain are from a UI perspective, whether\n> CVS refugees really would be best served by this system you are\n> designing, or whether a few wrapper scripts to hide some of the more\n> pointy spikes in git's CLI, plus some better tutorials, might in the\n> long run be much better for these CVS developers that you are trying\n> to serve.\n\nAbsolutly. I hope that you can understand my goal of an 'interactive command\nline/tutorial linear path from cvs/p4 to git'. One where they don't get stuck\nand turn back, but also where they work in ways which are 'fairly reasonable'\nin the git community. I also hope you'll help me evaluate whether I've succeed\nor just made another confusing set of compromises that are no good. There is no\nneed for more of the latter.\n\nI also have a group that's been using git and wants to switch back to cvs/p4.\nThey are willing to give up tracking their local changes (or do it with private\ngits) in order to get a simpler model for 'shared head of tree' development. I\nthink they are a good test-case as well.\n\n------\n\nSo far, 1/2 of the lines of my script merely transitional documentation from\np4/cvs to git. As I write more of this prose, I realize that it may be helpful\nas transition documentation webpages. However, it is much more than passive\ndocumentation, because if there are 3 steps from here to there, I can look at\nthe repository and see where the user is, and tell them what they need to do\nnext.\n\nAs one example, I have a command \"pending\" (like p4 pending) which shows local\nchanges in my branch (on my inaccessible firewalled machine) which are not on\nmy origin repo(s). Except that in order for this concept to even make sense, it\nfirst:\n\n- checks if I have an 'origin' for a public repo\n- checks that my current branch is tracking an [some]origin\n- if it is mapped to a 'myorigin' personal published repo\n(because I'm firewalled), it checks that the name of the\nbranch matches the myorigin/branchname (because it's easier\nto think straight if myorigin is a literal copy of my local\nrepo)\n- shows what changes I have which are not submitted to myorigin\nand/or origin\n\nIf at any step along that path something doesn't check out, it explains what\ndidn't check out, and has a helpful help-page about ways that I might configure\nit so 'pending' can do something useful. Think of it like \"git lint\" and some\ndocumentation.\n\nThat said, it's trickier than I thought, because git is capable of working in\nso many ways. (all that complexity isn't there for nothing) Time will tell if I\ncan strike a useful balance.\n"},{"id":"299237","messageId":"willow-jeske-01l6zg4eFEDjCdFw","threadId":"14163","inReplyTo":"20080626113710.GD8610@mit.edu","subject":"Re: policy and mechanism for less-connected clients","fromName":"David Jeske","fromEmail":"jeske@willowmail.com","sentAt":null,"receivedAt":"2016-08-14T00:43:17Z","isPatch":false,"sender":{"key":"jeske@willowmail.com","avatar":null},"body":"\nThanks for pointing out the issue with automatically committing and bisect.\nYou're right, if I'm going to automatically commit under the covers I should\nuse stash instead. However, I don't want users to keep a dirty tree, and now\nthey don't have to.\n\nTo use your two-months-without-checkins example.. one of the big problems I\nhave with cvs/p4 is this notion that I'm not supposed to record my work every\n5-50 minutes. I checkin every time my code does something new and the tests\npass. In my own startup projects/companies this is fine, because it's my tree.\nAs soon as the group policy stops me from checking in every 5-50 minutes, I\npainfully make my own branch so I can checkin on my schedule. I'm starting to\nwitness some users solving this problem in a very libertarian way, by using git\nto manage their local changes even though they work in a code-review restricted\ncvs/p4 environment.\n\n-- Theodore Tso wrote:\n> I'd suggest that you try using git straight for a bit longer, before\n> you start drawing these conclusions. Trust me, the concepts of git\n> really aren't that hard to explain to people; that's not what you need\n> to hide from people coming from the CVS world.  The hard part is the\n> fact that git's UI has all sorts of non-linearities and that git's\n> documentation and introductory tutorials are not as good as it should\n> be.  (Although it's gotten a LOT better than just a year or two ago.)\n\nI agree 100%. I am using git straight. I think I have read more git\ndocumentation and definitely read more git source-code in trying to use it over\na couple months, than I have read of cvs/p4 in decades - just to try to\nunderstand which of the 3 ways to get from here-to-there is correct, and then\nwhen I pull back the red curtain a little further I realize I was totally\nwrong.\n\nThis started as a \"cheat sheet\" file with the combination of git commands I had\nto execute to perform each task. However, they are only valid in the context of\na git-repo that's configured in certain ways. I realized it would be simpler\n(even for just me) if I had something that grouped commands and did 'lint'\nsanity checks, with helpful tutorial responses. Thus the wrapper.\n\n> Exactly.  So what I would ask you to consider is that you may find it\n> personally useful to design this system,\n\nI see where you're going with this, and I agree...\n\n> but afterwards, before you inflict it on projects, and deal\n> with some of the attendent side effects (like all of these trash\n> commits causing \"git bisect\" to go down the drain), that you\n> consider whether *now* that you understand how git works and\n> why it does some of the things it does, and what the\n> shortcomings of the git porcelain are from a UI perspective, whether\n> CVS refugees really would be best served by this system you are\n> designing, or whether a few wrapper scripts to hide some of the more\n> pointy spikes in git's CLI, plus some better tutorials, might in the\n> long run be much better for these CVS developers that you are trying\n> to serve.\n\nAbsolutly. I hope that you can understand my goal of an 'interactive command\nline/tutorial linear path from cvs/p4 to git'. One where they don't get stuck\nand turn back, but also where they work in ways which are 'fairly reasonable'\nin the git community. I also hope you'll help me evaluate whether I've succeed\nor just made another confusing set of compromises that are no good. There is no\nneed for more of the latter.\n\nI also have a group that's been using git and wants to switch back to cvs/p4.\nThey are willing to give up tracking their local changes (or do it with private\ngits) in order to get a simpler model for 'shared head of tree' development. I\nthink they are a good test-case as well.\n\n------\n\nSo far, 1/2 of the lines of my script merely transitional documentation from\np4/cvs to git. As I write more of this prose, I realize that it may be helpful\nas transition documentation webpages. However, it is much more than passive\ndocumentation, because if there are 3 steps from here to there, I can look at\nthe repository and see where the user is, and tell them what they need to do\nnext.\n\nAs one example, I have a command \"pending\" (like p4 pending) which shows local\nchanges in my branch (on my inaccessible firewalled machine) which are not on\nmy origin repo(s). Except that in order for this concept to even make sense, it\nfirst:\n\n- checks if I have an 'origin' for a public repo\n- checks that my current branch is tracking an [some]origin\n- if it is mapped to a 'myorigin' personal published repo\n(because I'm firewalled), it checks that the name of the\nbranch matches the myorigin/branchname (because it's easier\nto think straight if myorigin is a literal copy of my local\nrepo)\n- shows what changes I have which are not submitted to myorigin\nand/or origin\n\nIf at any step along that path something doesn't check out, it explains what\ndidn't check out, and has a helpful help-page about ways that I might configure\nit so 'pending' can do something useful. Think of it like \"git lint\" and some\ndocumentation.\n\nThat said, it's trickier than I thought, because git is capable of working in\nso many ways. (all that complexity isn't there for nothing) Time will tell if I\ncan strike a useful balance.\n"}]}