* Clueless bisect error message
From: Nguyen Thai Ngoc Duy @ 2006-10-11 7:08 UTC (permalink / raw)
To: git
$ git bisect start
won't bisect on seeked tree
It complained because .git/head-name contained 't' which had been
deleted before. git-bisect reset works. However I'd request git-bisect
to inform more useful messages. At first, I was completely stunned:
"what is a seeked tree? how can I fix that?"
--
Duy
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Junio C Hamano @ 2006-10-11 5:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <egdge3$t12$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> 1. Cleanups and refactoring
>
> * HTML and CSS cleanup. All (or almost all) styling should be done using
> CSS, and not embedded style or presentation elements. All HTML elements
> except perhaps a few should have either class attribute (if such
> element can be multiple times on page) or id attribute (if there can be
> only one such element). Perhaps some class attributes should be changed
> to id attributes. Gitweb has much improved from the incorporation in
> this area.
It scares me when somebody says "all X should do Y". Aiming for
consistency and cleanliness is good but taking it to extreme and
becoming dogmatic about it isn't. Let's not repeat the crusade
against redundant links.
> ... When the new
> --grep/--author/--commiter options to git-rev-list hits released version,
> perhaps also git_search could be put together with the previous set.
Sounds like a good idea, but I think people can (and should)
start preparing for it in "next"; after all that is what "next"
is for.
> * Refactor calling a git command and reading it's output into separate
> subroutine git_command/git_pipe, so for example if someone _has_ to use
> gitweb with ancient Perl version which does not understand list version
> of magic "-|" open could do it changing only one subroutine. Well, we can
> use Git.pm when it hits main release.
I agree this is a good thing to do while refactoring. There are
too many similar looking code sprinkled all over. Git.pm is
already in the "master" and there is nothing cooking in "next".
> * Add simplified git config file parser, which would _read_ only gitweb
> entries (and convert them to bool/int if necessary). With this we could
> move description, category, export_ok, .hide, cloneurl to config file,
> instead of cluttering $GIT_DIR. Or just make it an option (read file
> first, if it doesn't exist try config file).
I do not see why you would need anything "simplified"; I think
writing a .git/config parser purely in Perl is much easier than
waiting for libified interface that talks .xs and would run just
as efficient -- after all Perl is the ideal tool for text file
processing like this. And I do not particularly worry about
issues that could arise from two different configuration parsers
having different set of bugs. The file format is simple enough.
It would be a very good addition to Git.pm suite.
> * Add categories support a la gitweb-xmms2 to the projects list view (and
> perhaps also OPML); perhaps with option to use first part of path to
> repository as category.
Perhaps; hosting site would want this.
> * Code highlighting (or generic filter) support in blob view, perhaps as
> a feature.
Not particularly interested myself but as long as it would not
add huge load on the server I would not much object either.
> * Crossreferencing in blob view.
Lxr is certainly interesting, but I would rather use local "git grep".
> * add summary of number of lines changed for each file (a la darcsview)
> in the difftree part of commit and *diff* views, e.g.
>
> blame.c +1 -0 diff | history | blame
>
> or something like that.
I'll place "diff --numstat" to the stack of "things to do on the
core side". Should be trivial.
> * Reflog view (most probably limited to heads only). I'm not sure if it is
> worth time spend on calling git commands to mark unreachable commits for
> example using strikethrough, and hyperlink reachable. Any ideas how such
> a view should look like?
If the feature is useful, do not be afraid to add core side
support for it. As long as the proposed core side support is
reasonable and not too specific to a niche task, that is.
> * "List of the files in given directory, touched by given commit"
Have no idea what you mean. "diff-tree -r --name-only $commit"?
> X. Proposed improvements to core git commands
> * add --stdin option to git-ls-tree, a la --stdin option to git-diff-tree.
Not particularly interested, as it is unclear how the output
boundary should be marked, but should be trivial to add once we
know what the output should look like.
> * add --follow option to git-rev-list, allow to provide path limiter via
> stdin (with --stdin option) in git-diff-tree
The "path limiter via stdin" part is murky. I would not object
to "rev-list --follow=$this_path_at_the_tip $start_at_this_commit"
which I can see clear semantics for.
^ permalink raw reply
* Re: git-fetch --update-head-ok ?
From: Junio C Hamano @ 2006-10-11 5:25 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20061003123452.GK2871@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> I have no idea why there is a --update-head-ok, but the code looks
> like it has a typo:
I looked at it again, and indeed it looks like a typo.
> @@ -433,7 +433,7 @@ esac
> # If the original head was empty (i.e. no "master" yet), or
> # if we were told not to worry, we do not have to check.
> case ",$update_head_ok,$orig_head," in
> -*,, | t,* )
> +*,, | ,t,* )
> ;;
> *)
> curr_head=$(git-rev-parse --verify HEAD 2>/dev/null)
Interestingly enough, when update_head_ok is set, orig_head
never is so the typo does not matter at all by pure accident (it
was there from the very first version that introduced this
feature).
It should just be something like this:
case "$orig_head" in
'')
;;
?*)
curr_head=$(git-rev-parse --verify HEAD 2>/dev/null)
...
^ permalink raw reply
* Re: [PATCH] gitweb: Fix zebra coloring flip introduced by eeef88cd2
From: Junio C Hamano @ 2006-10-11 4:45 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20061011020903.63831.qmail@web31812.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Commit eeef88cd2 introduced $group_size which
> inverted the meaning of $current_color.
>
> Normally we start with white (same as background) color
> for the zebra coloring, and flip to dark shade only when
> another commit changed some lines of the file. (Thus
> if there are no changes, the file appears black on white.)
I do not have much preference either way, but it was done more
or less deliberately to match what you did with 6dd36ac.
^ permalink raw reply
* Re: Why gitweb commitdiff NO diff output ?
From: Dongsheng Song @ 2006-10-11 2:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viris2hkh.fsf@assigned-by-dhcp.cox.net>
Yes, it was /tmp/gitweb permission problem.
I think it's a good idea for add a "common pitfals" section to gitweb/README.
2006/10/11, Junio C Hamano <junkio@cox.net>:
>
> Care to share your experience to help others?
>
> If it was /tmp/gitweb permission problem then the newer gitweb
> shouldn't have that issue so it would be a moot point, but if
> the pitfall still applies to the current software we might want
> to add a "common pitfals" section to gitweb/README.
>
^ permalink raw reply
* [PATCH] gitweb: Fix zebra coloring flip introduced by eeef88cd2
From: Luben Tuikov @ 2006-10-11 2:09 UTC (permalink / raw)
To: git
Commit eeef88cd2 introduced $group_size which
inverted the meaning of $current_color.
Normally we start with white (same as background) color
for the zebra coloring, and flip to dark shade only when
another commit changed some lines of the file. (Thus
if there are no changes, the file appears black on white.)
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 173f521..77063f0 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2583,7 +2583,7 @@ sub git_blame2 {
git_print_page_path($file_name, $ftype, $hash_base);
my @rev_color = (qw(light2 dark2));
my $num_colors = scalar(@rev_color);
- my $current_color = 0;
+ my $current_color = 1;
my $last_rev;
print <<HTML;
<div class="page_body">
--
1.4.3.rc2.gd2a59
^ permalink raw reply related
* Re: [ANNOUNCE] repo.or.cz does full-fledged hosting now, and more
From: Martin Langhoff @ 2006-10-11 1:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061011003051.GS20017@pasky.or.cz>
On 10/11/06, Petr Baudis <pasky@ucw.cz> wrote:
> few weeks ago, I have announced repo.or.cz public mirroring service
> which would snap repositories, mirror them and provide a gitweb
> interface for them. While at it, it also aims to serve as a testbed
> for various new cool gitweb-related enhancements.
I shall co-opt your "git-related free services" message and say:
Eduforge.org is a Gforge setup that supports GIT, openly available for
education-related projects.
Wohoo!
martin
^ permalink raw reply
* Re: [PATCH] cvsserver: fix "cvs diff" in a subdirectory
From: Junio C Hamano @ 2006-10-11 1:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Martyn Smith, Martin Langhoff
In-Reply-To: <Pine.LNX.4.63.0610110032560.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Will park this and the "U for update, M for modified" patch in
"pu", waiting for acks from actual git-cvsserver users. It
feels it is safe enough change, so with an Ack from Mart[yi]n
it may be woth having it in 1.4.3
^ permalink raw reply
* Re: [PATCH] paginate git-diff by default
From: Junio C Hamano @ 2006-10-11 0:57 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20061010191625.GF8612@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> On Tue, Oct 10, 2006 at 02:15:58PM -0400, Shawn Pearce wrote:
>> Martin Waitz <tali@admingilde.org> wrote:
>> > I always find myself typing "git -p diff".
>> > Should we paginate git-diff output by default?
>>
>> I agree. I'm very used to git log automatically running my $PAGER;
>> I'm always surprised that git diff doesn't do the same when attached
>> to my tty.
Hmm. So close to 1.4.3... Will take it.
^ permalink raw reply
* [RFH] RPM gurus? (Re: rpmbuild fails)
From: Junio C Hamano @ 2006-10-11 0:38 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git, Anders Larsen
In-Reply-To: <200610110018.19035.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Tuesday 10 October 2006 22:31, Anders Larsen wrote:
>> The current git fails when building rpms:
>>
>> RPM build errors:
>> Installed (but unpackaged) file(s) found:
>> /usr/lib/perl5/vendor_perl/5.8.6/Git.pm
>
> I got the same.
> I'm no rpm guru, but changing %{perl_vendorarch} into
> %{perl_vendorlib} in git.spec.in helped for me.
>
> Obviously, the generated perl/Makefile installs Git.pm
> into the perl vendor *library* directory, and not the arch
> one.
Thanks.
Also I noticed that we now build-require perl(Error); I have to
ask kernel.org people to install it.
^ permalink raw reply
* [ANNOUNCE] repo.or.cz does full-fledged hosting now, and more
From: Petr Baudis @ 2006-10-11 0:30 UTC (permalink / raw)
To: git
Hi,
few weeks ago, I have announced repo.or.cz public mirroring service
which would snap repositories, mirror them and provide a gitweb
interface for them. While at it, it also aims to serve as a testbed
for various new cool gitweb-related enhancements.
I have finally got around to enhance it some more. Here go the big
changes:
(i) repo.or.cz now permits an alternative hosting model: instead of
mirroring a remote repository, you can push over SSH. This makes
repo.or.cz full-fledged public hosting service. Each developer can
create own account, and you can give push access to multiple developers
if you want to do the CVS-style development. Authentication is done
purely using SSH keys. Furthermore, _optional_ support for anonymous
pushing to a dedicated 'mob' branch is supported.
(ii) Bunch of extra project fields have been added - you can now
customize short description, homepage URL, give a short README to be
shown at the project summary page, ...
(iii) Reorganized and extended the online documentation; gitweb now
uses pathinfo URLs and is aliased to http://repo.or.cz/w/
(iv) Select a project and click at the 'graphiclog' button; if you
have a javascript-capable browser, watch the fireworks. This gadget
(http://repo.or.cz/w/git-browser.git) is nearly year old now and
back then swooshed through the mailing list without much interest
(apart few "cool!" replies). And I positively *HATE* not having it
when I browse any project whose history is not totally linear.
OTOH, I have almost zero javascript skills so I'm not gonna be able
to develop it much further. Will someone pick up the slack? It's pretty
nice but leaves much to be desired; more tight gitweb integration (make
it basically some kind of external gitweb plugin) would be great.
(v) Basically all the infrastructure is available at
http://repo.or.cz/w/repo.git
Please review the code, send patches, feel free to roll out your very
own...
What now? Send me your ideas, or even patches! (Hey, the code is
public. ;-) It might be interesting to have some forking support: there
goes project X and anyone can setup project fork(X, foo) and push his
changes there. I currently think the best way to do it technically would
be to just set up a separate repository with alternate pointing to the
main repository's database, and only group the forks with the main
project in gitweb. Is there a demand for that?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] repack: allow simultaneous packing and pruning
From: Eran Tromer @ 2006-10-10 23:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610101524050.3952@g5.osdl.org>
On 2006-10-11 00:27, Linus Torvalds wrote:
> Those unreferenced objects are old history that won't be part of any new
> history.
>
> If you create new history, they won't be in the pack.
... because git-repack moves only already-referenced objects to packs
(and once they're referenced a subsequent "git-repack -a -d" won't lose
them). Curiously, this critically depends on Documentation/git-repack
being wrong:
This script is used to combine all objects that do not currently
reside in a "pack", into a pack.
However, this means there is no safe way to create a new pack without
adding all its content as loose objects first.
For example, the following is racy because there's a point where the new
pack is on disk but not yet referenced:
$ git-fetch --keep foo & git-repack -a -d
>> But "git prune" does not GC packs, only loose objects.
>
> Right. And you'd want to repack _and_ prune, but they should be kept
> separate, because one is safe, the other is not.
Ah, semantics.
The request was for removing unreferenced objects ("pruning") in *packs*
while doing the repacking. This turns out to be already implemented
(contrary to the docs) and, as you explained, safe.
Pruning both packed and loose objects while repacking is neither safe
nor requested (and is indeed roughly equivalent to just
"git-repack -a -d; git-prune").
Eran
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Jakub Narebski @ 2006-10-10 22:40 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git
In-Reply-To: <20061010221458.85789.qmail@web31804.mail.mud.yahoo.com>
Dnia środa 11. października 2006 00:14, Luben Tuikov napisał:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
> > Luben Tuikov wrote:
> > > P.S. Notice how there is a "snapshot" link on each line of
> > > shortlog, but there is no "snapshot" link in the nav bar
> > > of a=commit. The "snapshot" link is next to "tree" down
> > > in the commit data. There is also a "tree" link which is also
> > > in the navbar, but "shortlog" is missing.
> >
> > The problem with snapshot is that we can have snapshot of a commit
> > (and all links in the top part of navigation bar till now deals with
> > current commit), and snapshot of a tree, which can be subdirectory
> > (and all links in the bottom part of navigation bar deals with
> > the views/presentations of a current object).
>
> Oh, yes, that's exactly what we need: two links of the same name
> ("snapshot") in the top row of navbar and in the bottom row of navbar.
I'm mentioning the problem, that "snapshot" has two meaning for a tree.
I personally think that we should have commit snapshot links (with
commit sha in the extended tar header if we use tgz snapshots) for
"heads", "tags" and "project list" views, and perhaps in the "commit"
and optionally "commitdiff" view; perhaps but not necessary for each
commit-list view like log, shortlog, search, history. But the snapshot
link should be as a view of a (sub)directory only in the bottom part of
navigation bar.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] cvsserver: fix "cvs diff" in a subdirectory
From: Johannes Schindelin @ 2006-10-10 22:33 UTC (permalink / raw)
To: Martyn Smith, Martin Langhoff; +Cc: git
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-cvsserver.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 7260f32..da00432 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -277,7 +277,7 @@ sub req_Directory
$state->{directory} = "" if ( $state->{directory} eq "." );
$state->{directory} .= "/" if ( $state->{directory} =~ /\S/ );
- if ( not defined($state->{prependdir}) and $state->{localdir} eq "." and $state->{path} =~ /\S/ )
+ if ( (not defined($state->{prependdir}) or $state->{prependdir} eq '') and $state->{localdir} eq "." and $state->{path} =~ /\S/ )
{
$log->info("Setting prepend to '$state->{path}'");
$state->{prependdir} = $state->{path};
--
1.4.3.rc2.g55b2-dirty
^ permalink raw reply related
* Re: [PATCH] repack: allow simultaneous packing and pruning
From: Linus Torvalds @ 2006-10-10 22:27 UTC (permalink / raw)
To: Eran Tromer; +Cc: git
In-Reply-To: <452C19FC.7030001@tromer.org>
On Wed, 11 Oct 2006, Eran Tromer wrote:
>
> How so? This process loses the unreferenced objects from the old packs,
> where "referenced" is determined in a racy way. Same problem.
No.
Those unreferenced objects are old history that won't be part of any new
history.
If you create new history, they won't be in the pack.
It's obviously possible that you create new history that has a blob that
is equal to some old history (and no loose object will be created), but by
then we're _really_ reaching.
> But "git prune" does not GC packs, only loose objects.
Right. And you'd want to repack _and_ prune, but they should be kept
separate, because one is safe, the other is not.
Of course, if the code were to check that no references have changed over
the operation, then I wouldn't have any objections.
Linus
^ permalink raw reply
* [PATCH] cvsserver: Show correct letters for modified, removed and added files
From: Johannes Schindelin @ 2006-10-10 22:20 UTC (permalink / raw)
To: Martyn Smith, Martin Langhoff; +Cc: git
Earlier, cvsserver showed always an 'U', sometimes even without a space
between the 'U' and the name. Now, the correct letter is shown, with a
space.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-cvsserver.perl | 63 ++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 2c1b0c7..7260f32 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -807,7 +807,14 @@ sub req_update
$meta = $updater->getmeta($filename);
}
- next unless ( $meta->{revision} );
+ if ( ! defined $meta )
+ {
+ $meta = {
+ name => $filename,
+ revision => 0,
+ filehash => 'added'
+ };
+ }
my $oldmeta = $meta;
@@ -837,7 +844,7 @@ sub req_update
and not exists ( $state->{opt}{C} ) )
{
$log->info("Tell the client the file is modified");
- print "MT text U\n";
+ print "MT text M \n";
print "MT fname $filename\n";
print "MT newline\n";
next;
@@ -857,15 +864,36 @@ sub req_update
}
}
elsif ( not defined ( $state->{entries}{$filename}{modified_hash} )
- or $state->{entries}{$filename}{modified_hash} eq $oldmeta->{filehash} )
+ or $state->{entries}{$filename}{modified_hash} eq $oldmeta->{filehash}
+ or $meta->{filehash} eq 'added' )
{
- $log->info("Updating '$filename'");
- # normal update, just send the new revision (either U=Update, or A=Add, or R=Remove)
- print "MT +updated\n";
- print "MT text U\n";
- print "MT fname $filename\n";
- print "MT newline\n";
- print "MT -updated\n";
+ # normal update, just send the new revision (either U=Update,
+ # or A=Add, or R=Remove)
+ if ( defined($wrev) && $wrev < 0 )
+ {
+ $log->info("Tell the client the file is scheduled for removal");
+ print "MT text R \n";
+ print "MT fname $filename\n";
+ print "MT newline\n";
+ next;
+ }
+ elsif ( !defined($wrev) || $wrev == 0 )
+ {
+ $log->info("Tell the client the file will be added");
+ print "MT text A \n";
+ print "MT fname $filename\n";
+ print "MT newline\n";
+ next;
+
+ }
+ else {
+ $log->info("Updating '$filename' $wrev");
+ print "MT +updated\n";
+ print "MT text U \n";
+ print "MT fname $filename\n";
+ print "MT newline\n";
+ print "MT -updated\n";
+ }
my ( $filepart, $dirpart ) = filenamesplit($filename,1);
@@ -1711,6 +1739,17 @@ sub argsfromdir
return if ( scalar ( @{$state->{args}} ) > 1 );
+ my @gethead = @{$updater->gethead};
+
+ # push added files
+ foreach my $file (keys %{$state->{entries}}) {
+ if ( exists $state->{entries}{$file}{revision} &&
+ $state->{entries}{$file}{revision} == 0 )
+ {
+ push @gethead, { name => $file, filehash => 'added' };
+ }
+ }
+
if ( scalar(@{$state->{args}}) == 1 )
{
my $arg = $state->{args}[0];
@@ -1718,7 +1757,7 @@ sub argsfromdir
$log->info("Only one arg specified, checking for directory expansion on '$arg'");
- foreach my $file ( @{$updater->gethead} )
+ foreach my $file ( @gethead )
{
next if ( $file->{filehash} eq "deleted" and not defined ( $state->{entries}{$file->{name}} ) );
next unless ( $file->{name} =~ /^$arg\// or $file->{name} eq $arg );
@@ -1731,7 +1770,7 @@ sub argsfromdir
$state->{args} = [];
- foreach my $file ( @{$updater->gethead} )
+ foreach my $file ( @gethead )
{
next if ( $file->{filehash} eq "deleted" and not defined ( $state->{entries}{$file->{name}} ) );
next unless ( $file->{name} =~ s/^$state->{prependdir}// );
--
1.4.3.rc2.g35de
^ permalink raw reply related
* Re: rpmbuild fails
From: Josef Weidendorfer @ 2006-10-10 22:18 UTC (permalink / raw)
To: Anders Larsen; +Cc: git, Junio Hamano
In-Reply-To: <pan.2006.10.10.20.31.48.692444@alarsen.net>
On Tuesday 10 October 2006 22:31, Anders Larsen wrote:
> The current git fails when building rpms:
>
> RPM build errors:
> Installed (but unpackaged) file(s) found:
> /usr/lib/perl5/vendor_perl/5.8.6/Git.pm
I got the same.
I'm no rpm guru, but changing %{perl_vendorarch} into
%{perl_vendorlib} in git.spec.in helped for me.
Obviously, the generated perl/Makefile installs Git.pm
into the perl vendor *library* directory, and not the arch
one.
I do not provide a real patch, as I have no idea if
this is really the correct fix (we have no arch-dependent
perl files anymore, yes?).
However, something like the above should go into git-1.4.3.
> Indeed git.spec.in does not specify any files for perl-Git, only
> %files -n perl-Git -f perl-files
> %defattr(-,root,root)
> nothing more.
Hmm... Obviously the "... -f perl-files" includes all files
mentioned in file "perl-files" into perl-Git. The problem was
that without the above change this file was empty.
Josef
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Luben Tuikov @ 2006-10-10 22:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200610102313.48170.jnareb@gmail.com>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Dnia wtorek 10. pa�dziernika 2006 23:02, Luben Tuikov napisa�:
> > > > Isn't that a simple "labelling" question? �I do not think
> > > > anybody minds to show clickable string "contents" (instead of
> > > > "blob" or "tree") at the places you mention above and if we did
> > > > so everybody would be happy, right?
> > >
> > > Not, IMHO it is not a good idea. Clicking on file name leads to it
> > > contents, but it is not obvoius what kind of view is it. "blob" link
> >
> > It is pretty obvious to me: the contents of the object, whether it be
> > "blob" or "tree". �The contents of "blob" and the contents of "tree"
> > as shown by gitweb.
>
> It's pretty obvous to you, because there is only one basic view of tree,
> and one basic view of blob. It is not the case for example for commits
> in shortlog view, where we have commit and commitdiff views. It is
> possible that either blobs or trees acquire another views.
Excuse me, weren't we talking about "blob" and "tree"?
How come you all of a sudden introduce commits? Let's keep on topic:
"blob" and "tree".
Luben
^ permalink raw reply
* Re: [PATCH] repack: allow simultaneous packing and pruning
From: Eran Tromer @ 2006-10-10 22:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610101423561.3952@g5.osdl.org>
On 2006-10-10 23:25, Linus Torvalds wrote:
> On Tue, 10 Oct 2006, Eran Tromer wrote:
>> Too late: "git repack -a -d" already does it, in contradiction to its
>> manpage. It creates a new pack by following .git/refs, and then deletes
>> all old pack files.
>
> That's very different.
>
> That just means that you should not try to do two _concurrent_ repacks.
How so? This process loses the unreferenced objects from the old packs,
where "referenced" is determined in a racy way. Same problem.
>
>> Don't run it on a shared repo, then. And grab a coffee while it runs.
>> But why force leaf repositories to accumulate garbage?
>
> Nobody forces that.
>
> You can run "git prune" if you want to. But at least we know that "git
> prune" is unsafe.
But "git prune" does not GC packs, only loose objects.
Anyway, I think the right thing to do is to make "git repack -a -d"
operate safely (not drop any objects), and add a new --prune option
so that "git repack -a -d --prune" does what "git repack -a -d" used to do.
Eran
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Luben Tuikov @ 2006-10-10 22:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200610102300.16935.jnareb@gmail.com>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Luben Tuikov wrote:
> > P.S. Notice how there is a "snapshot" link on each line of
> > shortlog, but there is no "snapshot" link in the nav bar
> > of a=commit. �The "snapshot" link is next to "tree" down
> > in the commit data. �There is also a "tree" link which is also
> > in the navbar, but "shortlog" is missing.
>
> The problem with snapshot is that we can have snapshot of a commit
> (and all links in the top part of navigation bar till now deals with
> current commit), and snapshot of a tree, which can be subdirectory
> (and all links in the bottom part of navigation bar deals with
> the views/presentations of a current object).
Oh, yes, that's exactly what we need: two links of the same name
("snapshot") in the top row of navbar and in the bottom row of navbar.
Luben
^ permalink raw reply
* Re: Junio's wishes [Was: Re: Approxidate licensing]
From: Linus Torvalds @ 2006-10-10 22:12 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Junio C Hamano, Daniel Barkalow, git
In-Reply-To: <200610102054.k9AKsQ2a004095@laptop13.inf.utfsm.cl>
On Tue, 10 Oct 2006, Horst H. von Brand wrote:
>
> There is a small practical problem with that: How would you find out I'm
> using a modified version of your code internally? Also, the "distribution"
> part of GPLv2 is a useful filter: Only such modifications that are
> worthwhile to distribute get back, not each and every corner I paint myself
> into while playing around.
Hey, I obviously agree that the GPLv2 is a good license, but at the same
time, I think too many people tend to think _just_ about legal issues.
Sometimes the wishes of an author should matter, regardless of whether
there is any law that forces you to do so. So I personally think a license
that says: "if you improve this, give out the improvements regardless of
whether you distribute things further or not" is a nice sentiment, and
should be honored, regardless of whether you can legally enforce any such
private tinkering or not.
Linus
^ permalink raw reply
* Re: Release 1.4.2 build failure
From: Junio C Hamano @ 2006-10-10 22:11 UTC (permalink / raw)
To: Phillip Susi; +Cc: git
In-Reply-To: <452C00FD.1020307@cfl.rr.com>
Are you by any chance running the test with the stdin connected
to </dev/null?
If so, the fix is in 1.4.2.2.
BTW, the latest "maint" release is 1.4.2.3 and we have 1.4.3-rc2
from the "master" branch.
^ permalink raw reply
* Re: [PATCH] repack: allow simultaneous packing and pruning
From: Linus Torvalds @ 2006-10-10 21:25 UTC (permalink / raw)
To: Eran Tromer; +Cc: git
In-Reply-To: <452BF8B3.5090305@tromer.org>
On Tue, 10 Oct 2006, Eran Tromer wrote:
>
> Too late: "git repack -a -d" already does it, in contradiction to its
> manpage. It creates a new pack by following .git/refs, and then deletes
> all old pack files.
That's very different.
That just means that you should not try to do two _concurrent_ repacks.
> Don't run it on a shared repo, then. And grab a coffee while it runs.
> But why force leaf repositories to accumulate garbage?
Nobody forces that.
You can run "git prune" if you want to. But at least we know that "git
prune" is unsafe.
Linus
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Jakub Narebski @ 2006-10-10 21:13 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git
In-Reply-To: <20061010210226.47626.qmail@web31809.mail.mud.yahoo.com>
Dnia wtorek 10. października 2006 23:02, Luben Tuikov napisał:
> > > Isn't that a simple "labelling" question? I do not think
> > > anybody minds to show clickable string "contents" (instead of
> > > "blob" or "tree") at the places you mention above and if we did
> > > so everybody would be happy, right?
> >
> > Not, IMHO it is not a good idea. Clicking on file name leads to it
> > contents, but it is not obvoius what kind of view is it. "blob" link
>
> It is pretty obvious to me: the contents of the object, whether it be
> "blob" or "tree". The contents of "blob" and the contents of "tree"
> as shown by gitweb.
It's pretty obvous to you, because there is only one basic view of tree,
and one basic view of blob. It is not the case for example for commits
in shortlog view, where we have commit and commitdiff views. It is
possible that either blobs or trees acquire another views.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Add --dry-run option to git-send-email
From: Jakub Narebski @ 2006-10-10 21:03 UTC (permalink / raw)
To: git
In-Reply-To: <20061010145823.GB8993@parisc-linux.org>
Matthew Wilcox wrote:
> Add a --dry-run option to git-send-email due to having made too many
> mistakes with it in the past week. I like having a safety catch on my
> machine gun.
+1
I'd like also for git-send-email to check if there are any patches to send,
as I oftend did forgot to provide patches.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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