From: Sergey Organov <sorganov@gmail•com>
To: Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla "git rebase" in DESCRIPTION.
Date: Mon, 29 Sep 2014 14:05:37 +0400 [thread overview]
Message-ID: <87k34mvj0u.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqqvboa6lvj.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Fri, 26 Sep 2014 15:46:24 -0700")
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.
prev parent reply other threads:[~2014-09-29 10:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-18 19:03 [PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla "git rebase" in DESCRIPTION Sergey Organov
2014-09-18 19:03 ` [PATCH v2] " Sergey Organov
2014-09-29 16:26 ` Junio C Hamano
2014-09-29 20:17 ` Sergey Organov
2014-09-22 19:35 ` [PATCH] " Junio C Hamano
2014-09-23 9:04 ` Sergey Organov
2014-09-26 22:46 ` Junio C Hamano
2014-09-29 10:05 ` Sergey Organov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k34mvj0u.fsf@osv.gnss.ru \
--to=sorganov@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox