Re: [Groff] Overview, Sept. 2014

[Ingo Schwarze]

Hi Ulrich,

Ulrich Lauther wrote on Wed, Sep 10, 2014 at 01:01:37PM +0200:
> On Wed, Sep 10, 2014 at 12:16:06PM +0200, Werner LEMBERG wrote:

>>  Additionally, `git blame' would become much more inconvenient to use.

> I am not familiar with git and git blame, used cvs in my active time.
> Could you explain, what the problem with upper case class names
> and git blame would be?

You got that wrong.  ;-)

Git blame is almost exactly the same as cvs annotate,
which should answer your question.

Actually, familiarity with CVS can greatly help you to quickly get
going with some features of git - and it can also mislead you to
get confused about some other aspects of git.  I tried that half a
decade ago...

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.
 * 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.
 * cvs annotate    ->   git blame
 * 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.
                        git checkout ref file
   Is more similar to   cvs up -j,   but you normally don't do that,
   you rather use   git merge   or   git cherry-pick   or   git revert,
   all of which commit right away (without pushing)
 * cvs add dir     ->   not needed, no replacement
                        git add directory
   Does something completely different, never do that coming from CVS.
 * cvs commit      ->   completely different concept
   The whole   git add / git commit / git push   three-step concept
   feels EXTREMELY confusing and contorted when coming from CVS.
   This is a point you really want to spend time on to thoroughly
   understand the git mindset.
 * cvs tag -b      ->   git branch   and   git checkout -b
   These may seem superficially similar, but the whole concept of
   branches is completely different.  The concept of git is both
   simpler and more powerful, which i consider git's main asset.
   This is another aspect you really want to spend time on
   to thorougly understand.
   In CVS, you typically use tag -b very rarely.
   In git, you use checkout -b (and reset) all the time.
   Somewhere in the middle of this, you need to understand the
   difference between   git checkout   and   git reset
   even though the latter has no CVS analogue short of
   cvs tag -bF   which you almost never do in CVS
   but which is a common operation when working with git.
   As a last step in this area, you must learn about
   git rebase   even though there is no equivalent in CVS and
   even though you need to be very careful with it after push.
 * cvs admin -m    ->   absolutely impossible in git by design
   No replacement that keeps other people's checkouts working.
 * cvs admin -o    ->   absolutely impossible in git by design
 *                      git stash
   Doesn't exist in CVS, but you will definitely find use for it.

Most definitely, you want to read gitrevisions(7).  That will teach
you about the complexity of git (some might cry "overengineering"),
but you won't find your way around any git repo without understanding
at least some bits of that.

Ulrich, I hope the above table helps you to find your way around
the git manuals - which tend to be somewhat wordy and long-winded,
hardly avoidable given the overabundance of features coming with
git.

Yours,
  Ingo