From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4502 invoked by alias); 14 Oct 2011 15:21:34 -0000 Received: (qmail 4490 invoked by uid 22791); 14 Oct 2011 15:21:33 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 14 Oct 2011 15:21:16 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LT200C00AH4NW00@a-mtaout21.012.net.il> for gdb@sourceware.org; Fri, 14 Oct 2011 17:21:14 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.93.74]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LT200CAKANDN120@a-mtaout21.012.net.il>; Fri, 14 Oct 2011 17:21:14 +0200 (IST) Date: Fri, 14 Oct 2011 15:21:00 -0000 From: Eli Zaretskii Subject: Re: GIT and CVS In-reply-to: To: pmuldoon@redhat.com Cc: jan.kratochvil@redhat.com, mark.kettenis@xs4all.nl, gdb@sourceware.org Reply-to: Eli Zaretskii Message-id: <83wrc7k39u.fsf@gnu.org> References: <83r52g1rly.fsf@gnu.org> <83hb3ckn2s.fsf@gnu.org> <201110141022.p9EAMrUN030848@glazunov.sibelius.xs4all.nl> <20111014125356.GA15329@host1.jankratochvil.net> <831uuflkeq.fsf@gnu.org> 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-10/txt/msg00132.txt.bz2 > From: Phil Muldoon > Cc: Jan Kratochvil , mark.kettenis@xs4all.nl, > gdb@sourceware.org > Date: Fri, 14 Oct 2011 16:05:37 +0100 > > > You mean, you can pull or merge when you have uncommitted changes? > > git pull > > or > > git fetch/git merge > > If a conflict arises you have to git stash, then do above, then git > stash pop. Or you can just commit your changes locally. The choice is > yours. With bzr, I have a better choice: resolve the conflicts, and that's it. Just like with CVS. So I think for Mark it would be much easier to adapt. Not that I fool myself that I will be able to convince the others to adopt bzr... > This is not how things are right now with CVS, but those steps are not > onerous. They might well be for someone who is a newcomer to git. The user documentation is not exactly favorable to newbies, so you are at the mercy of tutorials out there on the net, whose quality and accuracy are questionable, especially with newer git versions making them outdated quickly enough to cost you quite an amount of trial and error.