Re: [PATCH v6 02/10] replace: add --graft option

Christian Couder [off-list ref] writes:

quoted

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.

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?