On Tue, Mar 25, 2008 at 07:03:43PM +0000, Julian Foad wrote:
> For perhaps the most complex related behaviour, consider a switched
> sub-tree in the WC. This is handled, I think, a bit like a missing target
> within its parent directory in that the sub-tree that's not being touched
> shall have this fact recorded with explicit mergeinfo. As well as that, the
> changes to be merged into that sub-tree are made within the switched
> location. Therefore all of the merge source is applied somewhere, but
> different parts of it are applied within different destination branches. No
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> "skipped" notification is printed, so this isn't actually a case in
> question.
Wait a minute... Isn't this behaviour a tiny bit insane?
Shouldn't we forbid merging into partly switched working copies
altogether unless --force is present?
Because I can't really see this being useful except for confusing people
who want to track which changeset (a.k.a. revision) has been applied
to which branch, since they might end up finding parts of the change
set on one branch and other parts of the changeset on another branch.
And let's not even start thinking about someone merging a changeset
into a working copy with more than one of its directories all being
switched to entirely different branches -- that's insanity.
If such a merge happened to be committed by accident I don't think
anyone would enjoy cleaning up the resulting mess.
Please enlighten me if there is a legitimate use case that supports
the described behaviour. Otherwise I might end up filing an issue
for this, because it scares me... IMHO stuff like this should require
--force so people doing this are made aware that they should really
know what they are doing.
--
Stefan Sperling <stsp_at_elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
- application/pgp-signature attachment: stored
Received on 2008-03-26 14:59:24 CET