- User Since
- Feb 8 2018, 1:15 PM (88 w, 1 d)
Sep 16 2019
Just tracked --add-include. A workaround to simplify the upgrade would be to change wireprototypes.SUPPORTED_ELLIPSESCAP to be (ELLIPSESCAP1, ) on the server from now until all clients have upgraded. But that may still be annoying and error-prone for you to deal with. @pulkit, I suppose we should just add a exp-narrow-2 capability to deal with this? It doesn't seem fair to make @idlsoft deal with it.
Sounds like a good idea!
Sep 14 2019
If you mean "reject bad pushes as long as people don't push -f", both versions implement this (the client-side check is not racy thanks to these check:bookmark bundle parts).
That was the idea. This implementation is a bit more flexible I think.
Since it’s server side, you don’t have to upgrade your clients.
It’s true old clients won’t be able to use —force, but new ones can.
And you can add a trigger if you want to limit who can use —force.
Sep 13 2019
Isn't that a client-side change only though, so we still need functionality on the server to reject bad pushes? (I could be missing something.)
Sep 12 2019
Sep 11 2019
Sep 9 2019
Yes, server changed since your last pull, and you override the bookmark without so much as a warning.
Sep 3 2019
I see --force as a general "I know what I'm doing, forget your checks" instruction.
If it's not, then all the variations would need their own --force-heads, --force-bookmarks, --force-*.
May be a bit much.
Aug 30 2019
This is a potential fix for https://bz.mercurial-scm.org/show_bug.cgi?id=6193
The actual validation is in bundle2.handlebookmark.
The rest of the changes are there to pass the force parameter.
I've also made force available to hooks. That way one can validate who can and cannot use --force on a shared repo.
Apr 25 2019
Apr 24 2019
Apr 18 2019
This is nitpicking, but there is a duplicate _NARROWACL_SECTION definition in narrowbundle2.py,
I think only the one in exchange.py should remain.
Btw it's still 'narrowhgacl' from the old days.
Apr 17 2019
If ACL is enabled, processing this part is mandatory, yes.
On clone, or pull the user doesn't specify includes, so reading this part is the only way the client can get them.
Because the current client ignores the data completely, the only way to force it to fail I think is to change the name of the part.
This would make things cleaner probably, but I'll deal with whatever solution you guys settle on.
Dec 6 2018
Bookmarks have been in core for some time now, and there is not one mention anywhere that they are not to be used.
They may not be trivial to use but it's certainly not officially discouraged anywhere.
Bookmarks is the first thing that comes up when you search for "mercurial light branching", although it's from a blog post, not the official wiki.
Meanwhile the official wiki plainly states that light branching is a different abstraction, and branches should not be used for for that.
Dec 5 2018
Dec 4 2018
Dec 3 2018
Obviously, I can't say I'm too happy with this. Allowing users to shoot themselves in the foot even more is pretty bad.
I don't think that's fair.
Everyone's experience is different, but it did precisely the opposite for us.
Oct 25 2018
@smf I just noticed your name on https://www.mercurial-scm.org/wiki/BookmarkUpdatePlan, which puts your comments into a larger context.
This would definitely be an improvement, and reduce the scope of what this extension does.
Would you consider also addressing the hg bookmark NAME doing two very different things depending on the bookmark already existing?
Oct 20 2018
Were there particular pain points before? The list of things to polish isn't short, but I don't mind reprioritizing things if it helps.
Oct 18 2018
First of all, thank you for reviewing the patch.
Oct 15 2018
If this is accepted we might want to look into changing the behavior of hg pull -u.
It should update the working directory only if the active bookmark was moved remotely.
I didn't find an easy way to do this without changes to core.
At some point RhodeCode was checking if the destination bookmark was a descendant of the source, and not allowing such pull requests to be created.
That would have to be handled as a fast-forward, in other words just moving the destination bookmark.
Sep 5 2018
Sep 4 2018
Sep 2 2018
I added some inline comments.
A test for hg book EXISTING is indeed missing, there is, however, one for not moving the bookmark on update, it's line 52: (leaving bookmark X).
Hopefully, I'll be able to make some changes later in the week.
Was not aware about the wiki page, this indeed seems to be addressing the same problem. At least that's how it started., and later evolved into something that helps you follow the workflow.
Aug 22 2018
Created a new one instead of updating D4312
Aug 18 2018
Aug 17 2018
Aug 16 2018
This was submitted in error, not sure how to delete it.