* [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-29 23:51 UTC (permalink / raw)
To: git
In-Reply-To: <200610291122.30852.jnareb@gmail.com>
Replace "gitweb diff header" with its full sha1 of blobs and replace
it by "git diff" header and extended diff header. Change also somewhat
highlighting of diffs.
Changes:
* "gitweb diff header" which looked for example like below:
file:_<sha1 before>_ -> file:_<sha1 after>_
where 'file' is file type and '<sha1>' is full sha1 of blob is
changed to
diff --git _a/<file before>_ _b/<file after>_
In both cases links are visible and use default link style. If file
is added, a/<file> is not hyperlinked, if file is deleted, b/<file>
is not hyperlinked.
* there is added "extended diff header", with <path> and <hash>
hyperlinked (and <hash> shortened to 7 characters), and <mode>
explained: '<mode>' is extended to '<mode> (<file type>)'.
* <file> hyperlinking should work also when <file> is originally
quoted. For now we present filename quoted. This needed changes to
parse_difftree_raw_line subroutine. And doesn't work: perhaps
unquote is broken.
* from-file/to-file two-line header lines have slightly darker color
than removed/added lines.
* chunk header has now delicate line above for easier finding chunk
boundary, and top margin of 1px.
WORK IN PROGRESS: might not work (and actually doesn't work correctly)
for strange filenames, i.e. filenames contaning either metacharacters
or having TAB, LF, backslash or doublequote in them.
Code should be much more clean, by the way.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.css | 46 +++++++++++---
gitweb/gitweb.perl | 178 +++++++++++++++++++++++++++++++++-------------------
2 files changed, 151 insertions(+), 73 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 83d900d..3aeceed 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -303,6 +303,33 @@ td.mode {
font-family: monospace;
}
+
+div.diff.header,
+div.diff.extended_header {
+ white-space: normal;
+}
+
+div.diff.header {
+ font-weight: bold;
+
+ background-color: #edece6;
+
+ margin-top: 4px;
+ padding: 4px 0px 2px 0px;
+ border: solid #d9d8d1;
+ border-width: 1px 0px 1px 0px;
+}
+
+div.diff.extended_header,
+div.diff.extended_header a.list {
+ color: #777777;
+}
+
+div.diff.extended_header {
+ background-color: #f6f5ee;
+ padding: 2px 0px 2px 0px;
+}
+
div.diff a.list {
text-decoration: none;
}
@@ -312,31 +339,34 @@ div.diff a.list:hover {
}
div.diff.to_file a.list,
-div.diff.to_file,
+div.diff.to_file {
+ color: #007000;
+}
+
div.diff.add {
color: #008800;
}
div.diff.from_file a.list,
-div.diff.from_file,
+div.diff.from_file {
+ color: #aa0000;
+}
+
div.diff.rem {
color: #cc0000;
}
div.diff.chunk_header {
color: #990099;
+ border: dotted #ffbbff;
+ border-width: 1px 0px 0px 0px;
+ margin-top: 1px;
}
div.diff.incomplete {
color: #cccccc;
}
-div.diff_info {
- font-family: monospace;
- color: #000099;
- background-color: #edece6;
- font-style: italic;
-}
div.index_include {
border: solid #d9d8d1;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index cbab3c9..a5a140c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1255,9 +1255,12 @@ sub parse_difftree_raw_line {
$res{'status'} = $5;
$res{'similarity'} = $6;
if ($res{'status'} eq 'R' || $res{'status'} eq 'C') { # renamed or copied
- ($res{'from_file'}, $res{'to_file'}) = map { unquote($_) } split("\t", $7);
+ ($res{'from_file_raw'}, $res{'to_file_raw'}) = split("\t", $7);
+ $res{'from_file'} = unquote($res{'from_file_raw'});
+ $res{'to_file'} = unquote($res{'to_file_raw'});
} else {
- $res{'file'} = unquote($7);
+ $res{'file_raw'} = $7;
+ $res{'file'} = unquote($res{'file_raw'});
}
}
# 'c512b523472485aef4fff9e57b229d9d243c967f'
@@ -2023,7 +2026,9 @@ sub git_patchset_body {
my $patch_idx = 0;
my $in_header = 0;
my $patch_found = 0;
+ my $skip_patch = 0;
my $diffinfo;
+ my (%from, %to);
print "<div class=\"patchset\">\n";
@@ -2033,6 +2038,8 @@ sub git_patchset_body {
if ($patch_line =~ m/^diff /) { # "git diff" header
# beginning of patch (in patchset)
+ $skip_patch = 0;
+
if ($patch_found) {
# close previous patch
print "</div>\n"; # class="patch"
@@ -2042,96 +2049,137 @@ sub git_patchset_body {
}
print "<div class=\"patch\" id=\"patch". ($patch_idx+1) ."\">\n";
+ # read and prepare patch information
if (ref($difftree->[$patch_idx]) eq "HASH") {
+ # pre-parsed (or generated by hand)
$diffinfo = $difftree->[$patch_idx];
} else {
$diffinfo = parse_difftree_raw_line($difftree->[$patch_idx]);
}
+ if ($diffinfo->{'status'} ne "A") { # not new (added) file
+ $from{'name'} = $diffinfo->{'from_file_raw'} || $diffinfo->{'file_raw'};
+ # because of "a/file" not a/"file"
+ $from{'quoted'} = ($from{'name'} =~ s/^"(.*)"$/$1/);
+
+ my $file = $diffinfo->{'from_file'} || $diffinfo->{'file'};
+ $from{'href'} = href(action=>"blob", hash_base=>$hash_parent,
+ hash=>$diffinfo->{'from_id'}, file_name=>$file);
+ }
+ if ($diffinfo->{'status'} ne "D") { # not deleted file
+ $to{'name'} = $diffinfo->{'to_file_raw'} || $diffinfo->{'file_raw'};
+ # because of "b/file" not b/"file"
+ $to{'quoted'} = ($to{'name'} =~ s/^"(.*)"$/$1/);
+
+ my $file = $diffinfo->{'to_file'} || $diffinfo->{'file'};
+ $to{'href'} = href(action=>"blob", hash_base=>$hash,
+ hash=>$diffinfo->{'to_id'}, file_name=>$file);
+ }
$patch_idx++;
# for now we skip empty patches
if ($diffinfo->{'from_id'} eq $diffinfo->{'to_id'}) {
# no change, empty patch
$in_header = 1;
+ $skip_patch = 0;
next LINE;
}
- if ($diffinfo->{'status'} eq "A") { # added
- print "<div class=\"diff_info\">" . file_type($diffinfo->{'to_mode'}) . ":" .
- $cgi->a({-href => href(action=>"blob", hash_base=>$hash,
- hash=>$diffinfo->{'to_id'}, file_name=>$diffinfo->{'file'})},
- $diffinfo->{'to_id'}) . " (new)" .
- "</div>\n"; # class="diff_info"
-
- } elsif ($diffinfo->{'status'} eq "D") { # deleted
- print "<div class=\"diff_info\">" . file_type($diffinfo->{'from_mode'}) . ":" .
- $cgi->a({-href => href(action=>"blob", hash_base=>$hash_parent,
- hash=>$diffinfo->{'from_id'}, file_name=>$diffinfo->{'file'})},
- $diffinfo->{'from_id'}) . " (deleted)" .
- "</div>\n"; # class="diff_info"
-
- } elsif ($diffinfo->{'status'} eq "R" || # renamed
- $diffinfo->{'status'} eq "C" || # copied
- $diffinfo->{'status'} eq "2") { # with two filenames (from git_blobdiff)
- print "<div class=\"diff_info\">" .
- file_type($diffinfo->{'from_mode'}) . ":" .
- $cgi->a({-href => href(action=>"blob", hash_base=>$hash_parent,
- hash=>$diffinfo->{'from_id'}, file_name=>$diffinfo->{'from_file'})},
- $diffinfo->{'from_id'}) .
- " -> " .
- file_type($diffinfo->{'to_mode'}) . ":" .
- $cgi->a({-href => href(action=>"blob", hash_base=>$hash,
- hash=>$diffinfo->{'to_id'}, file_name=>$diffinfo->{'to_file'})},
- $diffinfo->{'to_id'});
- print "</div>\n"; # class="diff_info"
-
- } else { # modified, mode changed, ...
- print "<div class=\"diff_info\">" .
- file_type($diffinfo->{'from_mode'}) . ":" .
- $cgi->a({-href => href(action=>"blob", hash_base=>$hash_parent,
- hash=>$diffinfo->{'from_id'}, file_name=>$diffinfo->{'file'})},
- $diffinfo->{'from_id'}) .
- " -> " .
- file_type($diffinfo->{'to_mode'}) . ":" .
- $cgi->a({-href => href(action=>"blob", hash_base=>$hash,
- hash=>$diffinfo->{'to_id'}, file_name=>$diffinfo->{'file'})},
- $diffinfo->{'to_id'});
- print "</div>\n"; # class="diff_info"
+ # print "git diff" header
+ if ($from{'name'}) {
+ my $from_link = $cgi->a({-href => $from{'href'}, -class => "path"},
+ 'a/' . esc_html($from{'name'}));
+ my ($q, $qq) = $from{'quoted'} ? ('"', '"') : ('', '');
+ $patch_line =~ s|${q}a/\Q$from{'name'}\E${q}|${qq}$from_link${qq}|;
+ } else {
+ # at least one of %from and %to must be set
+ $patch_line =~ s|(["]?a/\Q$to{'name'}\E["]?)|esc_html($1)|e;
+ }
+ if ($to{'name'}) {
+ my $to_link = $cgi->a({-href => $to{'href'}, -class => "path"},
+ 'b/' . esc_html($to{'name'}));
+ my ($q, $qq) = $to{'quoted'} ? ('"', '"') : ('', '');
+ $patch_line =~ s|${q}b/\Q$to{'name'}\E${q}$|${qq}$to_link${qq}|;
+ } else {
+ # at least one of %from and %to must be set
+ $patch_line =~ s|(["]?b/\Q$from{'name'}\E["]?)$|esc_html($1)|e;
}
- #print "<div class=\"diff extended_header\">\n";
+ print "<div class=\"diff header\">$patch_line</div>\n";
+ print "<div class=\"diff extended_header\">\n";
$in_header = 1;
next LINE;
+ } else {
+ next LINE if $skip_patch;
} # start of patch in patchset
+ if ($in_header) {
+ if ($patch_line !~ m/^---/) {
+ # match <path>
+ if ($patch_line =~ m!^(copy|rename) from ! && $from{'name'}) {
+ my $qq = $from{'quoted'} ? '"' : '';
+ my $from_link = $cgi->a({-href=>$from{'href'},-class=>"list"},
+ esc_html($from{'name'}));
+ $patch_line =~ s!from .*$!from $qq$from_link$qq!;
+ }
+ if ($patch_line =~ m!^(copy|rename) to ! && $to{'name'}) {
+ my $qq = $to{'quoted'} ? '"' : '';
+ my $to_link = $cgi->a({-href=>$to{'href'},-class=>"list"},
+ esc_html($to{'name'}));
+ $patch_line =~ s!to .*$!to $qq$to_link$qq!;
+ }
+ # match <mode>
+ if ($patch_line =~ m/\s(\d{6})$/) {
+ $patch_line .= '<span class="info"> (' . file_type($1) . ')</span>';
+ }
+ # match <hash>
+ if ($patch_line =~ m/^index/) {
+ my ($from_link, $to_link);
+ if ($from{'href'}) {
+ $from_link = $cgi->a({-href=>$from{'href'},-class=>"list"},
+ substr($diffinfo->{'from_id'},0,7));
+ } else {
+ $from_link = '0' x 7;
+ }
+ if ($to{'href'}) {
+ $to_link = $cgi->a({-href=>$to{'href'},-class=>"list"},
+ substr($diffinfo->{'to_id'},0,7));
+ } else {
+ $to_link = '0' x 7;
+ }
+ my ($from_id, $to_id) = ($diffinfo->{'from_id'}, $diffinfo->{'to_id'});
+ $patch_line =~ s!$from_id\.\.$to_id!$from_link..$to_link!;
+ }
+ print $patch_line . "<br/>\n";
- if ($in_header && $patch_line =~ m/^---/) {
- #print "</div>\n"; # class="diff extended_header"
- $in_header = 0;
+ } else {
+ #$patch_line =~ m/^---/;
+ print "</div>\n"; # class="diff extended_header"
+ $in_header = 0;
+
+ if ($from{'name'}) {
+ my $qq = $from{'quoted'} ? '"' : '';
+ my $from_link = $cgi->a({-href=>$from{'href'},-class=>"list"},
+ esc_html($from{'name'}));
+ $patch_line =~ s!["]?a/.*$!${qq}a/$from_link${qq}!;
+ }
+ print "<div class=\"diff from_file\">$patch_line</div>\n";
- my $file = $diffinfo->{'from_file'};
- $file ||= $diffinfo->{'file'};
- $file = $cgi->a({-href => href(action=>"blob", hash_base=>$hash_parent,
- hash=>$diffinfo->{'from_id'}, file_name=>$file),
- -class => "list"}, esc_html($file));
- $patch_line =~ s|a/.*$|a/$file|g;
- print "<div class=\"diff from_file\">$patch_line</div>\n";
+ $patch_line = <$fd>;
+ chomp $patch_line;
- $patch_line = <$fd>;
- chomp $patch_line;
+ #$patch_line =~ m/^+++/;
+ if ($to{'name'}) {
+ my $qq = $to{'quoted'} ? '"' : '';
+ my $from_link = $cgi->a({-href=>$to{'href'},-class=>"list"},
+ esc_html($to{'name'}));
+ $patch_line =~ s!["]?b/.*$!${qq}b/$from_link${qq}!;
+ }
+ print "<div class=\"diff to_file\">$patch_line</div>\n";
- #$patch_line =~ m/^+++/;
- $file = $diffinfo->{'to_file'};
- $file ||= $diffinfo->{'file'};
- $file = $cgi->a({-href => href(action=>"blob", hash_base=>$hash,
- hash=>$diffinfo->{'to_id'}, file_name=>$file),
- -class => "list"}, esc_html($file));
- $patch_line =~ s|b/.*|b/$file|g;
- print "<div class=\"diff to_file\">$patch_line</div>\n";
+ }
next LINE;
}
- next LINE if $in_header;
print format_diff_line($patch_line);
}
--
1.4.3.3
^ permalink raw reply related
* Re: VCS comparison table
From: Theodore Tso @ 2006-10-30 0:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, bazaar-ng
In-Reply-To: <ei2563$m1u$1@sea.gmane.org>
On Sun, Oct 29, 2006 at 01:01:07PM +0100, Jakub Narebski wrote:
> > You can give Bazaar for me, a bk user, and I can understand what to do
> > with the branches that are like bk clones. (The repository stuff is
> > later development and still optional.) Switching a CVS environment to
> > Bazaar one can be done so that most of the users can be just told to
> > use bzr checkout and they don't have to care about pushing.
>
> That is of course because you are familiar with branch-centric distributed
> SCM, namely BitKeeper, when trying Bazaar-NG. IMHO branch-centric view
> is somewhat limiting; you can always use repository-centric SCM with
> one-live-branch-per-repository paradigm and emulate branch-centric SCM,
> which is not (or not always) the case for branch-centric SCM. Branch-centric
> and repo-centric SCM promote different workflows, namely parallel uncommited
> work on few development branches for branch-centric SCM, one-change
> per-commit multiple temporary and feature branches for repo-centric SCM.
I've got to disagree here. Being a former bitkeeper user myself, I
find BZR-NG to be nothing like bk. In particular, Bitkeeper is *not*
branch-centric the way that BZR is; in fact, bk is much closer to git
and bk both in terms of how it works and its terminology. You can
have a non-linear set of history without using any "branches" in both
bk and mercurial, simply by creating two commits changing different
files in two different repositories (using the bk, git, and hg sense
of the word --- only bzr attaches a completely different definitoin to
term "repository"), and then pull them together.
With bzr, the only way you can do the following is by explicitly
creating a separate branch and then merging the two branches together.
In bzr --- unlike bk, git, and hg --- when you are on a "branch" the
history must be completely linear. The difference between bk, and git
and hg, is that bk enforces a restriction that there must be one
"head", or "tip" on a particular repository (in the bk, hg, and git
sense). So if you start by cloning the repository A -> B, and then
make one or more commits in repository A, and then one or more commits
in repository B, when you pull from repository B to A, bk will enforce
the creation of a merge changeset on the resulting repository --- or
fail the merge. (Actually, with BK there was the option to create
multiple tips using "lines of development", but it was never fully
developed or supported.)
With hg and git, you have the *option* of pulling the two lines of
commits together using a merge changeset *or* leaving the two "tips"
or "heads" unmerged. But that's only a very minor difference between
bk and hg/git --- and if you are willing to always merge two heads
after pulling so that your git or hg repository only has one head/tip,
then conceptually the changeset history is just like bk.
In contrast, it's impossible to do this with bzr without leaving the
named branches around, so in this sense it's quite different form BK.
- Ted
P.S. I'm going to teaching a class entitled "Bzr, Hg, and Git, Oh
my!" at LISA conference in Washington, D.C. It's only a half-day
tutorial intending to cover the basics of Distributed SCM systems, so
most folks on this list will probably know everything I'm planning on
discussing, but if you have some colleagues who need a gentle
introduction, please feel tell them to head on over to the LISA
conference website at www.usenix.org.
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-30 0:34 UTC (permalink / raw)
To: git; +Cc: Junio Hamano, Luben Tuikov
In-Reply-To: <200610300051.37896.jnareb@gmail.com>
Few other questions, probably to be adressed in the future patches, and
not added to this one.
0. git-ls-tree and git-diff-tree without -z does quote not only !isprint
characters like LF '\n' and non-space whitespace characters like TAB
'\t' (and of course quoting characters '\' and '"'), but for example
also UTF-8 characters. See for example git-ls-tree output for
gitweb/test directory. This screws somewhat idea how we should treat
filenames which are quoted.
[BTW. How git should deal with being deployed in the environment where
filesystem pathnames coding might not be UTF-8, and console (terminal)
coding might be not UTF-8?]
1. Current version doesn't display empty patches (i.e. pure rename and
mode change combinations) and doesn't provide links to them from
difftree. This is legacy of old /usr/bin/diff using code, which did not
generated extended diff header, which is only output for "empty
patches". Should we change this, or leave as is?
2. Schould we change syntax highlighting of chunk header line, namely
changing slightly syntax coloring of "in which function are we" part of
chunk header?
3. Should we make from-range/to-range in chunk header hyperlink to the
start of given bunch of lines in appropriate file? Or perhaps to the
middle of the bunch of lines? Or to first changed line (omitting
context)?
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Junio C Hamano @ 2006-10-30 1:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610300134.53668.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Few other questions, probably to be adressed in the future patches, and
> not added to this one.
>
> 0. git-ls-tree and git-diff-tree without -z does quote not only ...
> also UTF-8 characters.
I've already mentioned this in an earlier message to you:
Message-ID: <7v3b972bzq.fsf@assigned-by-dhcp.cox.net>
Let's illustrate what I mean by an untested patch; this does:
0. Use explicitly "unsigned char" so that (ch < ' ') does not
catch bytes in 0x80- range. The original meant to catch the
control characters only so this is a bugfix;
1. We still worry about control characters in 0x80-0x9f range;
if there are some, that is not a valid UTF-8 string (or
other encodings that is compatible with ASCII), and quoting
only these bytes and not quoting 0xa0- range can result
in letters chopped in the middle, so we would quote all
bytes in 0xa0- range when we have them;
2. Otherwise we do not quote bytes in 0xa0- range.
-- >8 --
diff --git a/quote.c b/quote.c
index ee7d62c..4f086fb 100644
--- a/quote.c
+++ b/quote.c
@@ -199,18 +199,32 @@ static int quote_c_style_counted(const c
#define EMITQ() EMIT('\\')
- const char *sp;
- int ch, count = 0, needquote = 0;
+ const unsigned char *name_u = (const unsigned char *)name;
+ const unsigned char *sp;
+ int ch, count = 0, needquote = 0, has_high_ctrl = 0;
+
+ /* Check if we have control character in 0x80-0x9f range */
+ for (sp = name_u; sp < name_u + namelen; sp++) {
+ ch = *sp;
+ if (!ch)
+ break;
+ if ((ch < ' ') || (ch == '"') || (ch == '\\') ||
+ (ch == 0177) || (ch == 0377))
+ needquote = 1;
+ else if (0x80 <= ch && ch <= 0x9f)
+ needquote = has_high_ctrl = 1;
+ }
if (!no_dq)
EMIT('"');
- for (sp = name; sp < name + namelen; sp++) {
+
+ for (sp = name_u; sp < name_u + namelen; sp++) {
ch = *sp;
if (!ch)
break;
if ((ch < ' ') || (ch == '"') || (ch == '\\') ||
- (ch == 0177) || (ch == 0377)) {
- needquote = 1;
+ (ch == 0177) ||
+ (has_high_ctrl && 0x80 <= ch)) {
switch (ch) {
case '\a': EMITQ(); ch = 'a'; break;
case '\b': EMITQ(); ch = 'b'; break;
-- 8< --
> 1. Current version doesn't display empty patches (i.e. pure rename and
> mode change combinations) and doesn't provide links to them from
> difftree. This is legacy of old /usr/bin/diff using code, which did not
> generated extended diff header, which is only output for "empty
> patches". Should we change this, or leave as is?
I think this needs to be fixed.
> 2. Schould we change syntax highlighting of chunk header line, namely
> changing slightly syntax coloring of "in which function are we" part of
> chunk header?
Probably matching "git diff --color" would be sensible; by
following what has already been done, you do not have to think
about what to color and how yourself.
> 3. Should we make from-range/to-range in chunk header hyperlink to the
> start of given bunch of lines in appropriate file? Or perhaps to the
> middle of the bunch of lines? Or to first changed line (omitting
> context)?
I do not see what usage pattern this link would help. Care to
explain a bit better?
^ permalink raw reply related
* Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-30 1:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6wqy5cb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> 3. Should we make from-range/to-range in chunk header hyperlink to the
>> start of given bunch of lines in appropriate file? Or perhaps to the
>> middle of the bunch of lines? Or to first changed line (omitting
>> context)?
>
> I do not see what usage pattern this link would help. Care to
> explain a bit better?
For example for the following header
diff --git _a/gitweb/gitweb.perl_ _b/gitweb/gitweb.perl_
index _cbab3c9_.._a5a140c_ 100755
--- a/_gitweb/gitweb.perl_
+++ b/_gitweb/gitweb.perl_
@@ _-1255,9_ _+1255,12_ @@ sub parse_difftree_raw_line {
The '-1255,9' would be link to older version of gitweb/gitweb.perl file,
directly to the line #1255 (or to first changed line, or to the middle
of the chunk i.e. 1255+9/2 line).
The '+1255,12' would be link to newer version of file, to line 1255.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Luben Tuikov @ 2006-10-30 1:43 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git
In-Reply-To: <7v3b972bzq.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Before answering 3 questions, I think we need to ask a bigger
> question. What is the primary target audience of gitweb?
>
> If it is for git-uninitiated, then staying as close to what GNU
> diff would give would be a better idea. I would say we at least
> can assume that the user has some familiarity with SCM, and
> knows what kind of information is kept track of and is shown as
> differences between versions, and what files, directories and
> symlinks are, but not how git represents these. On the other
> hand, if the user uses git to track a project (not necessarily
> the project the user is looking at with gitweb) and is familiar
> with the way git-diff presents these information, deviating from
> git-diff output is distractiing.
I agree.
gitweb's primary audience is the developers who type "git ..."
at shell prompt all the time.
> At least to me /-rw-rw-... part made me feel uneasy for that
> reason.
It made me feel uneasy to see it where it was because it
didn't belong there either way.
> WIth that in mind, I'll think aloud what I would like if I were
> not familiar with git:
>
> * "diff --git a/file b/file" would not use /dev/null but
> ---/+++ does. If the former is shown as link, it should be
> visible which side is a link and which side is not for
> creation or deletion diff; otherwise you would need a second
I'd argue otherwise: trying to click on /dev/null and failing
but succeeding on b/file has already taught something to the
uinitiated user.
OTOH, if one is trying to "click" on /dev/null in gitweb commitdiff
view -- they have other problems to resolve first...
> to realize it is not a bug that clicking on a/file on the
> "diff --git" line did not show anything for a creation diff.
>
> * I think showing object names in "index xxx..yyy mode" line is
> not very useful to humans (they are added for tools). I do
I like to see it because I might need to know the sha in order to
go back to shell prompt and do something with the object. Instead
of having to git-ls-tree -r .... in order to find it from the sha
of the commitdiff.
> agree that we would want some clickable handle in combined
> diff output, but people not familiar with git would not know
> that "index xxx,yyy..zzz" is where you would find the
> parents, so that line needs to be munged anyway.
I think gitweb should first and foremost cater to git users.
> Side note: Even though some git people (Luben, for example)
> claim they recognize some abbreviated object names, I suspect
> that are mostly recent commits and not blobs.
Yes, commit-8 for the day, blob-8 for less than a minute
which allows me to move the mouse pointer from to the xterm.
> * Mode on the "index" line may be useful, but as you say 100644
> is probably too git specific; however if our audience is
> git-uninitiated, I doubt -rw-r--r-- is much better (it is
> UNIXism, which I personally do not mind). Spelling them out
> like "regular file", "executable file", or "symbolic link"
> might be more readable.
It would be more readable, but then it would be more readable.
Ideally I'd like it to be less readable, i.e. less to read.
> * I think the filename quoting is better left as-is, since it
> is a way to indicate something funny is going on.
I agree.
Luben
^ permalink raw reply
* Re: [PATCH] send-pack --keep: do not explode into loose objects on the receiving end.
From: Nicolas Pitre @ 2006-10-30 1:44 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061029075638.GB3847@spearce.org>
On Sun, 29 Oct 2006, Shawn Pearce wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> > This adds "keep-pack" extension to send-pack vs receive pack protocol,
> > and makes the receiver invoke "index-pack --stdin --fix-thin".
>
> I'm torn on this. I see that keeping a pack vs. exploding to loose
> objects is a local repository decision and thus should be determined
> by the receiving repository, not the sending one.
I second this. I think it is really not the remote end's business to
decide what the local storage policy is, and vice versa.
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Luben Tuikov @ 2006-10-30 1:59 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <200610300051.37896.jnareb@gmail.com>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Replace "gitweb diff header" with its full sha1 of blobs and replace
> it by "git diff" header and extended diff header. Change also somewhat
> highlighting of diffs.
>
> Changes:
> * "gitweb diff header" which looked for example like below:
> file:_<sha1 before>_ -> file:_<sha1 after>_
> where 'file' is file type and '<sha1>' is full sha1 of blob is
> changed to
> diff --git _a/<file before>_ _b/<file after>_
> In both cases links are visible and use default link style. If file
> is added, a/<file> is not hyperlinked, if file is deleted, b/<file>
> is not hyperlinked.
"Everything clickable underlined" isn't the best way to represent things.
Anyway, my 2 cents is that I don't like the overly explicit underlineing.
I liked it the way it was in take 1.
> * there is added "extended diff header", with <path> and <hash>
> hyperlinked (and <hash> shortened to 7 characters), and <mode>
> explained: '<mode>' is extended to '<mode> (<file type>)'.
> * <file> hyperlinking should work also when <file> is originally
> quoted. For now we present filename quoted. This needed changes to
> parse_difftree_raw_line subroutine. And doesn't work: perhaps
> unquote is broken.
In which case we shouldn't commit this. IOW, let's commit things
which we _know_ to work.
Why not resubmit your original patch with the bugfixes as few comments
as mentioned?
> * from-file/to-file two-line header lines have slightly darker color
> than removed/added lines.
> * chunk header has now delicate line above for easier finding chunk
> boundary, and top margin of 1px.
Wouldn't this be confusing with the other fine lines?
I personally don't like this chunk separation. Chunk separation
already exists as is and we view it all the time elsewhere.
If you'd like to separate chunks, why not darken the background
of the section of line the chunk header is printed at? I.e.
anything between the @@ including the @@.
Luben
^ permalink raw reply
* [PATCH] missing small substitution
From: Nicolas Pitre @ 2006-10-30 2:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/fetch-clone.c b/fetch-clone.c
index 96cdab4..f629d8d 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -46,7 +46,7 @@ static int get_pack(int xd[2], const cha
side_pid = setup_sideband(sideband, me, fd, xd);
pid = fork();
if (pid < 0)
- die("%s: unable to fork off git-unpack-objects", me);
+ die("%s: unable to fork off %s", me, argv[0]);
if (!pid) {
dup2(fd[0], 0);
^ permalink raw reply related
* Re: [PATCH 3/3] Teach git-index-pack how to keep a pack file.
From: Nicolas Pitre @ 2006-10-30 3:47 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061029094159.GE3847@spearce.org>
On Sun, 29 Oct 2006, Shawn Pearce wrote:
> I'm throwing a pair of pipes around index-pack so I can capture
> the pack name thus allowing receive-pack to delete the correct
> .keep file after its completed the ref updates. At that point
> receive-pack can easily examine the object count in the pack header
> and compare that against a config entry to decide if it should be
> keeping the pack or exploding it.
Is it really worth the trouble? Especially if you've already written
the pack out, why just not keep it instead of burning more CPU cycles
exploding it? The next repack will delete it anyway.
At least for the fetch/pull case here's what I've done so far. It is
not complete as the .keep file is not deleted as I'm not clear exactly
where in git-fetch.sh it can be safely deleted. But at least it works
to the point of displaying the name of the file it should consider for
deletion.
diff --git a/fetch-clone.c b/fetch-clone.c
index 96cdab4..c5747f4 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -81,7 +81,7 @@ int receive_unpack_pack(int xd[2], const
int receive_keep_pack(int xd[2], const char *me, int quiet, int sideband)
{
- const char *argv[5] = { "index-pack", "--stdin", "--fix-thin",
+ const char *argv[6] = { "index-pack", "--stdin", "--fix-thin", "--keep",
quiet ? NULL : "-v", NULL };
return get_pack(xd, me, sideband, argv);
}
diff --git a/git-fetch.sh b/git-fetch.sh
index 539dff6..dd0c00b 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -378,6 +378,10 @@ fetch_main () {
failed)
echo >&2 "Fetch failure: $remote"
exit 1 ;;
+ pack)
+ pack_lockfile="$GIT_OBJECT_DIRECTORY/pack/pack-$remote_name.keep"
+ [ -e "$pack_lockfile" ] && echo >&2 "$pack_lockfile exists"
+ continue ;;
esac
found=
single_force=
diff --git a/index-pack.c b/index-pack.c
index b37dd78..8db3c93 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -767,18 +767,6 @@ static void final(const char *final_pack
if (err)
die("error while closing pack file: %s", strerror(errno));
chmod(curr_pack_name, 0444);
-
- /*
- * Let's just mimic git-unpack-objects here and write
- * the last part of the buffer to stdout.
- */
- while (input_len) {
- err = xwrite(1, input_buffer + input_offset, input_len);
- if (err <= 0)
- break;
- input_len -= err;
- input_offset += err;
- }
}
if (keep_msg) {
@@ -818,6 +806,27 @@ static void final(const char *final_pack
if (move_temp_to_file(curr_index_name, final_index_name))
die("cannot store index file");
}
+
+ if (!from_stdin) {
+ printf("%s\n", sha1_to_hex(sha1));
+ } else {
+ char buf[48];
+ int len = snprintf(buf, sizeof(buf), "pack\t%s\n",
+ sha1_to_hex(sha1));
+ xwrite(1, buf, len);
+
+ /*
+ * Let's just mimic git-unpack-objects here and write
+ * the last part of the input buffer to stdout.
+ */
+ while (input_len) {
+ err = xwrite(1, input_buffer + input_offset, input_len);
+ if (err <= 0)
+ break;
+ input_len -= err;
+ input_offset += err;
+ }
+ }
}
int main(int argc, char **argv)
@@ -921,8 +930,5 @@ int main(int argc, char **argv)
free(index_name_buf);
free(keep_name_buf);
- if (!from_stdin)
- printf("%s\n", sha1_to_hex(sha1));
-
return 0;
^ permalink raw reply related
* Re: Merging five months of Linux kernel history
From: Jan-Benedict Glaw @ 2006-10-30 7:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcxm274i.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]
On Sun, 2006-10-29 12:34:53 -0800, Junio C Hamano <junkio@cox.net> wrote:
> Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
> > Due to a move to a new flat and other reasons, I wasn't able to
> > do daily merges from Linus's tree into our vax-linux tree.
> > My time situation has improved and I want to merge all the new
> > and shiny stuff, but it seems a straight "git pull" isn't the
> > best way to do that.
> >
> > What I'd actually love to do is to go through all commits since the
> > last merge and pull/accept/cherry-pick then one by one. That way I'll
> > learn about new stuff. I'll specifically see generic changes that
> > imply arch-specific stuff, things I'll need to implement later on.
> >
> > Is there any sane way to cluse such a large gap? I don't mind looking
> > through tenthousands of commits, as long as I get a chance to spot
> > "important" ones.
>
> I think the best way is:
>
> git pull
> git log ORIG_HEAD..
>
> The latter would give your ten thousands of commits to inspect.
>
> If the pull results in a conflict, then
>
> git pull
> git log --merge
>
> ... fix conflicts ...
> git commit
> git log ORIG_HEAD..
That's the point--I don't really expect any conflicts, or only a very
little number of them. Basically, only the Makefiles and the Kconfig
files do have a chance to conflict. It's no more than a new arch/
directory and some drivers.
The hard part will be to figure out all the needed changes in arch
code, like the IRQ handling rework etc :)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: Ich hatte in letzter Zeit ein bißchen viel Realitycheck.
the second : Langsam möchte ich mal wieder weiterträumen können.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-30 8:05 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <92622.251.qm@web31812.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
>> Replace "gitweb diff header" with its full sha1 of blobs and replace
>> it by "git diff" header and extended diff header. Change also somewhat
>> highlighting of diffs.
>>
>> Changes:
>> * "gitweb diff header" which looked for example like below:
>> file:_<sha1 before>_ -> file:_<sha1 after>_
>> where 'file' is file type and '<sha1>' is full sha1 of blob is
>> changed to
>> diff --git _a/<file before>_ _b/<file after>_
>> In both cases links are visible and use default link style. If file
>> is added, a/<file> is not hyperlinked, if file is deleted, b/<file>
>> is not hyperlinked.
>
> "Everything clickable underlined" isn't the best way to represent things.
> Anyway, my 2 cents is that I don't like the overly explicit underlineing.
> I liked it the way it was in take 1.
Thet is the only "obviously link" per patch. And I think there should be
at least one non-hidden link.
BTW. comments like this are the reason I've sent the patch as-is, without
resolving the strange filenames problem (it would be nice if somebody was
to send code; well Junio send patch to address core git filename quoting
issue).
>> * there is added "extended diff header", with <path> and <hash>
>> hyperlinked (and <hash> shortened to 7 characters), and <mode>
>> explained: '<mode>' is extended to '<mode> (<file type>)'.
>> * <file> hyperlinking should work also when <file> is originally
>> quoted. For now we present filename quoted. This needed changes to
>> parse_difftree_raw_line subroutine. And doesn't work: perhaps
>> unquote is broken.
>
> In which case we shouldn't commit this. IOW, let's commit things
> which we _know_ to work.
>
> Why not resubmit your original patch with the bugfixes as few comments
> as mentioned?
I'll do that, but for now quoting/unquoting filename is broken, both
in gitweb but also to lesser extent in git core (quoting perfectly valid
UTF-8 characters).
I'll try to adress that, but I wanted to send next RFC patch for review.
>> * from-file/to-file two-line header lines have slightly darker color
>> than removed/added lines.
>> * chunk header has now delicate line above for easier finding chunk
>> boundary, and top margin of 1px.
>
> Wouldn't this be confusing with the other fine lines?
> I personally don't like this chunk separation. Chunk separation
> already exists as is and we view it all the time elsewhere.
But not always the program displaying diff can display such line
separating chunks, for example on text terminal it can't.
But if you think that the dotted 1px #ffbbff line is too intrusive,
we can remove it (and perhaps increase vertical space a few pixels).
I'd like to have more opinions first.
BTW. you can easily override it in your CSS file.
> If you'd like to separate chunks, why not darken the background
> of the section of line the chunk header is printed at? I.e.
> anything between the @@ including the @@.
I'd rather have this one in a separate commit (this needs changes
to format_diff_line, not only to git_patchset_body).
--
Jakub Narebski
^ permalink raw reply
* Re: Merging five months of Linux kernel history
From: Junio C Hamano @ 2006-10-30 8:05 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20061030075002.GT26271@lug-owl.de>
Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
>> git log ORIG_HEAD..
>
> That's the point--I don't really expect any conflicts, or only a very
> little number of them. Basically, only the Makefiles and the Kconfig
> files do have a chance to conflict. It's no more than a new arch/
> directory and some drivers.
>
> The hard part will be to figure out all the needed changes in arch
> code, like the IRQ handling rework etc :)
Since you are maintaining your own arch/ and the other in-tree
architectures progressed as common core code did, you would want
to make matching changes to your arch to adjust to the core
changes.
[a big warning in red capital letters: I do not hack kernel]
I suspect you would want to see what _other_ architecture did to
adjust to the changes in the common core code that happened in
the meantime. How about...
$ git log ORIG_HEAD.. -- arch/$somearch include/asm-$somearch
where $somearch is something that has difference from the
mainstream that is similar to vax, to figure out what other
architectures needed to adjust, perhaps?
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Junio C Hamano @ 2006-10-30 8:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610300905.04454.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> ..., without
> resolving the strange filenames problem (it would be nice if somebody was
> to send code; well Junio send patch to address core git filename quoting
> issue).
Having showed that patch, I do not think it is a good way to go.
I think the UI layer like gitweb should have freedom to choose
its own pathname handling, and should read from -z output.
The git plumbing is agnostic to the character encoding issues,
and does not care what character set pathnames are encoded, and
what character set the file contents are encoded. These are
very project specific and should be handled per project.
One of the primary purposes, aside from being understandable by
humans, of human readable "git diff" format is to convey machine
readable information without corruption in text form transport
(think "e-mail"), so quoting pathnames to avoid high-bits has
clear advantage (pathname character set and file contents
character set are often different, and when both are non-ascii
we would need to sacrifice one if we spit diff out in a single
text file --- we choose to quote pathnames so that it would not
interfere with file contents, which would be more important to
be inspectable by humans reading "diff" output). People in the
past suggested converting everything to UTF-8 but that is not a
usable robust solution in the real world.
The HTML output generated by gitweb do not have the "machine
readably robust" requirement, so it _can_ stress more on
readability by humans, including converting both pathname and
contents to UTF-8; for this, the project needs to tell gitweb
what its pathname character encoding is, and blob contents
encoding, at the worst case blob-by-blob, but more often
path-by-path.
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Junio C Hamano @ 2006-10-30 8:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7qyw6w6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> ..., without
>> resolving the strange filenames problem (it would be nice if somebody was
>> to send code; well Junio send patch to address core git filename quoting
>> issue).
>
> Having showed that patch, I do not think it is a good way to go.
>
> I think the UI layer like gitweb should have freedom to choose
> its own pathname handling, and should read from -z output.
>
> The git plumbing is agnostic to the character encoding issues,
> and does not care what character set pathnames are encoded, and
> what character set the file contents are encoded. These are
> very project specific and should be handled per project.
Side note.
There is one action item for shorter term I realized we would
need. We need to make patch-id generation use unquoted
filenames, so that no matter how differently we might
reimplement quote_c_style() later, we would get the same
patch-id from the diff between the same two trees. Currently I
think it hashes the quoted filename that appear on ---/+++ lines
(and "rename from"/"rename to" lines as well, but usually you do
not use -M/-C when computing the patch-id, so these are not
really an issue).
I think longer term plan for git should include standardizing on
how pathname encoding and content encoding are handled at the UI
layer.
And that plan _should_ eventually include the textual diff part.
But textual diff has a machine readability requirements, so we
need to proceed very carefully. I think the patch I sent out
earlier is probably good enough if we only care about utf-8, but
would not correctly handle other sane pathname encodings such as
extended UNIX code (let alone broken but still widely used
encodings such as MS-Kanji aka Shift_JIS).
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-30 9:43 UTC (permalink / raw)
To: Junio C Hamano, Luben Tuikov; +Cc: git
In-Reply-To: <7vy7qyw6w6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> ..., without
>> resolving the strange filenames problem (it would be nice if somebody was
>> to send code; well Junio send patch to address core git filename quoting
>> issue).
>
> Having showed that patch, I do not think it is a good way to go.
>
> I think the UI layer like gitweb should have freedom to choose
> its own pathname handling, and should read from -z output.
That's a very good idea. I'll send separate patch (if noone else will
do this, that is) which would convert gitweb to always use -z output,
both git-ls-tree and git-diff-tree... oh, well, there is no -z patch
output, so in patch part we would have to replace git quoted part by
gitweb quoted part.
BTW gitweb has to do it's own pathname handling, at least LF, perhaps
TAB, perhaps other control characters like ESC; quote quoting character
and mark filename as quoted somewhat (it can be with CSS style, not
necessary by surrounding with some kind of quotes; besides that can
also be added via CSS in modern enough browsers using :before and
:after pseudo-elements and 'content' property).
--
Jakub Narebski
^ permalink raw reply
* Re: [StGIT PATCH] Bash snippet to show branch and patch in bash prompt
From: Eran Tromer @ 2006-10-30 9:57 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <20061029233745.24899.1470.stgit@lathund.dewire.com>
On 2006-10-30 01:37, Robin Rosenberg wrote:
> +# include this in your bashrc or copy to /etc/bash_completions.d
> +
> +if [ "$PS1" ]; then
> + # trap 'PS1="\u@\h [$(stg top)] \w]\$ "' DEBUG
> + function stgtag
> + {
> + br=$(stg branch 2>/dev/null)
> + top=$(stg top 2>/dev/null)
> + if [[ -n "$br$top" ]];then
> + echo "[$top@$br]"
> + return
> + fi
> + }
> + PS1='\u@\h$(stgtag)\w\$ '
> +
> +fi
That's an annoying 430ms delay at every prompt, on my box. Does StGIT do
something expensive on every invocation?
Ben Clifford'd solution is pretty much instantaneous, and the following
extends it to StGIT (in a less clean but much faster way):
----------------------------------------------
__prompt_githead() {
__PS_GIT="$(git-symbolic-ref HEAD 2>/dev/null)" || exit
__PS_GIT="$(basename $__PS_GIT)"
echo -n " $__PS_GIT"
__PS_GIT=$(cat "${GIT_DIR:-.git}/patches/$__PS_GIT/current" \
2>/dev/null) || exit
echo -n ":$__PS_GIT"
}
PS1='[\u@\h \W$(__prompt_githead)]\$ '
----------------------------------------------
^ permalink raw reply
* Progress reporting (was: VCS comparison table)
From: Jakub Narebski @ 2006-10-30 10:18 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <ehvnal$tjg$1@sea.gmane.org>
Jakub Narebski wrote:
> Ilpo Nyyssönen wrote:
>> 3. Understanding output
>>
>> G: Speaks a language of its own, hard to understand. No progress
>> reported for long lasting operations.
>>
>> B: Could maybe speak a bit more. Progress reporting is quite good.
>
> Which long lasting operations lack progress bar/progress reporting?
> "git clone" and "git fetch"/"git pull" both have progress report
> for both "smart" git://, git+ssh:// and local protocols, and "dumb"
> http://, https://, ftp://, rsync:// protocols. "git rebase" has
> progress report. "git am" has progress report.
I was bitten lately by git lack of progress reporting for git-push.
While it nicely reports local progress (generating data) it unfortunately
lacks wget like, "curl -o" like or scp like pack upload progress
reporting. And while usually push is fast, initial push of whole
project to empty repository can be quite slow on low-bandwidth link
(or busy network).
git version 1.4.3.3 on local side, git+ssh:// protocol, git version
1.4.3.3.g9ab2 on the remote side (repo.or.cz).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [StGIT PATCH] Bash snippet to show branch and patch in bash prompt
From: Catalin Marinas @ 2006-10-30 10:24 UTC (permalink / raw)
To: Eran Tromer; +Cc: Robin Rosenberg, git
In-Reply-To: <4545CC6F.90001@tromer.org>
Eran Tromer <git2eran@tromer.org> wrote:
> On 2006-10-30 01:37, Robin Rosenberg wrote:
>> +# include this in your bashrc or copy to /etc/bash_completions.d
>> +
>> +if [ "$PS1" ]; then
>> + # trap 'PS1="\u@\h [$(stg top)] \w]\$ "' DEBUG
>> + function stgtag
>> + {
>> + br=$(stg branch 2>/dev/null)
>> + top=$(stg top 2>/dev/null)
>> + if [[ -n "$br$top" ]];then
>> + echo "[$top@$br]"
>> + return
>> + fi
>> + }
>> + PS1='\u@\h$(stgtag)\w\$ '
>> +
>> +fi
>
> That's an annoying 430ms delay at every prompt, on my box. Does StGIT do
> something expensive on every invocation?
Well, there are some forks. For every "stg" command, "git-symbolic-ref
HEAD" and "git-rev-parse --git-dir" are invoked to get the name of the
main branch and the .git directory. There is also the delay of
invoking python and loading the command modules in main.py (maybe I
should modify this to import the modules on demand, based on what
command was given).
Since the repository format is stable, you could use something like
this (it should be faster):
git_dir=$(git-rev-parse --git-dir 2> /dev/null)
ref=$(git-symbolic-ref HEAD 2> /dev/null)
br=${ref##*/}
top=$(cat $git_dir/patches/$br/current)
--
^ permalink raw reply
* Re: [StGIT PATCH] Bash snippet to show branch and patch in bash prompt
From: Robin Rosenberg @ 2006-10-30 10:32 UTC (permalink / raw)
To: Eran Tromer; +Cc: git
In-Reply-To: <4545CC6F.90001@tromer.org>
måndag 30 oktober 2006 10:57 skrev Eran Tromer:
> That's an annoying 430ms delay at every prompt, on my box. Does StGIT do
> something expensive on every invocation?
I don't type fast enough to notice really and my machine seems faster, ~300 ms
per prompt.
>
> Ben Clifford'd solution is pretty much instantaneous, and the following
> extends it to StGIT (in a less clean but much faster way):
>
> ----------------------------------------------
> __prompt_githead() {
> __PS_GIT="$(git-symbolic-ref HEAD 2>/dev/null)" || exit
> __PS_GIT="$(basename $__PS_GIT)"
> echo -n " $__PS_GIT"
> __PS_GIT=$(cat "${GIT_DIR:-.git}/patches/$__PS_GIT/current" \
> 2>/dev/null) || exit
> echo -n ":$__PS_GIT"
> }
> PS1='[\u@\h \W$(__prompt_githead)]\$ '
> ----------------------------------------------
This doesn't work if the branch have a / in the name or if you are in a
subdirectory, not the top level. Probably not hard to fix though.
^ permalink raw reply
* [PATCH] Bash snippet to show branch and patch in bash prompt
From: Robin Rosenberg @ 2006-10-30 10:42 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Eran Tromer, git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
contrib/stgbashprompt.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh
new file mode 100755
index 0000000..792da53
--- /dev/null
+++ b/contrib/stgbashprompt.sh
@@ -0,0 +1,16 @@
+# include this in your bashrc or copy to /etc/bash_completions.d
+
+if [ "$PS1" ]; then
+ # trap 'PS1="\u@\h [$(stg top)] \w]\$ "' DEBUG
+ function stgtag
+ {
+ br=$(stg branch 2>/dev/null)
+ top=$(stg top 2>/dev/null)
+ if [[ -n "$br$top" ]];then
+ echo "[$top@$br]"
+ return
+ fi
+ }
+ PS1='\u@\h$(stgtag)\w\$ '
+
^ permalink raw reply related
* Re: [PATCH] Bash snippet to show branch and patch in bash prompt
From: Catalin Marinas @ 2006-10-30 10:46 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Eran Tromer, git
In-Reply-To: <20061030104225.11875.57076.stgit@lathund.dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> From: Robin Rosenberg <robin.rosenberg@dewire.com>
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
> ---
>
> contrib/stgbashprompt.sh | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh
> new file mode 100755
> index 0000000..792da53
> --- /dev/null
> +++ b/contrib/stgbashprompt.sh
> @@ -0,0 +1,16 @@
> +# include this in your bashrc or copy to /etc/bash_completions.d
> +
> +if [ "$PS1" ]; then
> + # trap 'PS1="\u@\h [$(stg top)] \w]\$ "' DEBUG
> + function stgtag
> + {
> + br=$(stg branch 2>/dev/null)
> + top=$(stg top 2>/dev/null)
> + if [[ -n "$br$top" ]];then
> + echo "[$top@$br]"
> + return
> + fi
> + }
> + PS1='\u@\h$(stgtag)\w\$ '
> +
> +fi
Isn't this the same patch? "stg refresh" :-)?
--
Catalin
P.S. could you please send them to my catalin.marinas@gmail.com
^ permalink raw reply
* Re: [PATCH] Bash snippet to show branch and patch in bash prompt
From: Robin Rosenberg @ 2006-10-30 10:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Eran Tromer, git
In-Reply-To: <20061030104225.11875.57076.stgit@lathund.dewire.com>
måndag 30 oktober 2006 11:42 skrev Robin Rosenberg:
> From: Robin Rosenberg <robin.rosenberg@dewire.com>
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
This was a "reply" using stgit, but the reference missed the ange brackets.
Anyway thanks for the feedback on the prompt.
-- robin
^ permalink raw reply
* Re: [PATCH] Bash snippet to show branch and patch in bash prompt
From: Robin Rosenberg @ 2006-10-30 10:59 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Eran Tromer, git
In-Reply-To: <20061030104225.11875.57076.stgit@lathund.dewire.com>
Oops, didn't refresh before sending..
^ permalink raw reply
* [PATCH] Bash snippet to show branch and patch in bash prompt
From: Robin Rosenberg @ 2006-10-30 10:59 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Eran Tromer, git
In-Reply-To: <4545CC6F.90001@tromer.org>
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
contrib/stgbashprompt.sh | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh
new file mode 100755
index 0000000..a79561e
--- /dev/null
+++ b/contrib/stgbashprompt.sh
@@ -0,0 +1,18 @@
+# include this in your bashrc or copy to /etc/bash_completions.d
+
+if [ "$PS1" ]; then
+ # trap 'PS1="\u@\h [$(stg top)] \w]\$ "' DEBUG
+ function stgtag
+ {
+ git_dir=$(git-rev-parse --git-dir 2> /dev/null)
+ ref=$(git-symbolic-ref HEAD 2> /dev/null)
+ br=${ref/refs\/heads\//}
+ top=$(cat $git_dir/patches/$br/current 2>/dev/null)
+ if [[ -n "$br$top" ]];then
+ echo "[$top@$br]"
+ return
+ fi
+ }
+ PS1='\u@\h$(stgtag)\w\$ '
+
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox