Mads Kiilerich <madski@unity3d.com> [Sat, 16 Nov 2013 15:46:29 -0500] rev 20251
tests: introduce test for rebasing on named branches with closed heads
Mads Kiilerich <madski@unity3d.com> [Sat, 16 Nov 2013 15:46:29 -0500] rev 20250
rebase: remove old code for handling empty rebaseset
Mads Kiilerich <madski@unity3d.com> [Sun, 17 Nov 2013 18:21:58 -0500] rev 20249
rebase: improve error message for --base being empty or causing emptiness
Before it just said 'nothing to rebase'.
Now 'if "base" is an empty set:
abort: empty "base" revision set - can't compute rebase set
If the set of changesets to rebase can't be found from "base", it will fail as
before but with more explanation of what the problem was.
The name of the "base" option is not obvious - it is more like "samples
identifying the branch to rebase". The error messages for problems with the
specified "base" value will use that term and might thus also not be obvious,
but at least they are consistent with the option name. The name "base" will not
be used if the base only was specified implicitly as the working directory
parent.
Mads Kiilerich <madski@unity3d.com> [Sun, 17 Nov 2013 18:21:58 -0500] rev 20248
rebase: improve error message for empty --source set
Before, it just said 'nothing to rebase' in this case. Now, it aborts
mentioning the reason: 'empty "source" revision set'.
Specifying revisions that cannot be rebased is a 'soft' error, but specifying
an empty set deserves an abort that explains exactly what the problem is.
Mads Kiilerich <madski@unity3d.com> [Sat, 16 Nov 2013 15:46:29 -0500] rev 20247
rebase: improve error message for empty --rev set
Before, it just said 'nothing to rebase' in this case. Now, it aborts
mentioning the reason: 'empty "rev" revision set'.
Specifying revisions that cannot be rebased is a 'soft' error, but specifying
an empty set deserves an abort that explains exactly what the problem is.
Mads Kiilerich <madski@unity3d.com> [Sun, 17 Nov 2013 18:21:58 -0500] rev 20246
rebase: test for empty dest revision
Mads Kiilerich <madski@unity3d.com> [Thu, 21 Nov 2013 15:17:18 -0500] rev 20245
help: branch names primarily denote the tipmost unclosed branch head
Was the behavior correct and the description wrong so it should be updated as
in this patch? Or should the code work as the documentation says?
Both ways could make some sense ... but none of them are obvious in all cases.
One place where it currently cause problems is when the current revision has
another branch head that is closer to tip but closed. 'hg rebase' refuses to
rebase to that as it only see the tip-most unclosed branch head which is the
current revision.
/me kind of likes named branches, but no so much how branch closing works ...