- Jul 25, 2013
-
-
Matt Mackall authored
The tests contain a couple corner cases where workarounds are now required. Strictly speaking, these are behavior regressions, but of an extremely obscure and marginal sort. Commits or updates in the middle of a histedit would have almost always been fairly serious user error.
-
- Jul 24, 2013
-
-
durin42 authored
-
- Jul 16, 2013
-
-
durin42 authored
-
- Jul 15, 2013
-
-
Martin Geisler authored
When a file was renamed in the very first changeset being histedited, the rename was not detected. Consider a history like this: 0 base: add a.txt 1 first: rename a.txt to b.txt 2 last: edit b.txt When 1 and 2 are edited, copies.pathcopies(first, last) correctly returns that nothing was renamed. We must instead use copies.pathcopies(first, last) to detect the initial rename.
-
- Jun 07, 2013
-
-
Matt Mackall authored
-
- Jun 05, 2013
-
-
Simon Heimberg authored
-
- May 14, 2013
-
-
Bryan O'Sullivan authored
-
- Apr 18, 2013
-
-
Pierre-Yves David authored
Now that we explicitly detect duplicated changesets, we can explicitly detect missing ones. We cover the same cases as before, some others and we offer a better error message in all cases.
-
Pierre-Yves David authored
Before this change one would issue rules with duplicated entries. For this to happen some other changeset had to be missing to maintain the rules length.
-
Pierre-Yves David authored
This simplifies set usage and allow us to add a missing revision check in a later commit.
-
Pierre-Yves David authored
Handling homogeneous data is both simpler and safer.
-
Pierre-Yves David authored
There is some clue that the previous code intended to handle that but it was actually not the case. As a result action could apply to the empty string '' changeset, leading to the use the current working directory parent in some operations.
-
- Apr 16, 2013
-
-
Pierre-Yves David authored
Every piece of code extracted from the main command is a win. We simplify changeset determination in the process. Parent ceases being a list before becoming a node. We how have a root variable containing a node all the time.
-
Pierre-Yves David authored
This changeset move all checks and raises related to arguments validation to the top of the file. This gathers all the logic in one place and clarifies the code doing actual work. This paves the way for splitting this gigantic function in separated functions. A `goal` variable is introduced in the process. It holds the action to be done by this invocation (new, continue or abort). An invalid invocation is found in the process (the new code is a bit stricter).
-
Pierre-Yves David authored
When "-" is specified as a command file, we read rules from stdin. Alter a single test to demo the behavior, but most of them could benefit from this. There is minor change in test output resulting from the fact we no longer change log messages.
-
Pierre-Yves David authored
When all changes from the fold have been dropped, the --continue code was confused. This changeset handles this case. The test for this case existed but was broken.
-
- Apr 09, 2013
-
-
Katsunori FUJIWARA authored
Before this patch, "hg histedit" are not sensitive to the branch specified in the URL of the destination repository, even though "hg push"/"hg outgoing" are so: Invocation of "discovery.findcommonoutgoing()" without "onlyheads" argument treats revisions on branches other than the one specified in the URL as outgoing ones unexpectedly. This patch specifies list of head revisions, which are already detected by "hg.addbranchrevs()" from URL and looked up against local repository, as "onlyheads" to "discovery.findcommonoutgoing()" to limit calculation of outgoing revisions.
-
- Feb 08, 2013
-
-
durin42 authored
-
- Apr 12, 2013
-
-
Bryan O'Sullivan authored
-
- Feb 10, 2013
-
-
kiilerix authored
-
- Aug 03, 2013
-
-
Simon Heimberg authored
Using only one message makes live easier for translators. The clearer error message was supposed by Augie Fackler.
-
Simon Heimberg authored
Editing the history only is possible when the working dir is a descendant of the revisions to edit. When this happens explain it by writing abort: %s is not an ancestor of working directory
-
- Jan 30, 2013
-
-
durin42 authored
If the binary hash of the parent node guessed via --outgoing happened to contain a special revset character (":" was specified in the bug), the revset parser would abort. Hexlifying the node before passing it to the revsingle call should fix that.
-
- Jan 16, 2013
-
-
Pierre-Yves David authored
Before this changeset, histedit created all new changesets according phases.new-commit option without any regards for the phases of the original changesets. This changeset fix that using the phase of rewritten changeset to decide the phase of the resulting changeset. In case of reordering or folding, we keep secret item secret as it seems the safer path. temporary commit creation are not affected. They are head only and stripped at the end of the histedit. As for the resolution of issue3681 (obsolescence cycle prevention), we do not handle changesets created by edit command.
-
Pierre-Yves David authored
Have histedit record the hex of the original changeset as already done by: - graft - commit --amend - rebase My main motivation for adding this is to prevent the creation of obsolescence cycle (see issue3681). Note that commit created during edit are not affected yet.
-
Pierre-Yves David authored
Later commits add two important items to histedit: - Obsolescence cycle prevention - Proper phase conservation Those logics must be applied to all simple operations (pick, edit, mess) and will require verbose code. So we introduce a new function that will provide an entry point for this new. logic. The function build a closure to have a clear distinction between commit arguments and data provided to the function to fulfil its logic.
-
- Dec 12, 2012
-
-
kiilerix authored
-
- Jan 14, 2013
-
-
Kevin Bullock authored
-
Katsunori FUJIWARA authored
In the context of help document on which this patch focuses, the example repository, which is source of cloning, should be already histedit-ed, and contain only 3 revisions (rev # 0 to 2). So, not 3, but 4 revisions should be added to the destination repository of cloning, if it contains 7 revisions (rev # 0 to 6). This patch also adds modifier "histedit-ed" to "example repository", to make context clear.
-
Katsunori FUJIWARA authored
There is no '633536316234' revision in the example repository. It should be 'c561b4e977df', according to the revisions in it and explanation in help document.
-
- Dec 24, 2012
-
-
Pierre-Yves David authored
Hidden changeset filtering is now done at repo level. The orphaned children computation will not include any (unless you add --hidden).
-
- Dec 31, 2012
-
-
Pierre-Yves David authored
Obsolescence markers can represent this situation just fine. Rewritten revisions are marked as precursors of the ones creates by histedit. Unaffected descendants become "unstable". If obsolescence is not enabled we keep the current behavior of aborting. This new behavior only applies when obsolete is enabled and is subject to future discussion and changes.
-
- Nov 07, 2012
-
-
durin42 authored
Bookmarks persistence still showed a fair amount of its legacy as a monkeypatching extension. This encapsulates all bookmarks serialization and parsing in a single class, and offers a single location where other bookmarks storage engines can be substituted in. As a result, many files no longer import the bookmarks module, which strikes me as an encapsulation win. This doesn't do anything to the current bookmark state yet, but I'm hoping put that in the bmstore class as well.
-
- Oct 16, 2012
-
-
Pierre-Yves David authored
I arbitrary use the revnum of the precursor because it sound a right order.
-
Thomas Arendsen Hein authored
Use sorted(x, key=y)[-1] or sorted(x, key=y)[0] instead.
-
- Oct 14, 2012
-
-
Pierre-Yves David authored
It does not crash but does not compare revision number at all. We actually remove any call to min because the list is already topologically sorted.
-
Pierre-Yves David authored
-
Pierre-Yves David authored
The variable content is actually contexts, not revision numbers.
-
- Oct 12, 2012
-
-
Pierre-Yves David authored
Public changeset are immutable. This changeset enforce that in histedit.
-
- Sep 27, 2012
-
-
Pierre-Yves David authored
We do not want hidden revision to block histedit. They are already "dead" and we do not care about dead orphans. see similar changeset 9e2dc0d292cd for rebase.
-