{"thread":{"id":"45245","subject":"[RFC] - url-safe base64 commit-id's","startedAt":"2017-02-28T02:27:57Z","lastAt":"2017-02-28T07:35:11Z","messageCount":2,"participants":["G. Sylvie Davies","Bryan Turner"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"312816","messageId":"CAAj3zPzwWr4u1qSMp5CwVMzExW2eg9LQ7t7RX-5m6fRRGh9pcA@mail.gmail.com","threadId":"45245","inReplyTo":null,"subject":"[RFC] - url-safe base64 commit-id's","fromName":"G. Sylvie Davies","fromEmail":"sylvie@bit-booster.com","sentAt":"2017-02-28T02:27:49Z","receivedAt":"2017-02-28T02:27:57Z","isPatch":false,"sender":{"key":"sylvie@bit-booster.com","avatar":"https://gravatar.com/avatar/eb5bda7d3fb1e3361252bbf100d1f355ffe9ff8d8b559a08e4c7bc17d6f949d5?d=mp&s=160"},"body":"Is there any appetite for base64'd commit-id's, using the url-safe\nvariant (e.g. RFC 4648 [1] with padding removed)?\n\nAnd so this:\n712bad335dfa9c410a83f9873614a19726acb3a8\n\nBecomes this:\ncSutM136nEEKg_mHNhShlyass6g\n\n\nUnder the hood things cannot change (e.g., \".git/objects/71/\") because\nfile systems are not always case sensitive.\n\nBut for \"git log\" and \"git show\" output it would be nice. And helps\nwith ambiguous commit id's too if you only want to specify a 7\ncharacter commit-id, since that encodes 42 bits instead of 28 bits.\nI've run into problems with maximum command length on windows (32767\nchars) because I was specifying so many commit-ids on the command-line\nthat I blew past that limit. This would help there, too.\n\nMight be particularly helpful with the transition to a new hash.\ne.g., a 43 character Base64 id instead of a 64 character hex id.\n\n\n- Sylvie\n\n[1] - https://tools.ietf.org/html/rfc4648#page-7\n"},{"id":"312822","messageId":"CAGyf7-Hp5b5r-NROVehnpwS2cSdwMz_kSUgzaQJ03Ba+K8g9wA@mail.gmail.com","threadId":"45245","inReplyTo":"CAAj3zPzwWr4u1qSMp5CwVMzExW2eg9LQ7t7RX-5m6fRRGh9pcA@mail.gmail.com","subject":"Re: [RFC] - url-safe base64 commit-id's","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2017-02-28T06:30:04Z","receivedAt":"2017-02-28T07:35:11Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Mon, Feb 27, 2017 at 6:27 PM, G. Sylvie Davies\n<sylvie@bit-booster.com> wrote:\n> Is there any appetite for base64'd commit-id's, using the url-safe\n> variant (e.g. RFC 4648 [1] with padding removed)?\n>\n> And so this:\n> 712bad335dfa9c410a83f9873614a19726acb3a8\n>\n> Becomes this:\n> cSutM136nEEKg_mHNhShlyass6g\n>\n>\n> Under the hood things cannot change (e.g., \".git/objects/71/\") because\n> file systems are not always case sensitive.\n>\n> But for \"git log\" and \"git show\" output it would be nice. And helps\n> with ambiguous commit id's too if you only want to specify a 7\n> character commit-id, since that encodes 42 bits instead of 28 bits.\n> I've run into problems with maximum command length on windows (32767\n> chars) because I was specifying so many commit-ids on the command-line\n> that I blew past that limit. This would help there, too.\n\nDepending on the command, have you considered using stdin instead? git log,\nfor example, is perfectly happy to read commit IDs from stdin instead of\nthe command line.\n\nIn general, I think the pattern of getting away from command line arguments\nis better than trying to shoehorn more data into the same character limit.\nBase64 encoding might help get a few more arguments into the available\nlimit, but in the end it's not going to solve the underlying problem.\n\n>\n> Might be particularly helpful with the transition to a new hash.\n> e.g., a 43 character Base64 id instead of a 64 character hex id.\n>\n>\n> - Sylvie\n>\n> [1] - https://tools.ietf.org/html/rfc4648#page-7\n"}]}