You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 3, 2018. It is now read-only.
Sometimes, branches move nonlinearly (e.g. force push), and sometimes, tags get moved. It's important to define how the SourceManager handles these cases to make sure we're not missing anything.
Here is, more or less, the order of considerations:
Cached repos are mirrors of their upstreams - even of bad citizen changes.
If a bad citizen-type change occurs, we don't actually complain about it unless something in the solving process directly touches the problematic ref.
If we run into a bad-citizen change, and it's an improper move (e.g. force push) on a branch...well, we probably won't say anything about that. It's a branch; they move.
If the bad-citizen change is a tag being moved, and something was pinned to the old tag, we absolutely should push out a warning to the user strongly encouraging them to make a change, as they're in a potentially risky situation (that lock might be unfulfillable on a machine without an old cache).
Some additional safety measures can be taken - for example, setting gc.pruneExpire = never could ensure oprhaned objects aren't lost on git repositories. (I'll need to research the equivalents for hg and bzr).
The text was updated successfully, but these errors were encountered:
We really don't care about nonlinear branch moves, I don't think, so it's just tag movement that we have to worry about.
sdboyer
changed the title
Define behavior of solver when branches and tags move in nasty ways
Define behavior of solver when tags move in nasty ways
Oct 6, 2016
Sometimes, branches move nonlinearly (e.g. force push), and sometimes, tags get moved. It's important to define how the
SourceManager
handles these cases to make sure we're not missing anything.Here is, more or less, the order of considerations:
Some additional safety measures can be taken - for example, setting
gc.pruneExpire = never
could ensure oprhaned objects aren't lost on git repositories. (I'll need to research the equivalents forhg
andbzr
).The text was updated successfully, but these errors were encountered: