From: Junio C Hamano <gitster@pobox•com>
To: Christian Couder <christian.couder@gmail•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: Thu, 10 Jul 2014 10:36:09 -0700 [thread overview]
Message-ID: <xmqqegxt86ba.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <xmqqr41t88dz.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Thu, 10 Jul 2014 09:51:20 -0700")
Junio C Hamano <gitster@pobox•com> writes:
> Christian Couder <christian.couder@gmail•com> writes:
>
>>> Is this really an error? It may be a warning-worthy situation for a
>>> user or a script to end up doing a no-op graft, e.g.
>>>
>>> git replace --graft HEAD HEAD^
>>>
>>> but I wonder if it is more convenient to signal an error (like this
>>> patch does) or just ignore the request and return without adding the
>>> replace ref.
>>
>> 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.
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. "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?
>
> 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?
next prev parent reply other threads:[~2014-07-10 17:36 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 [this message]
2014-07-11 8:59 ` Christian Couder
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=xmqqegxt86ba.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=chriscool@tuxfamily$(echo .)org \
--cc=christian.couder@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jnareb@gmail$(echo .)com \
--cc=mhagger@alum$(echo .)mit.edu \
--cc=peff@peff$(echo .)net \
--cc=sunshine@sunshineco$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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