From: "David Jeske" <jeske@willowmail.com>
To: Theodore Tso <tytso@mit.edu>
Cc: "Junio C Hamano" <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: policy and mechanism for less-connected clients
Date: Thu, 26 Jun 2008 06:08:55 -0000 [thread overview]
Message-ID: <willow-jeske-01l6jzyMFEDjCXvz> (raw)
In-Reply-To: <20080626052310.GC8610@mit.edu>
-- 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.
next prev parent reply other threads:[~2008-06-26 6:17 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <willow-jeske-01l6@3PlFEDjCVAh-01l6it3ZFEDjCd5X>
2008-06-26 5:23 ` policy and mechanism for less-connected clients Theodore Tso
2008-06-26 5:26 ` Junio C Hamano
2008-06-26 6:08 ` David Jeske
2008-06-26 6:08 ` David Jeske [this message]
[not found] <willow-jeske-01l6@3PlFEDjCVAh-01l6rSE7FEDjCYv6>
2008-06-26 11:37 ` Theodore Tso
2008-06-26 16:21 ` David Jeske
2008-06-26 16:21 ` David Jeske
2008-06-25 14:03 Petr Baudis
[not found] <willow-jeske-01l6@3PlFEDjCVAh-01l6OB5yFEDjCYe3>
2008-06-25 13:34 ` Theodore Tso
2008-06-25 17:34 ` Junio C Hamano
2008-06-25 19:37 ` David Jeske
2008-06-25 20:52 ` Jakub Narebski
2008-06-25 20:54 ` Jakub Narebski
2008-06-25 19:37 ` David Jeske
2008-06-25 21:34 ` David Jeske
2008-06-25 22:10 ` Jakub Narebski
2008-06-25 22:13 ` Junio C Hamano
2008-06-25 23:03 ` David Jeske
2008-06-25 23:03 ` David Jeske
2008-06-25 21:34 ` David Jeske
[not found] <willow-jeske-01l6@3PlFEDjCVAh-01l6@3N@FEDjCXZO>
2008-06-25 2:33 ` Theodore Tso
2008-06-25 5:20 ` David Jeske
2008-06-25 19:17 ` Daniel Barkalow
2008-06-25 20:12 ` Raimund Bauer
2008-06-25 5:20 ` David Jeske
2008-06-25 9:30 ` Jakub Narebski
-- strict thread matches above, loose matches on Subject: below --
2008-06-25 0:36 David Jeske
2008-06-25 0:36 David Jeske
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=willow-jeske-01l6jzyMFEDjCXvz \
--to=jeske@willowmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox