- User Since
- Feb 8 2018, 1:15 PM (62 w, 6 d)
Thu, Apr 18
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.
Wed, Apr 17
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.