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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip