Re: [Groff] Overview, Sept. 2014

[Ulrich Lauther]

On Wed, Sep 10, 2014 at 05:29:13PM +0200, Ingo Schwarze wrote:
> 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

Thanks a lot!
        
        ulrich