Re: [PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla "git rebase" in DESCRIPTION.

[Junio C Hamano <gitster@pobox.com>]

Sergey Organov <sorganov@gmail.com> writes:

> I think you meant to say that we may find a better source to calculate
> the exact set of commits to rebase,...

Yes.

>> It is debatable if we should do the same when the user tells us to
>> rebase with respect to a specific _branch_ by giving the 'upstream'
>> argument, but that is an entirely separate issue.  We might want to
>> do a similar command line heuristics to tell between the branch
>> switching "git checkout master" (which is an operation about a
>> branch) and head detaching "git checkout refs/heads/master^0" (which
>> is an operation about a commit) if we want to help the users by
>> auto-enabling fork-point mode.
>
> Well, IMHO "git rebase" and "git rebase @{u}" must do exactly the same
> thing.

"That is not part of the current discussion" is what I meant by "It
is debatable... We might want to".  There is no such patch to "git
rebase" itself in this topic ;-).

With the "We might want to", I mean "git rebase", "git rebase @{u}"
and "git rebase origin/master" (if your @{u} happens to be that
branch) may want to do exactly the same thing.  The last one however
is very questionable, as sometimes you would want the --fork-point
heuristics, and some other times you would want no digging of the
reflogs involved (i.e. "I want everything not in this _exact_ commit
to be rebased").

> On the other hand, I'm afraid different defaults were chosen for
> backward compatibility?

There is no backward compatibility issue involved with the current
behaviour.  Changing it _will_ break compatibility, of course.

It is more like the command used not to guess with fork-point at
all, i.e. we liked its exactness, but "git rebase" (no argument)
case is so obviously not about an exact commit but is about branch
that it is safe to use --fork-point guess without being confusing.
Once you start giving the commit/branch with respect to which you
conduct your rebase, it no longer is so cut-and-dried obvious that
by "git rebase @{u}" if the user wants us to guess by digging the
reflog of @{u} to find a better fork point, or if the user wants to
do an exact rebase with respect to the commit at the tip of that
branch.