Malcolm Matalka <mmata...@gmail.com> writes: > So if the second most frequent thing one will probably do in a repo > (committing hopefully coming first), has uncertainty around it and > requires some serious thought and research to make the right decision, > on top of which since branches are permanent, making the wrong decision > runs the risk of being a forever-mistake, I think the reluctance is > understandable.
It is, yes.
Though looking at git, I see that this is even worse. There might be
only one kind of branch, but in return you have to control not only how
you call it locally but also its remote tracking branch.
For example I yesterday accidentally pushed to next from IntelliJ. I
created a local branch from origin/next, worked on it, and then pushed.
I had intentionally created the branch to move off next, but IntelliJ
pushed to next.
What was the problem? Git has additional state per branch, which is the
name of the remote branch. Mercurial avoids that.
Great, I broke the workflow.
And last weekend I lost half an hour while working out how to rebase
branches I had in consecutive pull-requests when I added a commit to one
of them.
next
|
v
A->Ax
|
v
B
The easy solution would have been:
hg rebase --base B --dest Ax && hg evolve --any && hg push
The actual solution was to give up on pull-request B and fold it into
Ax. Ugh. Force-pushing B wasn’t an option.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
signature.asc
Description: PGP signature
_______________________________________________ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial
