On Mon, Sep 5, 2011 at 13:04, Matthew Knepley <knepley at gmail.com> wrote:
> But this is not what Barry is complaining about. I agree that it would be > nice not to jiggle files that were not > affected by the change, but he is saying that files which were affected are > annoying. As Satish points out, > this happens even with update. Therefore, I agree with Sean's suggestion > that he put the crap in his Emacs > setup. > My point was that rebase jiggles files that merge does not. I think this is also what Barry is complaining about since he knows that if the file is actually different before and after the merge/rebase, then there is no way to avoid having it be updated. (Maybe he would still like global-auto-revert-mode.) This is more than just interaction with emacs buffers, however. Suppose I add a field to petscsys.h, rebuild everything, then pull some change from upstream that does not touch headers. If I rebase, mtime will change on petscsys.h and I will have to do a complete rebuild (for every PETSC_ARCH): minutes If I merge, mtime will NOT change on petscsys.h and I can do a partial rebuild (only the files that upstream changed): seconds I prefer rebase in this context, but it annoys me that it needlessly changes mtime. Yes, it would be more complicated to implement, but I'm surprised that the C++ projects with hour-long build times aren't complaining loudly about this. http://stackoverflow.com/questions/4913360/can-i-rebase-a-git-branch-without-modifying-my-working-copy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110905/b269f762/attachment.html>