On Sat, Feb 18, 2012 at 10:18 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> On Sat, 18 Feb 2012, Barry Smith wrote: > > > 2) If the rebase implementation has been fixed from the hacky > > versions that fucked unnecessarily with my file system I'll be happy > > to start using rebase. Is it fixed? > > The issue is: > > >> > When file 'a.c' is locally commited, and a pull potentially has > changes to 'b.c', 'pull --rebase' also changes the timestamp on a.c > [whereas 'pull; merge; commit' does not change timestamp on a.c] > << > > Latest hg [version 2.1] still updates the timestamp of a.c on rebase. > > Rebase is doing state changes [wrt commit states] - in this process I > think removes local changesets and recommits them - so the locally > changed files get new timestamps in this process. > > The fact that 'make' relies on timestamps messes things up [causing > unnecessary recompiles]. Reseting timestamps on unchanged files would > be a good optimziation - which is what Barry wants.. Ah, I don't see it because the Python build uses md5. Doesn't cmake? Matt > > Satish > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120218/ea6c601e/attachment.html>
