* [PATCH] Link git-name-rev and git-symbolic-ref from the main git page
From: Johannes Schindelin @ 2005-10-27 9:57 UTC (permalink / raw)
To: git, junkio
According to my checks, these were the only commands not yet linked.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Matthias Urlichs wrote:
> Johannes Schindelin wrote:
>
> > [PATCH] Add git-name-rev
>
> Please update the "git" manpage when you add a new command.
> (I bet that others are missing too..?)
I did not do it right away, because I did not expect that it
was merged into master *that* fast.
Documentation/git.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 054f091..6c80e27 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -133,6 +133,9 @@ gitlink:git-ls-tree[1]::
gitlink:git-merge-base[1]::
Finds as good a common ancestor as possible for a merge
+gitlink:git-name-rev[1]::
+ Find symbolic names for given revs
+
gitlink:git-rev-list[1]::
Lists commit objects in reverse chronological order
@@ -360,6 +363,9 @@ gitlink:git-sh-setup[1]::
Common git shell script setup code.
Previously this command was known as git-sh-setup-script.
+gitlink:git-symbolic-ref[1]::
+ Read and modify symbolic refs
+
gitlink:git-tag[1]::
An example script to create a tag object signed with GPG
Previously this command was known as git-tag-script.
^ permalink raw reply related
* [PATCH] Add more generated files to .gitignore
From: Johannes Schindelin @ 2005-10-27 10:03 UTC (permalink / raw)
To: git, junkio
git-name-rev, git-mv and git-shell are recent additions to git.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
.gitignore | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 52cb9e2..927c89c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -54,6 +54,8 @@ git-merge-recursive
git-merge-resolve
git-merge-stupid
git-mktag
+git-name-rev
+git-mv
git-octopus
git-pack-objects
git-parse-remote
@@ -78,6 +80,7 @@ git-revert
git-send-email
git-send-pack
git-sh-setup
+git-shell
git-shortlog
git-show-branch
git-show-index
^ permalink raw reply related
* Re: [RFC] multi_ack protocol v2
From: Sergey Vlasov @ 2005-10-27 10:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vzmov4elu.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2780 bytes --]
On Thu, 27 Oct 2005 00:13:17 -0700 Junio C Hamano wrote:
[skip]
> So let's illustrate the v2 the same way as I understand it.
>
> upload-pack (S) | fetch/clone-pack (C) protocol (v2):
>
> # Tell the puller what commits we have and what their names are
> S: SHA1 name
> S: ...
> S: SHA1 name
> S: # flush -- it's your turn
> # Tell the pusher what commits we want, and what we have.
> # In addition, we tell the other end that we support protocol
> # extensions, without breaking the old servers.
> C: want SHA1 extended
> C: ..
> C: want SHA1
> C: # flush -- done with "want" lines.
>
> Notice that until we hear from the server, we cannot tell if our
> "extended" protocol wish will be granted, and in the original
> protocol, "NAK" will come in fixed length, and the only thing we
> could tack arbitrary garbage to was "ACK SHA1". That's why your
> "ACK SHA1 continue" works nicely, but at the time you could not
> find out if you are talking with updated server until you get at
> least one ACK.
Actually, there is another way to pass some data from the server
which would be ignored by older clients - at the first stage,
when upload-pack sends the list of refs to the client:
packet_write(1, "%s %s%c%s\n", sha1_to_hex(sha1), refname, '\0',
server_capabilities);
Old clients will ignore the additional data (functions which
work with the received name will happily stop at the added NUL
character; just some memory will be wasted), but the new
implementation of get_remote_heads() could look for that NUL
inside the received packet and find extended server capabilities
after it. Then the client could just use new commands at the
"want" stage.
> However, at this point, we *could* force the server to reveal
> what it supports, by doing an extra flush here, before sending
> *ANY* "have" lines yet:
>
> C: # flush -- this is another one after "I'm done with wants".
>
> Upon receiving this, if we were talking with an old upload-pack,
> we would certanly get an NAK. Note that the server already
> knows that we support extended protocol at this point, so our
> updated server can send anything here to say it knows what
> protocol extensions it supports. Let's say it says something
> like this:
>
> S: proto v2 v3 v5
>
> to tell the puller it understands protocol v2, v3, and v5, to
> which the puller responds:
>
> C: proto v2
>
> After this exchange, both ends know they understand and would
> want to talk at protocol level v2. This leaves door open for
> future protocol extension, but more importantly, I think this
> arrangement would make things safer.
This looks cleaner (no NUL bytes in the protocol), but does not
allow to replace the "want" stage with something entirely
different (if we ever want to do that).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] multi_ack protocol v2
From: Paul Mackerras @ 2005-10-27 9:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510270149590.12163@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin writes:
> after thinking about my earlier approach, I think there's a better, less
> intrusive, and all in all just simpler approach:
How many round-trips does it take? When you're on the other side of
the Pacific from the server you care about round-trips. :) One of the
nice things about rsync is that it does everything with only 1.5
round-trips.
Paul.
^ permalink raw reply
* Re: [RFC] multi_ack protocol v2
From: Johannes Schindelin @ 2005-10-27 10:47 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: Junio C Hamano, git
In-Reply-To: <20051027141619.0e8029f2.vsu@altlinux.ru>
Hi,
On Thu, 27 Oct 2005, Sergey Vlasov wrote:
> Actually, there is another way to pass some data from the server
> which would be ignored by older clients - at the first stage,
> when upload-pack sends the list of refs to the client:
>
> packet_write(1, "%s %s%c%s\n", sha1_to_hex(sha1), refname, '\0',
> server_capabilities);
That exploits that packet_write() uses vnsprintf() to find out the length,
not strlen(). Sweet.
get_remote_heads() would need to store the server_capabilities, maybe with
a function "server_supports(const char *extension_string)"
Actually, I like that even more than Junio's proposal. I was thinking hard
about how to enhance get_ack() to understand -- and most importantly to
return -- the capabilities. I could not think of an elegant way.
So, unless people complain, I'll go with that approach.
> This looks cleaner (no NUL bytes in the protocol), but does not
> allow to replace the "want" stage with something entirely
> different (if we ever want to do that).
Also it feels wrong that a client should ask for capabilities, where it
does not yet know if the server supports them.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] multi_ack protocol v2
From: Johannes Schindelin @ 2005-10-27 10:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17248.39333.181379.615274@cargo.ozlabs.ibm.com>
Hi,
On Thu, 27 Oct 2005, Paul Mackerras wrote:
> Johannes Schindelin writes:
>
> > after thinking about my earlier approach, I think there's a better, less
> > intrusive, and all in all just simpler approach:
>
> How many round-trips does it take? When you're on the other side of
> the Pacific from the server you care about round-trips. :) One of the
> nice things about rsync is that it does everything with only 1.5
> round-trips.
The plan is to reuse the existing framework. It sends 32 "have" messages,
then a flush, then again 32 "have" messages, flush again, then reads all
answers until a "NAK". The last 3 steps are repeated over and over again.
That means that there are always at least 32 "have" messages on the wire
(which is described in the source code as "one window ahead"), i.e. it is
about 32x faster than simple "have" -> "NAK/ACK" handshakes.
Ciao,
Dscho
^ permalink raw reply
* Re: Make "gitk" work better with dense revlists
From: Linus Torvalds @ 2005-10-27 14:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <17248.28857.90315.543669@cargo.ozlabs.ibm.com>
On Thu, 27 Oct 2005, Paul Mackerras wrote:
>
> Linus Torvalds writes:
> >
> > So this makes gitk just show the diff of _that_ commit.
>
> Committed and pushed out, but ...
Btw, the "show diff for commit" fails for the root case - you never see
the initial commit.
That is definitely correct for big archives that started out of nothing
(due to being imported), but it's sad/wrong for something like git itself,
and it'a usually wrong when using --dense and a filename, since then the
diff is often smaller (ie it might be a simple rename).
> > Also, having now tested the previous "handle root commit in the
> > TREECHANGED" logic a bit more, I think it's (a) stable and (b) the right
> > thing to do. Sign me off on that one too.
>
> What is that about?
That's just me improving how --dense works wrt root commits. Junio already
merged it ("git-rev-list: fix --dense flag")
> I'm hoping to get back to gitk hacking RSN - I've been going flat out
> on the ppc32/ppc64 merge. Thanks for doing the --dense thing; I was
> thinking about doing something like that inside gitk but doing it in
> git-rev-list is better.
A _lot_ better. You'd have been totally screwed performance-wise trying to
do it in tcl/tk and executing git-diff-tree for everything.
> It does mean that I now want to be able to
> get gitk to contract the view to just a given set of files or
> directories and then expand back to the whole tree view, which means
> running git-rev-list multiple times, which gitk can't do at the
> moment...
Yes. And please also give the option to contract the diffs to a set of
files (I think that should be independently controlled, although perhaps
with some way to set them both at the same time).
Linus
^ permalink raw reply
* Re: Make "gitk" work better with dense revlists
From: Sven Verdoolaege @ 2005-10-27 15:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <17248.28857.90315.543669@cargo.ozlabs.ibm.com>
On Thu, Oct 27, 2005 at 04:16:25PM +1000, Paul Mackerras wrote:
> git-rev-list is better. It does mean that I now want to be able to
> get gitk to contract the view to just a given set of files or
> directories and then expand back to the whole tree view, which means
> running git-rev-list multiple times, which gitk can't do at the
> moment...
My "gitk Update" patch could be useful here.
Instead of being careful about what is new and what is old,
you can just throw everything out.
skimo
------------------
gitk: add Update menu item.
Update will redraw the commits if any commits have been added to any
of the selected heads. The new commits appear on the top.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
commit d867cc8df4b7756dbc738358540e845ac5cd8a86
tree f762e01ce91365d95cfed147f3b605d492aeb7f4
parent f3123c4ab3d3698262e59561ac084de45b10365a
author Sven Verdoolaege <skimo@kotnet.org> Thu, 22 Sep 2005 15:27:19 +0200
committer Sven Verdoolaege <skimo@kotnet.org> Wed, 26 Oct 2005 23:05:23 +0200
gitk | 175 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 141 insertions(+), 34 deletions(-)
diff --git a/gitk b/gitk
index f1ea4e1..8c37b60 100755
--- a/gitk
+++ b/gitk
@@ -16,8 +16,24 @@ proc gitdir {} {
}
}
+proc parse_args {rargs} {
+ global parsed_args
+
+ if [catch {
+ set parse_args [concat --default HEAD $rargs]
+ set parsed_args [split [eval exec git-rev-parse $parse_args] "\n"]
+ }] {
+ # if git-rev-parse failed for some reason...
+ if {$rargs == {}} {
+ set rargs HEAD
+ }
+ set parsed_args $rargs
+ }
+ return $parsed_args
+}
+
proc getcommits {rargs} {
- global commits commfd phase canv mainfont env
+ global oldcommits commits commfd phase canv mainfont env
global startmsecs nextupdate ncmupdate
global ctext maincursor textcursor leftover
@@ -27,21 +43,13 @@ proc getcommits {rargs} {
error_popup "Cannot find the git directory \"$gitdir\"."
exit 1
}
+ set oldcommits {}
set commits {}
set phase getcommits
set startmsecs [clock clicks -milliseconds]
set nextupdate [expr $startmsecs + 100]
set ncmupdate 1
- if [catch {
- set parse_args [concat --default HEAD $rargs]
- set parsed_args [split [eval exec git-rev-parse $parse_args] "\n"]
- }] {
- # if git-rev-parse failed for some reason...
- if {$rargs == {}} {
- set rargs HEAD
- }
- set parsed_args $rargs
- }
+ set parsed_args [parse_args $rargs]
if [catch {
set commfd [open "|git-rev-list --header --topo-order --parents $parsed_args" r]
} err] {
@@ -59,9 +67,10 @@ proc getcommits {rargs} {
}
proc getcommitlines {commfd} {
- global commits parents cdate children
+ global oldcommits commits parents cdate children nchildren
global commitlisted phase commitinfo nextupdate
global stopped redisplaying leftover
+ global canv
set stuff [read $commfd]
if {$stuff == {}} {
@@ -119,10 +128,18 @@ to allow selection of commits to be disp
set id [lindex $ids 0]
set olds [lrange $ids 1 end]
set cmit [string range $cmit [expr {$j + 1}] end]
+ if {$phase == "updatecommits"} {
+ $canv delete all
+ set oldcommits $commits
+ set commits {}
+ unset children
+ unset nchildren
+ set phase getcommits
+ }
lappend commits $id
set commitlisted($id) 1
parsecommit $id $cmit 1 [lrange $ids 1 end]
- drawcommit $id
+ drawcommit $id 1
if {[clock clicks -milliseconds] >= $nextupdate} {
doupdate 1
}
@@ -132,7 +149,7 @@ to allow selection of commits to be disp
set stopped 0
set phase "getcommits"
foreach id $commits {
- drawcommit $id
+ drawcommit $id 1
if {$stopped} break
if {[clock clicks -milliseconds] >= $nextupdate} {
doupdate 1
@@ -168,16 +185,9 @@ proc readcommit {id} {
parsecommit $id $contents 0 {}
}
-proc parsecommit {id contents listed olds} {
- global commitinfo children nchildren parents nparents cdate ncleft
+proc updatechildren {id olds} {
+ global children nchildren parents nparents ncleft
- set inhdr 1
- set comment {}
- set headline {}
- set auname {}
- set audate {}
- set comname {}
- set comdate {}
if {![info exists nchildren($id)]} {
set children($id) {}
set nchildren($id) 0
@@ -196,6 +206,19 @@ proc parsecommit {id contents listed old
incr ncleft($p)
}
}
+}
+
+proc parsecommit {id contents listed olds} {
+ global commitinfo cdate
+
+ set inhdr 1
+ set comment {}
+ set headline {}
+ set auname {}
+ set audate {}
+ set comname {}
+ set comdate {}
+ updatechildren $id $olds
foreach line [split $contents "\n"] {
if {$inhdr} {
if {$line == {}} {
@@ -240,6 +263,9 @@ proc parsecommit {id contents listed old
proc readrefs {} {
global tagids idtags headids idheads tagcontents
+ foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
+ catch {unset $v}
+ }
set tags [glob -nocomplain -types f [gitdir]/refs/tags/*]
foreach f $tags {
catch {
@@ -324,7 +350,7 @@ proc error_popup msg {
tkwait window $w
}
-proc makewindow {} {
+proc makewindow {rargs} {
global canv canv2 canv3 linespc charspc ctext cflist textfont
global findtype findtypemenu findloc findstring fstring geometry
global entries sha1entry sha1string sha1but
@@ -334,6 +360,7 @@ proc makewindow {} {
menu .bar
.bar add cascade -label "File" -menu .bar.file
menu .bar.file
+ .bar.file add command -label "Update" -command [list updatecommits $rargs]
.bar.file add command -label "Reread references" -command rereadrefs
.bar.file add command -label "Quit" -command doquit
menu .bar.help
@@ -1445,7 +1472,7 @@ proc decidenext {{noread 0}} {
return $level
}
-proc drawcommit {id} {
+proc drawcommit {id reading} {
global phase todo nchildren datemode nextupdate
global numcommits ncmupdate displayorder todo onscreen
@@ -1474,20 +1501,29 @@ proc drawcommit {id} {
break
}
}
- drawmore 1
+ drawmore $reading
}
proc finishcommits {} {
- global phase
+ global phase oldcommits commits
global canv mainfont ctext maincursor textcursor
+ global parents
- if {$phase != "incrdraw"} {
+ if {$phase == "incrdraw" || $phase == "removecommits"} {
+ foreach id $oldcommits {
+ lappend commits $id
+ updatechildren $id $parents($id)
+ drawcommit $id 0
+ }
+ set oldcommits {}
+ drawrest
+ } elseif {$phase == "updatecommits"} {
+ set phase {}
+ } else {
$canv delete all
$canv create text 3 3 -anchor nw -text "No commits selected" \
-font $mainfont -tags textitems
set phase {}
- } else {
- drawrest
}
. config -cursor $maincursor
settextcursor $textcursor
@@ -3611,9 +3647,6 @@ proc rereadrefs {} {
set ref($id) [listrefs $id]
}
}
- foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
- catch {unset $v}
- }
readrefs
set refids [lsort -unique [concat $refids [array names idtags] \
[array names idheads] [array names idotherrefs]]]
@@ -3625,6 +3658,80 @@ proc rereadrefs {} {
}
}
+proc updatecommits {rargs} {
+ global commitlisted commfd phase
+ global startmsecs nextupdate ncmupdate
+ global idtags idheads idotherrefs
+ global leftover
+ global parsed_args
+ global canv
+ global oldcommits commits
+ global parents nchildren children ncleft
+
+ set old_args $parsed_args
+ parse_args $rargs
+
+ foreach id $old_args {
+ if {![regexp {^[0-9a-f]{40}$} $id]} continue
+ if {[info exists oldref($id)]} continue
+ set oldref($id) $id
+ lappend ignoreold "^$id"
+ }
+ foreach id $parsed_args {
+ if {![regexp {^[0-9a-f]{40}$} $id]} continue
+ if {[info exists ref($id)]} continue
+ set ref($id) $id
+ lappend ignorenew "^$id"
+ }
+
+ foreach a $old_args {
+ if {![info exists ref($a)]} {
+ lappend ignorenew $a
+ }
+ }
+
+ set phase updatecommits
+ set removed_commits [split [eval exec git-rev-list $ignorenew] "\n" ]
+ if {[llength $removed_commits] > 0} {
+ $canv delete all
+ set oldcommits {}
+ foreach c $commits {
+ if {[lsearch $c $removed_commits] < 0} {
+ lappend oldcommits $c
+ } else {
+ unset commitlisted($c)
+ }
+ }
+ set commits {}
+ unset children
+ unset nchildren
+ set phase removecommits
+ }
+
+ set args {}
+ foreach a $parsed_args {
+ if {![info exists oldref($a)]} {
+ lappend args $a
+ }
+ }
+
+ readrefs
+ if [catch {
+ set commfd [open "|git-rev-list --header --topo-order --parents $args $ignoreold" r]
+ } err] {
+ puts stderr "Error executing git-rev-list: $err"
+ exit 1
+ }
+ set startmsecs [clock clicks -milliseconds]
+ set nextupdate [expr $startmsecs + 100]
+ set ncmupdate 1
+ set leftover {}
+ fconfigure $commfd -blocking 0 -translation lf
+ fileevent $commfd readable [list getcommitlines $commfd]
+ . config -cursor watch
+ settextcursor watch
+}
+
proc showtag {tag isnew} {
global ctext cflist tagcontents tagids linknum
@@ -3692,6 +3799,6 @@ set redisplaying 0
set stuffsaved 0
set patchnum 0
setcoords
-makewindow
+makewindow $revtreeargs
readrefs
getcommits $revtreeargs
^ permalink raw reply related
* Re: [PATCH] Avoid using dc in git-count-objects
From: Linus Torvalds @ 2005-10-27 15:12 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.10.27.08.49.59.849081@smurf.noris.de>
On Thu, 27 Oct 2005, Matthias Urlichs wrote:
>
> It'll fork a subshell, but if the $() is a builtin, it won't exec.
>
> That being said, "echo $((1 + 2 + $((3 + 4))))" will not even fork.
Right. Don't confuse $(..) with $((..)).
They have absolutely nothing to do with each other, except for looking a
bit similar.
The $((..)) is shell-builtin arithmetic. I could imagine a broken shell
forking and executing "dc" for it, but quite frankly, that sounds so
unlikely as to be totally silly. So realistically, a shell either supports
it or not.
Oh - there's another similarity between $(..) and $((..)). They're both
POSIX 1003.2 standard features, so any "modern" shell should support them.
Although in practice I don't know if that means anything else than ksh
(where both syntaxes came from, actually).
Linus
^ permalink raw reply
* gitk shows an empty line between "Comments" and changed files
From: Pavel Roskin @ 2005-10-27 17:30 UTC (permalink / raw)
To: git
Hello!
gitk is now showing an empty line between "Comments" and changes files.
This change was caused by 8b7e5d76e836396a097bb6f61cf930ea872a7bd3 (Make
"gitk" work better with dense revlists).
git-diff-tree outputs some SHA1 as the first line if only one tree-ish
argument is provided. I don't see any way to suppress that output (see
diff-tree.c, line 114).
One solution would be to add an option to git-diff-tree to suppress all
headers (let's call it --no-headers).
Or maybe the SHA1 header should never be printed at all? It looks like
it's not documented anywhere. It doesn't break the tests.
While debugging the patch, I have found that the p variable is unused in
both functions that stopped passing it to git-diff-tree.
Also, gettreediffs function in gitk could use --names-only for
git-diff-tree, because it only needs names.
Maybe --names-only and --name-status should suppress the SHA1 header to
match their descriptions? Unfortunately, they don't suppress the patch
is -p is specified, so "matching the descriptions" would have to take
care of it.
P.S. I consider printing the SHA1 header in git-diff-tree an
undocumented feature (in other words, a bug).
Proposed patch:
Don't print the SHA1 when only one tree-ish is given to git-diff-tree.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/diff-tree.c b/diff-tree.c
index 382011a..ac53f48 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -111,7 +111,6 @@ static int diff_tree_commit(const unsign
unsigned char parent[20];
if (get_sha1_hex(buf + offset + 7, parent))
return -1;
- header = generate_header(name, sha1_to_hex(parent), buf, size);
diff_tree_sha1_top(parent, commit, "");
if (!header && verbose_header) {
header_prefix = "\ndiff-tree ";
--
Regards,
Pavel Roskin
^ permalink raw reply related
* [TENTATIVE PATCH] Complain loudly, dying, when a ref is invalid
From: Johannes Schindelin @ 2005-10-27 17:40 UTC (permalink / raw)
To: git
for_each_ref() used to ignore refs which point nowhere. Making git-fsck-objects
be happy about them.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Of course, it may be by design. But then, it does not feel
right to me. If this is intended behaviour, please don't let me
die dumb.
refs.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
applies-to: d29f6558d14b1da55642659c9874d4f52dac18bf
047627834b0ecb7ec0e0a98066b4b28688c374bc
diff --git a/refs.c b/refs.c
index a52b038..d74ede9 100644
--- a/refs.c
+++ b/refs.c
@@ -194,9 +194,9 @@ static int do_for_each_ref(const char *b
continue;
}
if (read_ref(git_path("%s", path), sha1) < 0)
- continue;
+ die("%s points nowhere!", path);
if (!has_sha1_file(sha1))
- continue;
+ die("%s does not point to a valid commit object!", path);
retval = fn(path, sha1);
if (retval)
break;
---
0.99.8.GIT
^ permalink raw reply related
* Re: [RFC] multi_ack protocol v2
From: Junio C Hamano @ 2005-10-27 17:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sergey Vlasov, git
In-Reply-To: <Pine.LNX.4.63.0510271227490.2724@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 27 Oct 2005, Sergey Vlasov wrote:
>
>> Actually, there is another way to pass some data from the server
>> which would be ignored by older clients - at the first stage,
>> when upload-pack sends the list of refs to the client:
>>
>> packet_write(1, "%s %s%c%s\n", sha1_to_hex(sha1), refname, '\0',
>> server_capabilities);
>
> That exploits that packet_write() uses vnsprintf() to find out the length,
> not strlen(). Sweet.
OK.
> get_remote_heads() would need to store the server_capabilities, maybe with
> a function "server_supports(const char *extension_string)"
Another thing that would probably be helpful is to redo
get_remote_heads() slightly differently, so that it can return
information on *all* refs the other end has. We need to extend
"struct ref" to mark which one was actually matched/ignored by
path_match() and ignore_funny. An completely untested patch is
attached, based on fetch-pack that still runs rev-list as an
external process, to outline the idea.
---
diff --git a/cache.h b/cache.h
index 2e36cc5..d39a006 100644
--- a/cache.h
+++ b/cache.h
@@ -329,6 +329,7 @@ struct ref {
unsigned char old_sha1[20];
unsigned char new_sha1[20];
unsigned char force;
+ unsigned char matched; /* when using REPORT_ALL */
struct ref *peer_ref; /* when renaming */
char name[0];
};
@@ -339,7 +340,9 @@ extern int path_match(const char *path,
extern int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
int nr_refspec, char **refspec, int all);
extern int get_ack(int fd, unsigned char *result_sha1);
-extern struct ref **get_remote_heads(int in, struct ref **list, int nr_match, char **match, int ignore_funny);
+#define GET_REMOTE_HEADS_IGNORE_FUNNY 1
+#define GET_REMOTE_HEADS_REPORT_ALL 2
+extern struct ref **get_remote_heads(int in, struct ref **list, int nr_match, char **match, int match_options);
extern struct packed_git *parse_pack_index(unsigned char *sha1);
extern struct packed_git *parse_pack_index_file(const unsigned char *sha1,
diff --git a/clone-pack.c b/clone-pack.c
index 9609219..8b63183 100644
--- a/clone-pack.c
+++ b/clone-pack.c
@@ -250,7 +250,7 @@ static int clone_pack(int fd[2], int nr_
struct ref *refs;
int status;
- get_remote_heads(fd[0], &refs, nr_match, match, 1);
+ get_remote_heads(fd[0], &refs, nr_match, match, GET_REMOTE_HEADS_IGNORE_FUNNY);
if (!refs) {
packet_flush(fd[1]);
die("no matching remote head");
diff --git a/connect.c b/connect.c
index b171c5d..f7a3550 100644
--- a/connect.c
+++ b/connect.c
@@ -12,8 +12,11 @@
* Read all the refs from the other end
*/
struct ref **get_remote_heads(int in, struct ref **list,
- int nr_match, char **match, int ignore_funny)
+ int nr_match, char **match, int match_options)
{
+ int ignore_funny = match_options & GET_REMOTE_HEADS_IGNORE_FUNNY;
+ int report_all = match_options & GET_REMOTE_HEADS_REPORT_ALL;
+
*list = NULL;
for (;;) {
struct ref *ref;
@@ -21,6 +24,7 @@ struct ref **get_remote_heads(int in, st
static char buffer[1000];
char *name;
int len;
+ int matched = 1;
len = packet_read_line(in, buffer, sizeof(buffer));
if (!len)
@@ -28,17 +32,22 @@ struct ref **get_remote_heads(int in, st
if (buffer[len-1] == '\n')
buffer[--len] = 0;
- if (len < 42 || get_sha1_hex(buffer, old_sha1) || buffer[40] != ' ')
- die("protocol error: expected sha/ref, got '%s'", buffer);
+ if (len < 42 || get_sha1_hex(buffer, old_sha1) ||
+ buffer[40] != ' ')
+ die("protocol error: expected sha/ref, got '%s'",
+ buffer);
name = buffer + 41;
- if (ignore_funny && 45 < len && !memcmp(name, "refs/", 5) &&
- check_ref_format(name + 5))
- continue;
+ if ((ignore_funny && 45 < len && !memcmp(name, "refs/", 5) &&
+ check_ref_format(name + 5)) ||
+ (nr_match && !path_match(name, nr_match, match))) {
+ if (!report_all)
+ continue;
+ matched = 0;
+ }
- if (nr_match && !path_match(name, nr_match, match))
- continue;
ref = xcalloc(1, sizeof(*ref) + len - 40);
+ ref->matched = matched;
memcpy(ref->old_sha1, old_sha1, 20);
memcpy(ref->name, buffer + 41, len - 40);
*list = ref;
diff --git a/fetch-pack.c b/fetch-pack.c
index 8566ab1..11fb1c1 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -13,6 +13,7 @@ static const char fetch_pack_usage[] =
static const char *exec = "git-upload-pack";
#define COMPLETE (1U << 0)
+#define EXCLUDE (1U << 1)
static int find_common(int fd[2], unsigned char *result_sha1,
struct ref *refs)
@@ -52,17 +53,24 @@ static int find_common(int fd[2], unsign
p = commit->parents;
while (p &&
rev_command_len + 44 < sizeof(rev_command)) {
- snprintf(rev_command + rev_command_len, 44,
- " ^%s",
- sha1_to_hex(p->item->object.sha1));
- rev_command_len += 43;
+ struct object *pobj = &(p->item->object);
+ if (!pobj->flags & EXCLUDE) {
+ snprintf(rev_command +
+ rev_command_len, 44,
+ " ^%s",
+ sha1_to_hex(pobj->sha1));
+ rev_command_len += 43;
+ }
+ pobj->flags |= EXCLUDE;
p = p->next;
}
continue;
}
repair:
- packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
- fetching++;
+ if (refs->matched) {
+ packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
+ fetching = 1;
+ }
}
packet_flush(fd[1]);
if (!fetching)
@@ -183,6 +191,8 @@ static int everything_local(struct ref *
unsigned char local[20];
struct object *o;
+ if (!refs->matched)
+ continue;
o = parse_object(remote);
if (!o || !(o->flags & COMPLETE)) {
retval = 0;
@@ -204,6 +214,16 @@ static int everything_local(struct ref *
return retval;
}
+static int no_matching_remote(struct ref *ref)
+{
+ while (ref)
+ if (ref->matched)
+ return 0;
+ else
+ ref = ref->next;
+ return 1;
+}
+
static int fetch_pack(int fd[2], int nr_match, char **match)
{
struct ref *ref;
@@ -211,8 +231,10 @@ static int fetch_pack(int fd[2], int nr_
int status;
pid_t pid;
- get_remote_heads(fd[0], &ref, nr_match, match, 1);
- if (!ref) {
+ get_remote_heads(fd[0], &ref, nr_match, match,
+ GET_REMOTE_HEADS_IGNORE_FUNNY |
+ GET_REMOTE_HEADS_REPORT_ALL);
+ if (no_matching_remote(ref)) {
packet_flush(fd[1]);
die("no matching remote head");
}
@@ -245,8 +267,9 @@ static int fetch_pack(int fd[2], int nr_
die("git-unpack-objects died with error code %d", code);
all_done:
while (ref) {
- printf("%s %s\n",
- sha1_to_hex(ref->old_sha1), ref->name);
+ if (ref->matched)
+ printf("%s %s\n",
+ sha1_to_hex(ref->old_sha1), ref->name);
ref = ref->next;
}
return 0;
diff --git a/send-pack.c b/send-pack.c
index 9f9a6e7..d7bb6c1 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -181,7 +181,8 @@ static int send_pack(int in, int out, in
int new_refs;
/* No funny business with the matcher */
- remote_tail = get_remote_heads(in, &remote_refs, 0, NULL, 1);
+ remote_tail = get_remote_heads(in, &remote_refs, 0, NULL,
+ GET_REMOTE_HEADS_IGNORE_FUNNY);
get_local_heads();
/* match them up */
^ permalink raw reply related
* Re: gitk shows an empty line between "Comments" and changed files
From: Junio C Hamano @ 2005-10-27 17:51 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1130434230.19641.21.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> Or maybe the SHA1 header should never be printed at all? It looks like
> it's not documented anywhere. It doesn't break the tests.
AFAIK, its only user (except humans) is patch-id.
> P.S. I consider printing the SHA1 header in git-diff-tree an
> undocumented feature (in other words, a bug).
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: Junio C Hamano @ 2005-10-27 18:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510270801560.4664@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Oh - there's another similarity between $(..) and $((..)). They're both
> POSIX 1003.2 standard features, so any "modern" shell should support them.
> Although in practice I don't know if that means anything else than ksh
> (where both syntaxes came from, actually).
OK, you prodded me enough to come to 21st century ;-).
I was hoping that doing .git/objects/ traversal and disk block
accounting ourselves maybe in C or Perl would be enough for that
particular program, but I would not object if the community
concensus is we would run on only POSIX shells anymore.
I still resist saying that we run only on Bash, though. I
suspect we already have some bashism on the periphery, but
eradicating them has been lower priority for me.
^ permalink raw reply
* Re: [RFC] multi_ack protocol v2
From: Johannes Schindelin @ 2005-10-27 18:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sergey Vlasov, git
In-Reply-To: <7vwtjy3lch.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 27 Oct 2005, Junio C Hamano wrote:
> Another thing that would probably be helpful is to redo
> get_remote_heads() slightly differently, so that it can return
> information on *all* refs the other end has. We need to extend
> "struct ref" to mark which one was actually matched/ignored by
> path_match() and ignore_funny. An completely untested patch is
> attached, based on fetch-pack that still runs rev-list as an
> external process, to outline the idea.
A completely tested patch (unfortunately in the middle of my work) does
not touch get_remote_heads() at all:
diff --git a/fetch-pack.c b/fetch-pack.c
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -274,7 +290,27 @@ static void mark_recent_complete_commits
}
}
-static int everything_local(struct ref *refs)
+static void filter_refs(struct ref **refs, int nr_match, char **match)
+{
+ struct ref *prev, *current, *next;
+
+ if (!nr_match)
+ return;
+
+ for (prev = NULL, current = *refs; current; current = next) {
+ next = current->next;
+ if (!path_match(current->name, nr_match, match)) {
+ if (prev == NULL)
+ *refs = next;
+ else
+ prev->next = next;
+ free(current);
+ } else
+ prev = current;
+ }
+}
+
+static int everything_local(struct ref **refs, int nr_match, char **match)
{
struct ref *ref;
int retval;
@@ -283,7 +319,7 @@ static int everything_local(struct ref *
track_object_refs = 0;
save_commit_buffer = 0;
- for (ref = refs; ref; ref = ref->next) {
+ for (ref = *refs; ref; ref = ref->next) {
struct object *o;
o = parse_object(ref->old_sha1);
@@ -305,8 +341,10 @@ static int everything_local(struct ref *
if (cutoff)
mark_recent_complete_commits(cutoff);
- for (retval = 1; refs ; refs = refs->next) {
- const unsigned char *remote = refs->old_sha1;
+ filter_refs(refs, nr_match, match);
+
+ for (retval = 1, ref = *refs; ref ; ref = ref->next) {
+ const unsigned char *remote = ref->old_sha1;
unsigned char local[20];
struct object *o;
@@ -317,16 +355,16 @@ static int everything_local(struct ref *
continue;
fprintf(stderr,
"want %s (%s)\n", sha1_to_hex(remote),
- refs->name);
+ ref->name);
continue;
}
- memcpy(refs->new_sha1, local, 20);
+ memcpy(ref->new_sha1, local, 20);
if (!verbose)
continue;
fprintf(stderr,
"already have %s (%s)\n", sha1_to_hex(remote),
- refs->name);
+ ref->name);
}
return retval;
}
@@ -338,12 +376,12 @@ static int fetch_pack(int fd[2], int nr_
int status;
pid_t pid;
- get_remote_heads(fd[0], &ref, nr_match, match, 1);
+ get_remote_heads(fd[0], &ref, 0, NULL, 1);
if (!ref) {
packet_flush(fd[1]);
die("no matching remote head");
}
- if (everything_local(ref)) {
+ if (everything_local(&ref, nr_match, match)) {
packet_flush(fd[1]);
goto all_done;
}
^ permalink raw reply
* Re: [TENTATIVE PATCH] Complain loudly, dying, when a ref is invalid
From: Junio C Hamano @ 2005-10-27 19:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510271936520.7518@wbgn013.biozentrum.uni-wuerzburg.de>
The only case that I can think of that this patch may make a
difference in behaviour in a valid repository is the HEAD
pointer that points at nowhere (i.e. refs/heads/master)
immediately after git-init-db, so in that sense this change may
be safe for most purposes.
However, we might want to write a tool to iterate over what we
have under .git/refs/ and warn about them to help the user fix
broken branches/tags, and do_for_each_ref() dying like this
would not help that usage.
Not that the current loop is any better for that purpose. We
silently ignore not just dangling ref and ref not storing
40-byte hex, but files starting with a period '.', names longer
than 255 bytes, and unreadable ones, all of which we would
probably want to warn about in such a tool.
-jc
^ permalink raw reply
* Re: [RFC] multi_ack protocol v2
From: Junio C Hamano @ 2005-10-27 19:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510272003060.22251@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> A completely tested patch (unfortunately in the middle of my work) does
> not touch get_remote_heads() at all:
Much nicer.
^ permalink raw reply
* Re: [TENTATIVE PATCH] Complain loudly, dying, when a ref is invalid
From: Johannes Schindelin @ 2005-10-27 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacgu3hta.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 27 Oct 2005, Junio C Hamano wrote:
> Not that the current loop is any better for that purpose. We
> silently ignore not just dangling ref and ref not storing
> 40-byte hex, but files starting with a period '.', names longer
> than 255 bytes, and unreadable ones, all of which we would
> probably want to warn about in such a tool.
Okay, how about 'fprintf(stderr, "Warning: ...\n"); continue;' instead of
'die("...");' then?
Ciao,
Dscho
^ permalink raw reply
* [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Chris Shoemaker @ 2005-10-27 20:39 UTC (permalink / raw)
To: git
I really like gitweb (thanks Kay!), but I thought it would be nice to
have a visual indication of patch size. I found this helpful when
scanning though the shortlogs.
To see what it looks like with the gitweb for gitweb (meta-gitweb?)
goto:
http://www.codesifter.com/cgi-bin/gitweb.cgi?p=gitweb.git;a=shortlog
I rather like the look of what I've hacked up (the enclosed patch),
but it should be considered as just a prototype: it only affects the
shortlog, it's horribly inefficient, and I don't really do perl. :)
If anyone thinks this is a good feature, then please tell me an
efficient way to get some heuristic of the patch size.
Right now, I'm using:
GIT_DIFF_OPTS='-U 0' $gitbin/git-diff-tree -p $hash | wc -l
which is pretty slow. Any suggestions?
-chris
Subject: [PATCH] initial hack at horizontal bars indicating patch size
---
gitweb.cgi | 38 +++++++++++++++++++++++++++++++++++++-
1 files changed, 37 insertions(+), 1 deletions(-)
c8d45f9a3cfdd7080a57e0de315f3ab9475f60bf
diff --git a/gitweb.cgi b/gitweb.cgi
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -53,6 +53,9 @@ if (defined $action) {
} elsif ($action eq "opml") {
git_opml();
exit;
+ } elsif ($action eq "bar.png") {
+ git_bar_png();
+ exit;
}
}
@@ -358,6 +361,16 @@ sub git_get_type {
return $type;
}
+sub git_get_commit_size {
+ my $hash = shift;
+
+ open my $fd, "-|", "GIT_DIFF_OPTS='-U 0' $gitbin/git-diff-tree -p $hash | wc -l" or return;
+ my $size = <$fd>;
+ close $fd or return;
+ chomp $size;
+ return $size;
+}
+
sub git_read_hash {
my $path = shift;
@@ -719,6 +732,21 @@ sub git_logo {
"\x12\x1c\x9a\xfe\x00\x00\x00\x00\x49\x45\x4e\x44\xae\x42\x60\x82";
}
+# git_bar_png (cached in browser for one day)
+sub git_bar_png {
+ print $cgi->header(-type => 'image/png', -expires => '+1d');
+ # cat bar.png | hexdump -e '"q" 16/1 "w%02x" "q . \n"' |
+ # sed 's/w/\\x/g' | sed 's/q/"/g'
+print "\x89\x50\x4e\x47\x0d\x0a\x1a\x0a\x00\x00\x00\x0d\x49\x48\x44\x52" .
+"\x00\x00\x00\x01\x00\x00\x00\x0c\x08\x02\x00\x00\x00\x2c\xe9\x40" .
+"\x00\x00\x00\x00\x3b\x49\x44\x41\x54\x08\x1d\x01\x30\x00\xcf\xff" .
+"\x00\xba\xba\xff\x02\xf1\xf1\x00\x02\xf2\xf2\x00\x02\xf1\xf2\x00" .
+"\x02\xf2\xf1\x00\x02\xf1\xf1\x00\x02\xf2\xf1\x00\x02\xf1\xf1\x00" .
+"\x02\xf1\xf2\x00\x02\xf1\xf1\x00\x02\xf2\xf2\x00\x02\xf2\xf1\x00" .
+"\x45\x85\x17\x49\x14\x70\x67\xdb\x00\x00\x00\x00\x49\x45\x4e\x44" .
+"\xae\x42\x60\x82";
+}
+
sub get_file_owner {
my $path = shift;
@@ -2280,8 +2308,16 @@ sub git_shortlog {
"<td class=\"link\">" .
$cgi->a({-href => "$my_uri?p=$project;a=commit;h=$commit"}, "commit") .
" | " . $cgi->a({-href => "$my_uri?p=$project;a=commitdiff;h=$commit"}, "commitdiff") .
- "</td>\n" .
+ "</td>\n";
+ my $scale = 100;
+ my $stretch = 32;
+ # commits of size 1.7*$scale will be $stretch pixels wide
+ my $size = int(log((git_get_commit_size($commit)+$scale)/$scale)*$stretch);
+ print "<td class=\"bar\">" .
+ "<img src=\"$my_uri?a=bar.png\" width=\"$size\" height=\"12\"/>" .
+ "</td>" .
"</tr>";
+
}
if ($#revlist >= (100 * ($page+1)-1)) {
print "<tr>\n" .
^ permalink raw reply
* Re: [TENTATIVE PATCH] Complain loudly, dying, when a ref is invalid
From: Junio C Hamano @ 2005-10-27 20:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510272125580.28705@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Thu, 27 Oct 2005, Junio C Hamano wrote:
>
>> Not that the current loop is any better for that purpose. We
>> silently ignore not just dangling ref and ref not storing
>> 40-byte hex, but files starting with a period '.', names longer
>> than 255 bytes, and unreadable ones, all of which we would
>> probably want to warn about in such a tool.
>
> Okay, how about 'fprintf(stderr, "Warning: ...\n"); continue;' instead of
> 'die("...");' then?
Yup. That sounds sensible.
^ permalink raw reply
* Re: [TENTATIVE PATCH] Complain loudly, dying, when a ref is invalid
From: Horst von Brand @ 2005-10-27 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vacgu3hta.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
[...]
> Not that the current loop is any better for that purpose. We
> silently ignore not just dangling ref and ref not storing
> 40-byte hex, but files starting with a period '.', names longer
> than 255 bytes, and unreadable ones, all of which we would
> probably want to warn about in such a tool.
I have yet to come across a filesystem allowing names of more than 255
characters...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Junio C Hamano @ 2005-10-27 22:02 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: git
In-Reply-To: <20051027203945.GC1622@pe.Belkin>
Chris Shoemaker <c.shoemaker@cox.net> writes:
> If anyone thinks this is a good feature, then please tell me an
> efficient way to get some heuristic of the patch size.
>
> Right now, I'm using:
>
> GIT_DIFF_OPTS='-U 0' $gitbin/git-diff-tree -p $hash | wc -l
>
> which is pretty slow. Any suggestions?
* do we really want to know the number of lines? sometimes the
number of pahts that are affected is more useful than number
of lines when assessing the damage, which can be done with
'git-diff-tree --name-only'.
* cache the result -- they never change.
An interesting question is what to do with merges, but probably
we can just ignore it for now.
^ permalink raw reply
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Chris Shoemaker @ 2005-10-27 23:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyqm1uvx.fsf@assigned-by-dhcp.cox.net>
On Thu, Oct 27, 2005 at 03:02:10PM -0700, Junio C Hamano wrote:
> Chris Shoemaker <c.shoemaker@cox.net> writes:
>
> > If anyone thinks this is a good feature, then please tell me an
> > efficient way to get some heuristic of the patch size.
> >
> > Right now, I'm using:
> >
> > GIT_DIFF_OPTS='-U 0' $gitbin/git-diff-tree -p $hash | wc -l
> >
> > which is pretty slow. Any suggestions?
>
> * do we really want to know the number of lines? sometimes the
> number of pahts that are affected is more useful than number
> of lines when assessing the damage, which can be done with
> 'git-diff-tree --name-only'.
That only shows the top-level names, so when 100s of files changes in
a subdir it looks just like one entry. It's ok when there's no
subdirs, but it just doesn't work when 95% of the code is under,
e.g. src/.
>
> * cache the result -- they never change.
True. Maybe gitk and gitweb can share a cache containing the tree
diffs. Or maybe git-core can cache tree diffs?
>
> An interesting question is what to do with merges, but probably
> we can just ignore it for now.
It's trivial to, e.g. use a different image for merges, maybe based on
# of parents?
But, in general, is there interest in a visual indicator of commit
size and/or type in gitweb?
-chris
^ permalink raw reply
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Linus Torvalds @ 2005-10-28 0:12 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: Junio C Hamano, git
In-Reply-To: <20051027234813.GA512@pe.Belkin>
On Thu, 27 Oct 2005, Chris Shoemaker wrote:
> >
> > * do we really want to know the number of lines? sometimes the
> > number of pahts that are affected is more useful than number
> > of lines when assessing the damage, which can be done with
> > 'git-diff-tree --name-only'.
>
> That only shows the top-level names, so when 100s of files changes in
> a subdir it looks just like one entry. It's ok when there's no
> subdirs, but it just doesn't work when 95% of the code is under,
> e.g. src/.
Add the "-r" flag to do the recursive thing, ie
git-diff-tree -r --name-only
should do the right thing.
> True. Maybe gitk and gitweb can share a cache containing the tree
> diffs. Or maybe git-core can cache tree diffs?
Creating them is fast enough if there is no IO. Make sure your project is
packed, and you should be ok.
The expensive part is the "-p" thing to create patches. If you avoid the
patch creation, you should be ok.
> But, in general, is there interest in a visual indicator of commit
> size and/or type in gitweb?
I kind of like it, but I'm not sure how useful it is, and maybe it does
really want the whole patch size (not just how many files it touches).
That's where caching might save your *ss.
Linus
^ permalink raw reply
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Chris Shoemaker @ 2005-10-28 0:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0510271709120.4664@g5.osdl.org>
On Thu, Oct 27, 2005 at 05:12:33PM -0700, Linus Torvalds wrote:
> Add the "-r" flag to do the recursive thing, ie
>
> git-diff-tree -r --name-only
>
> should do the right thing.
Ah, yes, it does. Thanks.
> > True. Maybe gitk and gitweb can share a cache containing the tree
> > diffs. Or maybe git-core can cache tree diffs?
>
> Creating them is fast enough if there is no IO. Make sure your project is
> packed, and you should be ok.
>
> The expensive part is the "-p" thing to create patches. If you avoid the
> patch creation, you should be ok.
git-diff-tree -r --name-only is pretty quick and it actually does a
halfway reasonable job of representing damage-potential.
> > But, in general, is there interest in a visual indicator of commit
> > size and/or type in gitweb?
>
> I kind of like it, but I'm not sure how useful it is, and maybe it does
> really want the whole patch size (not just how many files it touches).
Hard to say. Neither one is going to be perfect, so I'm ok with
settling for the cheap one if it's halfway reasonable. I think I'll
mock up the merge indicator and see if there's any value added there.
So, what's the best way to detect merges? Maybe see if
'git-cat-file commit $hash | grep ^parent | wc -l' is greater than 1?
> That's where caching might save your *ss.
Ok, but that cache would live inside GIT_DIR an be shared with gitk,
right?
-chris
^ permalink raw reply
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