Stephen J. Turnbull wrote:
The problem I'm worried about now is not the merge, it's the
commit
that creates a new head, which requires a merge or you can't push.
That commit only has one parent. In my repo, if I do
$ xemacs somefile
$ hg commit
$ hg push # fails because not up-to-date
$ hg pull
$ hg merge
$ hg push
That's exactly why I recommend in Patcher's doc to avoid that
situation. I'm actually wondering if it's a good thing at all to perform
such commits to the main repo. My current policy is to ensure that my
copy of the repository is up to date, and then patch and commit right
away so as to avoid the need for merging.
Doing things the way you describe feels wrong to me because you're
typically introducing information that is local to *you* into the main
repo: nobody else is interested in the fact that you committed in an
out-of-date copy of the main repo, and "fixed" this later on by merging.
--
5th European Lisp Workshop at ECOOP 2008, July 7:
http://elw.bknr.net/2008/
Didier Verna, didier(a)lrde.epita.fr,
http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-BicĂȘtre, France Fax.+33 (0)1 53 14 59 22 didier(a)xemacs.org
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches