* [PATCH 0/2] Minor document fixes @ 2019-04-06 13:27 Philip Oakley 2019-04-06 13:27 ` [PATCH 1/2] rerere doc: quote `rerere.enabled` Philip Oakley 2019-04-06 13:27 ` [PATCH 2/2] describe doc: remove '7-char' abbreviation reference Philip Oakley 0 siblings, 2 replies; 7+ messages in thread From: Philip Oakley @ 2019-04-06 13:27 UTC (permalink / raw) To: GitList A couple of minor fixes seen while looking at the Git-for-Wondows patch thicket and getting my head around the conflict resolutions I did note that there was potential for the rerere-train to be integrated with the main rerere code, and maybe learn from the range-diff, and the rebasing merge todo lists, when repetition is occuring in development. Maybe also 'show' options for the resolutions (-cc?). Possibly an intersting student project, including its documenation. Philip Oakley (2): rerere doc: quote `rerere.enabled` describe doc: remove '7-char' abbreviation reference Documentation/git-describe.txt | 2 +- Documentation/git-rerere.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.21.0.windows.1.80.gdc2ae9a382 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 1/2] rerere doc: quote `rerere.enabled` 2019-04-06 13:27 [PATCH 0/2] Minor document fixes Philip Oakley @ 2019-04-06 13:27 ` Philip Oakley 2019-04-08 1:10 ` Junio C Hamano 2019-04-06 13:27 ` [PATCH 2/2] describe doc: remove '7-char' abbreviation reference Philip Oakley 1 sibling, 1 reply; 7+ messages in thread From: Philip Oakley @ 2019-04-06 13:27 UTC (permalink / raw) To: GitList Signed-off-by: Philip Oakley <philipoakley@iee.org> --- Noticed while attempting to train the Git-for-Windows rebasing- merge series. --- Documentation/git-rerere.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt index df310d2a58..95763d7581 100644 --- a/Documentation/git-rerere.txt +++ b/Documentation/git-rerere.txt @@ -24,7 +24,7 @@ on the initial manual merge, and applying previously recorded hand resolutions to their corresponding automerge results. [NOTE] -You need to set the configuration variable rerere.enabled in order to +You need to set the configuration variable `rerere.enabled` in order to enable this command. -- 2.21.0.windows.1.80.gdc2ae9a382 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] rerere doc: quote `rerere.enabled` 2019-04-06 13:27 ` [PATCH 1/2] rerere doc: quote `rerere.enabled` Philip Oakley @ 2019-04-08 1:10 ` Junio C Hamano 0 siblings, 0 replies; 7+ messages in thread From: Junio C Hamano @ 2019-04-08 1:10 UTC (permalink / raw) To: Philip Oakley; +Cc: GitList Philip Oakley <philipoakley@iee.org> writes: > Signed-off-by: Philip Oakley <philipoakley@iee.org> > --- > Noticed while attempting to train the Git-for-Windows rebasing- > merge series. > --- > Documentation/git-rerere.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt > index df310d2a58..95763d7581 100644 > --- a/Documentation/git-rerere.txt > +++ b/Documentation/git-rerere.txt > @@ -24,7 +24,7 @@ on the initial manual merge, and applying previously recorded > hand resolutions to their corresponding automerge results. > > [NOTE] > -You need to set the configuration variable rerere.enabled in order to > +You need to set the configuration variable `rerere.enabled` in order to > enable this command. OK. That sounds good. Thanks. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 2/2] describe doc: remove '7-char' abbreviation reference 2019-04-06 13:27 [PATCH 0/2] Minor document fixes Philip Oakley 2019-04-06 13:27 ` [PATCH 1/2] rerere doc: quote `rerere.enabled` Philip Oakley @ 2019-04-06 13:27 ` Philip Oakley 2019-04-07 20:05 ` Ævar Arnfjörð Bjarmason 1 sibling, 1 reply; 7+ messages in thread From: Philip Oakley @ 2019-04-06 13:27 UTC (permalink / raw) To: GitList While the minimum is 7-char, the unambiguous length can be longer. Signed-off-by: Philip Oakley <philipoakley@iee.org> --- noticed while looking int the Git-for-Windows patch thicket - was looking for the ~n^m style! --- Documentation/git-describe.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt index ccdc5f83d6..a88f6ae2c6 100644 --- a/Documentation/git-describe.txt +++ b/Documentation/git-describe.txt @@ -139,7 +139,7 @@ at the end. The number of additional commits is the number of commits which would be displayed by "git log v1.0.4..parent". -The hash suffix is "-g" + 7-char abbreviation for the tip commit +The hash suffix is "-g" + unambiguous abbreviation for the tip commit of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). The "g" prefix stands for "git" and is used to allow describing the version of a software depending on the SCM the software is managed with. This is useful -- 2.21.0.windows.1.80.gdc2ae9a382 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] describe doc: remove '7-char' abbreviation reference 2019-04-06 13:27 ` [PATCH 2/2] describe doc: remove '7-char' abbreviation reference Philip Oakley @ 2019-04-07 20:05 ` Ævar Arnfjörð Bjarmason 2019-04-07 21:04 ` Junio C Hamano 2019-04-07 22:23 ` Philip Oakley 0 siblings, 2 replies; 7+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2019-04-07 20:05 UTC (permalink / raw) To: Philip Oakley; +Cc: GitList, Linus Torvalds, Jeff King On Sat, Apr 06 2019, Philip Oakley wrote: > While the minimum is 7-char, the unambiguous length can be longer. > > Signed-off-by: Philip Oakley <philipoakley@iee.org> > --- > noticed while looking int the Git-for-Windows patch thicket - > was looking for the ~n^m style! > --- > Documentation/git-describe.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt > index ccdc5f83d6..a88f6ae2c6 100644 > --- a/Documentation/git-describe.txt > +++ b/Documentation/git-describe.txt > @@ -139,7 +139,7 @@ at the end. > > The number of additional commits is the number > of commits which would be displayed by "git log v1.0.4..parent". > -The hash suffix is "-g" + 7-char abbreviation for the tip commit > +The hash suffix is "-g" + unambiguous abbreviation for the tip commit > of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). > The "g" prefix stands for "git" and is used to allow describing the version of > a software depending on the SCM the software is managed with. This is useful Both the old/new version are subtly wrong. Whether the new one is better is another matter. First, there's more places we mention the now-incorrect 7 characters, at least these (one of which you're fixing). Found by grepping for ' 7 ' and '7.*abbr': Documentation/git-branch.txt-181---abbrev=<length>:: Documentation/git-branch.txt-182- Alter the sha1's minimum display length in the output listing. Documentation/git-branch.txt:183: The default value is 7 and can be overridden by the `core.abbrev` Documentation/git-branch.txt-184- config option. Documentation/git-describe.txt-65---abbrev=<n>:: Documentation/git-describe.txt:66: Instead of using the default 7 hexadecimal digits as the Documentation/git-describe.txt-67- abbreviated object name, use <n> digits, or as many digits Documentation/git-ls-tree.txt-93-Object size identified by <object> is given in bytes, and right-justified Documentation/git-ls-tree.txt:94:with minimum width of 7 characters. Object size is given only for blobs Documentation/git-ls-tree.txt-95-(file) entries; for other entries `-` character is used in place of size. Documentation/gittutorial-2.txt-44- Documentation/gittutorial-2.txt:45:What are the 7 digits of hex that Git responded to the commit with? Documentation/gittutorial-2.txt-46- [...] Documentation/gittutorial-2.txt-52-name), and that the contents of a Git object will never change (since Documentation/gittutorial-2.txt:53:that would change the object's name as well). The 7 char hex strings Documentation/gittutorial-2.txt-54-here are simply the abbreviation of such 40 character long strings. It was never correct that we'd pick 7 characters, we'd *try* that before e6c587c733 ("abbrev: auto size the default abbreviation", 2016-09-30) but would pick a longer one if it was unambiguous. Whereas "unambiguous abbreviation" isn't correct either, and arguably less correct. At least 7 is what we *still* pick as a fallback in lieu of the auto-sizing, but just "unambiguous abbreviation" implies that in a repo with some 10 objects we might show just one character, or that we'd post-e6c587c733 pick say 7 characters in a repository where it *is* unambiguous but where we've auto-sized to 12. I've been meaning to follow-up on https://public-inbox.org/git/20190204161217.20047-1-avarab@gmail.com/ where I among other things wanted to just have these instances all say "commits will be abbreviated as described in XYZ in linkgit:<something>" and summarize what happens there. I don't mind if this goes in, I mainly wrote this E-Mail as a brain dump since it jolted my memory on the topic, and so that I could dig it up later & see how I intended to follow-up on those #leftoverbits ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] describe doc: remove '7-char' abbreviation reference 2019-04-07 20:05 ` Ævar Arnfjörð Bjarmason @ 2019-04-07 21:04 ` Junio C Hamano 2019-04-07 22:23 ` Philip Oakley 1 sibling, 0 replies; 7+ messages in thread From: Junio C Hamano @ 2019-04-07 21:04 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: Philip Oakley, GitList, Linus Torvalds, Jeff King Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > I've been meaning to follow-up on > https://public-inbox.org/git/20190204161217.20047-1-avarab@gmail.com/ > where I among other things wanted to just have these instances all say > "commits will be abbreviated as described in XYZ in linkgit:<something>" > and summarize what happens there. Thanks for a pointer. I do recall that I found that one very promising. I can see from https://public-inbox.org/git/xmqq7eefv02i.fsf@gitster-ct.c.googlers.com/ that I was mostly OK with the end-user facing documentation part, and also from https://public-inbox.org/git/xmqq36p3uxq2.fsf@gitster-ct.c.googlers.com/ I was OK with the idea of exposing the computation but found that the exact command option it was done with was suboptimal; neither of these was pointing out any incorrectable flaw). > I don't mind if this goes in, I mainly wrote this E-Mail as a brain dump > since it jolted my memory on the topic, and so that I could dig it up > later & see how I intended to follow-up on those #leftoverbits ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] describe doc: remove '7-char' abbreviation reference 2019-04-07 20:05 ` Ævar Arnfjörð Bjarmason 2019-04-07 21:04 ` Junio C Hamano @ 2019-04-07 22:23 ` Philip Oakley 1 sibling, 0 replies; 7+ messages in thread From: Philip Oakley @ 2019-04-07 22:23 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason, Philip Oakley Cc: GitList, Linus Torvalds, Jeff King, Junio C Hamano Hi Ævar On 07/04/2019 21:05, Ævar Arnfjörð Bjarmason wrote: > On Sat, Apr 06 2019, Philip Oakley wrote: > >> While the minimum is 7-char, the unambiguous length can be longer. >> >> Signed-off-by: Philip Oakley <philipoakley@iee.org> >> --- >> noticed while looking int the Git-for-Windows patch thicket - >> was looking for the ~n^m style! >> --- >> Documentation/git-describe.txt | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt >> index ccdc5f83d6..a88f6ae2c6 100644 >> --- a/Documentation/git-describe.txt >> +++ b/Documentation/git-describe.txt >> @@ -139,7 +139,7 @@ at the end. >> >> The number of additional commits is the number >> of commits which would be displayed by "git log v1.0.4..parent". >> -The hash suffix is "-g" + 7-char abbreviation for the tip commit >> +The hash suffix is "-g" + unambiguous abbreviation for the tip commit >> of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). >> The "g" prefix stands for "git" and is used to allow describing the version of >> a software depending on the SCM the software is managed with. This is useful > Both the old/new version are subtly wrong. Whether the new one is better > is another matter. > > First, there's more places we mention the now-incorrect 7 characters, at > least these (one of which you're fixing). Found by grepping for ' 7 ' > and '7.*abbr': > > Documentation/git-branch.txt-181---abbrev=<length>:: > Documentation/git-branch.txt-182- Alter the sha1's minimum display length in the output listing. > Documentation/git-branch.txt:183: The default value is 7 and can be overridden by the `core.abbrev` > Documentation/git-branch.txt-184- config option. > Documentation/git-describe.txt-65---abbrev=<n>:: > Documentation/git-describe.txt:66: Instead of using the default 7 hexadecimal digits as the > Documentation/git-describe.txt-67- abbreviated object name, use <n> digits, or as many digits > Documentation/git-ls-tree.txt-93-Object size identified by <object> is given in bytes, and right-justified > Documentation/git-ls-tree.txt:94:with minimum width of 7 characters. Object size is given only for blobs > Documentation/git-ls-tree.txt-95-(file) entries; for other entries `-` character is used in place of size. > Documentation/gittutorial-2.txt-44- > Documentation/gittutorial-2.txt:45:What are the 7 digits of hex that Git responded to the commit with? > Documentation/gittutorial-2.txt-46- > [...] > Documentation/gittutorial-2.txt-52-name), and that the contents of a Git object will never change (since > Documentation/gittutorial-2.txt:53:that would change the object's name as well). The 7 char hex strings > Documentation/gittutorial-2.txt-54-here are simply the abbreviation of such 40 character long strings. > > It was never correct that we'd pick 7 characters, we'd *try* that before > e6c587c733 ("abbrev: auto size the default abbreviation", 2016-09-30) > but would pick a longer one if it was unambiguous. > > Whereas "unambiguous abbreviation" isn't correct either, and arguably > less correct. At least 7 is what we *still* pick as a fallback in lieu > of the auto-sizing, but just "unambiguous abbreviation" implies that in > a repo with some 10 objects we might show just one character, or that > we'd post-e6c587c733 pick say 7 characters in a repository where it *is* > unambiguous but where we've auto-sized to 12. > > I've been meaning to follow-up on > https://public-inbox.org/git/20190204161217.20047-1-avarab@gmail.com/ > where I among other things wanted to just have these instances all say > "commits will be abbreviated as described in XYZ in linkgit:<something>" > and summarize what happens there. > > I don't mind if this goes in, I mainly wrote this E-Mail as a brain dump > since it jolted my memory on the topic, and so that I could dig it up > later & see how I intended to follow-up on those #leftoverbits I had had a look at most of the other '7 ' references and decided that most of those I saw were about the minimum abbreviation settings, but it looks like I maybe missed a few - like the gittutorials. I was aware that I was being slightly economical with the truth, but was just looking for a way of implying 'variable length' and I punted on the long explanation as the particular reference was way down the document. If anyone has a suggestion for a better phrase I'd be happy And I could add it to the tutorials as well). Philip (added Junio, given his follow up email, though we still need a term for this.) ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-04-08 1:10 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-06 13:27 [PATCH 0/2] Minor document fixes Philip Oakley 2019-04-06 13:27 ` [PATCH 1/2] rerere doc: quote `rerere.enabled` Philip Oakley 2019-04-08 1:10 ` Junio C Hamano 2019-04-06 13:27 ` [PATCH 2/2] describe doc: remove '7-char' abbreviation reference Philip Oakley 2019-04-07 20:05 ` Ævar Arnfjörð Bjarmason 2019-04-07 21:04 ` Junio C Hamano 2019-04-07 22:23 ` Philip Oakley
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).