git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Cc: "Rolf Eike Beer" <eb@emlix.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: Please add support for "git merge --continue -S"
Date: Mon, 28 Feb 2022 14:53:31 -0800	[thread overview]
Message-ID: <xmqq1qzmy55g.fsf@gitster.g> (raw)
In-Reply-To: <220228.86fso35k61.gmgdl@evledraar.gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Mon, 28 Feb 2022 11:58:11 +0100")

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> You can just drop the use of "merge --continue" entirely and use
> "commit" instead.
>
> Caveats related to this were recently discussed on-list:
> https://lore.kernel.org/git/CALRdAfcyfesNqfLhhe2GW_5V9s2hf++i6mZS1Lw5hqQYTca85w@mail.gmail.com/

Ah, that one.  We need to close the #leftoverbits on the topic.
Here is a starter.

----- >8 --------- >8 --------- >8 --------- >8 --------- >8 -----
Subject: merge: 'git merge --continue' is merely 'git commit'

Among the commands with "--continue", "merge --continue" came much
later, and it did not even need to exist.  The other commands with
"--continue", e.g. "rebase", deal with multi-step operations, and it
is worth to have a way to say "I am finished with this step, let's
CONTINUE WITH THE REST".  But in "merge", there is no remaining
thing to do after you are done with the conflict you saw.

In hindsight, we probably should have resisted the urge to add
"merge --continue", just for the sake of misguided "consistency"
perceived on non-existent similarity with other commands that truly
need "--continue".  What is called "merge --continue" should have
been called "merge --finish", if we needed to add something back
then.

The way to finish a conflicted merge has always been to run "git
commit" before "merge --continue" was added, and it still is not
just accepted but is the right way to finish a conflicted merge.

There is an argument that it makes it somehow "safer" to use "merge
--continue" because the command fails when there is no interrupted
merge going on, but what the user sees from "git commit" when there
is and there is not interrupted merge are so different, there is not
much "safety" benefit in practice.  We probably should deprecate and
eventually remove "git merge --continue" eventually, but one step at
a time.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/git-merge.txt | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git c/Documentation/git-merge.txt w/Documentation/git-merge.txt
index 3125473cc1..95f252598e 100644
--- c/Documentation/git-merge.txt
+++ w/Documentation/git-merge.txt
@@ -122,9 +122,9 @@ list.
 	stash entry will be saved to the stash list.
 
 --continue::
-	After a 'git merge' stops due to conflicts you can conclude the
-	merge by running 'git merge --continue' (see "HOW TO RESOLVE
-	CONFLICTS" section below).
+	After a 'git merge' stops due to conflicts, you can conclude
+	the merge with "git commit" (see "HOW TO RESOLVE CONFLICTS"
+	section below).  'git merge --continue' is a synonym for it.
 
 <commit>...::
 	Commits, usually other branch heads, to merge into our branch.
@@ -326,10 +326,9 @@ After seeing a conflict, you can do two things:
 
  * Resolve the conflicts.  Git will mark the conflicts in
    the working tree.  Edit the files into shape and
-   'git add' them to the index.  Use 'git commit' or
-   'git merge --continue' to seal the deal. The latter command
-   checks whether there is a (interrupted) merge in progress
-   before calling 'git commit'.
+   'git add' them to the index.  Use 'git commit' (or
+   'git merge --continue', which stops if there is no 
+   interrupted merge in progress) to seal the deal.
 
 You can work through the conflict with a number of tools:
 

  reply	other threads:[~2022-02-28 22:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28  9:48 Please add support for "git merge --continue -S" Rolf Eike Beer
2022-02-28 10:58 ` Ævar Arnfjörð Bjarmason
2022-02-28 22:53   ` Junio C Hamano [this message]
2022-02-28 23:28     ` Ævar Arnfjörð Bjarmason

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=xmqq1qzmy55g.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=eb@emlix.com \
    --cc=git@vger.kernel.org \
    /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).