[Python-Dev] Mercurial migration readiness

[Georg Brandl]

Am 04.07.2010 13:37, schrieb Martin Geisler:
> "Martin v. Löwis" <martin at v.loewis.de> writes:
> 
>>> My question is basically the same as Terry Reedy's, but I'm going to
>>> phrase it a bit differently:
>>> 
>>> This is perhaps a naive question, but why do you create a second local
>>> clone instead of just creating a branch?
>>
>> IIUC, if you create a named branch, the branch will become globally
>> visible when you push your changes back. I assume people will consider
>> that clutter - it would be sufficient to just push the changes on the
>> branch, along with commit messages, but not the branch itself (which
>> would be only temporary, anyway).
>>
>> I'm not even sure how you pull changes from one branch into another:
>> can somebody kindly explain the commands that would be required?
> 
> You don't -- it is tempting to think of a "named branch" as a kind of
> container for changesets, but that metaphor makes people think that you
> can put changesets "into" a named branch and takes them "out" again.

I'm not sure if I misunderstand Martin's intent, but in principle, if you
want to merge one changes (not changesets!) branch into another, all you
need to do would be "hg merge <otherbranch>".   Subsequently committing
the merge (after fixing conflicts) creates a new changeset "on" the current
branch.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.