Re: [RFC/PATCH] commit: make the error message on unmerged entries user-friendly.
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- Jan 6, 2010, 20:15 UTC
- Message-ID
- <vpqhbqz6lcr.fsf@bauges.imag.fr>
- In-Reply-To
- <7vy6kbt2ww.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 16 quoted lines
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> 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/