Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 29 Jul 2019 11:40:16 +0200] rev 4769
test-compat: merge mercurial-5.0 into mercurial-4.9
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 29 Jul 2019 11:40:14 +0200] rev 4768
test-compat: merge stable into mercurial-5.0
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 Jul 2019 18:29:59 +0200] rev 4767
test-compat: opening test compatibility branch for mercurial 5.0
5.1 has a release candidate.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 29 Jul 2019 12:45:29 +0200] rev 4766
test-compat: close branch for mercurial-4.0
We dropped compatibility in 9.0.0
Kyle Lippincott <spectral@google.com> [Thu, 25 Jul 2019 09:59:41 -0700] rev 4765
prune: fix small grammatical issues in help text
Anton Shestakov <av6@dwimlabs.net> [Fri, 19 Jul 2019 17:40:45 +0800] rev 4764
docs: update evolve-faq.rst with new prune flag and proper vocabulary
Also strip trailing newlines.
Anton Shestakov <av6@dwimlabs.net> [Fri, 19 Jul 2019 17:25:29 +0800] rev 4763
prune: spell --successor flag without any unnecessary shortcuts
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.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 Jul 2019 12:47:37 -0700] rev 4762
py3: redefine "troublecategories" in evolve as a dict
We'll want to the keys to be bytes and the values to be unicode on
py3. Having it defined as a dict makes that easier (instead of
converting between the types with e.g. pycompat.sysbytes()). It was
kind of ugly to convert between the forms by stripping '_' from the
string anyway.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Jul 2019 08:11:39 -0700] rev 4761
py3: store to __doc__ as str (unicode on py3)
Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 Jul 2019 12:47:20 -0700] rev 4760
py3: also catch ImportError when relative import fails
Python 3 apparently raises an ImportError where Python 2 raised a
ValueError.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Jul 2019 10:26:41 -0700] rev 4759
py3: convert exceptions to bytes using pycompat.bytestr()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 16:00:25 -0700] rev 4758
py3: use "%d" for formatting integers
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Jul 2019 08:17:25 -0700] rev 4757
py3: avoid "%s" for formatting None
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Jul 2019 08:16:30 -0700] rev 4756
py3: use "%f" for formatting floating point number
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 15:30:43 -0700] rev 4755
py3: fix progress() functions to not use "%s" with int
Python3 doesn't support "%s" with int arguments (and not with None
arguments either, which this code was also using).
Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 Jul 2019 11:45:37 -0700] rev 4754
py3: make random topic name generation consistent across py2/py3
random.choice() (and others based on random.randint()) changed between
py2 and py3 without a way to get the py2 behavior. However,
random.random() did not change, so we can re-implement random.choice()
based on that.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Jul 2019 17:02:35 -0700] rev 4753
py3: convert str to bytes before passing to core exception
Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 Jul 2019 11:03:09 -0700] rev 4752
py3: convert opts keys to bytes before passing to core APIs
kevpeng@google.com [Fri, 14 Jun 2019 18:44:43 -0700] rev 4751
evolve: further clarify when update is performed
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 15:30:40 -0700] rev 4750
py3: avoid comparing int and None
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 21:48:37 -0700] rev 4749
py3: avoid "%r" for list of byte strings, which produces b'' on py3
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 21:48:02 -0700] rev 4748
py3: avoid "%r" for byte string, which produces b'' on py3
Replaced by "'%s'", which I think is clearer anyway.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 14:46:17 -0700] rev 4747
py3: replace str(ctx) by bytes(ctx)
These are all for messages to the user and we don't want unicode for
that.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 16:04:17 -0700] rev 4746
py3: use inspect.signature() instead of inspect.getargspec() on py3
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Jul 2019 10:56:42 -0700] rev 4745
py3: use array.array.{to,from}bytes() on py3
array.array.{to,from}string() still exists on py3, but they're
deprecated and generate warnings.
I've put the compat function in compat.pt for now. We can move into a
dedicated pycompat.py if we end up with a lot of py3 compat stuff.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 14:31:32 -0700] rev 4744
py3: config values can be bytes, but never unicode
Martin von Zweigbergk <martinvonz@google.com> [Sat, 13 Jul 2019 00:17:03 -0700] rev 4743
py3: call branchmap.items() on py3 and continue to call iteritems() on py2
Mercurial's source transformer also replaces the 'def iteritems(' in
branchmap by 'def items(', so we need to call whichever version is
there.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Jul 2019 23:24:04 -0700] rev 4742
py3: switch from iteritems() to items() in the topics extension
The only remaining iteritems() call is on branchmap. That will be
dealt with in the next patch.
Martin von Zweigbergk <martinvonz@google.com> [Sun, 14 Jul 2019 22:34:36 -0700] rev 4741
py3: filter() now returns a generator, so wrap when we need a list
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Jul 2019 23:19:50 -0700] rev 4740
py3: don't depend on map() iterating over its input
map(some_generator()) in py2 returns a list, while in py3 it returns a
generator, so the passed-in generator won't be called unless the
returned one is.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 16:49:01 -0700] rev 4739
py3: implement __bool__ in addition to __nonzero__
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 14:21:23 -0700] rev 4738
py3: replace iter.next() by next(iter)
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 14:16:48 -0700] rev 4737
py3: replace xrange() by range()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 12:19:49 -0700] rev 4736
py3: read sqlite3 data as bytes
The py2 and py3 docs ([1] and [2]) disagree how to get bytes output,
but it seems obvious that this should be "bytes" to be compatible with
both.
[1] https://docs.python.org/2/library/sqlite3.html#sqlite3.Connection.text_factory
[2] https://docs.python.org/3/library/sqlite3.html#sqlite3.Connection.text_factory
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 12:11:43 -0700] rev 4735
py3: sqlite3.connect() expects str arguments
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Jul 2019 23:00:11 -0700] rev 4734
cleanup: remove check only needed for hg versions before 4.4
ui.edit() has had the "action" argument since 6e6452bc441d (editor:
use an unambiguous path suffix for editor files, 2017-08-30), which
was first released in hg version 4.4. Since we support only versions
higher than 4.5, we can drop this check.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Jul 2019 08:20:24 -0700] rev 4733
split: remove an unnecessary (and confusingly typed) fallback revision
`opts.get('rev') or '.'` is either a list of strings or just a
string. It happened to work because `'.'[0] == '.'` on Python 2, but
it won't work on Python 3 (for byte strings). The fallback value
wasn't even needed (it was also set just after), so let's just remove
it.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 22:23:32 -0700] rev 4732
evolve: rename variable "children" to "child" where it's clearly singular
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 16:24:13 -0700] rev 4731
evolve: remove some unused variables
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Jul 2019 09:38:42 -0700] rev 4730
py3: back out 23323092f0a7
D6623 has now been accepted in Mercurial (commit 83666f011679), so
evolve commit 23323092f0a7 (py3: convert _origdoc to sysstr to match
__doc__, 2019-07-09) is not longer needed.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 Jul 2019 18:06:14 +0200] rev 4729
branching: merge with stable
Sushil khanchi <sushilkhanchi97@gmail.com> [Wed, 17 Jul 2019 17:58:44 +0200] rev 4728
touch: fix the inconsistent behavior of divergence catching logic (issue6107)
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.
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 29 Jun 2019 14:28:35 +0530] rev 4727
touch: add test which shows touch can fail to warn about divergence
Sushil khanchi <sushilkhanchi97@gmail.com> [Wed, 17 Jul 2019 17:58:40 +0200] rev 4726
touch: clarify some inline documentation
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Jul 2019 16:53:07 -0700] rev 4725
tests: update output for new branch cache messsages from Mercurial
This makes tests pass again after Mercurial commit c7d236b55a3e (py3:
fix formatting of branchmap log messages with repo.filtername=None,
2019-07-14).
CORE-TEST-OUTPUT-UPDATE: c7d236b55a3e
Anton Shestakov <av6@dwimlabs.net> [Sat, 13 Jul 2019 18:22:34 +0800] rev 4724
metaedit: allow operations on merge commits with some conditions
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.
Anton Shestakov <av6@dwimlabs.net> [Thu, 11 Jul 2019 18:07:03 +0800] rev 4723
fold: allow operations on merge commits with some conditions
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 <av6@dwimlabs.net> [Thu, 11 Jul 2019 17:04:08 +0800] rev 4722
rewind: make sure merge commits include files from p1 and p2
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.
Anton Shestakov <av6@dwimlabs.net> [Wed, 10 Jul 2019 18:16:38 +0800] rev 4721
touch: make sure merge commits include files from p1 and p2
Otherwise touching 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.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Jul 2019 10:56:42 -0700] rev 4720
py3: make `import hgext3rd.evolve` work
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Jul 2019 10:56:42 -0700] rev 4719
py3: use bytes for template keyword registrations
This makes `import hgext3rd.topic` work.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Jul 2019 10:56:42 -0700] rev 4718
py3: convert _origdoc to sysstr to match __doc__
It's currently stored as bytes by core, so we need to convert it to
match Python's expected type for __doc__. This patch can be dropped if
D6623 gets accepted.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Jul 2019 10:56:42 -0700] rev 4717
py3: use bytes for revset predicate registrations
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Jul 2019 10:56:42 -0700] rev 4716
py3: use bytes for wireprotocol command registration
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Jul 2019 10:56:42 -0700] rev 4715
py3: use byte strings for @command registrations
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Jul 2019 11:13:47 -0700] rev 4714
py3: switch from iteritems() to items()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Jul 2019 11:37:29 -0700] rev 4713
py3: make metadata values be byte strings as Mercurial expects
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Jul 2019 21:49:37 -0700] rev 4712
tests: update output for shorted prompts from Mercurial
This makes tests pass again after Mercurial commits f802a75da585 (patch: use a
short, fixed-size message for last line of prompt (issue6158), 2019-06-20).
CORE-TEST-OUTPUT-UPDATE: f802a75da585
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 11 Jul 2019 10:07:39 +0200] rev 4711
tests: update output for shorted prompts from Mercurial
This makes tests pass again after Mercurial commits 4764e8436b2a
(filemerge: make last line of prompts <40 english chars (issue6158),
2019-06-20)
CORE-TEST-OUTPUT-UPDATE: 4764e8436b2a
Anton Shestakov <av6@dwimlabs.net> [Tue, 09 Jul 2019 17:08:34 +0800] rev 4710
rewriteutil: allow rewriting merge commits (issue4561)
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.
Anton Shestakov <av6@dwimlabs.net> [Tue, 09 Jul 2019 17:02:44 +0800] rev 4709
tests: show what happens when trying to hg touch a merge commit
kevpeng@google.com [Thu, 04 Jul 2019 17:32:58 +0200] rev 4708
evolve: further clarify that update is performed only when requested
Text further modified by Pierre-Yves David and Anton Shestakov.
Sushil khanchi <sushilkhanchi97@gmail.com> [Fri, 14 Jun 2019 22:46:58 +0530] rev 4707
touch: let's not use util.acceptintervention() as it's not required
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 04 Jul 2019 16:55:57 +0200] rev 4706
branching: merge with stable
Sushil khanchi <sushilkhanchi97@gmail.com> [Wed, 26 Jun 2019 21:11:25 +0530] rev 4705
evolve: use right value for branch name when finding branch heads
subbranch already formatted as "branchname:topicname", again appending it
with ":topicname" doesn't not make sense.
It's a little bit surprising that no tests fails though.
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 25 Jun 2019 21:54:22 +0530] rev 4704
evolve: fix confusion in branch heads checking logic when topic in play
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.
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 14 Apr 2019 12:55:46 +0530] rev 4703
topic: add tests to demonstrate topic confuses the branchhead checking logic
While topics are in play, we store the branchheads (which has a topic)
in "branchname:topicname" format. After digging into it I found that
even in the case when we should have branch heads for "bname:tname"
we get heads for "bname".
The tests output reflect the confusion in branch head checking logic.
Next patch will be fixing the problem.
Sushil khanchi <sushilkhanchi97@gmail.com> [Mon, 01 Jul 2019 19:15:57 +0530] rev 4702
evolve: fix the inconsistent behaviour of prune (issue6137)
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.
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 02 Jul 2019 21:00:46 +0530] rev 4701
prune: add tests to demonstrate issue6137
Here we can see that prune updates off to the parent revision
even when the pruned revision wasn't related with the working
directory parent.
A follow-up patch will fix this.
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 30 Jun 2019 23:50:57 +0530] rev 4700
compat: fix `setupevolveunfinished` for upstream
Anton Shestakov <av6@dwimlabs.net> [Sat, 29 Jun 2019 18:21:57 +0800] rev 4699
prune: update to the successor of wdir also with --pair/--biject (issue6142)
When prune is used with --pair flag, we can also update to the successor of
working directory parent.
No need to check len(sucs) or len(precs) here because there's a check for that
earlier in the code (it's a requirement of biject).
The tests are now demonstrate the correct behavior: when rev 14 was pruned with
12 as its successor, the bookmark that was on 14 was moved to 12. That bookmark
was also activated (even before this patch).
Anton Shestakov <av6@dwimlabs.net> [Sat, 22 Jun 2019 18:37:21 +0800] rev 4698
tests: demonstrate prune --pair not moving bookmark correctly
After `mkcommit n2` line the bookmark is on the correct changeset, but when we
prune --pair the two newly created changesets (revs 13 and 14), the bookmark
gets moved to their ancestor (rev 0). Instead, it should've moved to the last
of their successors (rev 12).
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 02 Jul 2019 10:17:42 +0200] rev 4697
oops: backed out changeset 7ac40b4ea24c
Anton requested some changes on it.
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 30 Jun 2019 23:50:57 +0530] rev 4696
compat: fix `setupevolveunfinished` for upstream
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 16 Jun 2019 23:39:55 +0530] rev 4695
evolve: fix the code flow pattern of solving obswdir par and troubled revs
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.
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 09 Jun 2019 12:07:08 +0530] rev 4694
evolve: refactor for consistent behavior of evolve when wdp is obsolete
This patch make sure that when working directory parent is obsolete
`hg evolve` and `hg evolve --all` don't behave differently.
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 15 Jun 2019 17:17:19 +0530] rev 4693
evolve: backout 3027005c42c3 to reintroduce a bug for right fix
This patch backout 3027005c42c3 as it was accepted by mistake
while it was being "in-discussion" state.
Anton Shestakov <av6@dwimlabs.net> [Fri, 14 Jun 2019 18:17:03 +0800] rev 4692
pick: register pickstate as an unfinished state
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.
Anton Shestakov <av6@dwimlabs.net> [Fri, 14 Jun 2019 18:14:57 +0800] rev 4691
pick: rename variable for unfinishedstates
Anton Shestakov <av6@dwimlabs.net> [Fri, 14 Jun 2019 18:26:24 +0800] rev 4690
pick: actually delete pickstate if --abort is given
Makes pick to be, uh, actually aborted.
Anton Shestakov <av6@dwimlabs.net> [Tue, 18 Jun 2019 17:17:31 +0800] rev 4689
evolve: orphans that evolve into nothing don't need successors (issue5967)
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().
Anton Shestakov <av6@dwimlabs.net> [Sat, 22 Dec 2018 18:31:32 +0800] rev 4688
tests: demonstrate obsmarker creation after discarding conflicting changes
Continued evolve creates an incorrect obsmarker that says 2 is a successor of
1. It's incorrect because 1 was dropped as it created no changes to commit
(after conflict resolution that discarded its changes).
If evolve does the same thing in one go (e.g. just by using --tool :local and
without subsequent need to continue) the obsmarker is correct.
Anton Shestakov <av6@dwimlabs.net> [Fri, 07 Jun 2019 18:14:48 +0800] rev 4687
pick: remove transaction on the whole command (issue6037)
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.
Anton Shestakov <av6@dwimlabs.net> [Sun, 23 Dec 2018 01:02:36 +0800] rev 4686
tests: demonstrate hg pick forgetting files after conflicts
This test currently passes to show that pick is behaving incorrectly.
Anton Shestakov <av6@dwimlabs.net> [Thu, 13 Jun 2019 13:27:26 +0800] rev 4685
packaging: follow hg's supported python version (>= 2.7)
"Mercurial 4.3 and newer require Python 2.7." (From
https://www.mercurial-scm.org/wiki/SupportedPythonVersions)
Also add X- prefix, because that's the correct form, apparently.
This line can also be removed in future, since "When Debian supported multiple
Python versions, X-Python-Version was used, but it is obsolete now as no
supported Debian release supports anything other than python2.7." (From
https://wiki.debian.org/Python/LibraryStyleGuide)
That page also mentions "X-Python3-Version".
Anton Shestakov <av6@dwimlabs.net> [Thu, 13 Jun 2019 13:19:44 +0800] rev 4684
packaging: require hg 4.5 also for usage, not just for building
Philippe Pepiot <philippe.pepiot@logilab.fr> [Tue, 11 Jun 2019 10:04:11 +0200] rev 4683
packaging: require mercurial >= 4.5
Otherwise building the doc package fails with:
(third party extension evolve requires version 4.5 or newer of Mercurial; disabling)
Exception occurred:
File "/usr/lib/python2.7/dist-packages/mercurial/help.py", line 624, in help_
raise error.Abort(msg, hint=hint)
Abort: no such help topic: evolve
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 08 Jun 2019 16:03:05 +0530] rev 4682
evolve: clarify why returning by adding inline doc
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 08 Jun 2019 15:59:31 +0530] rev 4681
evolve: move a code block to have right value in has_some_val
Because of this we were having wrong value of has_some_val and
had some buggy behavior which is being fixed by this patch.
Fixed behavior is reflected by the changes in test file.
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 27 Apr 2019 13:09:34 +0530] rev 4680
topic: add tests which demonstrate topicset failure of FilteredRepoLookupError
When topics are used, it fails to find hidden revs mentioned in a revset as
we are not using unfiltered view of repo. Next patch will fix it.
Anton Shestakov <av6@dwimlabs.net> [Sat, 08 Jun 2019 16:57:34 +0800] rev 4679
pick: reduce configoverride() scope
Merge tool is only needed for merge.graft() (it's what graft in core hg does),
so let's make the scope of the ui.configoverride() narrower.
Anton Shestakov <av6@dwimlabs.net> [Sat, 08 Jun 2019 16:09:37 +0800] rev 4678
evolve: correct action verb in a message
Anton Shestakov <av6@dwimlabs.net> [Sat, 08 Jun 2019 16:06:24 +0800] rev 4677
evolve: internationalize a message
This exact message was already wrapped in _() in the same file, just not here.
Anton Shestakov <av6@dwimlabs.net> [Thu, 06 Jun 2019 17:37:42 +0800] rev 4676
evolvecmd: the proper way to deal with conflicts is to resolve them
And it's worth making the suggestion an actual hint.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 17:56:44 +0200] rev 4675
test-compat: merge mercurial-4.5 into mercurial-4.4
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 17:46:06 +0200] rev 4674
test-compat: merge mercurial-4.6 into mercurial-4.5
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 17:45:45 +0200] rev 4673
test-compat: merge mercurial-4.7 into mercurial-4.6
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 17:42:50 +0200] rev 4672
test-compat: merge mercurial-4.8 into mercurial-4.7
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 17:39:32 +0200] rev 4671
test-compat: merge mercurial-4.9 into mercurial-4.8
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 17:38:32 +0200] rev 4670
test-compat: merge stable into mercurial-4.9
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 07 Jun 2019 02:25:02 +0200] rev 4669
branching: merge with 9.0.0
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 07 Jun 2019 02:24:08 +0200] rev 4668
branching: merge back with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 07 Jun 2019 02:22:05 +0200] rev 4667
packaging: mark as development versions
This help to distinct official release from in progress work.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 07 Jun 2019 02:15:50 +0200] rev 4666
Added tag 9.0.0 for changeset 756db65030c6
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 06 Jun 2019 14:24:19 +0200] rev 4665
packaging: prepare release 9.0.0
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 06 Jun 2019 14:32:25 +0200] rev 4664
doc: clarify the status of configuration of the obshashrange protocol
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 06 Jun 2019 13:26:44 +0200] rev 4663
changelog: add various missing bits
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 19:45:35 +0200] rev 4662
templatekw: keep compatibility with Mercurial 4.5
This is simple enough to do.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 17:21:45 +0200] rev 4661
test: adjust output to stable branch
We are about to make a release.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 04 Jun 2019 11:08:44 +0200] rev 4660
branching: merge with stable
Joerg Sonnenberger <joerg@bec.de> [Sat, 01 Jun 2019 02:30:14 +0200] rev 4659
templates: don't alias keywords directly
Putting the same function twice in the registry results in duplicate
doc strings and therefore confusing "hg help template" output.
Anton Shestakov <av6@dwimlabs.net> [Tue, 28 May 2019 16:46:18 +0800] rev 4658
stack: remove 'topic.' prefix from colors/labels
Stack is related to topics, sure, but it is also good enough to be recognized
on its own.
Anton Shestakov <av6@dwimlabs.net> [Sat, 18 May 2019 16:56:47 +0800] rev 4657
stack: handle hash sizes when --debug flag is provided
Since showstack() now uses fm.hexfunc() for node hashes, which depends on
ui.debugflag, we should handle situations when hashes are full-sized as well.
Anton Shestakov <av6@dwimlabs.net> [Fri, 17 May 2019 17:50:25 +0800] rev 4656
stack: always provide (full) node hash to non-default --template
Anton Shestakov <av6@dwimlabs.net> [Fri, 17 May 2019 17:42:06 +0800] rev 4655
stack: remove unnecessary prefix from stack output with non-default --template
"index" template keyword already exists (the current iteration of the loop), so
"stack_index" it is. It follows the same convention as other template keywords,
such as "files_added", "line_number", etc.
Anton Shestakov <av6@dwimlabs.net> [Fri, 17 May 2019 17:59:58 +0800] rev 4654
stack: provide context to formatter with non-default --template
This allows using template keywords that we don't explicitly provide to the
formatter, e.g. rev, branch and topic.
Anton Shestakov <av6@dwimlabs.net> [Sat, 11 May 2019 17:14:32 +0800] rev 4653
stack: leverage labelsgen() to produce all needed labels for fm.write()
Anton Shestakov <av6@dwimlabs.net> [Wed, 08 May 2019 16:00:34 +0800] rev 4652
stack: check if stack is empty more pythonically
Anton Shestakov <av6@dwimlabs.net> [Wed, 08 May 2019 15:57:54 +0800] rev 4651
stack: implement __bool__ and __nonzero__
Anton Shestakov <av6@dwimlabs.net> [Sun, 05 May 2019 17:39:46 +0800] rev 4650
stack: get stack data directly from stack and remove stackdata()
stackdata function began its life in 137f8b04901e as a proto-stack: it computed
stack revs on its own and only had one property to return, "changesetcount".
Later it started to prepare and return more properties, but since b933a8068c17
it was computing revs using a getstack function. And then finally in
17749d9d3968 it started to rely on stack class entirely.
It was a good function, but now, when all the logic it provided was factored
into stack class, I'd say it's finally time for it to be put to rest.