Patrick Mezard <patrick@mezard.eu> [Sun, 24 Jun 2012 18:11:52 +0200] rev 17178
patchbomb: rewrite getoutgoing() with revsets
Another version could have returned a revset expression from
getoutgoing(), but we do not know how many times it will be resolved, so
better do it once explicitely.
Patrick Mezard <patrick@mezard.eu> [Sun, 24 Jun 2012 17:39:27 +0200] rev 17177
patchbomb: support --outgoing and revsets
With --outgoing, input revisions were passed to getoutgoing() before
being resolved.
Patrick Mezard <patrick@mezard.eu> [Sat, 14 Jul 2012 19:21:31 +0200] rev 17176
patchbomb: make --outgoing ignore secret changesets
getoutgoing() is just rewritten almost like revset.outgoing(), a
follow-up will make it use revsets after the tests are adjusted.
Matt Mackall <mpm@selenic.com> [Sun, 15 Jul 2012 14:48:50 -0500] rev 17175
merge with stable
Wagner Bruna <wbruna@yahoo.com> [Fri, 06 Jul 2012 01:14:02 -0300] rev 17174
convert: make filemap renames consistently override revision renames
When the source repository had a revision renaming "$new -> $old",
but the filemap a "$old -> $new" rename, the converted revision could
use either $new (deleting the file) or $old (keeping the file) when
getting the file data, depending on the lexicographical order of
those names. So the resulting revision would leave some files
untouched (as expected), but delete others arbitrarely.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 06 Jul 2012 19:34:09 +0200] rev 17173
obsolete: compute extinct changesets
`extinct` changesets are obsolete changesets with obsolete descendants only. They
are of no interest anymore and can be:
- exclude from exchange
- hidden to the user in most situation
- safely garbage collected
This changeset just allows mercurial to detect them.
The implementation is a bit naive, as for unstable changesets. We better use a
simple revset query and a cache, but simple version comes first.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 10 Jul 2012 01:39:03 +0200] rev 17172
push: refuse to push unstable changesets without force
User should resolve unstability locally before pushing the same way we encourage
user to merge locally instead of pushing a new remote head.
If we are to push obsolete changeset, at least one set of the pushed set will be
either obsolete or unstable. The check is narrowed to only heads.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 06 Jul 2012 00:18:09 +0200] rev 17171
obsolete: compute unstable changeset
An unstable changeset is a changeset *not* obsolete but with some obsolete
ancestors.
The current logic to decide if a changeset is unstable is naive and very
inefficient. A better solution is to compute the set of unstable changeset with
a simple revset and to cache the result. But this require cache invalidation
logic. Simpler version goes first.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 06 Jul 2012 19:29:10 +0200] rev 17170
revset: add an `obsolete` symbol
This predicate matches obsolete changesets.
This is a naive implementation to be improved later.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 10 Jul 2012 01:32:18 +0200] rev 17169
push: refuse to push obsolete changesets
This is a first version. Simple but not very efficient.
Note that this changeset introduce the "obsolete" word in the UI.