From: Johannes Sixt <j.sixt@viscovery.net>
To: Junio C Hamano <gitster@pobox.com>,
Christian Couder <chriscool@tuxfamily.org>
Cc: git@vger.kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Stephan Beyer <s-beyer@gmx.net>,
Daniel Barkalow <barkalow@iabervon.org>,
Jakub Narebski <jnareb@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v3 3/4] reset: add option "--merge-safe" to "git reset"
Date: Thu, 17 Sep 2009 08:38:15 +0200 [thread overview]
Message-ID: <4AB1D957.20902@viscovery.net> (raw)
In-Reply-To: <7vk4zykv7o.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> As we established in the previous round, this is _different_ from --merge,
> but *not* in the sense that --merge is more dangerous and users should be
> using this new option instead, but in the sense that --merge perfectly
> works well for its intended use case, and this new option triggers a mode
> of operation that is meant to be used in a completely different use case,
> which is unspecified in this series without documentation.
>
> In that light, is --merge-safe still a good name for the option, or merely
> a misleading one?
Do I understand this correctly?
(1) The intended use-case of --merge is to "reset _a_ merge".
(2) The intended use-case of --merge-safe is to point the branch head to a
different commit, but to carry the changes that currently are in the index
and wd over to the new commit, similar to checkout --merge.
I had mistaken that --merge actually performs (2) because of the striking
similarity of the option's name to checkout's --merge. So, IMHO, whatever
the new option is named that performs (2) - it introduces an
inconsistency, because --merge is already taken.
-- Hannes
next prev parent reply other threads:[~2009-09-17 6:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-17 4:14 [PATCH v3 0/4] "git reset --merge" related improvements Christian Couder
2009-09-17 4:14 ` [PATCH v3 1/4] reset: add a few tests for "git reset --merge" Christian Couder
2009-09-17 4:14 ` [PATCH v3 2/4] reset: use "unpack_trees()" directly instead of "git read-tree" Christian Couder
2009-09-17 4:14 ` [PATCH v3 3/4] reset: add option "--merge-safe" to "git reset" Christian Couder
2009-09-17 5:15 ` Junio C Hamano
2009-09-17 6:38 ` Johannes Sixt [this message]
2009-09-17 7:07 ` Junio C Hamano
2009-09-17 7:24 ` Johannes Sixt
2009-09-17 12:12 ` Christian Couder
2009-09-17 13:05 ` Johannes Sixt
2009-09-17 13:25 ` Christian Couder
2009-09-17 20:43 ` Junio C Hamano
2009-09-17 12:25 ` Christian Couder
2009-09-17 21:04 ` Daniel Barkalow
2009-09-17 4:14 ` [PATCH v3 4/4] reset: add test cases for "--merge-safe" option Christian Couder
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=4AB1D957.20902@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=barkalow@iabervon.org \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
--cc=s-beyer@gmx.net \
--cc=torvalds@linux-foundation.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.
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.