Re: GIT and CVS

[Steinar Bang <sb at dod dot no>]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> Mark explicitly said he wanted to stick to his workflow. 

Even though it isn't the best workflow with the tool?  Many small
commits _is_ the best approach with git, because it prepares for clever
merging.

Many small commits gives nice `C-x v g' results in emacs (or for that
matter nice and relevant `C-x v l' results), even after merging right
and left.

(Also, speaking as an ex-CVS user I've actually wanted to do small
commits, with relevant comments.  But I have constrained myself to use
big commits, to avoid triggering too many builds on continous
integration servers.)

> Showing him a completely different workflow, one that uses 2
> additional commands, whose semantics is non-trivial (e.g., the
> "rebase" part needs to be well understood before you can use it
> safely,

I mentioned "rebase" because that's the thing that seems to give the
most familiar behaviour to many ex-CVS users (eg. myself).  I no longer
thing rebase is a good idea, so maybe I shouldn't have...?

> is not what was requested.

Then he could just use "git pull", instead of "cvs update" (as others
have suggested), and revert to
 git stash
 git pull
 git stash pop
if the pull touches a file that has been modified locally, and then
eventually "git push"(*).

That should be more or less identical to the cvs workflow.  At least I
fail to see the difference.

(*) I saw this discussed in a different place in the thread.  I do know
    the difference between a simple "git push" and "git push origin
    HEAD", but I will only spend time to explain it if anybody expresses
    interest...:-)