- 30 Jul, 2019 1 commit
-
-
Pierre-Yves David authored
-
- 29 Jul, 2019 2 commits
-
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-
- 19 Jul, 2019 1 commit
-
-
Anton Shestakov authored
If a user wants to spell out -s, it makes sense to allow that. Before this patch, prune would complain that --successor is not a recognized option. Obviously people don't usually need to spell --successors by hand thanks to shell completion (at least for Bash) using debugcomplete to see all available flags, so this patch doesn't bring any need for more typing. And thanks to Mercurial understanding shortened forms of command-line flags as long as they are unambiguous, the old-style `--succ` flags still work normally, and there are tests that use them. But two tests now use the full form to demonstrate that both ways work.
-
- 17 Jul, 2019 2 commits
-
-
Pierre-Yves David authored
-
Sushil Khanchi authored
When touching a node, the way we check if it can lead to divergence is we look at the successors sets of the rev being touched. And if there is successor revs exists (excluding the case when that successor set is (A,) for rev A) that means there will be divergence and we warn the user. This works fine but there is still a case (which is not covered by looking at successor sets) which can lead to divergence. That case is: when there is already a revision exists which is divergent to the revision being touched. And performing the touch would revive that "dead" divergence. (Dead because one of the revision is obsolete which is the one we are touching) And to see if there is any rev which is divergent to a particular rev we already have a function which we can use here i.e. `evolvecmd.divergentsets(repo, ctx_being_touched)` Changes in test file demonstrate the fixed behaviour.
-
- 13 Jul, 2019 1 commit
-
-
Anton Shestakov authored
As with fold (see the previous patch), it's allowed to metaedit a merge commit or a set of commits including merge commits (with --fold) as long as there are less than 2 parents of the set not included in the said set.
-
- 11 Jul, 2019 2 commits
-
-
Anton Shestakov authored
It's possible to fold revision chains that include a single merge commit: just fold everything into the merge commit while saving its other parent (so it continues being a merge commit). It's also possible to fold revisions that include multiple merge commits, on the condition that they merge with not more than 2 external changesets (i.e. a changesets that aren't going to be folded).
-
Anton Shestakov authored
Otherwise rewinding a merge commit makes it lose all changes. This fix populates `updates` argument of rewriteutil.rewrite() with parent changesets. That argument is normally used for folding multiple changesets, but in this case it's simply used to include files from p1 and p2. Usually, rewrite() works fine using ctx.files(), but that function can return an empty list when ctx is a merge commit.
-
- 09 Jul, 2019 1 commit
-
-
Anton Shestakov authored
This patch simply allows rewriteutil.rewrite() to work with commits with multiple parents (i.e. merges). That function is used in such commands as fold, metaedit, touch, rewind. The issue 4561 is marked as easy, the limitation is called unnecessary, no tests fail after this change. What can go wrong.
-
- 04 Jul, 2019 1 commit
-
-
Pierre-Yves David authored
-
- 25 Jun, 2019 1 commit
-
-
Sushil Khanchi authored
To provide some context, when topics are in play the branchmap cache we store contains the branch info of a rev as "branch:topic" format IIUC. Assuming that is right, now in present code we don't actually cover this part that "when looking for branch heads where we also have active topic we should look for branch='branch_name:topic' instead". And we get wrong branch heads as a result. This patch make sure that we pass right candidate to find branch heads using branchmap.branchheads() by overriding the localrepo.branchheads() Changes in test file reflect the fixed behavior.
-
- 01 Jul, 2019 1 commit
-
-
Sushil Khanchi authored
Let's not update to any revision when working directory parent is not related to the revision being pruned. Changes in test file demonstrate the fixed behaviour.
-
- 16 Jun, 2019 1 commit
-
-
Sushil Khanchi authored
Now we will go to _handlenotrouble() (which prints messages about no revs to solve) only when there is no troubled revs and working dir parent is not obsolete. This change also saves us from an issue which was about looking into the revset (smartset contains troubled revs to solve) when a rev from the revset gets hidden. This happens in the case when our wdir parent is obsolete. After resolving obswdir parent we were looking into the revset to check if there is any troubled revs to solve but we should have performed this check before performing the obswdir resolution. Changes in test file reflect this fixed behaviour.
-
- 14 Jun, 2019 1 commit
-
-
Anton Shestakov authored
This way pickstate file will indicate that unfinished pick command needs to be dealt with (--continue or --abort) before modifying the repo. Otherwise it would be e.g. possible to commit during an interrupted pick and that's not expected.
-
- 18 Jun, 2019 1 commit
-
-
Anton Shestakov authored
When continuing to solve an orphan that created no changes (i.e. clean wdir), _completeorphan() used to create an obsmarker that said that the result of that orphan evolution is the currently checked out changeset. That's not a correct obsmarker, because all of the orphan's changes were dropped and so it had no effect on the currently checked out changeset. This is an issue that has only existed when --continu'ing evolve, that's why the fix touches _completeorphan(), but not _solveunstable(). This fix is adapted from a similar "if node is None" block in _finalizerelocate().
-
- 07 Jun, 2019 1 commit
-
-
Anton Shestakov authored
At its core, pick is a pretty straightforward and well-behaving command, it uses functions already in core hg, it checks that wdir is clean and that changeset to pick is not public, it checks if there happen to be merge conflicts and can be --continue'd later, etc. It is very similar to graft in core (it also uses mergemod.graft function), but it obsoletes the original changeset. However, graft does not experience this incorrect behavior from issue 6037. What happens in the test case for this issue when we pick a revision that touches both "a" and "b": mergemod.graft() takes the original changeset and tries to apply it to the wdir, which results in "b" being marked as newly added and ready to be committed, "a" updated with the new content and being marked as modified, but "a" also has conflicts. Pick correctly notices this and saves its state before asking for user intervention. So far so good. However, when the command raises InterventionRequired to print a user-facing message and exit while being wrapped in repo.transaction() context manager, the latter partially undoes what mergemod.graft() did: it unmarks "b" as added. And when user continues pick, "b" is therefore not tracked and is not included in the resulting commit. The transaction is not useful here, because it doesn't touch wdir (it's still dirty), it doesn't remove pickstate (and other commands will refuse to work until pick --abort or --continue), it just makes "b" untracked. The solution is to use repo.transaction() only to wrap code that writes data to hg store in the final stages of the command after all checks have passed and is not expected to fail on trivial cases like merge conflicts. For example, committing the picked changeset. But since pick uses repo.commit() for that, and because that function already uses a transaction, wrapping it in another transaction doesn't make sense.
-
- 08 Jun, 2019 1 commit
-
-
Anton Shestakov authored
-
- 06 Jun, 2019 3 commits
-
-
Anton Shestakov authored
And it's worth making the suggestion an actual hint.
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-
- 27 May, 2019 1 commit
-
-
Pierre-Yves David authored
The option is pretty basic but it can be used as base to build larger feature. The main target for going in this direction is to be able to distinct between user that are "simple contributors" pushing topic for review and the "maintainers" or "automation" that can publish changesets.
-
- 26 May, 2019 1 commit
-
-
Pierre-Yves David authored
The protocol has been superseeded by stablerange for a long time. It is untested and more and more buggy. Since this is deprecated experimental code in an experimental code, we drop it. We keep the underlying computation and debug command around for now. They might still be useful to looks at repositories
-
- 27 May, 2019 1 commit
-
-
Pierre-Yves David authored
-
- 27 Apr, 2019 1 commit
-
-
Anton Shestakov authored
-
- 26 Apr, 2019 1 commit
-
-
Pulkit Goyal authored
When topic extension is enabled and we have some cset whose hash is `b1234`, topic extension thinks that we are accessing 1234 cset in current branch stack. However that's not the case generally. Also I am not sure many people use this bxxx thing. Since we have a generic sxxx way to access csets, let's drop support for accessing csets using bxx which leads to bad behavior. Looking at the tests, we don't show bxxx in hg stack output anymore. I update the test to use sxxx instead of bxxxx.
-
- 19 Apr, 2019 1 commit
-
-
Martin von Zweigbergk authored
This speeds up `hg evolve --all` of a stack of 24 commits in the hg repo from 11.5s to 3.7s (3x). As can be seen in the tests, it also avoid some warnings about transiently unstable commits.
-
- 10 Apr, 2019 1 commit
-
-
Anton Shestakov authored
-
- 24 Apr, 2019 3 commits
-
-
Anton Shestakov authored
allopt defaults to None to avoid touching _checkevolveopts(). If it were True by default, that function would always act like the flag was provided by user, and so using --abort, --stop, --continue or --rev on their own would never work (hg evolve will complain that you cannot specify both --rev and --all). A notable change in tests is "no troubled changesets" line that gets printed when using `hg evolve` to update to the evolved successor of working directory parent, but there were no actual instabilities.
-
Anton Shestakov authored
-
Pierre-Yves David authored
VErsion 8.5.0 got released
-
- 23 Apr, 2019 2 commits
-
-
Pierre-Yves David authored
-
Martin von Zweigbergk authored
Since d1aab9d82f5b (evolve: adapt for deprecated ui.progress(), 2019-01-14), the "item", "units" and "total" are all set to default values. The last one is especially bad since it results in a "spinner" instead of a progress bar.
-
- 12 Mar, 2019 1 commit
-
-
Martin von Zweigbergk authored
Iterating over the manifest when tree manifests and narrowness is in play produces entries for paths outside the narrowspec that represent trees. For example, if the tests/ directory of the hg repo was not in the narrowspec (and the hg repo was using tree manifests, which it doesn't), then there would be a "tests/" entry in the manifest. The merge code deals with some of these cases. For example, it's valid to do a merge if only the local side changes directories outside the narrowspec. That allows rebasing a local commit onto a public commit that had changes to the excluded paths to work. However, _resolvephasedivergent() was iterating of the manifests, which resulted in crashes for some of our users when they tried to resolve phase-divergent commits (actually content-divergent commits that became phase-divergent after the intermediate rebase). We can fix that by relying on merge.update(), since that already handles this case. [This re-install a changeset backed out for compatibility reason]
-
- 23 Apr, 2019 2 commits
-
-
Pierre-Yves David authored
-
Pierre-Yves David authored
That changesets breaks 4.4 compat. We will reinstall it for the next version.
-
- 19 Apr, 2019 1 commit
-
-
Sushil Khanchi authored
-
- 18 Apr, 2019 1 commit
-
-
Pierre-Yves David authored
-
- 17 Apr, 2019 1 commit
-
-
Pierre-Yves David authored
-
- 12 Apr, 2019 1 commit
-
-
Pierre-Yves David authored
-