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 16:21:20 -0000 [thread overview]
Message-ID: <willow-jeske-01l6zg4eFEDjCdFw> (raw)
In-Reply-To: <20080626113710.GD8610@mit.edu>
Thanks for pointing out the issue with automatically committing and bisect.
You're right, if I'm going to automatically commit under the covers I should
use stash instead. However, I don't want users to keep a dirty tree, and now
they don't have to.
To use your two-months-without-checkins example.. one of the big problems I
have with cvs/p4 is this notion that I'm not supposed to record my work every
5-50 minutes. I checkin every time my code does something new and the tests
pass. In my own startup projects/companies this is fine, because it's my tree.
As soon as the group policy stops me from checking in every 5-50 minutes, I
painfully make my own branch so I can checkin on my schedule. I'm starting to
witness some users solving this problem in a very libertarian way, by using git
to manage their local changes even though they work in a code-review restricted
cvs/p4 environment.
-- Theodore Tso wrote:
> I'd suggest that you try using git straight for a bit longer, before
> you start drawing these conclusions. Trust me, the concepts of git
> really aren't that hard to explain to people; that's not what you need
> to hide from people coming from the CVS world. The hard part is the
> fact that git's UI has all sorts of non-linearities and that git's
> documentation and introductory tutorials are not as good as it should
> be. (Although it's gotten a LOT better than just a year or two ago.)
I agree 100%. I am using git straight. I think I have read more git
documentation and definitely read more git source-code in trying to use it over
a couple months, than I have read of cvs/p4 in decades - just to try to
understand which of the 3 ways to get from here-to-there is correct, and then
when I pull back the red curtain a little further I realize I was totally
wrong.
This started as a "cheat sheet" file with the combination of git commands I had
to execute to perform each task. However, they are only valid in the context of
a git-repo that's configured in certain ways. I realized it would be simpler
(even for just me) if I had something that grouped commands and did 'lint'
sanity checks, with helpful tutorial responses. Thus the wrapper.
> Exactly. So what I would ask you to consider is that you may find it
> personally useful to design this system,
I see where you're going with this, and I agree...
> but afterwards, before you inflict it on projects, and deal
> with some of the attendent side effects (like all of these trash
> commits causing "git bisect" to go down the drain), that you
> consider whether *now* that you understand how git works and
> why it does some of the things it does, and what the
> shortcomings of the git porcelain are from a UI perspective, whether
> CVS refugees really would be best served by this system you are
> designing, or whether a few wrapper scripts to hide some of the more
> pointy spikes in git's CLI, plus some better tutorials, might in the
> long run be much better for these CVS developers that you are trying
> to serve.
Absolutly. I hope that you can understand my goal of an 'interactive command
line/tutorial linear path from cvs/p4 to git'. One where they don't get stuck
and turn back, but also where they work in ways which are 'fairly reasonable'
in the git community. I also hope you'll help me evaluate whether I've succeed
or just made another confusing set of compromises that are no good. There is no
need for more of the latter.
I also have a group that's been using git and wants to switch back to cvs/p4.
They are willing to give up tracking their local changes (or do it with private
gits) in order to get a simpler model for 'shared head of tree' development. I
think they are a good test-case as well.
------
So far, 1/2 of the lines of my script merely transitional documentation from
p4/cvs to git. As I write more of this prose, I realize that it may be helpful
as transition documentation webpages. However, it is much more than passive
documentation, because if there are 3 steps from here to there, I can look at
the repository and see where the user is, and tell them what they need to do
next.
As one example, I have a command "pending" (like p4 pending) which shows local
changes in my branch (on my inaccessible firewalled machine) which are not on
my origin repo(s). Except that in order for this concept to even make sense, it
first:
- checks if I have an 'origin' for a public repo
- checks that my current branch is tracking an [some]origin
- if it is mapped to a 'myorigin' personal published repo
(because I'm firewalled), it checks that the name of the
branch matches the myorigin/branchname (because it's easier
to think straight if myorigin is a literal copy of my local
repo)
- shows what changes I have which are not submitted to myorigin
and/or origin
If at any step along that path something doesn't check out, it explains what
didn't check out, and has a helpful help-page about ways that I might configure
it so 'pending' can do something useful. Think of it like "git lint" and some
documentation.
That said, it's trickier than I thought, because git is capable of working in
so many ways. (all that complexity isn't there for nothing) Time will tell if I
can strike a useful balance.
next prev parent reply other threads:[~2008-06-26 17:43 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <willow-jeske-01l6@3PlFEDjCVAh-01l6rSE7FEDjCYv6>
2008-06-26 11:37 ` policy and mechanism for less-connected clients Theodore Tso
2008-06-26 16:21 ` David Jeske
2008-06-26 16:21 ` David Jeske [this message]
[not found] <willow-jeske-01l6@3PlFEDjCVAh-01l6it3ZFEDjCd5X>
2008-06-26 5:23 ` Theodore Tso
2008-06-26 5:26 ` Junio C Hamano
2008-06-26 6:08 ` David Jeske
2008-06-26 6:08 ` 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 21:34 ` 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 19:37 ` David Jeske
2008-06-25 20:52 ` Jakub Narebski
2008-06-25 20:54 ` Jakub Narebski
[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 9:30 ` Jakub Narebski
2008-06-25 5:20 ` David Jeske
2008-06-25 19:17 ` Daniel Barkalow
2008-06-25 20:12 ` Raimund Bauer
-- 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-01l6zg4eFEDjCdFw \
--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