Hallo Ingo, Ulrich, list,
Ingo Schwarze <schwa...@usta.de> wrote:
[.]
|Some things work more or less similarly in git:
|
| * cvs co module -> git clone module
| Except that it also mirrors the whole repo including history.
Not necessarily. I usually find the advice to "clone" a repo
a bad one: now that using branches etc. is so easy and cheap it
also "gets misused" and leaves a lot of garbage laying around
which is no use for noone, but especially not normal users.
I always look into foreign repositories via "git ls-remote REPO"
first, and then selectively fetch what i need, as in
$ mkdir x; cd x
$ git ls-remote REPO
$ git init
$ git remote add origin -t GOOD-BRANCH-1 [-t GOOD-BRANCH-..] REPO
$ git fetch -v
Then when i say "git checkout GOOD-BRANCH-1" i automatically
create a local relation to the remote GOOD-BRANCH-1.
(This is not really what i do (normally), but in effect.)
| * cvs log -> git log
| But it only shows the ancestors of one given commit,
| there is no notion of "all (even later) versions of a file".
| And as opposed to CVS history, git history is not linear.
git log has an immense amount of options, including different kind
of commit ordering (like --topo-order to get some kind of
linearity, or --date-order), even following along renames
(--find-renames) etc. And all local!
| * cvs annotate -> git blame
git blame does support the -w option so that i think cleaning up
whitespace mess beyond indentation taste, e.g.,
?0[steffen@sherwood ]$ git grep -lE '[[:space:]]+$' 1.19.2|wc -l
191
can be cleaned up without banging your head against the problem
that Werner pointed out, but it is not configurable, just as for
diff (and log; and yet?).
| * cvs diff -> git diff (and git show)
| * cvs status -> git status (well, kind of)
| * cvs co tag -> git checkout ref
| * cvs up -> git pull
| Only vaguely similar and full of traps for the unwary;
| when getting confused, it may help to do git fetch
| and git merge separately and explicitly, even though
| that isn't quite simple to get right, either.
| * cvs up -C -> git reset --hard
| * cvs add file -> git add file
| * cvs rm -> git rm
| * cvs tag (no -b) -> git tag
|
|Some things are completely different:
|
| * cvs init -> not needed, no replacement
| Every git module is a stand-alone repo.
| Consequently, you don't usually do things like cvs rdiff.
| * cvs import -> not needed (what a relief!)
| It can all be comfortably done with git init / git add / git push.
| * cvs co rev file -> absolutely impossible in git
| You can only change the branch or commit of the whole repo at once.
You can always "git show REV file > ./file" in case you want that.
And leave those "changed" files laying around, "stash" them away,
whatever. You commit only the index (by default; now called
staging area i think). But, different to cvs(1), git(1) _knows_
there is something laying around which has changed, so "bundle" or
"stash" (as necessary with --all to get untracked stuff) will back
it up.
The difference is really that you can have complete control.
It has become a running joke that i say "When was it that i have
said that git is just awesome?". Just imagine *how* impossible it
was with, say, cvs(1) to rebase a change back over a history that
includes renames and file and complete directory removals? No,
you just cannot compare this at all, it is from a completely
different universe.
And then, what you describe above is in fact only the default user
interface, but the core of git(1) is a database of several types
of objects that can also be directly created and accessed! That
is packed and can be garbage-collected, etc.
..it seems i got used to some kind of addiction lately..
--steffen
