3rd party software customizations
Arne Babenhauserheide
arne_bab at web.de
Tue Apr 17 20:02:36 UTC 2012
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>
More information about the Mercurial
mailing list