* Tom Lane:
> I wondered for a second about symlinking .git from several checkout
> directories to a common master, but AFAICT .git stores both the
> "repository" and status information about the current checkout, so
> that's not gonna work.
"git clone --reference" stores just a reference and does not copy the
history.
It's not going to help in the long run because history accumulating on
the HEAD will be duplicated in your release branches. This is not a
problem if you never merge stuff into them, but I don't know how much
(recent) history browsing you want to do from your release checkouts.
> At the same time, I don't really buy the theory that relating commits on
> different branches via merges will work. In my experience it is very
> seldom the case that a patch applies to each back branch with no manual
> effort whatever, which is what I gather the merge functionality could
> help with. So maybe there's not much help to be had on this ...
Correct. Merging doesn't work if you pick individual patches. This
is a difficult problem, and few VCS seem to have tackled it.
Working with a single tree and ccache would be another alternative
(ccache still runs the preprocessor and hashes its output, so it
doesn't care about file modification times).
--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99