Junio C Hamano <gits...@pobox.com> writes: > Christian Couder <christian.cou...@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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
