[petsc-dev] rebase question

[Jed Brown]

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>