From: Junio C Hamano <gitster@pobox.com>
To: hIpPy <hippy2981@gmail.com>
Cc: "Martin Ågren" <martin.agren@gmail.com>,
"Michael J Gruber" <git@grubix.eu>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: [PATCH v2 1/3] Documentation/git-merge: explain --continue
Date: Tue, 22 Aug 2017 09:11:38 -0700 [thread overview]
Message-ID: <xmqq1so34m6d.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAM_JFCzq+DPUFbC60kjNjHz3OZLt-X3bLXJdSFpBnATtZ6otdA@mail.gmail.com> (hIpPy's message of "Tue, 22 Aug 2017 08:24:56 -0700")
hIpPy <hippy2981@gmail.com> writes:
> I think 'git merge --continue' should be advertised more that 'git
> commit' as typically one is familiar with 'git rebase --continue' and
> 'git cherry-pick --continue'. I for a long time did not know I could
> also use 'git commit' to continue a merge but that's just me.
Perhaps. "rebase" and "am" (and range pick "cherry-pick A..B") are
operations that works on more than one change, so it makes perfect
sense to have a way to say "I am done with this step. Please go on
and do the rest".
There is no "go on and do the rest" after resolving a conflicted
merge, as "merge" is, unlike the other ones to which "--continue"
legitimately has a reasonable meaning, an operation that does just
one thing. From that point of view, "git merge --continue" is a
mistaken UI that shouldn't have happened.
next prev parent reply other threads:[~2017-08-22 16:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-18 22:35 Git makes a merge commit but as a normal (non-merge) commit hIpPy
2017-08-21 10:03 ` Michael J Gruber
2017-08-21 10:06 ` [PATCH] merge: save merge state earlier Michael J Gruber
2017-08-21 12:53 ` [PATCH v2 0/3] Keep merge during kills Michael J Gruber
2017-08-21 12:53 ` [PATCH v2 1/3] Documentation/git-merge: explain --continue Michael J Gruber
2017-08-21 16:43 ` Martin Ågren
2017-08-22 9:26 ` Michael J Gruber
2017-08-22 10:06 ` Martin Ågren
2017-08-22 15:24 ` hIpPy
2017-08-22 16:11 ` Junio C Hamano [this message]
2017-08-23 12:10 ` [PATCH v3 0/4] Keep merge during kills Michael J Gruber
2017-08-23 12:10 ` [PATCH v3 1/4] Documentation/git-merge: explain --continue Michael J Gruber
2017-08-23 12:10 ` [PATCH v3 2/4] merge: clarify call chain Michael J Gruber
2017-08-23 12:10 ` [PATCH v3 3/4] merge: split write_merge_state in two Michael J Gruber
2017-08-23 12:10 ` [PATCH v3 4/4] merge: save merge state earlier Michael J Gruber
2017-08-22 0:20 ` [PATCH v2 1/3] Documentation/git-merge: explain --continue Junio C Hamano
2017-08-21 12:53 ` [PATCH v2 2/3] merge: split write_merge_state in two Michael J Gruber
2017-08-22 0:20 ` Junio C Hamano
2017-08-21 12:53 ` [PATCH v2 3/3] merge: save merge state earlier Michael J Gruber
2017-08-22 0:38 ` Junio C Hamano
2017-08-22 9:36 ` Michael J Gruber
2017-08-22 16:03 ` Junio C Hamano
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=xmqq1so34m6d.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@grubix.eu \
--cc=git@vger.kernel.org \
--cc=hippy2981@gmail.com \
--cc=martin.agren@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.