Add support for abbreviating hashes in URLs about git-brws

[rhysd]

Including entire hash is more accurate. And browser will redirect to the expanded hash URL automatically when accessing abbreviated hash URL. So I'm not seeing advantage to open a page with abbreviated hash URL. What is your use case?

[zx8]

I agree, it's most accurate, but for me 8 characters is always enough to reach the desired commit, and is very handy when linking commits in windows which are very narrow (e.g. Slack threads).

I'm not suggesting changing the default of 40 characters, just making it configurable for people like me where horizontal real estate is limited in some cases. 😄

[rhysd]

Do you mean you're not using git-brws for opening browser directly, but for making a string to share it on some other service like Slack?

e.g.

git brws --url | pbcopy

[zx8]

Yes, that's my exact use case. See the issue I accidentally raised #23 before I found the --url functionality!

For browsing alone, I don't have much use for shortened URLs, this would just be for linking shorter URLs to other people.

[rhysd]

OK, I'm considering interface. Two options:

1. Setting export GIT_BRWS_COMMIT_HAS_ABBREV=true always makes use of abbreviated hashes (default value is false)
2. Specifying --hash-abbrev option makes use of abbreviated hashes for the command execution

I guess 1. is more useful for you, am I correct?

[zx8]

Yeah, I think 1. would be my preference, but I think it's both more flexible and consistent with git rev-parse --short=<N> if its value was a number rather than a boolean?

$ git rev-parse--help
...
       --short[=length]
           Same as --verify but shortens the object name to a unique prefix
           with at least length characters. The minimum length is 4, the
           default is the effective value of the core.abbrev configuration
           variable (see git-config(1)).
...

See also core.abbrev:

core.abbrev

set the length object names are abbreviated to. If unspecified or set to
"auto", an appropriate value is computed based on the approximate number of
packed objects in your repository, which hopefully is enough for abbreviated
object names to stay unique for some time. The minimum length is 4.

[rhysd]

I want to start from minimal feature. Specifying length causes several error cases so I prefer fixed 7 length.

• when value other than unsigned integer
• when value is zero
• when value is longer than original hash
• when value is small (e.g. 2), generated URL is useless

7 length is used by Git and GitHub for human-friendly hash abbreviation. I could not come up with a use case where they want to specify a value other than 7 for the hash length. So I feel boolean value to switch full length or abbreviated short length is sufficient.

If someone raises a feature request to specify the hash length with practical use case, I would add a new option to specify hash length in the future.

[zx8]

Fair enough, but I think 8 is more suitable as a default because I’ve actually experienced collisions with 7 in very large repositories.

[rhysd]

But experiencing conflict with 7 length does not mean that 8 length is enough.. I want to use the same value as Git and GitHub because there would be some discussions to determine the size.

I know that the length used by Git had been 6 previously and was increased to 7 after. When Git increases the length to 8 in the future, git-brws also will follow it.

[zx8]

Ok, sounds reasonable!