Re: [Groff] Overview, Sept. 2014

[Steffen Nurpmeso]

Hallo Ingo, Ulrich, list,

Ingo Schwarze <address@hidden> 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.,

  address@hidden ]$ 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