Re: GIT and CVS

[Steinar Bang <sb@dod.no>]

>>>>> Mark Kettenis <mark.kettenis@xs4all.nl>:

> I'm a git hater.  And the reason I hate GIT is because of the
> development model it enforces.  It doesn't match the way I work.  My
> workflow looks more or less as follows:

> $ cvs update
> (make some changes)

git pull
make some changes

(or better:
 git pull
 make some changes and commit them)

> ...
> (come back a couple of days later)
> $ cvs update
> (merge conflicts, make some more changes)

git stash
git pull
git stash pop
(fix merge conflicts with the stash pop, make some more changes)

(or better:
 a) git pull
    (fix merge conflicts, make more changes and commit them)
 b) git pull --rebase
    (fix merge conflicts, make more changes and commit them)

> ...
> $ cvs update
> (test changes, write changelog, send diff for review)

git stash
git pull
git stash pop
(test changes, write changelog, send diff for review)

(or better:
 a) git pull
    (test changes, write changelog, send diff for review)
 b) git pull --rebase
    (test changes, write changelog, send diff for review)

> ...
> $ cvs update
> (test changes again, fixup changelog)

git stash
git pull
git stash pop
(test changes again, fixup changelog, commit)

(or better:
 a) git pull
    (test changes again, fixup changelog, commit)
 b) git pull --rebase
    (test changes again, fixup changelog, commit)

> $ cvs commit

git push.

Note to the following: using "git stash" lets you avoid having commits
for your changes, but
 1. that gives more commands for updates
 2. having fine grained commits helps the git merge magic

So the git way is to have fine grained commits.  That works for me,
because that's the way I used to prefer to stage my CVS checkins.  And
when working with continous integration server, that was always a pain.

With git I can have that, and it's the "git push" that triggers the
build.

And if you use commits there are two ways you can "update":
 1. git pull
 2. git pull --rebase

"git pull" will merge your current changes with the upstream changes,
and they will become intermingled in the history.

"git pull --rebase" will update the workspace, and then re-apply all of
your commits to the rebase (giving them a new date).

I started out using git, doing "git pull --rebase" since this seemed
most familiar to me (I was used to CVS and then SVN).  But today I use a
different pattern: I use shortlived local feature branches, and make my
commits on them, and after they are merged into the tracking branch and
pushed, I can delete the feature branches.