One of the main goal of having consolidated destination function is to allow
extension to play with this logic. We extract sub logic to make is wrapping more
practical.
One of the main goal of having consolidated destination function is to allow
extension to play with this logic. We extract sub logic to make is wrapping more
practical.
We want extension to be able to easily override or add new way to select the
default update destination. We use the same list + dict approach as in other
parts of the code.
One of the main goal of having consolidated destination function is to allow
extension to play with this logic. We extract sub logic to make is wrapping more
practical.
One of the main goal of having consolidated destination function is to allow
extension to play with this logic. We extract sub logic to make is wrapping more
practical.
One of the main goal of having consolidated destination function is to allow
extension to play with this logic. We extract sub logic to make is wrapping more
practical.
This block was overwriting any result from the previous block anyway. So we move
it first to prove it is possible and we'll extract it in its own function in the
next patch.
One of the main goal of having consolidated destination function is to allow
extension to play with this logic. We extract sub logic to make is wrapping more
practical.
Function in destutil are much simpler to wrap and more flexible than revset.
This also help consistency as 'destupdate' live here and cannot become a pure
revset anyway.
The revset is not ready for prime time yet. However it is useful to have some
version of it exposed to help candidate users to play with it and provide
feedback on what we should aim at.
We add a small test to make sure the code runs.
I'm about to add a cg3, and it seems prudent to annotate what formats
support what features. It strikes me that we may want to consider
moving to a more feature-oriented model in the future, but we'll see
how that looks in a little while I guess.
I'm not sure what to do abstraction-wise here. It might be more
sensible to make a memoryrepo that could apply a bundle in-memory and
then we could make the changegroup data be strictly an applyable
stream, but that's an idea for Later.
The new convention is that bundles contain changegroups. bundle1
happens to *only* be a changegroup, but bundle2 is a more featureful
container that isn't something you can pass to addgroup().
The client now sends a "cbattempted" boolean flag to the "getbundle"
wire protocol command to tell the server whether a clone bundle was
attempted.
The presence of this flag will enable the server to conditionally emit a
bundle2 "output" part advertising the availability of clone bundles to
compatible clients that don't have it enabled.
This is needed so a subsequent patch can conditionally add a bundle2
part to the "getbundle" wire protocol command depending on whether a
clone bundle was attempted.
If a clone bundle persistently fails to apply, users need a way to
disable it so they have a hope of the clone working. Change the hint for
the abort scenario to advertise the config option to disable clone
bundles.
The client represents boolean arguments as '0' and '1'.
bool('0') == bool('1') == True, so a simple bool(val) isn't sufficient
for converting the argument back to a bool type.
Currently, "obsmarkers" is the only boolean argument to getbundle.
I /think/ the only place where we currently set the "obsmarkers"
argument is during bundle2 pulls. As a result of this bug, the server
/might/ be sending obsolete markers bundle2 part(s) to clients that
don't request them. That is why I marked this BC.
Surprisingly there was no test fall out from this change. I suspect a
lapse in test coverage.
We would skip the part if it was fully unknown, so we should also skip it if we
know we won't be able to apply it. This will allow us to produce bundles with
obsolescence markers alongside changegroup while still being able to apply them
on any client.
We want to gracefully handle the read only case in some case (current target:
advisory obsmarkers parts in bundle2). So we expose the attribute in a clean
way.
The 'postincoming' function used by 'hg pull --update' and 'hg unbundle' is
catching 'Abort' exceptions to intercept failed update. This feel a bit too
wide to me, so I'm introducing a more precise exception to specify update
destination issues.
Now that all internal callers pre-compute and set a destination at a higher level
it feels like we can kill this API. This will allow us to simplify this
function. However I feel like this is a bit too central and critical to break
now. I'm adding a devel warning to let extension make catch this in the next
cycle.
Due to how the line links now reside outside of the source lines, hovering over
line numbers doesn't count as hovering over the appropriate source line. It can
be worked around by using a "+" css selector. However, it's necessary to
reorder the elements and put <a> before <span> (which is actually quite
logical). It works without further css tweaks because <a> is already
absolute-positioned and so the order doesn't matter visually.
Due to how the line links now reside outside of the source lines, hovering over
line numbers doesn't count as hovering over the appropriate source line. It can
be worked around by using a "+" css selector. However, it's necessary to
reorder the elements and put <a> before <span> (which is actually quite
logical). It works without further css tweaks because <a> is already
absolute-positioned and so the order doesn't matter visually.
Due to how the line numbers in monoblue are formed (via css counters), the size
of the area with the numbers and the size of the actually clickable links are
not tied together well enough. Before this patch, there were noticeable "gaps"
between line links - clicking on the bottom part of a visible line number did
nothing as opposed to selecting this line.
Let's set font-size for everything in pre.sourcelines so that it also affects
the links and then add a bit of padding to them so compensate for layout
differences.
This way the sizes are still not 100% the same, but should be very close.
In hgweb, some pages have a context of current revision; e.g. changelog and
shortlog show changesets starting from this current revision. However, some
gitweb templates were dropping current revision from some urls _to_ /graph page
and _on_ that page. This patch fixes it.