- Jun 01, 2012
-
-
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
-
- 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
-