- 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
-
- Sep 19, 2011
-
-
Pierre-Yves David authored
We only deny rebasing onto direct parent. Thanks to the ancestor argument of merge. the "implementation" of this feature only consist in loosing the check and imply detach when rebasing on ancestor.
-
- Jul 21, 2011
-
-
Augie Fackler authored
-
- Jul 18, 2011
-
-
Stefano Tortarolo authored
Collapse and keepbranches should be blocked when there is more than one named branch on the branch that's going to be rebased.
-
- Jul 15, 2011
-
-
Stefano Tortarolo authored
-
- Jun 08, 2011
-
-
Idan Kamara authored
-
- Jun 12, 2011
-
-
Idan Kamara authored
-
- Jun 13, 2011
-
-
Adrian Buehlmann authored
-
Adrian Buehlmann authored
-
- Jun 01, 2011
-
-
Matt Mackall authored
-
- Mar 26, 2011
-
-
Stefano Tortarolo authored
Guards on rebased mq patches were lost. This patch restores them after the qimporting step.
-
- May 27, 2011
-
-
Adrian Buehlmann authored
This makes 'pull --rebase' consistent with the merge command, which already provides that option to control the merges
-
- May 12, 2011
-
-
Adrian Buehlmann authored
-