[Python-Dev] Hg tips

[Victor Stinner]

Le 29/09/2011 09:54, Ezio Melotti a écrit :
> Tip 1 -- merging heads:
>
> A while ago Éric suggested a nice tip to make merges easier and since I
> haven't seen many people using it and now I got a chance to use it again, I
> think it might be worth showing it once more:
>
> # so assume you just committed some changes:
> $ hg ci Doc/whatsnew/3.3.rst -m 'Update and reorganize the whatsnew entry
> for PEP 393.'
> # you push them, but someone else pushed something in the meanwhile, so the
> push fails
> $ hg push
> pushing to ssh://hg@hg.python.org/cpython
> searching for changes
> abort: push creates new remote heads on branch 'default'!
> (you should pull and merge or use push -f to force)
> # so you pull the other changes
> $ hg pull -u
> pulling from ssh://hg@hg.python.org/cpython
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 4 changesets with 5 changes to 5 files (+1 heads)
> not updating, since new heads added
> (run 'hg heads' to see heads, 'hg merge' to merge)
> # and use "hg heads ." to see the two heads (yours and the one you pulled)
> in the current branch
> $ hg heads .
> changeset:   72521:e6a2b54c1d16
> tag:         tip
> user:        Victor Stinner<victor.stinner at haypocalc.com>
> date:        Thu Sep 29 04:02:13 2011 +0200
> summary:     Fix hex_digit_to_int() prototype: expect Py_UCS4, not
> Py_UNICODE
>
> changeset:   72517:ba6ee5cc9ed6
> user:        Ezio Melotti<ezio.melotti at gmail.com>
> date:        Thu Sep 29 08:34:36 2011 +0300
> summary:     Update and reorganize the whatsnew entry for PEP 393.
> # here comes the tip: before merging you switch to the other head (i.e. the
> one pushed by Victor),
> # if you don't switch, you'll be merging Victor changeset and in case of
> conflicts you will have to review
> # and modify his code (e.g. put a Misc/NEWS entry in the right section or
> something more complicated)
> $ hg up e6a2b54c1d16
> 6 files updated, 0 files merged, 0 files removed, 0 files unresolved
> # after the switch you will merge the changeset you just committed, so in
> case of conflicts
> # reviewing and merging is much easier because you know the changes already
> $ hg merge
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
> (branch merge, don't forget to commit)
> # here everything went fine and there were no conflicts, and in the diff I
> can see my last changeset
> $ hg di
> diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst
> [...]
> # everything looks fine, so I can commit the merge and push
> $ hg ci -m 'Merge heads.'
> $ hg push
> pushing to ssh://hg@hg.python.org/cpython
> searching for changes
> remote: adding
> changesets
>
> remote: adding manifests
> remote: adding file changes
> remote: added 2 changesets with 1 changes to 1 files
> remote: buildbot: 2 changes sent successfully
> remote: notified python-checkins at python.org of incoming changeset
> ba6ee5cc9ed6
> remote: notified python-checkins at python.org of incoming changeset
> e7672fe3cd35
>
> This tip is not only useful while merging, but it's also useful for
> python-checkins reviews, because the "merge" mail has the same diff  of the
> previous mail rather than having 15 unrelated changesets from the last week
> because the committer didn't pull in a while.

I prefer "hg pull --rebase && hg push": it's just one command (ok, two), 
there is nothing to do (it's fast)... if the new changes are not in 
conflict with my local changes, and it keeps a nice linear history.

hg rebase is more dangerous: you may lose work if you misuse it.

hg rebase is maybe more complex when you have a conflict (I don't really 
know, I never use hg merge).

hg rebase doesn't work at all if you have local changes in different 
branches. If hg push fails, I prefer to *remove* my changes using hg 
strip (!), update and redo the commits on the new tip. I should 
sometimes fix hg rebase instead :-)

> Tip 2 -- extended diffs:
>
> If you haven't already, enable git diffs, adding to your ~/.hgrc the
> following two lines:
>
>> [diff]
>> git = True
>>
> (this is already in the devguide, even if 'git = on' is used there. The
> mercurial website uses git = True too.)
> More info:  http://hgtip.com/tips/beginner/2009-10-22-always-use-git-diffs/

For diff, "showfunc = on" is also a cool feature. See my full ~/.hgrc:

https://bitbucket.org/haypo/misc/src/tip/conf/hgrc

  * I disabled the merge GUI: I lose a lot of work because I'm unable to 
use a GUI to do merge, I don't understand what are the 3 versions of the 
same file (which one is the merged version!?)
  * pager extension is just a must have
  * hgeditor is also a must have to write the changelog: in vim, it 
opens a second buffer with the diff

I also use "hg record" (like "git add -i") to do partial commit: after 
hacking during 3 hours, I do atomic commits. Then I use hg histedit 
(like "git rebase -i") to merge and reorganize local commits. It's 
useful to hide "oops, typo in my last commit".

> If you find operations like pulling, updating or cloning too slow, you might
> also want to look at the 'progress' extension, which displays a progress bar
> during these operations:
>
>> [extensions]
>> progress =

Yeah, I like it too :-)

Victor