Re: The essential problems of moving from CVS

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Jan 16, 2010 at 01:32:10AM +0000, Thomas Adam wrote:
 > > And another somewhat more tangentially related problem (that topgit
 > > might also fix) is that you can't really keep local patches, like the
 > > gross hack I need for the tulip ethernet in my test machine, in the
 > > same tree that you use for development and commit.
 > 
 > Depends on your workflow.  topgit might help, but I would just make use of
 > branches to solve this to be honest.  If you have a specific workflow
 > example, mention it and I will try and give you a potential solution using
 > Git.

The purpose of topgit is to manage such branches. Anyway, that *is*
the example, but perhaps I should be clearer.

The machine I currently use for kernel testing has a tulip ethernet
card. This particular tulip requires a hack to work. The hack is a not
entirely trivial patch to one file in src/sys/dev/ic, which is (both
physically and conceptually) a long way away from the things I
normally hack on in the kernel, so there's little or no chance of
conflict with anything I'm working on. However, in order to be able to
test anything I need that patch in place when I compile the kernel.

With CVS, one can just leave the patch in place as an uncommitted
change and it never conflicts with anything; nor does it end up
getting committed to the master repository by accident unless one does
something stupid.

With git, AIUI, one can't leave uncommitted changes around because it
interferes with merging. The alternative appears to be to commit it as
a local change on its own branch and then never push that branch;
however, that requires developing on a different branch and merging to
the hack branch for every test run, which is a major nuisance. Or I
guess one could conceivably develop on top of it and then rebase away
before committing, but that seems risky.

Do you have a better alternative?

-- 
David A. Holland
dholland%netbsd.org@localhost