This is the mail archive of the 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: time to be serious about dropping CVS

On Fri, 2010-01-01 at 11:25 +0100, Mark Kettenis wrote:
> There's no equivalent of a quick "cvs update" of a checked out
> tree that contains modifications. 

That's a bad habit from CVS/SVN usage which you should train yourself
out of. It's the cause of many a "my half-tested changes don't work at
all after the cvs update, how the hell do I figure out what went wrong"
trap I've fallen into before switching to git. No longer: a script which
runs a git_bisect/apply_my_change/test/repeat-until-culprit-is-found
is so cheap that I write it from scratch every time I need it.

This, by the way, is just one command where git _really_ shines.
Consider: You just updated from GCC 4.3 to 4.4. One of your tests shows
a regression. You want to figure out which of the 4527 patches and/or
293 merges which went into 4.4 caused it, so as to fix the regression
and/or render a qualified bug report and/or figure out how to circumvent
the problem. With "git bisect", this requires less than 15 compile/test
cycles (ceil(log2(4527+293))) and can be fully automated. 

(Yes, the numbers of patches and merges are made up.)

> And I can't get myself to commit half-finished or half-tested changes
> to a local repo.

Somebody else already mentioned "git stash". Writing a small script
which does a stash/merge/stash_pop, or a commit/merge/rebase, is
trivial. Problem solved.

SVN is _not_ acceptable for anybody who ever tried to do nontrivial work
when disconnected, e.g. on an airplane. Among other problems.

Please select a distributed VCS. SVN is not.

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