Avoiding excessive compiling after a rebase

Andrei Vermel avermel at mail.ru
Fri Jun 17 06:14:17 CDT 2011

On 17-Jun-11 2:21 PM, John Jefferies wrote:
> On 17/06/2011 09:30, Andrei Vermel wrote:
>> On 15-Jun-11 2:06 PM, 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.
>>> Has anyone considered touching the non-merged files to their 
>>> original timestamps following a rebase?
>> There's an extension 'qtimes' that does just that.
>> 'qtimes -s' stores timestamps of files in a patch queue. I have it 
>> called automatically after a build command.
>> 'qtimes -r' restores the timestamps.
> Thankyou Andrei, this looks like it will do exactly what I want (and I 
> don't know how I missed it).
> Unfortunately, when I try "hg qtimes -s" I get an exception. I presume 
> there's something I'm missing and I hope the info in the exception 
> makes it obvious to you or someone. FTR. I have 7 patches applied, 
> with 19 changed files.

Sorry, I forgot to post an update. Now I did.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110617/bee9ff18/attachment.htm>

More information about the Mercurial mailing list