update suggests merge, merge suggests update...
Marcin Kasperski
Marcin.Kasperski at softax.com.pl
Fri Feb 15 09:43:51 CST 2008
> Since it appears that there were actually no uncommitted changes
> here, what update -C would actually have done in this situation is
> the latter, which is perfectly safe (provided you know it's
> happening), and would have been the quickest way for Marcin to
> proceed.
Well, I in fact tried it too (copying the dir for the sake of
the test) and 'hg up -C' followed by 'hg merge' were the correct
way to proceed...
Although I am not sure whether there is any difference between 'hg up
-C' and 'hg up -r tip' here
> So, I think there ought to be a separate option to hg update (perhaps
> -f) that does only the safe action, and this error message ought to
> refer to that.
Well, I think that above all, the error message should consider the
repository state. Mercurial knows whether there are uncommited
changes, or not (so - whether I will loose the changes). Mercurial
knows whether I am on the head, or not (so - whether merge may work,
or not)...
So, instead of the current
abort: update spans branches, use 'hg merge' or 'hg update -C' to lose changes
it should probably format message conditionally, mentioning
- commit or update -C if there are uncommited changes
- update -r <headid> if I am not on the head
- merge if I am on the head
Also, the merge error message
abort: working dir not at a head rev - use "hg update" or merge with an explicit rev
would be more helpful if it mentioned WHICH explicit rev I should use.
Probably sth like:
abort: working dir not at a head rev - use "hg update -r <headrev>" before trying to merge ("hg heads" lists head revisions, "hg up -r tip" is most likely choice)
--
----------------------------------------------------------------------
| Marcin Kasperski | People resist change, regardless of what
| http://mekk.waw.pl | it is. (Michael Reed)
| |
----------------------------------------------------------------------
More information about the Mercurial
mailing list