On Sat, Dec 29, 2012 at 10:29 PM, Mike Meyer <m...@mired.org> wrote:
> Nico Williams <n...@cryptonector.com> wrote:
>>You missed my proposal that a fossil rebase operation always copy the
>>branch being rebased and rebase that copy. It was in my very first
>>post on this thread:
>
> I didn't miss it. I asked for clarification, for two reasons:
>
> 1) Rebase involves two branches, both of which get changed. Your proposal
> only mentions one. Given that I'm not all that familiar with rebase, I have
> *no* idea what this means in terms of additions to the history tree.
In git, the rebase command rebases only the current branch. There's
one or two other things to specify: <upstream> and, optionally,
<newbase>, but these two need not be branch names.
What I'm proposing is that in fossil the rebase operation create a new
branch named after the currently checked out branch (or named by the
user) with the rebased contents, leaving the original alone. The new
branch should get checked out too (for obvious reasons, as the process
of rebasing needs interim points checked out, and anyways, the user is
likely to want the new branch checked out.
> 2) Your use case (generating patches to make upstream happy) isn't one I've
> ever experienced, but it doesn't sound like it needs to change the tree at
> all.
It produces a different set of commits to be sent upstream than I had
before the rebase -- that's a "change to the tree", though, really,
it's a new branch. In git the branch name is then changed to point to
the new line of commits, and this change is what we all consider
destructive. That you've not experienced this says nothing about the
reality of it. For me the lack of rebase in any VCS is near fatal --
it's generally possible to obtain the same effect, even with fossil,
but at the cost of much manual labor or much labor spent automating
rebase tasks (never as well as git rebase does it anyways).
> So, for the third time, can you describe your proposed new feature *without*
> saying the words "git" or "rebase".
No: it's too much work, and many people understand "git rebase", and
it has documentation I can refer to. I don't want to copy that
documentation nor find a way of expressing the same concepts
differently -- that would be a waste of my time and would confuse all
those users who know what git rebase is. I'd much rather instead
offer a description as incremental change to "git rebase".
Given these command-line synopses from the git-rebase manpage:
git rebase [-i | --interactive] [options] [--onto <newbase>]
<upstream> [<branch>]
git rebase [-i | --interactive] [options] --onto <newbase>
--root [<branch>]
my proposal is for:
fossil rebase [-i | --interactive] [options] [--new
<newbranch>] [--onto <newbase>]
<upstream> [<branch>]
fossil rebase [-i | --interactive] [options] [--new
<newbranch>] --onto <newbase>
--root [<branch>]
if <newbranch> is not given then <newbranch> would be derived from the
selected <branch> (or current) by adding a suffix "-1" or by
incrementing the number if <branch> ends in "-<number>".
Nico
--
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
