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
