This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GIT and CVS


> From: Phil Muldoon <pmuldoon@redhat.com>
> Cc: eliz@gnu.org, gdb@sourceware.org
> Date: Fri, 14 Oct 2011 15:51:40 +0100
> 
> > $ cvs update
> > (make some changes)
> 
> git pull will fetch and merge changes.

Then why does the man page says it's "discouraged"?

       Warning: Running git pull (actually, the underlying git merge) with
       uncommitted changes is discouraged: while possible, it leaves you in a
       state that is hard to back out of in the case of a conflict.

That sounds like "don't do it".

> > $ cvs commit
> 
> git commit
> 
> then
> 
> git push

Bzr's "bzr commit" is simpler: just one command, no need to remember
to run 2 commands.

Let's face it: git usage frowns on centralized or star-shape
development patterns.  So git commands and "normal" workflows do not
lend themselves easily towards that.

> > With lots of "cvs diff" invocations in between to check my changes and
> > remind myself what I'm working on.
> 
> I think this is where GIT would benefit most.  This is something that
> GIT, imo, does far faster, and far better than CVS.

_Any_ dVCS will do much betetr here, because these operations are
entirely local, they don't need to hit the wire.

> My one brief experience with bzr while checking out emacs was
> painfully slow.

When was that, and how slow was "painfully slow"?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]