<div class="gmail_quote">On Mon, Sep 5, 2011 at 13:04, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>But this is not what Barry is complaining about. I agree that it would be nice not to jiggle files that were not<div>affected by the change, but he is saying that files which were affected are annoying. As Satish points out,</div>


<div>this happens even with update. Therefore, I agree with Sean's suggestion that he put the crap in his Emacs</div><div>setup.</div></div></blockquote></div><br><div>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.)</div>
<div><br></div><div><br></div><div>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.</div>
<div><br></div><div>If I rebase, mtime will change on petscsys.h and I will have to do a complete rebuild (for every PETSC_ARCH): minutes</div><div><br></div><div>If I merge, mtime will NOT change on petscsys.h and I can do a partial rebuild (only the files that upstream changed): seconds</div>
<div><br></div><div>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.</div>
<div><br></div><div><a href="http://stackoverflow.com/questions/4913360/can-i-rebase-a-git-branch-without-modifying-my-working-copy">http://stackoverflow.com/questions/4913360/can-i-rebase-a-git-branch-without-modifying-my-working-copy</a></div>