comparison tests/test-pick.t @ 4891:a9929dd36405 stable

pick: don't create any successors when there were no changes (issue6093) For example, when a changeset that user is trying to pick was already grafted or rebased (and no obsmarkers were created), pick will naturally say that there's no changes to commit and will not create the new commit. In that case it should not mark any changeset as a successor of the picked changeset, because the actual file changes were already there before picking. Technically, pick could (and did before this patch) mark the wdir commit as a successor of picked changeset (may be useful in the most trivial cases when e.g. wdir is a graft of the required change), but there are cases when the picked change is introduced in an ancestor of wdir, or even in multiple ancestors piece by piece. Pick definitely shouldn't be trying to guess something this complicated, so with this patch it always marks the picked change as pruned if it gave no changes to commit.
author Anton Shestakov <av6@dwimlabs.net>
date Mon, 07 Oct 2019 14:38:56 +0700
parents fa534a8c5863
children 5113b38cb677
comparison
equal deleted inserted replaced
4890:a8fa397795c1 4891:a9929dd36405
170 | 170 |
171 o 3:8e224524cd09 add x 171 o 3:8e224524cd09 add x
172 | 172 |
173 o 0:1f0dee641bb7 add a 173 o 0:1f0dee641bb7 add a
174 174
175
176 there were no changes to commit, so there shouldn't be any predecessors of 6,
177 and 2 should say it was pruned (issue6093)
178
179 $ hg olog --all --hidden -r 2+6
180 x 4538525df7e2 (2) add c
181 pruned using pick by test (Thu Jan 01 00:00:00 1970 +0000)
182
183 @ c4636a81ebeb (6) add c
184
185
175 interrupted pick 186 interrupted pick
176 187
177 $ hg up d46dc301d92f 188 $ hg up d46dc301d92f
178 0 files updated, 0 files merged, 2 files removed, 0 files unresolved 189 0 files updated, 0 files merged, 2 files removed, 0 files unresolved
179 $ echo foo > c 190 $ echo foo > c