[petsc-dev] rebase question

[Satish Balay]

On Sun, 4 Sep 2011, Sean Farley wrote:

> >
> > It bugs the heck out of me that hg "edits" files that I have committed and
> > then did a hg rebase with, so that next time I try to edit in my Emacs
> > buffer it asks me if I "really want to edit the buffer". Of course it wants
> > me to type yes or no but I'm busy typing away and this destroys my train of
> > thought.
> >
> 
> Isn't there an Emacs setting to automatically answer 'yes' or 'no'? After
> googling:
> 
> (global-auto-revert-mode t)
> 
> 
> > What's up with this behavior and is there some way to prevent it; it makes
> > rebase too painful to consider.

Just want to point out that the same thing should happen with 'hg
update' - or with the alternative workflow to 'hg pull --rebase' i.e
'hg pull; hg merge; hg commit'

i.e in all the above cases - the working files get updated by
mercurial underneath emacs.

> Ok, one, "too painful to consider?" Really? Come on now, just have Emacs
> auto-load from disk. If a file gets loaded from disk that you didn't want
> reloaded, then you should still have the previous version in an 'undo'
> buffer. Two, I've talked with Jed about this, and it occurs because of the
> way that mercurial does rebasing on the working directory instead of just on
> the metadata. The "right" way to fix this would be to submit a patch to the
> mercurial guys that does a rebase on the metadata (and not the working
> directory). 

With rebase one would want working files to be updated - so that any
changes/commits after rebase are wrt this new changeset [othwesise
newer commits would never be on tip].

Also after rebase - the current parent changeset nolonger exists 'as
the rev-graph is modified by rebase in such a way to delete the
current parent] - so if working files are not updated - they will
correspond to an unknown state [wrt whatever alternate parent hg could
potentially choose for you] - and any commits after this would have
this bad state [with new changes registered]. So I don't think 'rebase
should update metadata and not working files' is feasiable.

So this is primarily an emacs issue. And I would not expect hg to tell
emacs when to reload buffers - or which ones it should reload [as both
are separate applications - and one can't dictate what other does]. On
the other hand - if mercurial.el is somehow used to do the rebase with
the m-x vc-pull-rebase or eqivalent emacs binding - then it could
dictate what emacs could potentially do with the buffers touched by
that operation..

Satish

> Perhaps after Jed gets back from Zurich, we could force him to
> write it. I'll have to hide his climbing gear as ransom, though.
> 
> Sean
>