Re: "git merge" merges too much!

From: Greg A. Woods <woods@planix.com>
Date: Dec 1, 2009, 00:24 UTC
Message-ID: <m1NFGXS-000kn2C@most.weird.com>
In-Reply-To: <20091130211744.GA27278@dpotapov.dyndns.org>

At Tue, 1 Dec 2009 00:17:44 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
Subject: Re: "git merge" merges too much!

Show 6 quoted lines

> 
> It depends on the project and what tools are used, but using ccache and
> proper dependencies help a lot to reduce the cost of switching. In fact,
> it may be faster to switch to another branch and have to recompile a few
> files than to go into another working directory, because when you go to
> another working directory, you hit cold cache and things get very slow.

perhaps, sometimes, but at least with some tools that can more often than not just end up with a confusing mess if you happen to change something at exactly the wrong time, and with Git it seems almost too easy to wildly change many files in the working directory, even if you can get them back into their previous state relatively quickly

Things get even weirder if you happen to be playing with older branches too -- most build tools don't have ability to follow files that go back in time as they assume any product files newer than the sources are already up-to-date, no matter how much older the sources might become on a second build.

From a good software hygiene perspective the only safe way I can see to build a Git working directory after manipulating any branches with Git is to do a complete "make clean && make" cycle. That is until Git also incorporates, or integrates with, really good build tools.... :-)

Show 6 quoted lines

> And then if a project is huge and takes a lot of time to compile and
> test everything, I do not think, it is a good idea to build that in your
> work tree. Instead, you make a shanshot using git-archive and then run
> full build and test on it. In this way, you know that you test exactly
> what you have committed (you can amend any commit later until you
> publish it).

 
I think this "git-new-workdir" script is the thing to try.  It probably
means keeping separate "configuration" branches, one for each build
working directory, but I think that's OK.

These source trees are big enough that one doesn't just go throwing around entire copies of them willy-nilly. Disk bandwidth is also a limited resource we are very concerned about, not just disk space.

-- 
						Greg A. Woods
						Planix, Inc.

<woods@planix.com>       +1 416 218 0099        http://www.planix.com/