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: fix -f description to match actual git behavior.
Date: Fri, 15 Aug 2014 15:52:02 +0400 [thread overview]
Message-ID: <87d2c22cnx.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqqzjf94f5n.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Tue, 12 Aug 2014 13:38:28 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> So I think the reasoning (i.e. "is a descendant" is not quite right)
>> is correct, but the updated text is not quite right. Changing it
>> further to "only the committer timestamps and identities would
>> change" is probably not an improvement, either. "Force the rebase
>> that would otherwise be a no-op" may be a better phrasing that does
>> not risk going stale even if we update what are preserved and what
>> are modified in the future.
>>
>> Also I notice the sentence "Normally non-interactive...in such a
>> situation" is not helping the reader in this description very much.
>> I wonder if we should keep it if we are rewriting this paragraph.
>
> How about doing it this way, perhaps?
>
> -- >8 --
> From: Sergey Organov <sorganov@gmail.com>
> Date: Tue, 12 Aug 2014 00:22:48 +0400
> Subject: [PATCH] Documentation/git-rebase.txt: -f forces a rebase that would otherwise be a no-op
>
> "Current branch is a descendant of the commit you are rebasing onto"
> does not necessarily mean "rebase" requires "--force". For a plain
> vanilla "history flattening" rebase, the rebase can be done without
> forcing if there is a merge between the tip of the branch being
> rebased and the commit you are rebasing onto, even if the tip is
> descendant of the other.
>
> [jc: reworded both the text and the log description]
>
> Signed-off-by: Sergey Organov <sorganov@gmail.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/git-rebase.txt | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index 2a93c64..f14100a 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -316,11 +316,8 @@ which makes little sense.
>
> -f::
> --force-rebase::
> - Force the rebase even if the current branch is a descendant
> - of the commit you are rebasing onto. Normally non-interactive rebase will
> - exit with the message "Current branch is up to date" in such a
> - situation.
> - Incompatible with the --interactive option.
> + Force a rebase even if the current branch is up-to-date and
> + the command without `--force` would return without doing anything.
> +
> You may find this (or --no-ff with an interactive rebase) helpful after
> reverting a topic branch merge, as this option recreates the topic branch with
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> So I think the reasoning (i.e. "is a descendant" is not quite right)
>> is correct, but the updated text is not quite right. Changing it
>> further to "only the committer timestamps and identities would
>> change" is probably not an improvement, either. "Force the rebase
>> that would otherwise be a no-op" may be a better phrasing that does
>> not risk going stale even if we update what are preserved and what
>> are modified in the future.
>>
>> Also I notice the sentence "Normally non-interactive...in such a
>> situation" is not helping the reader in this description very much.
>> I wonder if we should keep it if we are rewriting this paragraph.
>
> How about doing it this way, perhaps?
>
> -- >8 --
> From: Sergey Organov <sorganov@gmail.com>
> Date: Tue, 12 Aug 2014 00:22:48 +0400
> Subject: [PATCH] Documentation/git-rebase.txt: -f forces a rebase that would otherwise be a no-op
>
> "Current branch is a descendant of the commit you are rebasing onto"
> does not necessarily mean "rebase" requires "--force". For a plain
> vanilla "history flattening" rebase, the rebase can be done without
> forcing if there is a merge between the tip of the branch being
> rebased and the commit you are rebasing onto, even if the tip is
> descendant of the other.
>
> [jc: reworded both the text and the log description]
>
> Signed-off-by: Sergey Organov <sorganov@gmail.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/git-rebase.txt | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index 2a93c64..f14100a 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -316,11 +316,8 @@ which makes little sense.
>
> -f::
> --force-rebase::
> - Force the rebase even if the current branch is a descendant
> - of the commit you are rebasing onto. Normally non-interactive rebase will
> - exit with the message "Current branch is up to date" in such a
> - situation.
> - Incompatible with the --interactive option.
> + Force a rebase even if the current branch is up-to-date and
> + the command without `--force` would return without doing anything.
> +
> You may find this (or --no-ff with an interactive rebase) helpful after
> reverting a topic branch merge, as this option recreates the topic branch with
I dig more into it, and that's what I came up with, using some of your
suggestions as well.
Please notice new text on essential interaction with --preserve-merges.
I also thought about "Force the rebase that would otherwise be a no-op",
and while it is future-changes-agnostic indeed, it doesn't actually
explain anything, so I put some explanation back.
-- >8 --
From: Sergey Organov <sorganov@gmail.com>
Date: Tue, 12 Aug 2014 00:10:19 +0400
Subject: [PATCH] Documentation/git-rebase.txt: fix -f description to match
"Current branch is a descendant of the commit you are rebasing onto"
does not necessarily mean "rebase" requires "--force". Presence of
merge commit(s) makes "rebase" perform its default flattening actions
anyway.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
Documentation/git-rebase.txt | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2a93c64..9153369 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -316,11 +316,10 @@ which makes little sense.
-f::
--force-rebase::
- Force the rebase even if the current branch is a descendant
- of the commit you are rebasing onto. Normally non-interactive rebase will
- exit with the message "Current branch is up to date" in such a
- situation.
- Incompatible with the --interactive option.
+ If --preserve-merges is given, has no effect. Otherwise forces
+ rebase even if the current branch is a descendant of the commit
+ you are rebasing onto and there are no merge commits among
+ those to be rebased.
+
You may find this (or --no-ff with an interactive rebase) helpful after
reverting a topic branch merge, as this option recreates the topic branch with
--
1.9.3
next prev parent reply other threads:[~2014-08-15 11:58 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
2014-08-18 13:27 ` Sergey Organov
2014-08-15 11:52 ` Sergey Organov [this message]
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d2c22cnx.fsf@osv.gnss.ru \
--to=sorganov@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).