-
Dan Villiom Podlaski Christiansen authored
This essentially makes our behaviour match the documentation, which states that ``git.public`` refers to “a list of Git branches”. It didn't: it actually referred to a list of Mercurial changesets that we would publish on push. Previously, this would lead to a rather nonsensical situation: * The remote ``stable`` points to commit A * The local, corresponding ``stable`` bookmark points to commit B * ``git.public`` is configured to list ``stable`` * The user performs a pull. Whatever you'd expect to happen in that case, it mostly likely _wouldn't_ be for B to be published, which was what happened. Please note that this change breaks backwards compatibility; previously, having ``git.public`` point to e.g. ``default/master`` would cause that to be published. But that was always undocumented.
Dan Villiom Podlaski Christiansen authoredThis essentially makes our behaviour match the documentation, which states that ``git.public`` refers to “a list of Git branches”. It didn't: it actually referred to a list of Mercurial changesets that we would publish on push. Previously, this would lead to a rather nonsensical situation: * The remote ``stable`` points to commit A * The local, corresponding ``stable`` bookmark points to commit B * ``git.public`` is configured to list ``stable`` * The user performs a pull. Whatever you'd expect to happen in that case, it mostly likely _wouldn't_ be for B to be published, which was what happened. Please note that this change breaks backwards compatibility; previously, having ``git.public`` point to e.g. ``default/master`` would cause that to be published. But that was always undocumented.