Guido Ostkamp <ooo <at> ostkamp.fastmail.fm> writes:
> Indeed, it does. But who wants an *anonymous* branch where after a while
> you don't remember what it was used for?
In my opinion, a branch is either big enough to be globally named (e.g. being
a CWS) or so specific that the dev will remember what it is about. I you really
so many minibranches that you loose overview in one CWS there is the bookmark
feature that Heiner already told you about. Please be so kind and read about
them.
> If you go
>
> hg up -C <earlierrevision>
> <change>
> hg commit
> hg up -C <original-top-changeset>
> hg push
>
> then Mercurial denies pushing because it would create remote heads. It is
> clear that it tries to publish your anonymous branch which is unwanted
> behaviour.
No, that is expected behavior. Also mercurial does not deny pushing, it just
warns you about the creation of new heads. If you are specific by either
pushing one revision (-r) or all (-f) mercurial will happily do that for you.
> You could theoretically 'hg clone -r <changeset>' and get only that single
> branch with all unmerged other branches stripped off. And you could 'hg
> pull -r <changeset> some other branches into it.
No, if you just want to push one branch, you would do just that:
hg push -r {branch/bookmark/changeset}
> So you would need 1 clone and n-1 pull's to remove one unmerged branch.
> The same that you can achieve in Git with just one call
>
> git branch -D sillybranch
No need for complex cloning and pulling - just use hg strip if you want to
delete an unwanted local branch (ok, that technically is the mq extension,
but requires none of the complex patch handling).
> MQ is generally inconvenient as it operates on a stack of patches and
> nothing that compares to Git's branches.
It is still useful in some scenarios. However, none of the scenarios you
named so far would needed manual MQ patch handling. Gits branches are
well featured directly by mercurial without the need for manual patch
queue handling.
> What is needed here is to put all changes within that branch into one
> changeset and apply this on top of the mainline, push the mainline change
> to the master repo and finally get rid off the local branch.
You mean like:
hg rebase --base <MINIBRANCH-HEAD> --collapse --dest <CWS-HEAD>
hg push -r <CWS-HEAD>
Both heads could be named with a bookmark if you insist.
> > Not needed. In fact I just did a build of a master and a cws reusing
> > most of the master build just today. Works like a charm.
>
> I would be interested to know how you did that with just one repo and no
> clones and without running into the anonymous branch issues listed above.
>
> Would it be possible to give a short example?
hg clone DEV300
hg pull my_cws
hg up -r DEV300_m53
build yadda yadda
hg up -Cr my_cws # note this is not a purge
build --from svtools --prepare yadda yadda
Absolutely no magic there.
Please read a bit about mercurial and its feature before coming back with
informed criticism.
Best Regards,
Bjoern
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
