Beat Bolli [off-list ref] writes:
When referring to earlier commits in commit messages or other text, one
of the established formats is
<abbrev-sha> ("<summary>", <author-date>)
...
+proc copysummary {} {
+ global rowmenuid commitinfo
+
+ set id [string range $rowmenuid 0 7]
+ set info $commitinfo($rowmenuid)
+ set commit [lindex $info 0]
7 hexdigits is not always an appropriate value for all projects.
The minimum necessary to guarantee uniqueness varies on project, and
it is not a good idea to hardcode such a small value. Not-so-old
Linux kernel history seems to use at least 12, for example.
I believe that the "one of the established formats" comes from a
"git one" alias I published somewhere long time ago, that did
something like this:
git show -s --abbrev=8 --pretty='format:%h (%s, %ai' "$@" |
sed -e 's/ [012][0-9]:[0-5][0-9]:[0-5][0-9] [-+][0-9][0-9][0-9][0-9]$/)/'
where the combination of --abbrev=8 and format:%h asks for a unique
abbreviation that is at least 8 hexdigits long but can use more than
8 if it is not long enough to uniquely identify the given commit.
I do not offhand know how $commitinfo is populated, but perhaps you
can tweak that code to ask for both %H (for the full commit object
ID) and %h (for the unique abbreviation of appropriate length) and
store the value for %h to a new field in the $commitinfo($rowmenuid)
array, so that you do not have to have such a hard-coded truncation
here?
+ set date [formatdate [lindex $info 2]]
+ set summary "$id (\"$commit\", $date)"
+
+ clipboard clear
+ clipboard append $summary
+}
+
proc writecommit {} {
global rowmenuid wrcomtop commitinfo wrcomcmd NS
Junio C Hamano [off-list ref] wrote:
Beat Bolli [off-list ref] writes:
quoted
When referring to earlier commits in commit messages or other text, one
of the established formats is
<abbrev-sha> ("<summary>", <author-date>)
...
+proc copysummary {} {
+ global rowmenuid commitinfo
+
+ set id [string range $rowmenuid 0 7]
+ set info $commitinfo($rowmenuid)
+ set commit [lindex $info 0]
7 hexdigits is not always an appropriate value for all projects.
The minimum necessary to guarantee uniqueness varies on project, and
it is not a good idea to hardcode such a small value. Not-so-old
Linux kernel history seems to use at least 12, for example.
I believe that the "one of the established formats" comes from a
"git one" alias I published somewhere long time ago, that did
something like this:
git show -s --abbrev=8 --pretty='format:%h (%s, %ai' "$@" |
sed -e 's/ [012][0-9]:[0-5][0-9]:[0-5][0-9] [-+][0-9][0-9][0-9][0-9]$/)/'
where the combination of --abbrev=8 and format:%h asks for a unique
abbreviation that is at least 8 hexdigits long but can use more than
8 if it is not long enough to uniquely identify the given commit.
For the intended use case of this feature (referring to earlier commits
in commit messages), guaranteeing uniqueness isn't sufficiant either.
What is unique at the time of creating the commit might no longer be
unique a few years later.
So one strategy would be to add one or two digits to what %h returns, to
give some future leeway; or rely on the user to configure core.abbrev
appropriatly for their project; or just make the hard-coded value
configurable, as Hannes suggests.
FWIW, a discussion of this that I find useful can be found here:
<http://blog.cuviper.com/2013/11/10/how-short-can-git-abbreviate/>.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
On 2015-07-17 10:50, lists@haller-berlin.de wrote:
Junio C Hamano [off-list ref] wrote:
quoted
Beat Bolli [off-list ref] writes:
quoted
When referring to earlier commits in commit messages or other
text, one
quoted
of the established formats is
<abbrev-sha> ("<summary>", <author-date>)
...
+proc copysummary {} {
+ global rowmenuid commitinfo
+
+ set id [string range $rowmenuid 0 7]
+ set info $commitinfo($rowmenuid)
+ set commit [lindex $info 0]
7 hexdigits is not always an appropriate value for all projects.
The minimum necessary to guarantee uniqueness varies on project, and
it is not a good idea to hardcode such a small value. Not-so-old
Linux kernel history seems to use at least 12, for example.
I believe that the "one of the established formats" comes from a
"git one" alias I published somewhere long time ago, that did
something like this:
git show -s --abbrev=8 --pretty='format:%h (%s, %ai' "$@" |
sed -e 's/ [012][0-9]:[0-5][0-9]:[0-5][0-9]
[-+][0-9][0-9][0-9][0-9]$/)/'
where the combination of --abbrev=8 and format:%h asks for a unique
abbreviation that is at least 8 hexdigits long but can use more than
8 if it is not long enough to uniquely identify the given commit.
For the intended use case of this feature (referring to earlier
commits
in commit messages), guaranteeing uniqueness isn't sufficiant either.
What is unique at the time of creating the commit might no longer be
unique a few years later.
This is true, but the purpose of the format with the summary text and
date
is exactly to make it redundant enough that the hash doesn't have to be
unique
in eternity.
So one strategy would be to add one or two digits to what %h returns,
to
give some future leeway; or rely on the user to configure core.abbrev
appropriatly for their project; or just make the hard-coded value
configurable, as Hannes suggests.
FWIW, a discussion of this that I find useful can be found here:
<http://blog.cuviper.com/2013/11/10/how-short-can-git-abbreviate/>.