OpenJDK (Java) migrating from Mercurial?

Arne Babenhauserheide arne_bab at web.de
Tue Nov 19 22:32:05 UTC 2019


Malcolm Matalka <mmatalka at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1076 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20191119/0a3d862a/attachment.asc>


More information about the Mercurial mailing list