| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Mark Mielke <mark(at)mark(dot)mielke(dot)cc>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Managing multiple branches in git |
| Date: | 2009-06-03 00:01:32 |
| Message-ID: | 21761.1243987292@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 06/03/2009 01:39 AM, Tom Lane wrote:
>> But rebuilding the Linux kernel is hardly a zero-cost operation,
>> so how have Linus and co failed to notice this problem? There
>> must be some trick they're using that I haven't heard about, or
>> they'd not be nearly so pleased with git.
> Building out of tree and ccache are frequently mentioned.
Yeah, I thought about building out of tree, with a different build tree
for each branch and VPATH pointing at the common source tree (working
copy). That would probably work if it weren't that switching to branch
B and then back to branch A has to advance the filesystem timestamps on
every file that's different between the two branches. So it would
defeat whatever intelligence "make" might have. Even if ccache is not
fooled, that's only a very partial solution.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2009-06-03 00:24:21 | Re: Managing multiple branches in git |
| Previous Message | Alvaro Herrera | 2009-06-03 00:00:09 | Re: Managing multiple branches in git |