Sun, 16 Feb 2014 23:36:02 +0100 run-tests: fixed warn detection on detecting warn only for lines
Simon Heimberg <simohe@besonet.ch> [Sun, 16 Feb 2014 23:36:02 +0100] rev 20600
run-tests: fixed warn detection on detecting warn only for lines The state "warned" was reported too often. The main problem was that "False == 0" is true in python. Therefore use an empty string instead of 0 for reporting warn only for a line. The other problem is fixed in the next patch.
Thu, 27 Feb 2014 20:01:28 -0800 obsolete: extract encoding of marker for pushkey from the list key function
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 27 Feb 2014 20:01:28 -0800] rev 20599
obsolete: extract encoding of marker for pushkey from the list key function We now have a function taking a list and marker and returning an encoded version. This will allow obsolescence marker exchange experimentation to easily pushkey-encode markers to be pushed after selection.
Wed, 19 Feb 2014 13:46:49 -0800 solaris: diff -u emits "No differences encountered"
Danek Duvall <danek.duvall@oracle.com> [Wed, 19 Feb 2014 13:46:49 -0800] rev 20598
solaris: diff -u emits "No differences encountered" Solaris diff -u isn't silent when two files are identical, and tests that don't account for that will fail. Fix those tests, and introduce a check that prevents reintroduction.
Fri, 14 Feb 2014 00:34:20 +0100 rebase: do not raise an UnboundLocalError when called wrong (issue4106)
Simon Heimberg <simohe@besonet.ch> [Fri, 14 Feb 2014 00:34:20 +0100] rev 20597
rebase: do not raise an UnboundLocalError when called wrong (issue4106) When the base is not found, we should not raise a traceback about a not defined variable. This hides the real problem: the function rebasenode was (probably) called wrong. An AssertionError is raised to highlight that the caller of the function did something wrong. An alternative approach is to only assign None to the variable "base" and let the merge mechanism raise an abort message. This was the behaviour for this case before ad9db007656f. But the only known case for this problem is when an extension calls this function wrong. An AssertionError makes this clearer than an abort message. When a different case is detected, the behaviour can be improved then.
Thu, 27 Feb 2014 19:56:36 -0800 exchange: fix docs for pulloperation
Siddharth Agarwal <sid0@fb.com> [Thu, 27 Feb 2014 19:56:36 -0800] rev 20596
exchange: fix docs for pulloperation 'remote' is actually the remote, not the repo one is pulling into. This confused me quite a bit.
Thu, 27 Feb 2014 18:57:03 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 27 Feb 2014 18:57:03 -0600] rev 20595
merge with stable
Tue, 25 Feb 2014 18:45:01 -0800 resolve: use "other" changeset from merge state (issue4163) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 25 Feb 2014 18:45:01 -0800] rev 20594
resolve: use "other" changeset from merge state (issue4163) We can use the "other" data from the recorded merge state instead of inferring what the other could be from working copy parent. This will allow resolve to fulfil its duty even when the second parent have been dropped. Most direct benefit is fixing a regression in backout.
Tue, 25 Feb 2014 18:54:47 -0800 merge: add "other" file node in the merge state file stable
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 25 Feb 2014 18:54:47 -0800] rev 20593
merge: add "other" file node in the merge state file This data is mostly redundant with the "other" changeset node (+ other changeset file path). However, more data never hurt. The old format do not store it so this require some dancing to add and remove it on demand.
Thu, 27 Feb 2014 14:14:57 -0800 merge: infer the "other" changeset when falling back to v1 format stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 27 Feb 2014 14:14:57 -0800] rev 20592
merge: infer the "other" changeset when falling back to v1 format When we have to fallback to the old version of the file, we infer the "other" from current working directory parent. The same way it is currently done in the resolve command. This is know to have shortcoming… but we cannot do better from the data contained in the old file format. This is actually the motivation to add this new file format.
Tue, 25 Feb 2014 18:42:11 -0800 merge: record the "other" node in merge state stable
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 25 Feb 2014 18:42:11 -0800] rev 20591
merge: record the "other" node in merge state We need to record the merge we were merging with. This solve multiple bug with resolve when dropping the second parent after a merge. This happen a lot when doing special merge (overriding the ancestor). Backout, shelve, rebase, etc. can takes advantage of it. This changeset just add the information in the merge state. We'll use it in the resolve process in a later changeset.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip