On Sat, Feb 18, 2012 at 10:18 PM, Satish Balay <span dir="ltr">&lt;<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>&gt;</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>
&gt;   2) If the rebase implementation has been fixed from the hacky<br>
&gt; versions that fucked unnecessarily with my file system I&#39;ll be happy<br>
&gt; to start using rebase. Is it fixed?<br>
<br>
</div>The issue is:<br>
<br>
&gt;&gt;<br>
When file &#39;a.c&#39; is locally commited, and a pull potentially has<br>
changes to &#39;b.c&#39;, &#39;pull --rebase&#39; also changes the timestamp on a.c<br>
[whereas &#39;pull; merge; commit&#39; does not change timestamp on a.c]<br>
&lt;&lt;<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 &#39;make&#39; 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&#39;t see it because the Python build uses md5. Doesn&#39;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>