* [PATCH] repack: allow simultaneous packing and pruning
From: Sam Vilain @ 2006-10-10 10:14 UTC (permalink / raw)
To: git
If using git-repack -a, unreferenced objects are kept behind in the
pack. This might be the best default, but there are no good ways
to clean up the packfiles if a lot of rebasing is happening, or
branches have been deleted.
---
see also http://colabti.de/irclogger/irclogger_log/git?date=2006-10-10,Tue&sel=27#l75
Documentation/git-repack.txt | 7 ++++++-
git-repack.sh | 14 +++++++++++++-
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 9516227..63ee7cb 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -9,7 +9,7 @@ objects into pack files.
SYNOPSIS
--------
-'git-repack' [-a] [-d] [-f] [-l] [-n] [-q]
+'git-repack' [-a] [-d] [-f] [-l] [-n] [-q] [-p]
DESCRIPTION
-----------
@@ -40,6 +40,11 @@ OPTIONS
existing packs redundant, remove the redundant packs.
Also runs gitlink:git-prune-packed[1].
+-p::
+ Before packing, remove any unreferenced objects with
+ gitlink:git-prune[1]. When used with '-a', unreferenced
+ objects in the old packs are not taken across.
+
-l::
Pass the `--local` option to `git pack-objects`, see
gitlink:git-pack-objects[1].
diff --git a/git-repack.sh b/git-repack.sh
index 640ad8d..a2ad955 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -7,13 +7,14 @@ USAGE='[-a] [-d] [-f] [-l] [-n] [-q]'
. git-sh-setup
no_update_info= all_into_one= remove_redundant=
-local= quiet= no_reuse_delta= extra=
+local= quiet= no_reuse_delta= extra= prune=
while case "$#" in 0) break ;; esac
do
case "$1" in
-n) no_update_info=t ;;
-a) all_into_one=t ;;
-d) remove_redundant=t ;;
+ -p) prune=t ;;
-q) quiet=-q ;;
-f) no_reuse_delta=--no-reuse-delta ;;
-l) local=--local ;;
@@ -32,6 +33,11 @@ case ",$all_into_one," in
,,)
rev_list='--unpacked'
pack_objects='--incremental'
+ if [ -n "$prune" ]
+ then
+ # prune junk first
+ git-prune
+ fi
;;
,t,)
rev_list=
@@ -40,8 +46,14 @@ case ",$all_into_one," in
# Redundancy check in all-into-one case is trivial.
existing=`cd "$PACKDIR" && \
find . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
+
+ if [ -n "$prune" ]
+ then
+ rev_list=`cd "$GIT_DIR" && find refs -type f -print`
+ fi
;;
esac
+
pack_objects="$pack_objects $local $quiet $no_reuse_delta$extra"
name=$(git-rev-list --objects --all $rev_list 2>&1 |
git-pack-objects --non-empty $pack_objects .tmp-pack) ||
--
1.4.2.g0ea2
^ permalink raw reply related
* Re: GIT 1.4.3-rc2
From: Martin Waitz @ 2006-10-10 9:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viris63xz.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
hoi :)
On Tue, Oct 10, 2006 at 12:11:04AM -0700, Junio C Hamano wrote:
> Modulo last minute brown paper bag, I think we are pretty close to the
> real thing, hopefully should happen this weekend.
very nice! :-)
have you looked into the git-fetch --update-head-ok thing I sent last
week?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Jakub Narebski @ 2006-10-10 9:15 UTC (permalink / raw)
To: git
In-Reply-To: <20061010053841.42852.qmail@web31815.mail.mud.yahoo.com>
Luben Tuikov wrote:
>> It probably is wise to resurrect those "redundant" links.
>
> If someone does this, can they also remove the now "other"
> redundant link? (the link at the pathname itself) A simple
> code analyzer would show the duplicate code in gitweb.
Easy, easy now.
I'd rather add some more "hidden" links, but for each hidden
link (which are convenience only, to have larger are to click,
or to have closer area to click) I'd like to have clearly marked
link (marked as a link, i.e. using default link style; and with link text
denoting _kind_ of link) which leads to the same contents.
For example on project list page I would made also project description
(and not only project name) clickable, leading tp project summary.
Making project name direct link wouldn't work for sites like kernel.org
with long (hierarchical) project names like
linux/kernel/git/wim/linux-2.6-watchdog-experimental.git
And for other sites project name is/can be bit on the short side.
But we agreed (I guess) to disagree on the whole redundancy in user
interface issue (although I agree on the issue of reducing clutter).
BTW. we can reduce redundancy in the code without need for removing
"alternate entry points" in interface, I think.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Show project README if available
From: Jakub Narebski @ 2006-10-10 9:00 UTC (permalink / raw)
To: git
In-Reply-To: <20061010025627.19317.70511.stgit@rover>
Petr Baudis wrote:
> + print $_ while (<$fd>);
Wouldn't it be better to do it in slurp mode, i.e.
{
local $/
print <$fd>;
}
instead?
Do you assume that README is HTML fragment? If not, you should esc_html it.
Besides, we have similar (if assumed to have one line only) file, namely
description.
Besides, README for a project can be huge. Git README has 589 lines!
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-10-10 8:54 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20061010014743.80094.qmail@web31801.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
> > * Improve blame view, making use of --porcelain option to git-blame (for
> > later). Perhaps change blame view from table based one to div based one.
>
> > Use different colors for different commits (graph coloring problem).
>
> Oh, no please no.
>
> Why do you think I left the color list as a list? I did try to use
> more colors when I wrote it, and it was ugly as h3ll and very distracting
> when doing real work. So I ended up with the two color (shades) we have
> now and this is what I submitted.
>
> Also, any kind of "graph coloring problem" would make blame slow.
One of ideas (without having some nice _mathematical_ solution, i.e. not
having for to try and check different coloring but calculating coloring,
of a blame graph coloring problem[*1*]) was to use few colors, 3, 6, 8
based on some hash of sha1 of commit (for example first character) plus
alternating "darkness" of those colors to ensure that neighbours would
have different colors. Another was to use first 6 characters of sha1 as
a color, then flatten the color to suitable for background (perhaps also
with some kind of ensuring that neigbour blames would have different color).
Junio idea of basing color/brighness (of some part of blame output at
least) on the _age_ of region (perhaps using two altrenating _colors_)
has also it's merit.
Nevertheless, such change would be preceded by an RFC, and discussion.
> In any way, if you/someone does implement this "coloring" can you please
> make it an option, because I'll never turn it on. Thanks!
Not a problem to make blame coloring a feature.
Footnotes:
[*1*] Blame graph coloring problem: 1) regions blamed on the same commit
should have the same color 2) neighbour blame regions should have different
colors.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: Show project README if available
From: Andreas Ericsson @ 2006-10-10 8:33 UTC (permalink / raw)
To: ltuikov; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <20061010051545.15859.qmail@web31801.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Petr Baudis <pasky@suse.cz> wrote:
>> If the project includes a README file, show it in the summary page.
>> The usual "this should be in the config file" argument does not apply here
>> since this can be larger and having such a big string in the config file
>> would be impractical.
>>
>> I don't know if this is suitable upstream, but it's one of the repo.or.cz
>> custom modifications that I've thought could be interesting for others
>> as well.
>
> I don't see how a read-me file relates to gitweb.
>
> People may call those files "00README" or "README.txt"
> or "README.TXT" or "README_001", etc.
>
> The contents of such a file has nothing to do with gitweb,
> and or git. It may work for repo.or.cz but is unlikely that
> it would work for all projects for all git repos and for all
> gitweb interfaces.
>
Well, git isn't the right tool for everything, and umbrellas are only
good when it rains.
> The contents of a read-me file could be quite large and thus
> not suitable for the "summary" page. Both the contents and the
> size may not be suitable. "repo.or.cz" is the exception, not
> the rule.
>
> A readme file isn't written with the intent of git or gitweb.
> It is a function of the project, not the SCM used to keep it in, or
> the SCM web interface used to show it.
>
I can quite clearly envision usage for a README file for gitweb
exclusive usage; It would show a link to coding guidelines,
email-addresses for mailing-lists and project maintainers, bugtracker
urls and other things which are handy to find fast on the web but that
you don't necessarily want to dig around inside the repo for.
the project-root/README usually holds info along the lines of
"This program is really spiffy. It does this, this and that, and if you
configure it properly, it will Make the World a Better Place(tm)."; Too
newbie'ish info for people looking to submit bugs, patches and suggestions.
> I don't understand why the "description" file doesn't do what
> you want? Do you need it to be multi-line or slightly larger?
> Why not just extend "description" and/or create/use a second
> file called "description_long" to store multi-line descriptions?
>
I imagine description_long is what's discussed here, although README is
the suggested name.
> Or why not extend the "description" file s.t. only the first
> line would be shown in the "description" line of "summary" and
> down below, show the rest of the description file if present?
>
Junio suggested this 2 hours before you sent your mail, and it seems as
reasonable now as it did then. It also makes .git/description consistent
with how we write and show commit-messages.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Junio C Hamano @ 2006-10-10 8:28 UTC (permalink / raw)
To: Jeff King; +Cc: Luben Tuikov, Petr Baudis, Jakub Narebski, git
In-Reply-To: <20061010070531.GB2413@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Oct 09, 2006 at 11:21:26PM -0700, Luben Tuikov wrote:
>
>> Anyone can come up with any "statistic" to convince anyone of
>> anything. It's the American way! (to financial success)
>
> Petr introduced quantitative evidence and an analysis. You can argue
> that his numbers or his analysis are incorrect, but berating statistics
> as a whole is not a compelling argument.
Although I tend to agree with Pasky, I think Luben has a point
in that the click count he quoted does not have enough samples
and also tainted by known skews (both Gitzilla and I have
admitted that we hit blames unnecessarily not because we wanted
to see the blamed project but because we wanted to see how the
blame on his site shows things) to draw any meaningful
conclusion.
But that is as far as I would go agreeing with Luben on this
thread. If we did not have anything else that obviously are
clickable it might be natural to expect people to click on
otherwise unhighlighted filenames to grab the blob data. But
the current layout that shows filenames in plain and a few
obviously clickable links on the same line draws eyes and mouse
away from the filename and to the links on the right hand side,
even for somebody like me, who intellectually knows (because I
merged it) that the filenames in trees ought to be clickable.
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Andreas Ericsson @ 2006-10-10 8:07 UTC (permalink / raw)
To: Jeff King; +Cc: Luben Tuikov, Petr Baudis, Jakub Narebski, git, Junio C Hamano
In-Reply-To: <20061010070531.GB2413@coredump.intra.peff.net>
This discussion has taken a wrong turn and ended up somewhere in the
murky backwaters of questionable sanity.
I like my links blue and underlined. Can't be arsed to mouse over things
to figure out if they're clickable. If they're not blue and underlined,
they're not, insofar as I'm concerned.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Does GIT has vc keywords like CVS/Subversion?
From: Rene Scharfe @ 2006-10-10 7:37 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Liu Yubao, Dongsheng Song, git
In-Reply-To: <46a038f90610091408y29f60a12gea7040b5412331c6@mail.gmail.com>
Martin Langhoff schrieb:
> For the outside of the SCM case, keyword subst is useful indeed if
> someone has a $version_unknown tarball, unpacks it and hacks away. It
> is a pretty broken scenario, and less likely to happen nowadays with
> easy access to SCM tools.
If you still have the tar file, and if it has been created using
git-archive or git-tar-tree it may contain the commit ID in an archive
comment. You can use git-get-tar-commit-id to extract it in that case.
This won't work with official git project tarballs btw., as commit ID
embedding has been turned off. The reason is that older tar versions
extracted the comment as a regular file, which confused users.
René
^ permalink raw reply
* GIT 1.4.3-rc2
From: Junio C Hamano @ 2006-10-10 7:11 UTC (permalink / raw)
To: git
I've tagged the tip of master as 1.4.3-rc2. Modulo last minute
brown paper bag, I think we are pretty close to the real thing,
hopefully should happen this weekend.
Changes since 1.4.3-rc1 are as follows; they are mostly fixes as
expected (except one thing -- which shows in this list itself).
Alan Chandler (2):
Update the gitweb/README file to include setting the GITWEB_CONFIG environment
Fix usage string to match that given in the man page
Alexandre Julliard (2):
git.el: Fixed inverted "renamed from/to" message.
vc-git.el: Switch to using git-blame instead of git-annotate.
Dennis Stosberg (2):
lock_ref_sha1_basic does not remove empty directories on BSD
Add default values for --window and --depth to the docs
Franck Bui-Huu (1):
Add git-upload-archive to the main git man page
Jakub Narebski (1):
gitweb: Cleanup Git logo and Git logo target generation
Junio C Hamano (9):
Makefile: install and clean merge-recur, still.
git-mv: invalidate the removed path properly in cache-tree
git-push: .git/remotes/ file does not require SP after colon
escape tilde in Documentation/git-rev-parse.txt
tar-tree deprecation: we eat our own dog food.
gitweb: Make the Git logo link target to point to the homepage
git-send-email: avoid uninitialized variable warning.
cherry-pick: make -r the default
Fix git-revert
Luben Tuikov (3):
gitweb: Escape ESCAPE (\e) character
gitweb: Do not print "log" and "shortlog" redundantly in commit view
gitweb: blame: Minimize vertical table row padding
Martin Waitz (4):
gitweb: document webserver configuration for common gitweb/repo URLs.
git-commit: cleanup unused function.
git-commit: fix coding style.
test-lib: separate individual test better in verbose mode.
Nicolas Pitre (1):
add commit count options to git-shortlog
Petr Baudis (4):
Show snapshot link in shortlog only if have_snapsho
gitweb: Separate (new) and (deleted) in commitdiff by a space
gitweb: Handle commits with empty commit messages more reasonably
gitweb: [commit view] Do not suppress commitdiff link in root commit
Rene Scharfe (1):
git-tar-tree: don't RUN_SETUP
Robin Rosenberg (1):
Error in test description of t1200-tutorial
Yasushi SHOJI (1):
gitweb: refactor decode() for utf8 conversion
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Jeff King @ 2006-10-10 7:05 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Petr Baudis, Jakub Narebski, git, Junio C Hamano
In-Reply-To: <20061010062126.46664.qmail@web31810.mail.mud.yahoo.com>
On Mon, Oct 09, 2006 at 11:21:26PM -0700, Luben Tuikov wrote:
> Anyone can come up with any "statistic" to convince anyone of
> anything. It's the American way! (to financial success)
Petr introduced quantitative evidence and an analysis. You can argue
that his numbers or his analysis are incorrect, but berating statistics
as a whole is not a compelling argument.
> Anyway, the "confused" link clearly says "blame". I'm not sure why
> your people were trying to think and figure it out, as opposed to
> simply clicking on the file name itself. It is the most intuitive
> thing to do as I mentioned in my previous email.
Is it? I think the point of Petr's data is to show that, for whatever
reason, people are NOT intuitively doing as you expect.
> Did you do any demographics on your clickers? What is their background?
Aren't they, by definition, gitweb users? And isn't that the target
demographic? You can argue that there are potential gitweb users who
will behave completely differently, but I haven't seen any evidence to
support that claim.
> I can hardly accept this "statistic" as a proof to "reintroduce
> the redundant links".
It's not a proof. It's evidence in support of a claim. Sorry, but this
isn't math.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Jeff King @ 2006-10-10 6:58 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <20061010064117.86409.qmail@web31813.mail.mud.yahoo.com>
On Mon, Oct 09, 2006 at 11:41:17PM -0700, Luben Tuikov wrote:
> Then let's universally underline absolutely _every_ link in gitweb
> which is clickable, regardless of where it appears, the font, typeset
> and size.
Instead, let's make a strawman argument!
Though I agree that it would be nicer for ALL links in gitweb to be
consistent, I think there is an argument to be made about look. However,
the specific example I mentioned is a single list in which some elements
are underlined and blue (which has been the classic user interface hint
for a link for a decade), and some aren't. Do you see why I think that
might be inconsistent?
> Unless you have "a priori" knowlege of "underline means clickable" there
Which was my argument in the first place (note that I was talking about
people with a high degree of computer exposure).
> is no chance of thinking that "not-underlined means not-clickable".
There is clearly a non-zero chance. Here's a relatively ridiculous
argument.
Look at the 'summary' page for a project. For each commit, there are
blue and underlined 'commitdiff', 'text', and 'snapshot' links. The
date, author, and message text have no such decoration. I click on the
underlined things and see that they are all links. I click on date and
author and see they are not links. The pattern of underlining links has
held for five out of six elements. Do you think it's unreasonable to
guess that the sixth element is not a link based on that pattern?
Look, I agree that not underlining everything might make the page look
nicer. And if we want to balance consistency against aesthetics, that's
fine. But please don't argue that there isn't an inconsistency.
-Peff
^ permalink raw reply
* Re: Why gitweb commitdiff NO diff output ?
From: Junio C Hamano @ 2006-10-10 6:54 UTC (permalink / raw)
To: Dongsheng Song; +Cc: git
In-Reply-To: <4b3406f0610092336v5ab58134i280f64223a272b0b@mail.gmail.com>
"Dongsheng Song" <dongsheng.song@gmail.com> writes:
> There is the result:
>
> www-data@ab:/home/repository/git/gcc$ for blob in \
>> a34d77e47bf1561db1ade4f6b247598b880f80d5 \
>> 7625c494df01d4745e67bd4423e2fdbe9fc43799 \
>> b207fe30a5430f97d27d398d89c974b068694c7a \
>> 57b07ace4bb6352416bbf9436b9f2642b3273257
>> do
>> git cat-file -t $blob || echo $blob does not exist
>> done
> blob
> blob
> blob
> blob
> www-data@ab:/home/repository/git/gcc$ git cat-file commit
> c977ee1b2e54d67bb379ce476f784431c32136d7 |
>> grep 'parent '
> parent b693aceaba66f741cd6735d4ecd16fe59394a2cf
> www-data@ab:/home/repository/git/gcc$ git diff-tree -p
> c977ee1b2e54d67bb379ce476f784431c32136d7 | wc
> 37 137 1179
> ...
> I have the SAME problem with ALL commits, ONLY the 2.4.x machine, but
> git-core/cg tools is OK. All git/cg/gitweb is good for other 2.6.x
> machines.
That's mildly interesting. I do not know the difference between
your 2.4 and 2.6 machines (nor how many of each you have). I am
guessing that either these machines are sharing one repository
over NFS, or they have their own copies and none of them is
corrupt (i.e. you got these reasonable results you pasted above
from all of them).
At this point I have to say that this sounds like a problem that
reproduces only for you on that particular machine. Maybe
comparing the apache logs from a good machine and a bad one
would tell you what's different between them?
I am not sure what version of gitweb your distribution packages,
but it used to be that commitdiff page wanted to create
temporary file somewhere on the filesystem (the variable was
$git_temp and by default it was set to "/tmp/gitweb", I think).
Your other pages such as commit and log page seem to be working,
so perhaps your gitweb has trouble writing there only on that
machine?
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Luben Tuikov @ 2006-10-10 6:41 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <20061010054643.GA565@coredump.intra.peff.net>
--- Jeff King <peff@peff.net> wrote:
> 2/3 to 1/3 if you're counting categories, but you haven't presented any
> evidence that the number of people in each category is the same.
>
> Besides which, I think that people with a high degree of exposure to the
> web tend to look for the things that look like buttons or links. The
> near-universal sign for links on the web is underlining (and typically
Then let's universally underline absolutely _every_ link in gitweb
which is clickable, regardless of where it appears, the font, typeset
and size.
Who will be my hero and submit that patch? I'll surely commit it
and make the people happy.
> an alternate color). Looking at the repo.or.cz file lists, I see that
> none of the files is highlighted but the directories are. What am I to
> guess (either by intuition or by "figuring it out") except that there is
> some difference between clicking the two? I think we are failing a
> consistency test.
Let's see:
Each line which starts with a "d" also has some kind of underlined
text in the second column.
Each line which starts with a "-" has text which is not underlined
in the second column.
Which implies a connection between the "d" and the property of
underlining.
Unless you have "a priori" knowlege of "underline means clickable" there
is no chance of thinking that "not-underlined means not-clickable".
Luben
^ permalink raw reply
* Re: Why gitweb commitdiff NO diff output ?
From: Dongsheng Song @ 2006-10-10 6:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viris9a6g.fsf@assigned-by-dhcp.cox.net>
There is the result:
www-data@ab:/home/repository/git/gcc$ for blob in \
> a34d77e47bf1561db1ade4f6b247598b880f80d5 \
> 7625c494df01d4745e67bd4423e2fdbe9fc43799 \
> b207fe30a5430f97d27d398d89c974b068694c7a \
> 57b07ace4bb6352416bbf9436b9f2642b3273257
> do
> git cat-file -t $blob || echo $blob does not exist
> done
blob
blob
blob
blob
www-data@ab:/home/repository/git/gcc$ git cat-file commit
c977ee1b2e54d67bb379ce476f784431c32136d7 |
> grep 'parent '
parent b693aceaba66f741cd6735d4ecd16fe59394a2cf
www-data@ab:/home/repository/git/gcc$ git diff-tree -p
c977ee1b2e54d67bb379ce476f784431c32136d7 | wc
37 137 1179
I have the SAME problem with ALL commits, ONLY the 2.4.x machine, but
git-core/cg tools is OK. All git/cg/gitweb is good for other 2.6.x
machines.
you can browse the two gitweb site:
2.4.27 http://www.foresee.com.cn:8888/git/?p=gcc/.git;a=shortlog
2.6.16 http://www.foresee.com.cn:9999/git/?p=gcc/.git;a=shortlog
2006/10/10, Junio C Hamano <junkio@cox.net>:
> Junio C Hamano <junkio@cox.net> writes:
>
> > "Dongsheng Song" <dongsheng.song@gmail.com> writes:
> >
> >> NO.
> >>
> >> When I change the repository's owner to gitweb process, no diff output yet.
> >>
> >> $ chown -R www-data:www-data cauchy/ gcc/ mph/
> >>
> >> 2006/10/10, Junio C Hamano <junkio@cox.net>:
> >>> The site does not return any of these four blobs that are part
> >>> of the commitdiff when a=blob is requested on them.
> >>>
> >>> file:a34d77e47bf1561db1ade4f6b247598b880f80d5 ->
> >>> file:7625c494df01d4745e67bd4423e2fdbe9fc43799
> >>>
> >>> file:b207fe30a5430f97d27d398d89c974b068694c7a ->
> >>> file:57b07ace4bb6352416bbf9436b9f2642b3273257
> >>>
> >>> I would first suspect if the repository actually have them _and_
> >>> with an appropriate mode protection to be readable by your
> >>> gitweb process.
> >
> > And does the repository have these four blob objects?
>
> Sorry, the follow-up question was not very helpful to guide
> another person over e-mail. Let's try again with more specific
> questions.
>
> What do these say in that repository when run as the webserver
> user?
>
> $ for blob in \
> a34d77e47bf1561db1ade4f6b247598b880f80d5 \
> 7625c494df01d4745e67bd4423e2fdbe9fc43799 \
> b207fe30a5430f97d27d398d89c974b068694c7a \
> 57b07ace4bb6352416bbf9436b9f2642b3273257
> do
> git cat-file -t $blob || echo $blob does not exist
> done
> $ git cat-file commit c977ee1b2e54d67bb379ce476f784431c32136d7 |
> grep 'parent '
> $ git diff-tree -p c977ee1b2e54d67bb379ce476f784431c32136d7 | wc
>
> The first one tries to make sure you have those four blob
> objects in the repository, the second tries to make sure the
> commit is a single parent commit as your gitweb output suggests,
> and the last one is to obtain the diff text.
>
> Also do you have the same problem with other commits, or is this
> the only commit your gitweb is having trouble with showing
> commitdiff?
>
>
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Luben Tuikov @ 2006-10-10 6:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslhw7mfm.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> I would agree with that if we did not have anything on the right
> hand side that attracts eye and hand to tempt clicking. And
> that would be true for all levels of users.
>
> If we replaced UNIXy mode bits with folder/file/symlink icons,
> people might be tempted to click on them as well.
Then they should probably "get" the jpg/png image of the icon, ;-)
each time they click on it. If they really wanted the file, then
they should probably just simply click on the file name.
Luben
^ permalink raw reply
* Re: "fatal: Untracked working tree file 'so-and-so' would be overwritten by merge"
From: Junio C Hamano @ 2006-10-10 6:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610090858120.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 8 Oct 2006, Junio C Hamano wrote:
>>
>> Note note note. The above patch alone leaves merge risky to
>> remove an untracked working tree files, and needs to be
>> compensated by corresponding checks to the git-merge-xxx
>> strategies. The original code was overcautious, but was
>> protecting valid cases too.
>
> I think the difference _should_ be that we only remove the local file if
> it was removed _remotely_.
>...
> Agreed?
I reviewed the patch I sent out, the one after the one you
responded to, and I think it (which is the one I have in "pu")
is in line with the reasoning you outlined in your message.
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Luben Tuikov @ 2006-10-10 6:21 UTC (permalink / raw)
To: Petr Baudis, Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <20061009205551.GO20017@pasky.or.cz>
--- Petr Baudis <pasky@suse.cz> wrote:
> I was looking into accesslogs of repo.or.cz for something and noticed
> that I see unusually large number of blame requests. That of course
> attracted my curiosity and I came to conclusion that what I'm seeing is
> not just my personal whim but we have serious usability problem here.
>
> I'm unfortunately not sure when the update of repo.or.cz gitweb which
> dropped the blob/tree links happenned, so the following _is_ somewhat
> dubious, but I think it's quite telling anyway.
>
> I have three samples (logfiles) available: #2 almost certainly when the
> blob link was still there, #1 covering the switch and some time before
> and after, and #0 certainly when the blob link was not there anymore,
> but unfortunately spanning only one or two days.
>
> This is the count of actions invoked from the tree, commit and
> commitdiff view (using the referer information):
>
> blame blob total requests containing 'a='
> #2 1 18 264
> #1 31 23 399
> #0 4 6 50
>
> The disparation between #2 and #1,#0 is quite apparent. If we want more
> exact results, I will let #0 accumulate data for a week and then revert
> the removal of the links and start another sample.
Oh, my, oh, my.
Anyone can come up with any "statistic" to convince anyone of
anything. It's the American way! (to financial success)
I mean, I can even give you a mathematical series which I can add
in certain orders to give me any number I want... Which is not at
all intutitive.
Anyway, the "confused" link clearly says "blame". I'm not sure why
your people were trying to think and figure it out, as opposed to
simply clicking on the file name itself. It is the most intuitive
thing to do as I mentioned in my previous email.
Did you do any demographics on your clickers? What is their background?
Did you try to calculate how statistically correct your sample is
and if the clickers represent the general computer population out there?
What is your sampling error?
I can hardly accept this "statistic" as a proof to "reintroduce
the redundant links".
But I give up.
If you guys want the redundant links back in, so be it -- submit
a patch.
Then let's fortify gitweb, because we can. Lets add links and more
redundancy to fortify the user interface so that all and any possibilities
are covered. And as soon as a NEW git facility is introduced, then
we'll add 10 or 20 more links to gitweb for this just one, single
new facility. Then with each new single facility if it is related to
any other, the number of links would grow exponentially. Then after
such and such time has passed, let's look at the code. Then let's
ask if someone has left maintaining the then gitweb jungle. More
importantly, let's ask if someone has left _using_ it. (That would
be the ripe time to start afresh with gitweb2.perl.)
As long as job is being done and the patches are flowing in, and
more and more code is introduced, albeit redundantly, we shouldn't
care what the people who use this every day want or care for.
Hey, let's add more links!
Luben
P.S. I'll go and collect some statistics now.
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Jeff King @ 2006-10-10 5:46 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <20061010053841.42852.qmail@web31815.mail.mud.yahoo.com>
On Mon, Oct 09, 2006 at 10:38:41PM -0700, Luben Tuikov wrote:
> The interesting point here is that people with zero and high
> computer exposure tend to click on the file name to obtain it.
> Only people with some computer exposure start to "think" and
> "figure it out" and fail to intuit to naively point at the
> file name to get the file.
>
> So this is 2/3 to 1/3.
2/3 to 1/3 if you're counting categories, but you haven't presented any
evidence that the number of people in each category is the same.
Besides which, I think that people with a high degree of exposure to the
web tend to look for the things that look like buttons or links. The
near-universal sign for links on the web is underlining (and typically
an alternate color). Looking at the repo.or.cz file lists, I see that
none of the files is highlighted but the directories are. What am I to
guess (either by intuition or by "figuring it out") except that there is
some difference between clicking the two? I think we are failing a
consistency test.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Junio C Hamano @ 2006-10-10 5:46 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20061010053841.42852.qmail@web31815.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- Junio C Hamano <junkio@cox.net> wrote:
>> Having said that, I agree to the point you are trying to make
>> here. It was a mistake to remove blob/tree links from the view
>> that lists pathnames.
>>
>> If we did not have any obviously clickable links on the right
>> hand side it might have been a different story, but when given
>> UNIXy permission bits, pathname and blame/history/raw links,
>> nobody would think of clicking on the pathname itself to grab
>> its contents. The blame link would give you the same
>
> I've seen the exact opposite.
>
> BTW, what is our standard here? People with zero-computer
> exposure? With some? With high?
>
> Certainly, if I didn't know what a folder/directory/tree is,
> and what a file is and I was told to "get" that file, the first
> thing I'd do when I see it on the screen would be to "put my pointer
> over the file and press the action button".
I would agree with that if we did not have anything on the right
hand side that attracts eye and hand to tempt clicking. And
that would be true for all levels of users.
If we replaced UNIXy mode bits with folder/file/symlink icons,
people might be tempted to click on them as well.
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Luben Tuikov @ 2006-10-10 5:38 UTC (permalink / raw)
To: Junio C Hamano, Petr Baudis; +Cc: git
In-Reply-To: <7vy7ro7o3g.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Having said that, I agree to the point you are trying to make
> here. It was a mistake to remove blob/tree links from the view
> that lists pathnames.
>
> If we did not have any obviously clickable links on the right
> hand side it might have been a different story, but when given
> UNIXy permission bits, pathname and blame/history/raw links,
> nobody would think of clicking on the pathname itself to grab
> its contents. The blame link would give you the same
I've seen the exact opposite.
BTW, what is our standard here? People with zero-computer
exposure? With some? With high?
Certainly, if I didn't know what a folder/directory/tree is,
and what a file is and I was told to "get" that file, the first
thing I'd do when I see it on the screen would be to "put my pointer
over the file and press the action button".
It is when people actually start to "think" is when they fail
to naively click on the pathname (name of the file) to get it.
The naive approach is to simply click on what you want to get.
The interesting point here is that people with zero and high
computer exposure tend to click on the file name to obtain it.
Only people with some computer exposure start to "think" and
"figure it out" and fail to intuit to naively point at the
file name to get the file.
So this is 2/3 to 1/3.
> information (and a bit more) and people would just go there
> without much thinking.
>
> It probably is wise to resurrect those "redundant" links.
If someone does this, can they also remove the now "other"
redundant link? (the link at the pathname itself) A simple
code analyzer would show the duplicate code in gitweb.
Luben
^ permalink raw reply
* Re: [PATCH] gitweb: Show project README if available
From: Luben Tuikov @ 2006-10-10 5:15 UTC (permalink / raw)
To: Petr Baudis, Junio C Hamano; +Cc: git
In-Reply-To: <20061010025627.19317.70511.stgit@rover>
--- Petr Baudis <pasky@suse.cz> wrote:
> If the project includes a README file, show it in the summary page.
> The usual "this should be in the config file" argument does not apply here
> since this can be larger and having such a big string in the config file
> would be impractical.
>
> I don't know if this is suitable upstream, but it's one of the repo.or.cz
> custom modifications that I've thought could be interesting for others
> as well.
I don't see how a read-me file relates to gitweb.
People may call those files "00README" or "README.txt"
or "README.TXT" or "README_001", etc.
The contents of such a file has nothing to do with gitweb,
and or git. It may work for repo.or.cz but is unlikely that
it would work for all projects for all git repos and for all
gitweb interfaces.
The contents of a read-me file could be quite large and thus
not suitable for the "summary" page. Both the contents and the
size may not be suitable. "repo.or.cz" is the exception, not
the rule.
A readme file isn't written with the intent of git or gitweb.
It is a function of the project, not the SCM used to keep it in, or
the SCM web interface used to show it.
I don't understand why the "description" file doesn't do what
you want? Do you need it to be multi-line or slightly larger?
Why not just extend "description" and/or create/use a second
file called "description_long" to store multi-line descriptions?
Or why not extend the "description" file s.t. only the first
line would be shown in the "description" line of "summary" and
down below, show the rest of the description file if present?
This way it is known that this is a function of gitweb.
Luben
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
>
> gitweb/gitweb.perl | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 7547c4d..4e56af9 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2535,6 +2535,14 @@ sub git_summary {
> }
> print "</table>\n";
>
> + if (-s "$projectroot/$project/README") {
> + if (open my $fd, "$projectroot/$project/README") {
> + print "<div class=\"title\">readme</div>\n";
> + print $_ while (<$fd>);
> + close $fd;
> + }
> + }
> +
> open my $fd, "-|", git_cmd(), "rev-list", "--max-count=17",
> git_get_head_hash($project)
> or die_error(undef, "Open git-rev-list failed");
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Junio C Hamano @ 2006-10-10 5:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vslhx9k6c.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>> This is the count of actions invoked from the tree, commit and
>> commitdiff view (using the referer information):
>>
>> blame blob total requests containing 'a='
>> #2 1 18 264
>> #1 31 23 399
>> #0 4 6 50
>>
>> The disparation between #2 and #1,#0 is quite apparent. If we want more
>> exact results, I will let #0 accumulate data for a week and then revert
>> the removal of the links and start another sample.
>
> I am not sure -- you are certainly counting me looking at your
> blame output while working on the slimmed down blame output (you
> may remember that I noted that while your output gives names and
> dates for each line which is busier I kind of liked it in one of
> my previous messages), and we talked about gitweb blame lot
> recently on the list so that might have spurred people's
> curiosity.
Having said that, I agree to the point you are trying to make
here. It was a mistake to remove blob/tree links from the view
that lists pathnames.
If we did not have any obviously clickable links on the right
hand side it might have been a different story, but when given
UNIXy permission bits, pathname and blame/history/raw links,
nobody would think of clicking on the pathname itself to grab
its contents. The blame link would give you the same
information (and a bit more) and people would just go there
without much thinking.
It probably is wise to resurrect those "redundant" links.
^ permalink raw reply
* Re: [PATCH] gitweb: Show project README if available
From: Junio C Hamano @ 2006-10-10 4:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vejtg97qh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>> If the project includes a README file, show it in the summary page.
>...
> I wonder how this should relate to .git/description file,
> though. In other words, it _might_ make sense to change where
> we show the contents of description right now to show the first
> line and take README from the same location.
Also we might want to consider using this file (or description)
for git-daemon "motd" action if we were to enhance it. I
remember that early days of git-daemon some people wanted to
have motd.
^ permalink raw reply
* Re: [PATCH] gitweb: Show project README if available
From: Junio C Hamano @ 2006-10-10 3:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061010025627.19317.70511.stgit@rover>
Petr Baudis <pasky@suse.cz> writes:
> If the project includes a README file, show it in the summary page.
> The usual "this should be in the config file" argument does not apply here
> since this can be larger and having such a big string in the config file
> would be impractical.
>
> I don't know if this is suitable upstream, but it's one of the repo.or.cz
> custom modifications that I've thought could be interesting for others
> as well.
I agree something like this would be very useful.
I wonder how this should relate to .git/description file,
though. In other words, it _might_ make sense to change where
we show the contents of description right now to show the first
line and take README from the same location.
Having said that I'd take this as is in "next" and wait for
public to decide having two separate files is Ok (which I
suspect is the case) or we'd be better off in the longer term to
try to minimize random files under $GIT_DIR.
^ 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