[petsc-dev] rebase question

[Barry Smith]

On Sep 5, 2011, at 6:19 AM, Jed Brown wrote:

> 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

   Of course.

   Come on, it is total bullshit (as Jed notes) that these systems change the mtime of files they don't need to touch. That is moronic, I don't care how much "easier" it makes their life in writing hg and git.

   All of you "rebase is great folks" with your excuses of "Barry should just change his emacs settings" is a work around for a stupid "feature" of rebase.

    Barry



> 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