Here's something joyful: when you close a branch in Mercurial, e.g. via
hg update -C branch-to-be-closed
hg commit --close-branch -m 'branch to be closed'
it becomes the "tip" - the most recent changest.
Many tools confuse "tip" with something like "the tip of the default branch". And do stuff like checking out or diffstat'ing with tip.
Which probably is not what you want for a closed branch.
Disclaimer
The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.
See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.
See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.
Thursday, July 05, 2012
Merge node common to several branches
Noticing a pattern:
hg branch b
... edit b ...
... test ...
hg merge -r default
... test ...
hg ci -m 'merged default into b'
hg update -r default
hg merge -r b
... diff -r default -r b
... test ...
hg ci -m 'merged from branch b into default (after already merged default into branch b, i.e. identical node in both default and branch b'
This seems suboptimal.
It seems to me that instead of creating the same node, wrt content, on two branches, in this case default and b, we could create it once. And link it in to both branches.
Key: must remember that the node is on both branches, so that afterwards can continue working separately.
I.e. could have updated to the merge node M but be on the default branch. Or on the b branch. (Or possibly both?)
It may be common to end a branch at such a merge node. Perhaps commn enough to be the default. But not univeral.
hg branch b
... edit b ...
... test ...
hg merge -r default
... test ...
hg ci -m 'merged default into b'
hg update -r default
hg merge -r b
... diff -r default -r b
... test ...
hg ci -m 'merged from branch b into default (after already merged default into branch b, i.e. identical node in both default and branch b'
This seems suboptimal.
It seems to me that instead of creating the same node, wrt content, on two branches, in this case default and b, we could create it once. And link it in to both branches.
Key: must remember that the node is on both branches, so that afterwards can continue working separately.
I.e. could have updated to the merge node M but be on the default branch. Or on the b branch. (Or possibly both?)
It may be common to end a branch at such a merge node. Perhaps commn enough to be the default. But not univeral.
Subscribe to:
Posts (Atom)