- complain about attempts to merge with ancestor
- when updating, differentiate between
- crossing named branches with no local changes (jump)
- crossing named branches with local changes (complain)
- nonlinear update on the same named branch, no changes (complain some more)
- nonlinear update on the same named branch, changes (different complaining)
(including small changes to revert and backout to not show these stats
with the exception of backout --merge)
Show update stats (unless -q), e.g.:
K files updated, L files merged, M files removed, N files unresolved
Inform the user what to do after a merge:
(branch merge, don't forget to commit)
Inform the user what to do if a branch merge failed:
There are unresolved merges, you can redo the full merge using:
hg update -C X
hg merge Y
Inform the user what to do if a working directory merge failed:
There are unresolved merges with locally modified files.
repo.addchangegroup method now returns number of heads modified and added,
so command line can tell whether update or merge needed. this makes
tiny change to ssh wire protocol, but change is backwards compatible.
pull command now returns 0 if no changes to pull.
# HG changeset patch
# User maf46@burn.cl.cam.ac.uk
# Node ID 57667c9b93a5a743e4629d15a0e6bd76699130c3
# Parent 4309b0a5a6010dd2e5811b77d2bc29a51acf290f
Fix zombie files in merge
Keir Fraser observed the following:
> I made a small test case that illustrates the bug in merging changesets
> with 'hg remove's in them:
>
> 1. Create a repository A containing files foo & bar.
> 2. Create clone called B.
> 3. A removes file bar, and commits this removal.
> 4. B edits file foo, and commits this edit.
>
> Now, if B:
> # hg pull ../A; hg update -m; hg commit
> Then bar remains deleted.
>
> If A:
> # hg pull ../B; hg update -m; hg commit
> Then bar is resurrected!
>
> It looks as though, when you merge across a branch, any deletions in
> your own branch are forgotten.
> ...
> Fixing this is a must, as zombie files are a real pain. :-)
Keir later patched our local copy of hg as shown below, which fixes
the problem. I've also enclosed a test which captures the test Keir
outlined...
Files deleted on a branch should not automatically reappear in a merge
Patch notes:
1. The first chunk does not change behaviour, but cleans up the code
to more closely match check of 'force' in the second chunk. I
think it makes the code clearer.
2. The second chunk fixes two bugs --
i. If we choose to keep a remotely-changed locally-deleted file,
then we need to 'get' that file. If we choose to delete it
then no action need be taken (it is already deleted in the
working manifest). Without this fix, choosing to delete would
get a Python traceback.
ii. The test for whether the file was remotely-created is
insufficient. It is only true if f is not in the common
ancestor. Otherwise the file was deleted locally, and should
remain deleted. (this is the most important fix!)
Index: hg/tests/test-merge6
===================================================================
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[PATCH] Don't prompt user for keep-vs-delete when the merge is about to be aborted
From: Michael A Fetterman <Michael.Fetterman@cl.cam.ac.uk>
If an "hg update" is attempted across branches, it is aborted with an
error message, basically saying that "update -m" is required. Don't
prompt the user for "keep vs delete" kinds of questions before deciding
to abort.
manifest hash: 250d3a0e866af2feac9344d499b26c254c33abc4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCuNeDywK+sNU5EO8RAu2BAJwNWXXN2L+4TnOUGaOe9iBj6CgOYgCfRKIE
RF5czx2UQ2pSIP119xzq9mQ=
=Akj6
-----END PGP SIGNATURE-----
