From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12935 invoked by alias); 11 Nov 2011 21:00:24 -0000 Received: (qmail 12925 invoked by uid 22791); 11 Nov 2011 21:00:23 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Nov 2011 21:00:07 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1ROyCj-0001jK-S8 for gdb@sources.redhat.com; Fri, 11 Nov 2011 22:00:05 +0100 Received: from cm-84.208.231.161.getinternet.no ([84.208.231.161]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Nov 2011 22:00:05 +0100 Received: from sb by cm-84.208.231.161.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Nov 2011 22:00:05 +0100 Mail-Followup-To: gdb@sources.redhat.com To: gdb@sources.redhat.com From: Steinar Bang Subject: Re: GIT and CVS Date: Fri, 11 Nov 2011 21:00:00 -0000 Message-ID: <87bosi5qts.fsf@dod.no> References: <83r52g1rly.fsf@gnu.org> <83hb3ckn2s.fsf@gnu.org> <201110141022.p9EAMrUN030848@glazunov.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain Mail-Copies-To: never User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.1 (gnu/linux) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00083.txt.bz2 >>>>> Mark Kettenis : > 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.