Junio C Hamano <gitster@xxxxxxxxx> writes: >> This is my first dive into git's code, so it's likely I'm not doing things >> right. The first candidate for that is the literal `7`,... Actually, the first candidate is not related to any code, but that you did not explain "why" in your log message. I raised two issues with your change in my response, which are (1) loss of convenience (i.e. why would a user want to type fc77dbd when v4.5-rc6 is easier to remember) and (2) loss of information (i.e. renaming fetch loses the assurance from the report that v1.0 did indeed copied to his/v1.0). Both of these things tell us that the change only makes the result worse. But I am sure you didn't make this change to make the resulting system worse. That is why I asked "why is this an improvement?" and that is _not_ a rhetorical question (i.e. I wasn't making a statement: "this cannot possibly be an improvement"). You must have thought that the user would benefit in some way if the report showed a raw abbreviated object name there. But you failed to say what exactly that benefit is, and I couldn't guess, and that is why I asked. Because a raw abbreviated object name alone is a fairly useless piece of information (i.e. to get anything meaningful, the user needs to give it to some Git command like "git log", "git show", etc.), and the resulting local tag name is equally usable as a raw object name is if the user is going to use these Git commands to learn more about the object anyway, the only semi-sensible justification I can think of offhand for this change is that the user somehow already has a list of raw object names for the refs expected to be updated available and showing the raw object name in the update-local report may serve as an assurance that the right object was fetched. Perhaps there was an announcement e-mail message that said fc77dbd is the object name of the v4.5-rc6 tag, and the user can see that object was fetched without having to run extra Git command, or something like that. 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). Anyway, welcome to Git development community. -- 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