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

[Sergey Organov <sorganov@gmail.com>]

Junio C Hamano <gitster@pobox.com> writes:

> 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 ;-).

Yes, but to suggest better documentation I figure I need to understand
all the related issues, so it is still somewhat relevant.

> 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.

Well, that's exactly what ended-up being /extremely/ confusing in my
case.

> 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.

Whatever excuses are, to me it still looks entirely unnatural that 'git
rebase' and 'git rebase @{u}' mean almost the same /except/ the default
value of --fork-point is different, sorry.

P.S. I'll prepare improved patch for the documentation shortly.

-- 
Segey.