Re: policy and mechanism for less-connected clients

Theodore Tso· Jun 26, 2008, 05:23 UTC · lore

On Wed, Jun 25, 2008 at 11:03:02PM -0000, David Jeske wrote:

> I don't want to replicate CVS behavior, just the workflow.

It's not clear exactly what you want. If you want the CVS workflow (with all of its downsides), then just use "git pull; hack hack hack; git push" all on the master branch. If you are going to preserve the workflow of CVS, then you're also going to preserve all of the downsides of CVS. If you aren't willing to make the users learn anything new, then what's the point?

And if you are willing to make the users change their behaviour a somewhat -- how much change are you willing to make them deviate from the CVS workflow, and how much smarts are you willing to assume that they have?

							- Ted

Junio C Hamano· Jun 26, 2008, 05:26 UTC · re: Theodore Tso · lore

Theodore Tso <tytso@mit.edu> writes:

Show 6 quoted lines

> On Wed, Jun 25, 2008 at 11:03:02PM -0000, David Jeske wrote:
>> I don't want to replicate CVS behavior, just the workflow.
>
> It's not clear exactly what you want.  If you want the CVS workflow
> (with all of its downsides), then just use "git pull; hack hack hack;
> git push" all on the master branch.

Eh, my point was more about "to preserve CVS workflow, fetch+rebase+push is much closer than pull+push"...

David Jeske· Jun 26, 2008, 06:04 UTC · re: Theodore Tso · lore

-- Theodore Tso wrote:

> If you are going to preserve the workflow of CVS, then you're
> also going to preserve all of the downsides of CVS.

I don't agree with this, and I don't see you proposing any logic that proves it to be true. Of course I plan to make small changes. However, in my previous message I proposed 3 same-workflow improvements, and 2 small-workflow-extension improvements. I have more in mind..

http://marc.info/?l=git&m=121442660332114&w=2

Maybe it was too confusing or too long to read. Just consider the first simple example.

Currently "cvs up" in a dirty tree is a destructive operation. If you merge badly, you can't get back to your local working files before the "up". I've been burned by this in cvs/perforce enough that now when there are complicated update-conflicts I tar up the tree before trying to fix them. I still can't really get back to the pre-up state.

I can be better than cvs with the EXACT same workflow, by checking in their local changes (git checkin;) and then doing the "up" (git pull;). If they decide they botched their merge, they can get back to where they were before the UP because I'm using a richer underlying mechanism to implement their workflow.

Do you think that's not an improvement? or not the same workflow? It sure seems like a same-workflow improvement to me.

----

git's mechanisms are really great for making a hybrid central/distributed system which has the simplicity of cvs/perforce and several of the benefits of git. The git interface is just too complicated to be used for this. Fortunately, building on git means that power users will still be able to use git directly and people can distribute the repositories as much as they want.

> how much change are you willing to make them deviate from
> the CVS workflow, and how much smarts are you willing to assume that
> they have?

Good question. I'm working on a command-line wrapper for git that does it. Digging into the "plumbling" is making it more obvious why I find git's porcelain operations hard to understand. I think I can make a 2-repository setup (personal-inaccessible, origin) work like cvs/perforce with local checkins, and I can make a 3-repository setup (personal-inaccessible, personal-accessible, origin) work nearly the same as cvs while allowing distributed collaboration. I think I will need a tiny bit of custom server support (to create the personal-accessible repositories automatically).

Right now it looks like I'll be a simple hybrid of cvs/perforce, with a couple git concepts peppered in. (but just a couple) It seems simple so far, it's just taking me a while to dig through git-plumbing to understand it.

Also remember, this isn't built to handle what linux-kernel folks do with git. It's designed to provide a familiar environment for cvs/perforce style users that is just as simple but a whole lot better. Even if it eventually gets lots of git concepts, they won't HAVE to understand them to use it. They can learn them as they go. This is obviously something that people want, as cogito and easy-git show.

David Jeske· Aug 14, 2016, 00:43 UTC · re: Theodore Tso · lore

-- Theodore Tso wrote:

> If you are going to preserve the workflow of CVS, then you're
> also going to preserve all of the downsides of CVS.

I don't agree with this, and I don't see you proposing any logic that proves it to be true. Of course I plan to make small changes. However, in my previous message I proposed 3 same-workflow improvements, and 2 small-workflow-extension improvements. I have more in mind..

http://marc.info/?l=git&m=121442660332114&w=2

Maybe it was too confusing or too long to read. Just consider the first simple example.

Currently "cvs up" in a dirty tree is a destructive operation. If you merge badly, you can't get back to your local working files before the "up". I've been burned by this in cvs/perforce enough that now when there are complicated update-conflicts I tar up the tree before trying to fix them. I still can't really get back to the pre-up state.

I can be better than cvs with the EXACT same workflow, by checking in their local changes (git checkin;) and then doing the "up" (git pull;). If they decide they botched their merge, they can get back to where they were before the UP because I'm using a richer underlying mechanism to implement their workflow.

Do you think that's not an improvement? or not the same workflow? It sure seems like a same-workflow improvement to me.

----

git's mechanisms are really great for making a hybrid central/distributed system which has the simplicity of cvs/perforce and several of the benefits of git. The git interface is just too complicated to be used for this. Fortunately, building on git means that power users will still be able to use git directly and people can distribute the repositories as much as they want.

> how much change are you willing to make them deviate from
> the CVS workflow, and how much smarts are you willing to assume that
> they have?

Good question. I'm working on a command-line wrapper for git that does it. Digging into the "plumbling" is making it more obvious why I find git's porcelain operations hard to understand. I think I can make a 2-repository setup (personal-inaccessible, origin) work like cvs/perforce with local checkins, and I can make a 3-repository setup (personal-inaccessible, personal-accessible, origin) work nearly the same as cvs while allowing distributed collaboration. I think I will need a tiny bit of custom server support (to create the personal-accessible repositories automatically).

Right now it looks like I'll be a simple hybrid of cvs/perforce, with a couple git concepts peppered in. (but just a couple) It seems simple so far, it's just taking me a while to dig through git-plumbing to understand it.

Also remember, this isn't built to handle what linux-kernel folks do with git. It's designed to provide a familiar environment for cvs/perforce style users that is just as simple but a whole lot better. Even if it eventually gets lots of git concepts, they won't HAVE to understand them to use it. They can learn them as they go. This is obviously something that people want, as cogito and easy-git show.