On Thu, Jun 26, 2008 at 06:08:55AM -0000, David Jeske wrote:
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.
This is a really good example of the problems involved. One of the
major problems with CVS is that CVS developers have a tendency to use
"cvs up" *way* too often --- i.e., with a dirty tree. Why do they
have a dirty tree? Well, generally because they commit too rarely;
since CVS branches are so awful to use, they generally don't use CVS
branches, and so if they are in the middle of making major changes the
source base, they may not do a CVS checkin for weeks or months, since
they don't want to break the centrally visible branch until their
project actuall is at a stage where it can be checked into the tree
without breaking core functionality.
(I once supervised a programmer who didn't do a CVS checkin for two
months, and then lost two months of work when his local disk died, and
as a result he had a nervous breakdown; you just can't make up some of
the massive, major problems that can result from CVS-inspired
workflows.)
So if you are going to accomodate the broken workflow where people
leave dirty state in their local tree for vast amounts of time, and
thus insist on running "cvs up" all the time, and will try to cover
for it by committing their work under their noses when they do the
equivalent of "cvs up" in a dirty worktree --- what does that mean?
Well, maybe you can make it work, but it breaks other nice features of
git. For example, it means that "git bisect" can't possibly work,
since there will be huge number of commits where the tree may not even
build!
Accomodating the CVS workflow is basically about the fact that users
don't want to learn about CVS branches, because they were horrible to
use, and even worse to merge. But that's not true with git branches;
so maybe it's better to teach them how to use git branches instead,
instead of trying to coddle them into letting them use the the same
old broken CVS workflow that was based on branch-avoidance?
I've created and taught a Usenix tutorial which covers the basics of
distributed source code management systems, including branches,
repositories, pushing and pulling between them, for git, hg, AND bzr,
and I did it in half a day. The concepts really aren't hard. The
main problem with git is that because the UI grew organically, there
are all sorts of exceptions and non-linearities in its CLI.
For example, the fact that "git checkout" can be used both to switch
between branches, and revert and editing file. Or the fact that how
you specify a set of revisions in git-format-patch is different in
terms of what happens when you specify a single commit; it's
documented in the man page now, at least, and people who teach git
after a while learn about the things that you have to teach newbies
that git experts take for granted. (Just as people who teach English
as a second language learn about all of the exceptions to the language
that you have to point out that are second nature to the natives.)
But really, git *isn't* that hard, once you get past the somewhat
awkard CLI. (It's no worse, and probably much better, than the Unix
shell/test/awk/sed/head/tail/sort/uniq/comm, etc. You just have to
get over the learning curve.)
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.
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.)
Also, if your program when used by CVS refugees to causes the git
repository to be peppered with trash commits which don't build, even
if power users are using git directly, their ability to browse the
repository using "git log" or "gitk", or to try to find problems using
"git bisect", will be horribly, negatively affected. So I am a bit
worried that the result will end up destroying value for the project
in the long-term, and that the costs will not be matched by the
benefits of simply teaching the CVS refugees a few bits of git and
DSCM core concepts, which I've found is *not* the hard parts of
getting newbies to use git.
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.
Exactly. So what I would ask you to consider is that you may find it
personally useful to design this system, 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.
- Ted
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.
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.