On Sat, Feb 18, 2012 at 10:18 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sat, 18 Feb 2012, Barry Smith wrote:<br>
<br>
>   2) If the rebase implementation has been fixed from the hacky<br>
> versions that fucked unnecessarily with my file system I'll be happy<br>
> to start using rebase. Is it fixed?<br>
<br>
</div>The issue is:<br>
<br>
>><br>
When file 'a.c' is locally commited, and a pull potentially has<br>
changes to 'b.c', 'pull --rebase' also changes the timestamp on a.c<br>
[whereas 'pull; merge; commit' does not change timestamp on a.c]<br>
<<<br>
<br>
Latest hg [version 2.1] still updates the timestamp of a.c on rebase.<br>
<br>
Rebase is doing state changes [wrt commit states] - in this process I<br>
think removes local changesets and recommits them - so the locally<br>
changed files get new timestamps in this process.<br>
<br>
The fact that 'make' relies on timestamps messes things up [causing<br>
unnecessary recompiles]. Reseting timestamps on unchanged files would<br>
be a good optimziation - which is what Barry wants..</blockquote><div><br></div><div>Ah, I don't see it because the Python build uses md5. Doesn't cmake?</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Satish<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>