Re: The essential problems of moving from CVS

[Thomas Adam <thomas.adam22%gmail.com@localhost>]

On Sat, Jan 16, 2010 at 08:16:30PM +0000, David Holland wrote:
> With git, AIUI, one can't leave uncommitted changes around because it
> interferes with merging. The alternative appears to be to commit it as

Yes -- it *might* interfere with merging if you git a git pull and the
resultant commits from that touched on this file.

> 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?

No, and in fact, the proper solutions to your question are ones you're
dismissing.  To be honest, what I would do if I were you, is make use of
"git stash".  So for example:

% git checkout master
% patch -p0 < this-patch-you-use-for-tulip
% git stash save tulip-changes
[ hack, hack, hack... woo, testing time. ]
% git add/commit
% git stash apply
[compile]
[Fix a mistake...]:

# Might as well use reset --hard here
% git reset --hard
[fix mistake]
% git add/compile
% git stash apply

... and so it goes on.

Is that any more of a nusiance than having those tulip changes on a separate
branch?  No, but the reason why you wouldn't want them to be is because of
the history you're forming on your test branch, each time you're merging in
the tulip changes for testing.  At least this way, using "git stash", those
things aren't polluting the actual work you're doing.

-- Thomas Adam

-- 
"It was the cruelest game I've ever played and it's played inside my head."
-- "Hush The Warmth", Gorky's Zygotic Mynci.