Hi Junio, Thanks for the warm welcome, but after your explanation on the purpose of the second field, it looks like my patch was just a plain bad idea. I'm not that new to git (I've been using it actively for 6+ years), but as you guessed, I thought it was just redundant info as I had never seen a tag with a different remote name (unlike new branches, for which you always see the `remote/branch` name), and I thought I might as well replace it with an other info. As you mentioned though, a tag can be used everywhere its hash can, so there's no point showing that either. I guess I'll just take that as a lesson :] “Make sure you actually understand what the code is doing before trying to modify it” Cheers, Eric On Mon, Mar 07, 2016 at 08:28:06PM -0800, Junio C Hamano wrote: > 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