merge vs pull (was What we did at UBZ)

[Jan Hudec]

On Mon, Nov 21, 2005 at 08:57:43 -0500, Aaron Bentley wrote:
> -----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.

You mean something like Quilt, Stacked GIT or Mercurial Queues? Is anyone
working to get shelves there?

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

Quilt can sure do that and so can stacked git and mercurial queues.

> > 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.

IIUC mq versions the patch queue. So when you rebase the patches to the new
head, you create a new revision of them. The history is not passed along when
the patch is commited though, but I believe it's actually correct -- the
patch history is only important until the patch is finished.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051122/9b4d0c35/attachment.pgp