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