git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Couder <christian.couder@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Christian Couder <chriscool@tuxfamily.org>,
	git <git@vger.kernel.org>, Jeff King <peff@peff.net>,
	Michael Haggerty <mhagger@alum.mit.edu>,
	Jakub Narebski <jnareb@gmail.com>,
	Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH v6 02/10] replace: add --graft option
Date: Fri, 11 Jul 2014 10:59:32 +0200	[thread overview]
Message-ID: <CAP8UFD0_m5aFVcBQr3d9pXR=9rLjAVPGrj=UsBYFcnTQFwNKGA@mail.gmail.com> (raw)
In-Reply-To: <xmqqegxt86ba.fsf@gitster.dls.corp.google.com>

On Thu, Jul 10, 2014 at 7:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>>
>>> As the user might expect that a new replace ref was created on success
>>> (0 exit code), and as we should at least warn if we would create a
>>> commit that is the same as an existing one,...
>>
>> Why is it an event that needs a warning?  I do not buy that "as we
>> should at least" at all.

Here you ask why this event needs a warning...

> Ehh, it came a bit differently from what I meant.  Perhaps s/do not
> buy/do not understand/ is closer to what I think---that is, it is
> not like I with a strong conviction think you are wrong.  It is more
> like I do not understand why you think it needs a warning, meaing
> you would need to explain it better.
>
>> If you say "make sure A's parent is B" and then you asked the same
>> thing again when there already is a replacement in place, that
>> should be a no-op.

(When there is already a replacement in place we error out in
replace_object_sha1() unless --force is used. What we are talking
about here is what happens if the replacement commit is the same as
the original commit.)

>> "Making sure A's parent is B" would be an
>> idempotent operation, no?  Why not just make sure A's parent is
>> already B and report "Your wish has been granted" to the user?

... and here you say we should report "your wish has been granted"...

>> Why would it be simpler for the user to get an error, inspect the
>> situation and realize that his wish has been granted after all?

... but for me reporting to the user "your wish has been granted" and
warning (or errorring out) saying "the new commit would be the same as
the old one" are nearly the same thing.

So I wonder what exactly you are not happy with.

Is it the fact that I use the error() function, because it would
prefix the message with "fatal:" and that would be too scary?

Is it because with error() the exit code would not be 0?

Is it because the message "new commit is the same as the old one:
'%s'" is too scary or unnecessarily technical by itself?

Is it ok if I just print the message on stderr without "warning:" or
"fatal:" in front of it?

By the way, when I say "As ... and ..., I think it is just simpler to
error out in this case.", I mean that it is simpler from the
developer's point of view, not necessarily for the user.

Of course I am ok with improving things for the user even if it
requires more code/work, but it is difficult to properly do that if I
don't see how I could do it.

Thanks,
Christian.

  reply	other threads:[~2014-07-11  8:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-07  6:35 [PATCH v6 00/10] Add --graft option to git replace Christian Couder
2014-07-07  6:35 ` [PATCH v6 01/10] replace: cleanup redirection style in tests Christian Couder
2014-07-07  6:35 ` [PATCH v6 02/10] replace: add --graft option Christian Couder
2014-07-09 14:59   ` Junio C Hamano
2014-07-10  9:30     ` Christian Couder
2014-07-10 16:51       ` Junio C Hamano
2014-07-10 17:36         ` Junio C Hamano
2014-07-11  8:59           ` Christian Couder [this message]
2014-07-11 14:22             ` Junio C Hamano
2014-07-11 16:24               ` Christian Couder
2014-07-11 18:25                 ` Junio C Hamano
2014-07-11 18:29                   ` Jeff King
2014-07-07  6:35 ` [PATCH v6 03/10] replace: add test for --graft Christian Couder
2014-07-07 22:16   ` Junio C Hamano
2014-07-08  5:36     ` Christian Couder
2014-07-07  6:35 ` [PATCH v6 04/10] Documentation: replace: add --graft option Christian Couder
2014-07-07  6:35 ` [PATCH v6 05/10] contrib: add convert-grafts-to-replace-refs.sh Christian Couder
2014-07-07  6:35 ` [PATCH v6 06/10] replace: remove signature when using --graft Christian Couder
2014-07-07  6:35 ` [PATCH v6 07/10] replace: add test for --graft with signed commit Christian Couder
2014-07-07  6:35 ` [PATCH v6 08/10] commit: add for_each_mergetag() Christian Couder
2014-07-07 22:30   ` Junio C Hamano
2014-07-08  5:53     ` Christian Couder
2014-07-07  6:35 ` [PATCH v6 09/10] replace: check mergetags when using --graft Christian Couder
2014-07-07 22:28   ` Junio C Hamano
2014-07-08  5:35     ` Christian Couder
2014-07-07  6:35 ` [PATCH v6 10/10] replace: add test for --graft with a mergetag 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='CAP8UFD0_m5aFVcBQr3d9pXR=9rLjAVPGrj=UsBYFcnTQFwNKGA@mail.gmail.com' \
    --to=christian.couder@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=mhagger@alum.mit.edu \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.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;
as well as URLs for NNTP newsgroup(s).