Christian Couder <christian.couder@xxxxxxxxx> 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. 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html