Junio C Hamano <gitster@xxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > But I am merely guessing from the your patch text what the reasoning > behind the change was and you are the one who had the original > reason why you needed this change, so your "why" may be a lot more > useful use case than the one I made up and called "semi-sensible" > here. The proposed log message needs to explain your "why". > > And if you explained "why", you may have heard other people agreeing > with you that this new piece of information is nice to have. They > may even have helped you by suggesting to add this extra information > somewhere in the output, instead of replacing existing information > in the output (which would lead to loss of convenience and > information). I just thought of another possible explanation why you may have thought that it is a good idea to clobber the right hand side of the fetch report. Perhaps you thought that LHS and RHS say the same thing and that is redundant? Because "git fetch" is flexible and allows you to store what the remote side called X locally as Y, the fetch report in the most general form must say X on the remot side) was fetched and stored as Y in the local repository, i.e. [new tag] X -> Y but it is excusable that people new to Git who never saw such a renaming fetch to misunderstand that we are giving redundant information. If that was the motivation, a possible way to change the behaviour would be to show [new tag] X if and only if the remote side and the local side uses exactly the sae name for the ref. The lack of " -> " can clearly tell the user that the output is telling us that what they call X is fetched and stored as X (i.e. under the same name) locally. A fetched ref that does not update any local ref (i.e. the ones that are recorded only in the FETCH_HEAD file) is shown as tag X -> FETCH_HEAD so there is no ambiguity there, either. -- 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