- Jul 31, 2012
-
-
Patrick Mézard authored
Displaying multiple synopsis in online help has been broken since Matt RST refactoring, around ff26712a0c50. Rebase help is apparently the only one using this trick, just drop the second synopsis and assume people will understand as with graft help.
-
- Jun 29, 2012
-
-
Matt Mackall authored
-
- Jun 22, 2012
-
-
David Schleimer authored
When you rebased with a currently active bookmark, that bookmark would always point at the new tip, regardless of what revision it pointed at before the rebase. All bookmarks will now point at the equivalent post-rebase commit. However, the currently active bookmark will cease to be active unless it points at the new tip post-rebase. Rebase will always leave the new tip as the working copy parent, which is incompatible with having an active bookmark that points at some other revision. The common case should be that the active bookmark will point at the new tip post-rebase.
-
- Jun 21, 2012
-
-
Matt Mackall authored
-
Martin Geisler authored
-
- Jun 18, 2012
-
-
Dan Villiom Podlaski Christiansen authored
The previous error message had two issues: The first issue was that it wasn't, in fact, an error but a warning, even though it described a fatal error condition preventing the successful completion of the command. The second was that it didn't mention the immutable changesets, leaving the user guessing at the true cause of the error. The main downside to this change is that we now get an 'abort: can't abort...' message which technically contradicts itself. In this case, I blame that on the two uses we have for the word; if it weren't for backwards compatibility, we could make util.Abort print out 'error: <whatever>'.
-
- Jun 20, 2012
-
-
Pierre-Yves David authored
Rebase now behaves as if --detach was always passed. Non-merges are rebased as non-merges, regardless of their parent being an ancestor of the destination. Merges will usually be rebased as merges unless both of their parents are ancestors of the destination, or one of their parents is pruned when rebased. This only alters the behavior of rebase when using the --source/--rev options. --detach option is deprecated. All test changes were carefully validated.
-
- Jun 01, 2012
-
-
Bryan O'Sullivan authored
Once again making the API more rational, as with ancestors.
-
Bryan O'Sullivan authored
Accepting a variable number of arguments as the old API did is deeply ugly, particularly as it means the API can't be extended with new arguments. Partly as a result, we have at least three different implementations of the same ancestors algorithm (!?). Most callers were forced to call ancestors(*somelist), adding to both inefficiency and ugliness.
-
- May 15, 2012
-
-
durin42 authored
-
- May 03, 2012
-
-
Patrick Mézard authored
We allow rebase plus collapse, but not collapse only? I imagine people would rebase first then collapse once they are sure the rebase is correct and it is the right time to finish it. I was reluctant to submit this patch for reasons detailed below, but it improves rebase --collapse usefulness so much it is worth the ugliness. The fix is ugly because we should be fixing the collapse code path rather than the merge. Collapsing by merging changesets repeatedly is inefficient compared to what commit --amend does: commitctx(), update, strip. The problem with the latter is, to generate the synthetic changeset, copy records are gathered with copies.pathcopies(). copies.pathcopies() is still implemented with merging in mind and discards information like file replaced by the copy of another, criss-cross copies and so forth. I believe this information should not be lost, even if we decide not to interpret it fully later, at merge time. The second issue with improving rebase --collapse is the option should not be there to begin with. Rebasing and collapsing are orthogonal and a dedicated command would probably enable a better, simpler ui. We should avoid advertizing rebase --collapse, but with this fix it becomes the best shipped solution to collapse changesets. And for the record, available techniques are: - revert + commit + strip: lose copies - mq/qfold: repeated patching() (mostly correct, fragile) - rebase: repeated merges (mostly correct, fragile) - collapse: revert + tag rewriting wizardry, lose copies - histedit: repeated patching() (mostly correct, fragile) - amend: copies.pathcopies() + commitctx() + update + strip
-
- May 01, 2012
-
-
Patrick Mézard authored
-
- May 02, 2012
-
-
Patrick Mézard authored
-
- Apr 29, 2012
-
-
Patrick Mézard authored
The fix introduced in eab9119c5dee was only partially successful. It is correct to turn dirstate 'm' merge records into normal/dirty ones but copy records are lost in the process. To adjust them as well, we need to look in the first parent manifest to know which files were added and preserve only related records. But the dirstate does not have access to changesets, the logic has to moved at another level, in localrepo.
-
- Apr 25, 2012
-
-
Patrick Mézard authored
The previous code was rebasing an applied series like: patch1 +guarded patch2 patch3 +guarded patch4 patch5 +guarded into: patch2 patch4 patch1 +guarded patch3 +guarded patch5 +guarded Reported by Lars Westerhoff <lars.westerhoff@newtec.eu> Also rename mq.series_dirty into mq.seriesdirty, missed by 599a72895c0d, and without effect since mq.qimport() was setting it already.
-
- Mar 22, 2012
-
-
Matt Mackall authored
Checking for descendants of target being public was also wrong.
-
- Mar 04, 2012
-
-
Matt Mackall authored
-
- Jan 20, 2012
-
-
Wagner Bruna authored
-
- Jan 19, 2012
-
-
Matt Mackall authored
-
- Jan 17, 2012
-
-
Alain Leufroy authored
Rebase now try to keep the phases of source changesets.
-
kiilerix authored
Rebase will remove empty changesets and will also completely remove the mq patch file for rebased empty patches. Starting with b28004513977 (1.9) it would preserve guards by writing the old series file back. That would however also reintroduce removed patch files in the series file and the inconsistency would make qpop + qpush fail. This patch backs out most of b28004513977 and makes sure guards are preserved without reintroducing removed patches.
-
- Jan 13, 2012
-
-
kiilerix authored
repo.lock was taken before repo.wlock - that could in principle cause a deadlock.
-
- Jan 10, 2012
-
-
Matt Mackall authored
-
- Jan 08, 2012
-
-
Steven Brown authored
As of b12362ab13e7 (first released as part of Mercurial 2.0), the rebase command accepted ONLY revsets for the source and base arguments and no longer accepted old-style revision specifications. As a result, some revision names were no longer recognised, e.g. hg rebase --base br-anch abort: unknown revision 'br'! These arguments are now interpreted first as old-style revision specifications, then as revsets when no matching revision is found. This restores backwards compatibility with releases prior to 2.0.
-
- Jan 06, 2012
-
-
Matt Mackall authored
-
- Dec 26, 2011
-
-
Pierre-Yves David authored
-
- Dec 27, 2011
-
-
Pierre-Yves David authored
Detach is usually what I want when I use --source or (in particular) --rev. Having a shorter option make it less an hassle to use it.
-
Pierre-Yves David authored
--rev is only a more specific --source and there is no reason to refuse to use detach with it.
-
- Nov 10, 2011
-
-
Matt Mackall authored
-
- Nov 08, 2011
-
-
Stefano Tortarolo authored
This could happen in specific situations in which 'target' was selected as external and used for p1 _and_ p2.
-
- Nov 06, 2011
-
-
Stefano Tortarolo authored
When storing/restoring a nullmerge (-2), a 'standard' conversion was made and an existing changeset was wrongly used. Nullmerge should instead be treated as a special case.
-
- Nov 02, 2011
-
-
Matt Mackall authored
-
- Oct 17, 2011
-
-
Wagner Bruna authored
-
- Oct 15, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Pierre-Yves David authored
This option allow a strict set of revision to be specified instead of using -s or -b. Rebase will refuse start if striping rebased changeset will strip non rebased changeset. Rebase will refuse to work on set with multiple root.
-
Matt Mackall authored
-
Pierre-Yves David authored
The buildstate function now take a set of revs. Logic related to --source and --base option have been moved in the main rebase function. In the process this fixes a bug where the wrong source changeset might be pick. This explain the changes in hgext/rebase.py
-
- Oct 11, 2011
-
-
Matt Mackall authored
-
- Oct 09, 2011
-
-
Matt Mackall authored
-