# [PATCH] gitweb: Add "next" link to commitdiff view 16 messages from 2006-10-22 to 2006-10-24. Participants: Jakub Narebski, Junio C Hamano, Petr Baudis. Thread: https://gitlist.dev/t/6005 ## Jakub Narebski, 2006-10-22 22:37 Subject: [PATCH] gitweb: Add "next" link to commitdiff view Message-ID: <200610230037.57183.jnareb@gmail.com> URL: https://gitlist.dev/e/200610230037.57183.jnareb%40gmail.com ``` Add a kind of "next" view in the bottom part of navigation bar for "commitdiff" view. For commitdiff between two commits: (from: _commit_) For commitdiff for one single parent commit: (parent: _commit_) For commitdiff for one merge commit (merge: _commit_ _commit_ ...) For commitdiff for root (parentless) commit (initial) where _link_ denotes hyperlink. SHA1 is shortened to 7 characters on display, everything is perhaps unnecessary esc_html on display. Signed-off-by: Jakub Narebski --- Junio (and others), is it what you wanted? The idea was to change "commitdiff" view only in minimal way, and preserve similarity to "commit" format. SHA1 ids are printed in monospace (fixed width) font. BTW. should we put '...' after shortened SHA1? Should those '...' be included in link? gitweb/gitweb.perl | 49 +++++++++++++++++++++++++++++++++++++++++++++---- 1 files changed, 45 insertions(+), 4 deletions(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index c9e57f0..4241d5c 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -3280,6 +3280,51 @@ sub git_commitdiff { if (!%co) { die_error(undef, "Unknown commit object"); } + + # we need to prepare $formats_nav before any parameter munging + my $formats_nav; + if ($format eq 'html') { + $formats_nav = + $cgi->a({-href => href(action=>"commitdiff_plain", + hash=>$hash, hash_parent=>$hash_parent)}, + "raw"); + + if (defined $hash_parent) { + # commitdiff with two commits given + my $hash_parent_short = $hash_parent; + if ($hash_parent =~ m/^[0-9a-fA-F]{40}$/) { + $hash_parent_short = substr($hash_parent, 0, 7); + } + $formats_nav .= + ' (from: ' . + $cgi->a({-href => href(action=>"commitdiff", + hash=>$hash_parent)}, + esc_html($hash_parent_short)) . + ')'; + } elsif (!$co{'parent'}) { + # --root commitdiff + $formats_nav .= ' (initial)'; + } elsif (scalar @{$co{'parents'}} == 1) { + # single parent commit + $formats_nav .= + ' (parent: ' . + $cgi->a({-href => href(action=>"commitdiff", + hash=>$co{'parent'})}, + esc_html(substr($co{'parent'}, 0, 7))) . + ')'; + } else { + # merge commit + $formats_nav .= + ' (merge: ' . + join(' ', map { + $cgi->a({-href => href(action=>"commitdiff", + hash=>$_)}, + esc_html(substr($_, 0, 7))); + } @{$co{'parents'}} ) . + ')'; + } + } + if (!defined $hash_parent) { $hash_parent = $co{'parent'} || '--root'; } @@ -3317,10 +3362,6 @@ sub git_commitdiff { if ($format eq 'html') { my $refs = git_get_references(); my $ref = format_ref_marker($refs, $co{'id'}); - my $formats_nav = - $cgi->a({-href => href(action=>"commitdiff_plain", - hash=>$hash, hash_parent=>$hash_parent)}, - "raw"); git_header_html(undef, $expires); git_print_page_nav('commitdiff','', $hash,$co{'tree'},$hash, $formats_nav); -- 1.4.2.1 ``` ## Jakub Narebski, 2006-10-22 22:43 Subject: Re: [PATCH] gitweb: Add "next" link to commitdiff view Message-ID: <200610230043.11524.jnareb@gmail.com> URL: https://gitlist.dev/e/200610230043.11524.jnareb%40gmail.com In-Reply-To: <200610230037.57183.jnareb@gmail.com> ``` BTW there are some errors in displaying commitdiff of initial commit, take for example a=commitdiff;h=161332a521fe10c41979bcd493d95e2ac562b7f for git.git repository in gitweb. Needs fixing. -- Jakub Narebski Poland ``` ## Junio C Hamano, 2006-10-22 23:16 Subject: Re: [PATCH] gitweb: Add "next" link to commitdiff view Message-ID: <7vd58k0wmx.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vd58k0wmx.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200610230037.57183.jnareb@gmail.com> ``` Jakub Narebski writes: > Add a kind of "next" view in the bottom part of navigation bar for > "commitdiff" view. > > For commitdiff between two commits: > (from: _commit_) > For commitdiff for one single parent commit: > (parent: _commit_) > For commitdiff for one merge commit > (merge: _commit_ _commit_ ...) > For commitdiff for root (parentless) commit > (initial) > where _link_ denotes hyperlink. SHA1 is shortened to 7 characters on > display, everything is perhaps unnecessary esc_html on display. > > Signed-off-by: Jakub Narebski Would it even be necessary to use any SHA-1 name in these cases, I wonder. Would it make the page less useful if we replace all of the above _commit_ with a fixed string, say, "parent"? I always hated gitweb diffs that prefix each filepair with their full 40-byte SHA-1 blob object names. It just adds noise to the output without adding any meaningful information. ``` ## Jakub Narebski, 2006-10-22 23:41 Subject: Re: [PATCH] gitweb: Add "next" link to commitdiff view Message-ID: <200610230141.54413.jnareb@gmail.com> URL: https://gitlist.dev/e/200610230141.54413.jnareb%40gmail.com In-Reply-To: <7vd58k0wmx.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Jakub Narebski writes: > >> Add a kind of "next" view in the bottom part of navigation bar for >> "commitdiff" view. >> >> For commitdiff between two commits: >> (from: _commit_) Perhaps we should use "(from: _commit_ to: _commit_)" here... >> For commitdiff for one single parent commit: >> (parent: _commit_) >> For commitdiff for one merge commit >> (merge: _commit_ _commit_ ...) >> For commitdiff for root (parentless) commit >> (initial) >> where _link_ denotes hyperlink. SHA1 is shortened to 7 characters on >> display, everything is perhaps unnecessary esc_html on display. >> >> Signed-off-by: Jakub Narebski > > Would it even be necessary to use any SHA-1 name in these cases, > I wonder. Would it make the page less useful if we replace all > of the above _commit_ with a fixed string, say, "parent"? I decided on using _shortened_ SHA1 because I didn't like neither "(parent parent ...) " nor "(parent1 parent2 ...)" for merges. Perhaps I should have used 8-characters abbreviation, like in git_blame2. And I was inspired by git-show output for merges: commit ff49fae6a547e5c70117970e01c53b64d983cd10 Merge: 7ad4ee7... 75f9007... 14eab2b... 0b35995... eee4609... > I always hated gitweb diffs that prefix each filepair with their > full 40-byte SHA-1 blob object names. It just adds noise to the > output without adding any meaningful information. I always thought about this only as a (somewhat sophisticated) separator marking where individual patch (patch for given files) begin. And a place to click (non-hidden link) for blob before and after. Please remember that this gitweb diff header was from the times where we didn't have difftree in commitdiff view. -- Jakub Narebski Poland ``` ## Jakub Narebski, 2006-10-23 22:08 Subject: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view Message-ID: <200610240008.08325.jnareb@gmail.com> URL: https://gitlist.dev/e/200610240008.08325.jnareb%40gmail.com In-Reply-To: <7vd58k0wmx.fsf@assigned-by-dhcp.cox.net> ``` Use fixed string instead of shortened SHA1 identifier of commit as a name for "mext" link in commitdiff view. Signed-off-by: Jakub Narebski --- Junio C Hamano wrote: > Jakub Narebski writes: > >> Add a kind of "next" link in the bottom part of navigation bar for >> "commitdiff" view. >> >> For commitdiff between two commits: >> (from: _commit_) >> For commitdiff for one single parent commit: >> (parent: _commit_) >> For commitdiff for one merge commit >> (merge: _commit_ _commit_ ...) >> For commitdiff for root (parentless) commit >> (initial) >> where _link_ denotes hyperlink. SHA1 is shortened to 7 characters on >> display, everything is perhaps unnecessary esc_html on display. > > Would it even be necessary to use any SHA-1 name in these cases, > I wonder. Would it make the page less useful if we replace all > of the above _commit_ with a fixed string, say, "parent"? > > I always hated gitweb diffs that prefix each filepair with their > full 40-byte SHA-1 blob object names. It just adds noise to the > output without adding any meaningful information. Here you have. I used patch on top of previous one instead of amending previous patch because I think it is interesting to have this history of this feature. This patch doesn't add any functionality. gitweb/gitweb.perl | 16 ++++++---------- 1 files changed, 6 insertions(+), 10 deletions(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index 4241d5c..255487d 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -3291,15 +3291,11 @@ sub git_commitdiff { if (defined $hash_parent) { # commitdiff with two commits given - my $hash_parent_short = $hash_parent; - if ($hash_parent =~ m/^[0-9a-fA-F]{40}$/) { - $hash_parent_short = substr($hash_parent, 0, 7); - } $formats_nav .= - ' (from: ' . + ' (' . $cgi->a({-href => href(action=>"commitdiff", hash=>$hash_parent)}, - esc_html($hash_parent_short)) . + 'from') . ')'; } elsif (!$co{'parent'}) { # --root commitdiff @@ -3307,19 +3303,19 @@ sub git_commitdiff { } elsif (scalar @{$co{'parents'}} == 1) { # single parent commit $formats_nav .= - ' (parent: ' . + ' (' . $cgi->a({-href => href(action=>"commitdiff", hash=>$co{'parent'})}, - esc_html(substr($co{'parent'}, 0, 7))) . + 'parent') . ')'; } else { # merge commit $formats_nav .= - ' (merge: ' . + ' (' . join(' ', map { $cgi->a({-href => href(action=>"commitdiff", hash=>$_)}, - esc_html(substr($_, 0, 7))); + 'parent'); } @{$co{'parents'}} ) . ')'; } -- 1.4.2.1 ``` ## Petr Baudis, 2006-10-23 23:21 Subject: Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view Message-ID: <20061023232117.GV20017@pasky.or.cz> URL: https://gitlist.dev/e/20061023232117.GV20017%40pasky.or.cz In-Reply-To: <200610240008.08325.jnareb@gmail.com> ``` Dear diary, on Tue, Oct 24, 2006 at 12:08:08AM CEST, I got a letter where Jakub Narebski said that... > @@ -3307,19 +3303,19 @@ sub git_commitdiff { > } elsif (scalar @{$co{'parents'}} == 1) { > # single parent commit > $formats_nav .= > - ' (parent: ' . > + ' (' . > $cgi->a({-href => href(action=>"commitdiff", > hash=>$co{'parent'})}, > - esc_html(substr($co{'parent'}, 0, 7))) . > + 'parent') . > ')'; > } else { > # merge commit > $formats_nav .= > - ' (merge: ' . > + ' (' . > join(' ', map { > $cgi->a({-href => href(action=>"commitdiff", > hash=>$_)}, > - esc_html(substr($_, 0, 7))); > + 'parent'); > } @{$co{'parents'}} ) . > ')'; > } For people not used to git, it would be more informative to keep the 'merge' text there. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i URL: https://gitlist.dev/e/200610241104.18517.jnareb%40gmail.com In-Reply-To: <20061023232117.GV20017@pasky.or.cz> ``` Use fixed string instead of shortened SHA1 identifier of commit as a name for "mext" link in commitdiff view. While at it make sure that we don't mistake option for a second commit. Signed-off-by: Jakub Narebski --- gitweb/gitweb.perl | 17 +++++++---------- 1 files changed, 7 insertions(+), 10 deletions(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index 4241d5c..9c81214 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -3289,17 +3289,14 @@ sub git_commitdiff { hash=>$hash, hash_parent=>$hash_parent)}, "raw"); - if (defined $hash_parent) { + if (defined $hash_parent && $hash_parent !~ m/^-/) { # commitdiff with two commits given - my $hash_parent_short = $hash_parent; - if ($hash_parent =~ m/^[0-9a-fA-F]{40}$/) { - $hash_parent_short = substr($hash_parent, 0, 7); - } + # second "commit" is not in fact diff option $formats_nav .= - ' (from: ' . + ' (' . $cgi->a({-href => href(action=>"commitdiff", hash=>$hash_parent)}, - esc_html($hash_parent_short)) . + 'from') . ')'; } elsif (!$co{'parent'}) { # --root commitdiff @@ -3307,10 +3304,10 @@ sub git_commitdiff { } elsif (scalar @{$co{'parents'}} == 1) { # single parent commit $formats_nav .= - ' (parent: ' . + ' (' . $cgi->a({-href => href(action=>"commitdiff", hash=>$co{'parent'})}, - esc_html(substr($co{'parent'}, 0, 7))) . + 'parent') . ')'; } else { # merge commit @@ -3319,7 +3316,7 @@ sub git_commitdiff { join(' ', map { $cgi->a({-href => href(action=>"commitdiff", hash=>$_)}, - esc_html(substr($_, 0, 7))); + 'parent'); } @{$co{'parents'}} ) . ')'; } -- 1.4.2.1 ``` ## Junio C Hamano, 2006-10-24 09:17 Subject: Re: [PATCH 2/1 (amend)] gitweb: Use fixed string for "next" link in commitdiff view Message-ID: <7vfydehy2q.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vfydehy2q.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200610241104.18517.jnareb@gmail.com> ``` Jakub Narebski writes: > Use fixed string instead of shortened SHA1 identifier of commit > as a name for "mext" link in commitdiff view. > > While at it make sure that we don't mistake option for a second > commit. > > Signed-off-by: Jakub Narebski > --- Q1. (amend) to fix what? Q2. "mext"? ``` ## Jakub Narebski, 2006-10-24 09:28 Subject: Re: [PATCH 2/1 (amend)] gitweb: Use fixed string for "next" link in commitdiff view Message-ID: <200610241128.34532.jnareb@gmail.com> URL: https://gitlist.dev/e/200610241128.34532.jnareb%40gmail.com In-Reply-To: <7vfydehy2q.fsf@assigned-by-dhcp.cox.net> ``` Dnia wtorek 24. października 2006 11:17, Junio C Hamano napisał: > Jakub Narebski writes: > >> Use fixed string instead of shortened SHA1 identifier of commit >> as a name for "mext" link in commitdiff view. >> >> While at it make sure that we don't mistake option for a second >> commit. >> >> Signed-off-by: Jakub Narebski >> --- > > Q1. (amend) to fix what? Petr "Pasky" Baudis wrote: >>               } else { >>                       # merge commit >>                       $formats_nav .= >> -                             ' (merge: ' . >> +                             ' (' . [...] > For people not used to git, it would be more informative to keep the > 'merge' text there. It also fixes detection if it is diff of two specified commits. Although $hash_parent is set to '--root' for rootloess commit later, we could have it set by hand. This is also preparation for later using '--cc' (although we wouldn't generate such URL, I don't think). > Q2. "mext"? Oops. -- Jakub Narebski Poland ``` ## Petr Baudis, 2006-10-24 11:49 Subject: Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view Message-ID: <20061024114923.GD20017@pasky.or.cz> URL: https://gitlist.dev/e/20061024114923.GD20017%40pasky.or.cz In-Reply-To: <200610240008.08325.jnareb@gmail.com> ``` Dear diary, on Tue, Oct 24, 2006 at 12:08:08AM CEST, I got a letter where Jakub Narebski said that... > Use fixed string instead of shortened SHA1 identifier of commit > as a name for "mext" link in commitdiff view. > > Signed-off-by: Jakub Narebski So I've read what the patch actually does this time, and I really dislike it. > Junio C Hamano wrote: > > Jakub Narebski writes: > > > >> Add a kind of "next" link in the bottom part of navigation bar for > >> "commitdiff" view. > >> > >> For commitdiff between two commits: > >> (from: _commit_) > >> For commitdiff for one single parent commit: > >> (parent: _commit_) > >> For commitdiff for one merge commit > >> (merge: _commit_ _commit_ ...) > >> For commitdiff for root (parentless) commit > >> (initial) > >> where _link_ denotes hyperlink. SHA1 is shortened to 7 characters on > >> display, everything is perhaps unnecessary esc_html on display. > > > > I always hated gitweb diffs that prefix each filepair with their > > full 40-byte SHA-1 blob object names. It just adds noise to the > > output without adding any meaningful information. I agree, using the shortened SHA1 would be definitely an improvement here, but > > Would it even be necessary to use any SHA-1 name in these cases, > > I wonder. Would it make the page less useful if we replace all > > of the above _commit_ with a fixed string, say, "parent"? I really disagree here - what's the point of not using SHA-1? The extra string carries zero information in comparison with the previous state and I just can't see how it *improves* stuff. If you're walking in a maze and making marks on walls, it's still more useful if you have corridors named by "A", "B", "C", "D" on junctions if you sometimes want to walk back to the marked corridors. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i URL: https://gitlist.dev/e/200610241359.57389.jnareb%40gmail.com In-Reply-To: <20061024114923.GD20017@pasky.or.cz> ``` Petr Baudis wrote: > Dear diary, on Tue, Oct 24, 2006 at 12:08:08AM CEST, I got a letter > where Jakub Narebski said that... >> Use fixed string instead of shortened SHA1 identifier of commit >> as a name for "mext" link in commitdiff view. >> >> Signed-off-by: Jakub Narebski > > So I've read what the patch actually does this time, and I really > dislike it. > >> Junio C Hamano wrote: >>> Jakub Narebski writes: [...] >>>> For commitdiff for one merge commit >>>> (merge: _commit_ _commit_ ...) [...] >>>> where _link_ denotes hyperlink. SHA1 is shortened to 7 characters on >>>> display, everything is perhaps unnecessary esc_html on display. >>> >>> I always hated gitweb diffs that prefix each filepair with their >>> full 40-byte SHA-1 blob object names. It just adds noise to the >>> output without adding any meaningful information. > > I agree, using the shortened SHA1 would be definitely an improvement > here, but I'm planning on revamping gitweb diff output. Any ideas? >>> Would it even be necessary to use any SHA-1 name in these cases, >>> I wonder. Would it make the page less useful if we replace all >>> of the above _commit_ with a fixed string, say, "parent"? > > I really disagree here - what's the point of not using SHA-1? The extra > string carries zero information in comparison with the previous state > and I just can't see how it *improves* stuff. If you're walking in a > maze and making marks on walls, it's still more useful if you have > corridors named by "A", "B", "C", "D" on junctions if you sometimes want > to walk back to the marked corridors. That's why instead of resending the patch/amending the commit, I have put changing shortened SHA1 to constant name in new patch. By the way, because those links to parents commitdiffs are just ordinary links, you can see when those links are visited. -- Jakub Narebski Poland ``` ## Petr Baudis, 2006-10-24 15:27 Subject: Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view Message-ID: <20061024152718.GE20017@pasky.or.cz> URL: https://gitlist.dev/e/20061024152718.GE20017%40pasky.or.cz In-Reply-To: <200610241359.57389.jnareb@gmail.com> ``` Dear diary, on Tue, Oct 24, 2006 at 01:59:57PM CEST, I got a letter where Jakub Narebski said that... > >>> Would it even be necessary to use any SHA-1 name in these cases, > >>> I wonder. Would it make the page less useful if we replace all > >>> of the above _commit_ with a fixed string, say, "parent"? > > > > I really disagree here - what's the point of not using SHA-1? The extra > > string carries zero information in comparison with the previous state > > and I just can't see how it *improves* stuff. If you're walking in a > > maze and making marks on walls, it's still more useful if you have > > corridors named by "A", "B", "C", "D" on junctions if you sometimes want > > to walk back to the marked corridors. > > That's why instead of resending the patch/amending the commit, I have > put changing shortened SHA1 to constant name in new patch. Huh, I don't quite understand. You threw away all the "A", "B", "C", "D" and kept only the marks. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i URL: https://gitlist.dev/e/7vu01thbvb.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20061024114923.GD20017@pasky.or.cz> ``` Petr Baudis writes: >> > Would it even be necessary to use any SHA-1 name in these cases, >> > I wonder. Would it make the page less useful if we replace all >> > of the above _commit_ with a fixed string, say, "parent"? > > I really disagree here - what's the point of not using SHA-1? The extra > string carries zero information in comparison with the previous state > and I just can't see how it *improves* stuff. If you're walking in a > maze and making marks on walls, it's still more useful if you have > corridors named by "A", "B", "C", "D" on junctions if you sometimes want > to walk back to the marked corridors. I think people would recognize A B C D as names but not 40- or 8- hexadecimal letters. I do not care much either way, actually, but I think it might make more sense to use abbreviated object names. On the other hand it may be Ok to have full 40 letters depending on the layout (e.g. the set of merge parents are shown on a single line in which case it would not fit, etc.). ``` ## Petr Baudis, 2006-10-24 17:26 Subject: Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view Message-ID: <20061024172627.GU18879@pasky.or.cz> URL: https://gitlist.dev/e/20061024172627.GU18879%40pasky.or.cz In-Reply-To: <7vu01thbvb.fsf@assigned-by-dhcp.cox.net> ``` On Tue, Oct 24, 2006 at 07:17:28PM CEST, Junio C Hamano wrote: > Petr Baudis writes: > > >> > Would it even be necessary to use any SHA-1 name in these cases, > >> > I wonder. Would it make the page less useful if we replace all > >> > of the above _commit_ with a fixed string, say, "parent"? > > > > I really disagree here - what's the point of not using SHA-1? The extra > > string carries zero information in comparison with the previous state > > and I just can't see how it *improves* stuff. If you're walking in a > > maze and making marks on walls, it's still more useful if you have > > corridors named by "A", "B", "C", "D" on junctions if you sometimes want > > to walk back to the marked corridors. > > I think people would recognize A B C D as names but not 40- or > 8- hexadecimal letters. 40-digit hex numbers is insane, I agree. But at least I personally tend to recognize 8-digit hex numbers when dancing around them intensively for a few minutes. Besides, it can be just "now I took the 8c5 way", which is much easier to train your neurons too than "now I took the fourth, uh, or was it the fifth parent? one, two, three, four, fifth... hmm, what's in the statusbar?". My point is that this does not improve the situation, and some people (me) think it makes it worse, so what's the point of the change? > I do not care much either way, actually, but I think it might > make more sense to use abbreviated object names. On the other > hand it may be Ok to have full 40 letters depending on the > layout (e.g. the set of merge parents are shown on a single line > in which case it would not fit, etc.). Yes, I'm all for abbreviated names, but I'm against just writing "parent" everywhere. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i URL: https://gitlist.dev/e/7viri9h8m4.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20061024172627.GU18879@pasky.or.cz> ``` Petr Baudis writes: > On Tue, Oct 24, 2006 at 07:17:28PM CEST, Junio C Hamano wrote: >> Petr Baudis writes: >> >> >> > Would it even be necessary to use any SHA-1 name in these cases, >> >> > I wonder. Would it make the page less useful if we replace all >> >> > of the above _commit_ with a fixed string, say, "parent"? >> > >> > I really disagree here - what's the point of not using SHA-1? The extra >> > string carries zero information in comparison with the previous state >> > and I just can't see how it *improves* stuff. If you're walking in a >> > maze and making marks on walls, it's still more useful if you have >> > corridors named by "A", "B", "C", "D" on junctions if you sometimes want >> > to walk back to the marked corridors. >> >> I think people would recognize A B C D as names but not 40- or >> 8- hexadecimal letters. > > 40-digit hex numbers is insane, I agree. But at least I personally tend > to recognize 8-digit hex numbers when dancing around them intensively > for a few minutes. Besides, it can be just "now I took the 8c5 way", > which is much easier to train your neurons too than "now I took the > fourth, uh, or was it the fifth parent? one, two, three, four, fifth... > hmm, what's in the statusbar?". > > My point is that this does not improve the situation, and some people > (me) think it makes it worse, so what's the point of the change? > >> I do not care much either way, actually, but I think it might >> make more sense to use abbreviated object names. On the other >> hand it may be Ok to have full 40 letters depending on the >> layout (e.g. the set of merge parents are shown on a single line >> in which case it would not fit, etc.). > > Yes, I'm all for abbreviated names, but I'm against just writing > "parent" everywhere. Fully agreed. Please make it so, if you so are inclined, perhaps between you and Jakub? ``` ## Jakub Narebski, 2006-10-24 18:37 Subject: Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view Message-ID: URL: https://gitlist.dev/e/ehlmfg%24bee%242%40sea.gmane.org In-Reply-To: <7viri9h8m4.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Petr Baudis writes: >> Yes, I'm all for abbreviated names, but I'm against just writing >> "parent" everywhere. > > Fully agreed.  Please make it so, if you so are inclined, > perhaps between you and Jakub? I'm all for abbreviated names (that was my first solution, wasn't it). This patch was because of Junio mail: > Would it even be necessary to use any SHA-1 name in these cases, > I wonder. Would it make the page less useful if we replace all > of the above _commit_ with a fixed string, say, "parent"? So please drop this patch. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ```