Avoiding excessive compiling after a rebase

Matt Mackall mpm at selenic.com
Wed Jun 15 16:15:18 CDT 2011

On Wed, 2011-06-15 at 11:06 +0100, John Jefferies wrote:
> I like using the rebase feature. In particular, I'm rebasing applied MQ 
> patches after pulling from the central repo.
> This workflow does suffer one flaw (from my PoV) in that in my usage, 
> the rebased files are all rewritten to disk. This has the conseqence of 
> needing to rebuild these files, even though much of the time the rebased 
> files haven't been merged during the rebase. My rebuild time can be 
> significant, 10 minutes or more if a rebased header has many 
> dependencies. And multiple configurations will require more again.

That's quite ugly, architecturally. "Restoring" timestamps is a
tricky/sneaky business, and... it's actually basically impossible to do
right in Python on systems with nanosecond timestamps (Python floats
don't have the requisite resolution!).

I'd consider something like this at the level of individual file merges
(ie avoiding touching a file altogether if a merge ended up being a
no-op). But for rebase, we're actually doing a chain of operations that
involve checking out other revisions. Short of mirror-imaging the rebase
process so that the rebased csets were 'local' (and thus flipping the
named branch logic, ouch), there's no clean way to do this.

If you can, I'd recommend using something like ccache:


Mathematics is the supreme nostalgia of our time.

More information about the Mercurial mailing list