Junio C Hamano <gitster@xxxxxxxxx> writes: > Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > >> They'd use "pull", not merge. Anyway, I did it for commit, merge, >> pull, revert, cherry-pick. I guess we covered the common cases. >> The patch seems to have a lot of redundancies, but I think trying to >> factor this into helper functions would be much more effort than the >> few cut-and-paste that I had to do, since each instance is a slight >> variant of each other ... > > I'd be more worried about longer term maintainability than one time > expediency of producing your single patch to add these messages. If the > messages are cast in stone, we can just verify they are consistent _now_ > and forget about them, but I suspect not even you are perfect to predict > that we won't come up with different/better ways to resolve and mark them > resolved in the future and write a set of messages that won't have to > change. Sorry, I sent the message a bit too early. Re-reading the patch, there were actually pieces to factor. There's still duplication between C and shell, and sentences which are actually reworded from a place to another. OTOH, maybe this reveals some differences that should be eliminated. For example, 'git cherry-pick' has no problem with $GIT_DIR/MERGE_HEAD, while 'git merge' will immediately if it exists. Maybe we should write a helper like ensure_everything_is_ok_for_a_merge_or_die() called by both cherry-pick and merge? This time, patch actually follows ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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