merge vs pull (was What we did at UBZ)

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Erik Bågfors wrote:
> What I would like to be able to do instead is to keep my commit(s) in
> the tip (to speak hg talk).  So, say I branch and get revno 1..2000. 
> Now I commit revno 2001.  Next time I pull you have done 10 more
> commits.  What I'd like to be able to do is make 2001..2010 be your
> revisions and my revision that was numbered 2001, will not be 2011. 
> As long as there are no conflicts at least.  Basically, undo, pull,
> redo.

Yeah, a lot of people would like this kind of patch-management foo.

Extra points if you can split commits in two, join commits, and reorder
commits.

> Once you merge my stuff, I'm happy with the history not being exactly
> the same as long as I can get to pulling again.  But to make a small
> change and keep up to date with upstream should be simple.

Well, the unfortunate thing is that it means creating duplicate
revisions, and can obscure the real history of the patch.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDgdJX0F+nu1YWqI0RAu/OAJ46TGs64EedYUQ10yuCGDq/0SoIPgCeLhuf
UaxNNrTuAcvdttdbLZBQwcQ=
=jFNO
-----END PGP SIGNATURE-----