3rd party software customizations

[Arne Babenhauserheide]

Am Dienstag, 17. April 2012, 11:32:21 schrieb Cristiano Cortezia:
> Sure it is. But as far as I know, it will only help me pick changesets, not
> pieces of code. In the mentioned strategy, the new vendor release is
> dropped as a whole in the vendor branch, composing one single changeset,
> and thus decreasing transplant's usability.

You can simply `hg revert` the files you want to include and then `hg record` 
the parts of the files which fit together to take the code cleanly.

That might then not work as well with merging, though.

>  Still, transplant is very useful for moving changesets around branches
> without merging their histories while keeping them "decoupled". But it
> seems a bit dangerous sometimes. I mean, will mercurial's merging algorythm
> be able to correctly analyze the presence of a changeset, which is common
> between two branches under merge, when it was in fact transplanted from one
> to another (or from a third branch common to both of them) ? My impression
> is that it won't.

If you use an up-to-date version of Mercurial you can just use graft. That’s a 
core command now and it does what transplant does - but using the merge 
machinery, so merging just works.

Since I started using it, having multiple branches for different machines does 
not hurt anymore.

Best wishes,
Arne
--
Ein Würfel System - einfach saubere Regeln: 

- http://1w6.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20120417/3ac74d92/attachment.asc>