[petsc-dev] rebase question

Matthew Knepley knepley at gmail.com
Mon Sep 5 06:04:46 CDT 2011


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.

   Matt

On Mon, Sep 5, 2011 at 2:58 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Mon, Sep 5, 2011 at 07:56, Satish Balay <balay at mcs.anl.gov> wrote:
>
>> 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.
>>
>
> Suppose you have a repository like this
>
> @  changeset:   2:c4d14c7899e5
> |  tag:         tip
> |  parent:      0:c2e4f2b285da
> |  user:        Jed Brown <jed at 59A2.org>
> |  date:        Mon Sep 05 09:39:37 2011 +0200
> |  summary:     mine
> |
> | o  changeset:   1:3a3076850a53
> |/   user:        Jed Brown <jed at 59A2.org>
> |    date:        Mon Sep 05 09:38:05 2011 +0200
> |    summary:     upstream
> |
> o  changeset:   0:c2e4f2b285da
>    user:        Jed Brown <jed at 59A2.org>
>    date:        Mon Sep 05 09:37:40 2011 +0200
>    summary:     initial
>
> and suppose r2 makes a modification to a file present in r0 that was not
> changed by r1. Then we could ask for rebase to not update mtime for this
> file. This is not the case:
>
> $ stat a
>   File: `a'
>   Size: 8               Blocks: 8          IO Block: 4096   regular file
> Device: 806h/2054d      Inode: 1439054     Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/     jed)   Gid: (  100/   users)
> Access: 2011-09-05 09:43:07.743270567 +0200
> Modify: 2011-09-05 09:42:53.809936424 +0200
> Change: 2011-09-05 09:42:53.809936424 +0200
>  Birth: -
> $ hg rebase -s 2 -d 1
>
>
> saved backup bundle to /tmp/repo-hg/.hg/strip-backup/a00050fc43a7-backup.hg
> $ stat a
>   File: `a'
>   Size: 8               Blocks: 8          IO Block: 4096   regular file
> Device: 806h/2054d      Inode: 1439054     Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/     jed)   Gid: (  100/   users)
> Access: 2011-09-05 09:43:18.689937868 +0200
> Modify: 2011-09-05 09:43:18.689937868 +0200
> Change: 2011-09-05 09:43:18.689937868 +0200
>  Birth: -
>
>
> If instead we merge, mtime is not updated:
>
> $ stat a
>   File: `a'
>   Size: 8               Blocks: 8          IO Block: 4096   regular file
> Device: 806h/2054d      Inode: 1439054     Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/     jed)   Gid: (  100/   users)
> Access: 2011-09-05 09:45:52.003280085 +0200
> Modify: 2011-09-05 09:45:49.719946619 +0200
> Change: 2011-09-05 09:45:49.719946619 +0200
>  Birth: -
> $ hg merge 1
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
> (branch merge, don't forget to commit)
> $ hg commit -m merge
> $ stat a
>   File: `a'
>   Size: 8               Blocks: 8          IO Block: 4096   regular file
> Device: 806h/2054d      Inode: 1439054     Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/     jed)   Gid: (  100/   users)
> Access: 2011-09-05 09:45:52.003280085 +0200
> Modify: 2011-09-05 09:45:49.719946619 +0200
> Change: 2011-09-05 09:45:49.719946619 +0200
>  Birth: -
>
>
> Sean, I was wrong in our conversation in the parking lot. Git behaves the
> same way:
>
> $ echo aaa > a
> repo-git$ git add a
> repo-git$ git commit -m initial
> [master (root-commit) ec625c5] initial
>  1 files changed, 1 insertions(+), 0 deletions(-)
>  create mode 100644 a
> master repo-git$ echo bbb > b
> repo-git$ git add b
> repo-git$ git commit -m upstream
> [master 740d68c] upstream
>  1 files changed, 1 insertions(+), 0 deletions(-)
>  create mode 100644 b
> repo-git$ git checkout -b mine HEAD^
> Switched to a new branch 'mine'
> repo-git$ echo ccc >> a
> repo-git$ git commit -am mine
> [mine 6f4c2d9] mine
>  1 files changed, 1 insertions(+), 0 deletions(-)
> $ git log master
> commit 740d68ca145ec28b3cf936d65827a64fe6a6682f
> Author: Jed Brown <jed at 59A2.org>
> Date:   Mon Sep 5 09:47:32 2011 +0200
>
>     upstream
>
> commit ec625c5bbc19b13ded14643a9f79cd0e99829313
> Author: Jed Brown <jed at 59A2.org>
> Date:   Mon Sep 5 09:47:21 2011 +0200
>
>     initial
> repo-git$ git log
> commit 6f4c2d9d5a8a632233fc0da0139e8d4ed52c6b23
> Author: Jed Brown <jed at 59A2.org>
> Date:   Mon Sep 5 09:48:11 2011 +0200
>
>     mine
>
> commit ec625c5bbc19b13ded14643a9f79cd0e99829313
> Author: Jed Brown <jed at 59A2.org>
> Date:   Mon Sep 5 09:47:21 2011 +0200
>
>     initial
> repo-git$ stat a
>   File: `a'
>   Size: 8               Blocks: 8          IO Block: 4096   regular file
> Device: 806h/2054d      Inode: 1439111     Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/     jed)   Gid: (  100/   users)
> Access: 2011-09-05 09:52:46.199970753 +0200
> Modify: 2011-09-05 09:52:06.809968470 +0200
> Change: 2011-09-05 09:52:06.809968470 +0200
>  Birth: -
> $ git rebase master
> First, rewinding head to replay your work on top of it...
> Applying: mine
> $ stat a
>   File: `a'
>   Size: 8               Blocks: 8          IO Block: 4096   regular file
> Device: 806h/2054d      Inode: 1439111     Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/     jed)   Gid: (  100/   users)
> Access: 2011-09-05 09:53:00.499971581 +0200
> Modify: 2011-09-05 09:53:00.496638247 +0200
> Change: 2011-09-05 09:53:00.496638247 +0200
>  Birth: -
>
>
> If you do the rebasing with an Emacs mode, it should track which files are
> changed and update them accordingly.
>
> If you don't want to set global-auto-revert-mode, you can do something like
> this
>
> (global-set-key (kbd "C-x T") '(lambda () (interactive) (revert-buffer nil
> t))) ; revert without query
>
> to reduce the interruption caused by reverting files. It all depends how
> tightly you like buffers to be associated with files.
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110905/a87fc1ff/attachment.html>


More information about the petsc-dev mailing list