A Large Angry SCM <gitzilla@xxxxxxxxx> writes: > Santi Béjar wrote: >> this patchset includes: >> >> fetch: Reset remote refs list each time fetch_main is called >> fetch & co: Use "hash1..hash2" instead of "from hash1 to hash2" >> fetch & co: Use short sha1 in the output >> fetch: Add output for the not fast forward case >> fetch: Clean output > > Please do not make short ID output the default. That is, unless you > can somehow guarantee that the short ID reported today will _always_ > be unambiguous even with future additions to the repository. I would understand your worries of spitting out only abbreviated object names if they appear in a document to be preserved for a long term. But we are talking about output to stderr to help people see what happened in the operation they initiated a few moments ago, and to help them use the output for cut&paste while it is still in the scrollbuffer of the terminal. Shortening them would help A..B avoid crossing the line boundaries, which terminal emulators have trouble with cutting sometimes. That benefit may outweigh the longer term ambiguity concerns. The only real-life situation I can imagine the program output is preserved in any longer term than immediate consumption for cut&paste is to paste it into a piece of e-mail (which is archived), to show exactly what the program said to the user. But then it carries the timestamp and you should be able to figure out what the abbreviation uniquely stood for back then if you really cared. If you are producing a document for longer term storage, the program that produces such a document should be doing its own rev-parse anyway (or maybe pass whatever it is piping through git-name-rev --stdin). I think it is Ok to always use the abbreviated form in the places Santi's patch touched, as long as people understand these messages are not for long term storage. We might want to use a bit longer abbreviation than the default (7 hexdigits). - 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