From: Junio C Hamano <gitster@pobox.com>
To: Sergey Organov <sorganov@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.
Date: Wed, 13 Aug 2014 09:48:02 -0700 [thread overview]
Message-ID: <xmqqha1g49q5.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <87mwb8ahtb.fsf@osv.gnss.ru> (Sergey Organov's message of "Wed, 13 Aug 2014 12:56:48 +0400")
Sergey Organov <sorganov@gmail.com> writes:
> ... I.e., git must not rebase anything
> when "Current branch is a descendant of the commit you are rebasing
> onto", unless -f is given. Simple, reasonable, straightforward.
It may be simple and straightforward, but breaks the use case the
plain vanilla rebase is used for, doesn't it? You seem to ignore,
or perhaps you don't realize the existence of, the need of those who
want to flatten the history on top of the tip from the other side;
your statements in the "pull --rebase[=preserve]" thread may be
coming from the same place, I suspect.
For the "flatten the history on top of that commit" use case, two
conditions must be satisfied before the command can say "the history
is already in the desired shape and nothing needs to be done" to
allow it to make a short-cut. It is not sufficient for the current
tip to be merely descendant of the tip from the other side (which is
the documentation bug we are fixing here). The history between the
two commits need also to be linear, or it would not be flattening.
Punting when when only one of the two conditions is met and
requiring "--force" to perform what the user wanted to ask the
command to do does not fall into the "reasonable" category.
If your workflow does not involve the flattening plain vanilla
"rebase", not using it is perfectly fine. But please do not break
it for other people only because you do not use it yourself.
next prev parent reply other threads:[~2014-08-13 16:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-11 20:22 [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior Sergey Organov
2014-08-12 19:47 ` Junio C Hamano
2014-08-12 20:38 ` Junio C Hamano
2014-08-13 8:56 ` Sergey Organov
2014-08-13 16:48 ` Junio C Hamano [this message]
2014-08-18 13:27 ` Sergey Organov
2014-08-15 11:52 ` Sergey Organov
2014-08-15 17:51 ` Junio C Hamano
2014-08-15 20:14 ` Sergey Organov
2014-08-15 21:57 ` Junio C Hamano
2014-08-18 8:53 ` Sergey Organov
2014-08-18 16:32 ` Junio C Hamano
2014-08-19 9:57 ` Sergey Organov
2014-08-19 10:05 ` Sergey Organov
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=xmqqha1g49q5.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=sorganov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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