In D8633#133117, @indygreg wrote:

I left a handful of comments.
Changing repo opening semantics and requirements handling is a bit scary.
I'm generally in favor of separating working directory requirements from non-working directory requirements so I think this patch is a step in the right direction. There are a few alternative implementations worth considering. (Although I'm unsure if they are superior.)

1. Write the new requirements file in the .hg directory as .hg/store-requires (or similar). Conceptually, we're talking about working directory and backend requirements. The "store" is just today's layout for storing backend data [which can be shared between working directories].
2. Write a new requirements file for working directory specific requirements.

As @valentin.gatienbaron pointed out, the now avoid adding more semantic to bare --force with an associated --force-bookmark especially because we want to be able to select the bookmarks that get force pushed here.

Looks legit. Thanks.

Changeset fc54f52779dd is doing the same thing.

According to IRC discussion, this series is not ready for review, so moving it out of yadda.

According to IRC discussion, this series is not ready for review, so moving it out of yadda.

According to IRC discussion, this series is not ready for review, so moving it out of yadda.

According to IRC discussion, this series is not ready for review, so moving it out of yadda.

According to IRC discussion, this series is not ready for review, so moving it out of yadda.

According to IRC discussion, this series is not ready for review, so moving it out of yadda.

According to IRC discussion, this series is not ready for review, so moving it out of yadda.

According to IRC discussion, this series is not ready for review, so moving it out of yadda.

According to IRC discussion, this series is not ready for review, so moving it out of yadda.

According to IRC discussion, this series is not ready for review, so moving it out of yadda.

According to IRC discussion, this series is not ready for review, so moving it out of yadda.

That is a bad reason to use a close. Make the function private and move it at the module level.
(Mercurial used to be full of this strange closure and this was a pain)

In D8771#131191, @pulkit wrote:

In D8771#131190, @marmoute wrote:

The tricky part is that all the requirements has default value. If requirement B depends on requirement A, and both are enabled by default, we cannot simply automatically enable A if B is true, because B is true by default. Warning would be good, but might end up a bit verbose for the same reason.
However if the user explicitly request A=no and B=yes, it seems bad to silently drop B since it was explicitly requested.
So, I don't see a good solution until we detect explicit activation vs default value (which is a scope bloat).

Very much agreed. Since we know that store is enabled by default and bookmarks in store is not enabled, we can be aware whether user is explicitly requesting something.

The tricky part is that all the requirements has default value. If requirement B depends on requirement A, and both are enabled by default, we cannot simply automatically enable A if B is true, because B is true by default. Warning would be good, but might end up a bit verbose for the same reason.

More serious question: Maybe we should stop passing around tuple of dictionnary and return an object holding all that data with a better API. What do you think ?

I resigned (and commented) on the wrong revision.

More serious question: Maybe we should stop passing around tuple of dictionnary and return an object holding all that data with a better API. What do you think ?

I can confirm phab eat my comment.

This is mostly a test of phab eating comment

This seems good and if the test are happy, we should be too.

I would be more confident if we get some explicit test about trust. However unshare is not working.

(reply written ages ago)

I am a bit late to the party, but does this mean that and old client and
a new client could do conflicting write to strip backup because they
would be respectively holding wlock and lock, thinking that make them safe?

In D8596#130836, @martinvonz wrote:

In D8596#130831, @marmoute wrote:

Can you mark them as "changes planned" in the mean time to clear up yadda?

There are no actual changes planned and I guess I figured that the base patch being marked as "changes planned" would be sufficient, so sure, I'll update the other ones to that status too.