{"thread":{"id":"14158","subject":"Re: policy and mechanism for less-connected clients","startedAt":"2008-06-26T05:23:10Z","lastAt":"2016-08-14T00:43:16Z","messageCount":4,"participants":["Theodore Tso","Junio C Hamano","David Jeske"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"81231","messageId":"20080626052310.GC8610@mit.edu","threadId":"14158","inReplyTo":null,"subject":"Re: policy and mechanism for less-connected clients","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-06-26T05:23:10Z","receivedAt":"2008-06-26T05:23:10Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Jun 25, 2008 at 11:03:02PM -0000, David Jeske wrote:\n> I don't want to replicate CVS behavior, just the workflow.\n\nIt's not clear exactly what you want.  If you want the CVS workflow\n(with all of its downsides), then just use \"git pull; hack hack hack;\ngit push\" all on the master branch.  If you are going to preserve the\nworkflow of CVS, then you're also going to preserve all of the\ndownsides of CVS.  If you aren't willing to make the users learn\nanything new, then what's the point?\n\nAnd if you are willing to make the users change their behaviour a\nsomewhat -- how much change are you willing to make them deviate from\nthe CVS workflow, and how much smarts are you willing to assume that\nthey have?\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"81232","messageId":"7vlk0su5pw.fsf@gitster.siamese.dyndns.org","threadId":"14158","inReplyTo":"20080626052310.GC8610@mit.edu","subject":"Re: policy and mechanism for less-connected clients","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-26T05:26:35Z","receivedAt":"2008-06-26T05:26:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso <tytso@mit.edu> writes:\n\n> On Wed, Jun 25, 2008 at 11:03:02PM -0000, David Jeske wrote:\n>> I don't want to replicate CVS behavior, just the workflow.\n>\n> It's not clear exactly what you want.  If you want the CVS workflow\n> (with all of its downsides), then just use \"git pull; hack hack hack;\n> git push\" all on the master branch.\n\nEh, my point was more about \"to preserve CVS workflow, fetch+rebase+push\nis much closer than pull+push\"...\n"},{"id":"81240","messageId":"32645.6224699088$1214461121@news.gmane.org","threadId":"14158","inReplyTo":"20080626052310.GC8610@mit.edu","subject":"Re: policy and mechanism for less-connected clients","fromName":"David Jeske","fromEmail":"jeske@willowmail.com","sentAt":null,"receivedAt":"2008-06-26T06:04:22Z","isPatch":false,"sender":{"key":"jeske@willowmail.com","avatar":null},"body":"-- Theodore Tso wrote:\n> If you are going to preserve the workflow of CVS, then you're\n> also going to preserve all of the downsides of CVS.\n\nI don't agree with this, and I don't see you proposing any logic that proves it\nto be true. Of course I plan to make small changes. However, in my previous\nmessage I proposed 3 same-workflow improvements, and 2 small-workflow-extension\nimprovements. I have more in mind..\n\nhttp://marc.info/?l=git&m=121442660332114&w=2\n\nMaybe it was too confusing or too long to read. Just consider the first simple\nexample.\n\nCurrently \"cvs up\" in a dirty tree is a destructive operation. If you merge\nbadly, you can't get back to your local working files before the \"up\". I've\nbeen burned by this in cvs/perforce enough that now when there are complicated\nupdate-conflicts I tar up the tree before trying to fix them. I still can't\nreally get back to the pre-up state.\n\nI can be better than cvs with the EXACT same workflow, by checking in their\nlocal changes (git checkin;) and then doing the \"up\" (git pull;). If they\ndecide they botched their merge, they can get back to where they were before\nthe UP because I'm using a richer underlying mechanism to implement their\nworkflow.\n\nDo you think that's not an improvement? or not the same workflow? It sure seems\nlike a same-workflow improvement to me.\n\n----\n\ngit's mechanisms are really great for making a hybrid central/distributed\nsystem which has the simplicity of cvs/perforce and several of the benefits of\ngit. The git interface is just too complicated to be used for this.\nFortunately, building on git means that power users will still be able to use\ngit directly and people can distribute the repositories as much as they want.\n\n> how much change are you willing to make them deviate from\n> the CVS workflow, and how much smarts are you willing to assume that\n> they have?\n\nGood question. I'm working on a command-line wrapper for git that does it.\nDigging into the \"plumbling\" is making it more obvious why I find git's\nporcelain operations hard to understand. I think I can make a 2-repository\nsetup (personal-inaccessible, origin) work like cvs/perforce with local\ncheckins, and I can make a 3-repository setup (personal-inaccessible,\npersonal-accessible, origin) work nearly the same as cvs while allowing\ndistributed collaboration. I think I will need a tiny bit of custom server\nsupport (to create the personal-accessible repositories automatically).\n\nRight now it looks like I'll be a simple hybrid of cvs/perforce, with a couple\ngit concepts peppered in. (but just a couple) It seems simple so far, it's just\ntaking me a while to dig through git-plumbing to understand it.\n\nAlso remember, this isn't built to handle what linux-kernel folks do with git.\nIt's designed to provide a familiar environment for cvs/perforce style users\nthat is just as simple but a whole lot better. Even if it eventually gets lots\nof git concepts, they won't HAVE to understand them to use it. They can learn\nthem as they go.  This is obviously something that people want, as cogito and\neasy-git show.\n"},{"id":"299236","messageId":"willow-jeske-01l6jzyMFEDjCXvz","threadId":"14158","inReplyTo":"20080626052310.GC8610@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:16Z","isPatch":false,"sender":{"key":"jeske@willowmail.com","avatar":null},"body":"-- Theodore Tso wrote:\n> If you are going to preserve the workflow of CVS, then you're\n> also going to preserve all of the downsides of CVS.\n\nI don't agree with this, and I don't see you proposing any logic that proves it\nto be true. Of course I plan to make small changes. However, in my previous\nmessage I proposed 3 same-workflow improvements, and 2 small-workflow-extension\nimprovements. I have more in mind..\n\nhttp://marc.info/?l=git&m=121442660332114&w=2\n\nMaybe it was too confusing or too long to read. Just consider the first simple\nexample.\n\nCurrently \"cvs up\" in a dirty tree is a destructive operation. If you merge\nbadly, you can't get back to your local working files before the \"up\". I've\nbeen burned by this in cvs/perforce enough that now when there are complicated\nupdate-conflicts I tar up the tree before trying to fix them. I still can't\nreally get back to the pre-up state.\n\nI can be better than cvs with the EXACT same workflow, by checking in their\nlocal changes (git checkin;) and then doing the \"up\" (git pull;). If they\ndecide they botched their merge, they can get back to where they were before\nthe UP because I'm using a richer underlying mechanism to implement their\nworkflow.\n\nDo you think that's not an improvement? or not the same workflow? It sure seems\nlike a same-workflow improvement to me.\n\n----\n\ngit's mechanisms are really great for making a hybrid central/distributed\nsystem which has the simplicity of cvs/perforce and several of the benefits of\ngit. The git interface is just too complicated to be used for this.\nFortunately, building on git means that power users will still be able to use\ngit directly and people can distribute the repositories as much as they want.\n\n> how much change are you willing to make them deviate from\n> the CVS workflow, and how much smarts are you willing to assume that\n> they have?\n\nGood question. I'm working on a command-line wrapper for git that does it.\nDigging into the \"plumbling\" is making it more obvious why I find git's\nporcelain operations hard to understand. I think I can make a 2-repository\nsetup (personal-inaccessible, origin) work like cvs/perforce with local\ncheckins, and I can make a 3-repository setup (personal-inaccessible,\npersonal-accessible, origin) work nearly the same as cvs while allowing\ndistributed collaboration. I think I will need a tiny bit of custom server\nsupport (to create the personal-accessible repositories automatically).\n\nRight now it looks like I'll be a simple hybrid of cvs/perforce, with a couple\ngit concepts peppered in. (but just a couple) It seems simple so far, it's just\ntaking me a while to dig through git-plumbing to understand it.\n\nAlso remember, this isn't built to handle what linux-kernel folks do with git.\nIt's designed to provide a familiar environment for cvs/perforce style users\nthat is just as simple but a whole lot better. Even if it eventually gets lots\nof git concepts, they won't HAVE to understand them to use it. They can learn\nthem as they go.  This is obviously something that people want, as cogito and\neasy-git show.\n"}]}