public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox•com>
To: Jonathon Mah <me@JonathonMah•com>
Cc: git@vger•kernel.org
Subject: Re: RFC: Renaming "git rebase --onto"
Date: Mon, 30 Mar 2015 14:12:08 -0700	[thread overview]
Message-ID: <xmqqk2xyw5p3.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <05D9209E-FAA2-44C8-9B98-B00997AF5779@JonathonMah.com> (Jonathon Mah's message of "Mon, 30 Mar 2015 13:49:34 -0700")

Jonathon Mah <me@JonathonMah•com> writes:

> During a few years of discussing git operations with colleagues, I’ve
> found the “git rebase --onto” operation particularly ambiguous. The
> reason is that I always describe a rebase operation as “onto”
> something else (because of the English phrase “A is based on
> B”). For example:
>
> $ git rebase new-base  # “Rebase HEAD onto new-base (from merge-base of HEAD and new-base)"
> $ git rebase new-base my-branch # “Rebase my-branch onto new-base
> (from merge-base of my-branch and new-base)”
>
> Personally, I understand “git-rebase --onto new-base old-base” as
> meaning “rebase from old-base to new-base”. Some prepositions that
> might make this clearer:
>
> $ git rebase --from old-base new-base  # “Rebase HEAD onto new-base, from old-base"
> $ git rebase --after old-base new-base # “Rebase commits on HEAD
> after old-base HEAD onto new-base"
> $ git rebase --excluding old-base new-base # “Rebase HEAD onto
> new-base, excluding commit old-base (and its parents)"
>
> In all cases this would change the order of the arguments compared to
> --onto, making it more consistent with the no-option rebase.

The bog-standard rebase is

    git rebase U

which rebases the current history that has diverged from the history
leading to U on to U.

Or

    git rebase U BRANCH

which rebases BRANCH that has diverged from the history leading to U
on to U.  In both of these invocations, these arguments define which
part of the local history is replayed.

Now,

    git rebase [--onto O] $other_args

is just a way to say $other_args still define which part of the
local history is replayed, but you are replaying on something that
is different from the usual default case (which is U).

Which feels very consistent between the cases with and without the
extra --onto parameter, at least to me.  Hence, if you change order
in any way, I would think you would break the existing consistency.

I suspect that this thread is a symptom of something unrelated,
though.  There might be something wrong in your workflow if you find
yourself using --onto too often, for example, and that may be the
issue we should be focusing on, not on how "rebase --onto" is
spelled.

> What do others think? Is my view of “onto” common or unusual?

"common or unusual" is a question we cannot answer, I would say.
People who are used to "rebase" may be so used to it that it might
feel natural to them but cannot tell if that is only because they
already know how "rebase" spells its arguments, or they would still
find it natural if they did not know anything about "rebase".

  parent reply	other threads:[~2015-03-30 21:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-30 20:49 RFC: Renaming "git rebase --onto" Jonathon Mah
2015-03-30 21:03 ` Jonathan Nieder
2015-03-30 21:12 ` Junio C Hamano [this message]
2015-04-02 16:40   ` Michael J Gruber
2015-03-30 21:53 ` Max Kirillov

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=xmqqk2xyw5p3.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=me@JonathonMah$(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