* Re: ETA for release of gjit 0.4?
From: Robin Rosenberg @ 2008-12-16 4:17 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: Shawn O. Pearce, git, fonseca
In-Reply-To: <4946DFBB.6030300@wellfleetsoftware.com>
Jonas, could you help us on this:
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error deploying artifact: Failed to transfer file: http://egit.googlecode.com/svn/maven/snapshot-repository//org/spearce/jgit/0.4.0/jgit-0.4.0.jar. Return code is: 401
I added this (nah, naming it release-repository didn't work either)
<repository>
<id>jgit-maven-release-repository</id>
<name>JGit Maven Release Repository</name>
<url>https://egit.googlecode.com/svn/maven/snapshot-repository/</url>
<uniqueVersion>true</uniqueVersion>
</repository>
(tried all combinations of dav/not-dav, http/https). Seems I don't have a dav provider,
but https should work, right?
and to ~/.m2/settings.xml
<servers>
<server>
<id>jgit-maven-snapshot-repository</id>
<username>tried both my project email and gmail email</username>
<password>nah, won't show you</password>
</server>
</servers>
-- robin
måndag 15 december 2008 23:52:43 skrev Farrukh Najmi:
>
> Hi Shawn,
>
> I was wondering if there are any updates on my question on whether we
> can have a 0.4 release of jgit (no SNAPSHOT).
> I am ready to release my software but maven wont let me release it
> because its dependency jgit is a SNAPSHOT release.
>
> As I recall you had planned to release 0.4 and make it available on the
> maven repo at:
>
> <http://egit.googlecode.com/svn/maven/snapshot-repository/org/spearce/jgit>
>
> I do not see it there yet. Any chance of getting that today? Thanks.
>
^ permalink raw reply
* Re: ETA for release of gjit 0.4?
From: Robin Rosenberg @ 2008-12-16 4:23 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: Shawn O. Pearce, git, fonseca
In-Reply-To: <200812160517.33975.robin.rosenberg.lists@dewire.com>
tisdag 16 december 2008 05:17:33 skrev Robin Rosenberg:
> and to ~/.m2/settings.xml
>
> <servers>
> <server>
> <id>jgit-maven-snapshot-repository</id>
tried <id>jgit-maven-release-repository</id> too ;/
-- robin
^ permalink raw reply
* Re: [PATCH] pack-objects: don't use too many threads with few objects
From: Nicolas Pitre @ 2008-12-16 5:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Ralphson, Jeff King, git
In-Reply-To: <7vy6ygudhb.fsf@gitster.siamese.dyndns.org>
On Mon, 15 Dec 2008, Junio C Hamano wrote:
> "Mike Ralphson" <mike.ralphson@gmail.com> writes:
>
> > 2008/12/13 Nicolas Pitre <nico@cam.org>
> >>
> >> If there are few objects to deltify, they might be split amongst threads
> >> so that there is simply no other objects left to delta against within
> >> the same thread. Let's use the same 2*window treshold as used for the
> >> final load balancing to allow extra threads to be created.
> >>
> >> This fixes the benign t5300 test failure.
> >
> > Even with this I'm seeing failures in t5302 which I think are probably
> > related to 43cc2b42
> > ...
> > * ok 2: pack-objects with index version 1
> >
> > * expecting success: pack2=$(git pack-objects --index-version=2 test-2
> > <obj-list) &&
> > git verify-pack -v "test-2-${pack2}.pack"
> > 0106e17481932f5c223fafadc1d26abc6adf40d6 blob 57 90 850531 1
> > 69e0b8ef8cda369575b6801c6ed47daf09aa3c62
> > ...
> > fff3a3a92d2268a464dbdcd00fc055885ee3cba9 blob 8196 8210 187404
> > chain length = 1: 109 objects
> > chain length = 2: 10 objects
> > chain length = 3: 10 objects
> > chain length = 4: 10 objects
> > chain length = 5: 10 objects
> > chain length = 6: 10 objects
> > chain length = 7: 10 objects
> > chain length = 8: 10 objects
> > chain length = 9: 9 objects
> > test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack: ok
> > * ok 3: pack-objects with index version 2
> >
> > * expecting success: cmp "test-1-${pack1}.pack" "test-2-${pack2}.pack"
> > test-1-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
> > test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack differ: char
> > 10236, line 32
> > * FAIL 4: both packs should be identical
> > cmp "test-1-${pack1}.pack" "test-2-${pack2}.pack"
>
> This is interesting. The same set of objects are packed with the
> identical list of objects stored in obj-list and the only difference
> between test #2 and test #3 are the format of the .idx file they produce.
> Yet they are producing different .pack file?
Indeed, this is really strange.
> Even though depending on the timings of how worker threads complete
> assigned work and grab more work for them, two otherwise identical runs,
> even with the same set of parameters, could assign different set of
> objects to different threads. But as far as I can see, the same set of
> objects should go to the same chunk, and the only difference should be
> which thread gets which chunk, and I do not see how that could affect the
> outcome. Puzzled...
You probably have the explanation here: worker threads are not
necessarily completing their own chunks alwais at the same time relative
with each other. Hence, a thread stealing more work from another thread
might or might not interrupt that other thread always at the same point
between runs, and therefore the final delta chain might get shifted a
bit.
I think the best "fix" is actually to configure only one thread for this
test. The point here is to make sure different index versions don't
introduce variations in pack generation, but multiple threads do defeat
that because of the inner randomness in thread scheduling.
I'm therefore giving my ACK to Johannes' patch posted earlier.
Nicolas
^ permalink raw reply
* Re: [PATCH] gitweb: make feature_blame return a list
From: Junio C Hamano @ 2008-12-16 5:38 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <20081216024605.GA4529@ftbfs.org>
Matt Kraai <kraai@ftbfs.org> writes:
> If you'd like me to resubmit my second patch, I'm happy to do so.
> Just let me know whether you prefer the resulting function to wrap its
> return values in parentheses (as is currently done by feature_grep and
> feature_pickaxe) or not.
Sure, keeping what feature_grep does is just fine.
Thanks.
^ permalink raw reply
* Re: git-clone --how-much-disk-space-will-this-cost-me? [--depth n]
From: Nicolas Pitre @ 2008-12-16 5:45 UTC (permalink / raw)
To: Jean-Luc Herren; +Cc: jidanni, git
In-Reply-To: <49470D65.40808@gmx.ch>
On Tue, 16 Dec 2008, Jean-Luc Herren wrote:
> jidanni@jidanni.org wrote:
> > JH> So maybe what you really want is an ETA display during the cloning
> > JH> process? Sounds like a good idea to me.
> >
> > ETA implies that git has an estimate of what is going to happen.
>
> Aren't you implying this too from the beginning? But reading
> Jeff's reply, there seems to be a reason why there isn't an ETA
> already.
>
> However, since some repositories get cloned in the same way very
> often, there could be some cache that keeps these size information
> around for any subsequent identical clones. The server could then
> send a hint about the expected amount of data at the beginning.
And then you'll end up being the unlucky bastard to be the first to
clones the new latest revision of a repository, and ETA won't be
available, and you'll complain about the fact that sometimes it is there
and sometimes it is not.
The fact is, fundamentally, we don't know how many bytes to push when
generating a pack to answer the clone request. Sometimes we _could_ but
not always. It is therefore better to be consistent and let people know
that there is simply no ETA.
Nicolas
^ permalink raw reply
* [PATCH] gitweb: unify boolean feature subroutines
From: Matt Kraai @ 2008-12-16 6:16 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Matt Kraai
In-Reply-To: <7vabawu1ao.fsf@gitster.siamese.dyndns.org>
The boolean feature subroutines behaved identically except for the
name of the configuration option, so make that a parameter and unify
them.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
gitweb/gitweb.perl | 41 +++++++++--------------------------------
1 files changed, 9 insertions(+), 32 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6eb370d..827e5c5 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -203,7 +203,7 @@ our %feature = (
# $feature{'blame'}{'override'} = 1;
# and in project config gitweb.blame = 0|1;
'blame' => {
- 'sub' => \&feature_blame,
+ 'sub' => sub { feature_bool('blame', @_) },
'override' => 0,
'default' => [0]},
@@ -241,7 +241,7 @@ our %feature = (
# $feature{'grep'}{'override'} = 1;
# and in project config gitweb.grep = 0|1;
'grep' => {
- 'sub' => \&feature_grep,
+ 'sub' => sub { feature_bool('grep', @_) },
'override' => 0,
'default' => [1]},
@@ -255,7 +255,7 @@ our %feature = (
# $feature{'pickaxe'}{'override'} = 1;
# and in project config gitweb.pickaxe = 0|1;
'pickaxe' => {
- 'sub' => \&feature_pickaxe,
+ 'sub' => sub { feature_bool('pickaxe', @_) },
'override' => 0,
'default' => [1]},
@@ -363,16 +363,17 @@ sub gitweb_check_feature {
}
-sub feature_blame {
- my ($val) = git_get_project_config('blame', '--bool');
+sub feature_bool {
+ my $key = shift;
+ my ($val) = git_get_project_config($key, '--bool');
if ($val eq 'true') {
- return 1;
+ return (1);
} elsif ($val eq 'false') {
- return 0;
+ return (0);
}
- return $_[0];
+ return ($_[0]);
}
sub feature_snapshot {
@@ -387,30 +388,6 @@ sub feature_snapshot {
return @fmts;
}
-sub feature_grep {
- my ($val) = git_get_project_config('grep', '--bool');
-
- if ($val eq 'true') {
- return (1);
- } elsif ($val eq 'false') {
- return (0);
- }
-
- return ($_[0]);
-}
-
-sub feature_pickaxe {
- my ($val) = git_get_project_config('pickaxe', '--bool');
-
- if ($val eq 'true') {
- return (1);
- } elsif ($val eq 'false') {
- return (0);
- }
-
- return ($_[0]);
-}
-
# checking HEAD file with -e is fragile if the repository was
# initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
# and then pruned.
--
1.5.6.5
^ permalink raw reply related
* Re: [usability bug] git branch -a does not disambiguate remote and local branches
From: Björn Steinbrink @ 2008-12-16 6:26 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50812151015t4d5bc2b8p4ea53a0e4ad25e64@mail.gmail.com>
On 2008.12.15 21:15:15 +0300, Constantine Plotnikov wrote:
> After this scenario is executed, git branch -a will give the following output:
> master
> * origin/master
> origin/master
>
> Note that there is two origin/master entries, but it is not clear
> which is remote is and which is the local. I think that "git branch
> -a" should print unambiguous names, qualifying them if needed.
Actually, it is clear. The one with the * is the local one. The remote
tracking branch will never be marked as checked out, as you would get a
detached HEAD when you do "git checkout remotes/origin/master".
When there are duplicate entries, you can be sure that you have a local
branch head and a remote tracking branch with the same shortname. And
when one of them has been marked as checked out, you can be sure that it
is the local one.
Björn
^ permalink raw reply
* Re: git-diff should not fire up $PAGER if there is no diff
From: Stefan Karpinski @ 2008-12-16 6:35 UTC (permalink / raw)
To: Jeff King; +Cc: jidanni, git
In-Reply-To: <20081216005658.GB3679@coredump.intra.peff.net>
> On Mon, Dec 15, 2008 at 7:56 PM, Jeff King <peff@peff.net> wrote:
> 2. detect EOF before starting the pager. We in fact already delay
> running the pager in the forked process until we have some activity
> on the pipe, but I don't know if there is a portable way of
> detecting that that activity is EOF without performing an actual
> read() call (which is undesirable, since it eats the first byte of
> output that should go to the pager).
Wouldn't ungetc work? Or is that not portable enough? (It would only
work here because the EOF has to be the first character.)
^ permalink raw reply
* Can I use git protocol to push change to remote repo?
From: Emily Ren @ 2008-12-16 7:22 UTC (permalink / raw)
To: git
In-Reply-To: <856bfe0e0812152318h1375401fx944834ad6410835d@mail.gmail.com>
Hello,
I can clone a remote repo with git protocol, but I can't push my
branch to origin repo with git protocol. If I use ssh protocol, I can
push sccuessfully. I'm confused, can someone give me a guide on this?
Can I use git protocol to push my branch to remote repo? If yes, how
can I do ? Thank you for your help in advance !
Error info is as below:
$ git push git://host.xz/testgit check_push
fatal: The remote end hung up unexpectedly
error: failed to push to 'git://host.xz/testgit'
Successful info with ssh protocol:
$ git push ssh://host.xz/testgit check_push
user's password:
updating 'refs/heads/check_push'
from 0000000000000000000000000000000000000000
to 60719ede9ef5d5fdc042e7aebcebc04a93d3928a
Generating pack...
Done counting 3 objects.
Deltifying 3 objects...
100% (3/3) done
Writing 3 objects...
100% (3/3) done
Total 3 (delta 0), reused 0 (delta 0)
Thanks,
Emily
^ permalink raw reply
* [PATCH] gitweb: pass the option name to the feature callback
From: Matt Kraai @ 2008-12-16 7:36 UTC (permalink / raw)
To: gitster, git; +Cc: Matt Kraai
In-Reply-To: <1229408179-7655-1-git-send-email-kraai@ftbfs.org>
The feature_bool callback required the option name to be passed to
it. Make gitweb_get_feature do so instead of constructing an
anonymous subroutine for each overrideable boolean option.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
gitweb/gitweb.perl | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
Sorry for the churn; I read the corresponding part of Higher-Order
Perl *after* sending my previous patches. :(
If I should squash this into my previous patch and resubmit it,
please let me know.
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 827e5c5..3459293 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -203,7 +203,7 @@ our %feature = (
# $feature{'blame'}{'override'} = 1;
# and in project config gitweb.blame = 0|1;
'blame' => {
- 'sub' => sub { feature_bool('blame', @_) },
+ 'sub' => \&feature_bool,
'override' => 0,
'default' => [0]},
@@ -241,7 +241,7 @@ our %feature = (
# $feature{'grep'}{'override'} = 1;
# and in project config gitweb.grep = 0|1;
'grep' => {
- 'sub' => sub { feature_bool('grep', @_) },
+ 'sub' => \&feature_bool,
'override' => 0,
'default' => [1]},
@@ -255,7 +255,7 @@ our %feature = (
# $feature{'pickaxe'}{'override'} = 1;
# and in project config gitweb.pickaxe = 0|1;
'pickaxe' => {
- 'sub' => sub { feature_bool('pickaxe', @_) },
+ 'sub' => \&feature_bool,
'override' => 0,
'default' => [1]},
@@ -344,7 +344,7 @@ sub gitweb_get_feature {
warn "feature $name is not overrideable";
return @defaults;
}
- return $sub->(@defaults);
+ return $sub->($name, @defaults);
}
# A wrapper to check if a given feature is enabled.
@@ -377,9 +377,9 @@ sub feature_bool {
}
sub feature_snapshot {
- my (@fmts) = @_;
+ my ($key, @fmts) = @_;
- my ($val) = git_get_project_config('snapshot');
+ my ($val) = git_get_project_config($key);
if ($val) {
@fmts = ($val eq 'none' ? () : split /\s*[,\s]\s*/, $val);
--
1.5.6.5
^ permalink raw reply related
* Re: Can I use git protocol to push change to remote repo?
From: Jeff King @ 2008-12-16 7:38 UTC (permalink / raw)
To: Emily Ren; +Cc: git
In-Reply-To: <856bfe0e0812152322i3a7fa376h8a35466b7abf82a5@mail.gmail.com>
On Tue, Dec 16, 2008 at 03:22:17PM +0800, Emily Ren wrote:
> I can clone a remote repo with git protocol, but I can't push my
> branch to origin repo with git protocol. If I use ssh protocol, I can
> push sccuessfully. I'm confused, can someone give me a guide on this?
> Can I use git protocol to push my branch to remote repo? If yes, how
> can I do ? Thank you for your help in advance !
Yes, git-daemon does not support pushing by default, since it doesn't do
any authentication of the pushing users. The recommended practice is to
push over ssh, which uses the exact same protocol, but is tunneled over
ssh, so the user is authenticated and the incoming data has an integrity
check (note that pulling by ssh is also the same protocol as pulling via
git://, except of course that it is also tunneled over ssh; this means
that if you are pushing and pulling, you can just set your remote to
talk to the ssh version).
If you _really_ want totally anonymous, unsecured pushing to your repo
(e.g., because you are on a restricted LAN and everybody is trusted),
you can enable the receive-pack service. See the git-daemon
documentation for details.
-Peff
^ permalink raw reply
* Re: git-diff should not fire up $PAGER if there is no diff
From: Jeff King @ 2008-12-16 7:44 UTC (permalink / raw)
To: Stefan Karpinski; +Cc: jidanni, git
In-Reply-To: <d4bc1a2a0812152235l14ec80bbr130a7ab152ad6b8@mail.gmail.com>
On Tue, Dec 16, 2008 at 01:35:53AM -0500, Stefan Karpinski wrote:
> > On Mon, Dec 15, 2008 at 7:56 PM, Jeff King <peff@peff.net> wrote:
> > 2. detect EOF before starting the pager. We in fact already delay
> > running the pager in the forked process until we have some activity
> > on the pipe, but I don't know if there is a portable way of
> > detecting that that activity is EOF without performing an actual
> > read() call (which is undesirable, since it eats the first byte of
> > output that should go to the pager).
>
> Wouldn't ungetc work? Or is that not portable enough? (It would only
> work here because the EOF has to be the first character.)
No, it won't work. ungetc works on the buffered stdio object, so it is
useful for pushing back characters onto the buffer to be read later in
the program from the same buffer. But in this case, we are going to
execv() (or on Windows, spawn) the pager, meaning it will throw away
anything that has been read() from the pipe and put in the buffer.
So we would need a system call to push a character back to the OS, so
that it was available for read() by the pager process.
-Peff
^ permalink raw reply
* Git Notes idea.
From: Govind Salinas @ 2008-12-16 8:15 UTC (permalink / raw)
To: Git Mailing List
Hi All,
I was thinking about possible ideas for my little pet project and I
had and idea for way to tack on notes to a commit, or any object
really. I know that the idea has been flying around for a long time
but there has never been any implementation or a concept that people
liked enough to use (unless I have missed something).
Here is my idea.
.git/refs/notes contains a tree-id (assuming that using a tree-id
will not cause any problems, otherwise a commit object can be used.
it does not *need* a history, but it *could* have one).
That tree has a structure similar to the layout of .git/objects, where
it is 2 letter subdirectories for the notes objects.
Given a git object (commit, tree, blob, tag), use its sha as the
path/filename in this tree.
If I have a commit 1234567890123456789012345678901234567890 then
the notes tree will have a file
12/34567890123456789012345678901234567890
That file has a list of sha1s (one per line). These shas are object
IDs for blobs that have the notes or whatever that you want attached
to the item.
I think you get the idea. When looking up an item, it should be
fairly easy to have the notes tree and subtrees available for doing
lookups. And as far as I know stuff under .git/refs can be
pushed/pulled even if its not under heads or remotes or tags using
already existing machinery. I am not sure, but I think that would
satisfy gc operations as well. Also, these trees and blobs never have
to be put in the working directory.
Does this sound like something that is workable? I thought it might
appeal since it uses only features that are already present.
This could be extended so that you have different sets of notes under
.git/refs/notes/<my note set> or whatever. So that you can have some
notes you keep private and some that you publish or whatever.
OK, hopefully this isn't a off the wall,
thats-what-you-get-for-being-up-at-2-AM idea.
Thanks,
Govind.
^ permalink raw reply
* Re: Can I use git protocol to push change to remote repo?
From: Emily Ren @ 2008-12-16 8:48 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081216073835.GA2468@coredump.intra.peff.net>
Peff,
Thank you for your help ! I read the git-daemon description, and
added following lines in the config file of remote repository.
[daemon]
receivepack = true
It failed with another error, is there anything I missed to config daemon ?
$ git push git://host.xz/testgit test_push2
updating 'refs/heads/test_push2'
from 0000000000000000000000000000000000000000
to eebb60caae38a38361d002cdace043124a2fc871
Generating pack...
Done counting 3 objects.
Deltifying 3 objects...
100% (3/3) done
Writing 3 objects...
100% (3/3) done
Total 3 (delta 0), reused 0 (delta 0)
unpack unpacker exited with error code
ng refs/heads/test_push2 n/a (unpacker error)
error: failed to push to 'git://host.xz/testgit'
Thanks,
Emily
On Tue, Dec 16, 2008 at 3:38 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Dec 16, 2008 at 03:22:17PM +0800, Emily Ren wrote:
>
>> I can clone a remote repo with git protocol, but I can't push my
>> branch to origin repo with git protocol. If I use ssh protocol, I can
>> push sccuessfully. I'm confused, can someone give me a guide on this?
>> Can I use git protocol to push my branch to remote repo? If yes, how
>> can I do ? Thank you for your help in advance !
>
> Yes, git-daemon does not support pushing by default, since it doesn't do
> any authentication of the pushing users. The recommended practice is to
> push over ssh, which uses the exact same protocol, but is tunneled over
> ssh, so the user is authenticated and the incoming data has an integrity
> check (note that pulling by ssh is also the same protocol as pulling via
> git://, except of course that it is also tunneled over ssh; this means
> that if you are pushing and pulling, you can just set your remote to
> talk to the ssh version).
>
> If you _really_ want totally anonymous, unsecured pushing to your repo
> (e.g., because you are on a restricted LAN and everybody is trusted),
> you can enable the receive-pack service. See the git-daemon
> documentation for details.
>
> -Peff
>
^ permalink raw reply
* Re: Git Notes idea.
From: Jeff King @ 2008-12-16 8:51 UTC (permalink / raw)
To: Govind Salinas; +Cc: Git Mailing List
In-Reply-To: <5d46db230812160015t55b4ff2fubbf1e2f826a97b98@mail.gmail.com>
On Tue, Dec 16, 2008 at 02:15:47AM -0600, Govind Salinas wrote:
> I was thinking about possible ideas for my little pet project and I
> had and idea for way to tack on notes to a commit, or any object
> really. I know that the idea has been flying around for a long time
> but there has never been any implementation or a concept that people
> liked enough to use (unless I have missed something).
I think you look at the previous suggestions, because yours is very
similar. Which is good, I think, because the current status is that the
design is good, but nobody has gotten around to working on it yet. So
maybe you can fix that. :)
> .git/refs/notes contains a tree-id (assuming that using a tree-id
> will not cause any problems, otherwise a commit object can be used.
> it does not *need* a history, but it *could* have one).
That is the same as the current proposal, except:
- the proposal is to use a commit, so your notes are version-controlled
- I have suggested supporting multiple note "bases" in the refs/notes
namespace. This would allow you to share some notes but not others
(e.g., if you had some automated notes related to a build/test
system, you might not want to mix those with your human-written
notes).
> That tree has a structure similar to the layout of .git/objects, where
> it is 2 letter subdirectories for the notes objects.
I don't think this has been suggested yet, but I'm not sure it is a good
idea. The usual reason for this split is that many filesystems handle
large directories badly; that isn't a problem here.
It does reduce the size of the resulting tree objects when a note is
modified (we make updates to two smaller trees instead of one big tree).
I don't know if this really matters all that much, since the trees
will end up deltified in a pack anyway.
And it does make the implementation slightly less simple, since we have
to deal with two levels of trees.
> Given a git object (commit, tree, blob, tag), use its sha as the
> path/filename in this tree.
> If I have a commit 1234567890123456789012345678901234567890 then
> the notes tree will have a file
> 12/34567890123456789012345678901234567890
>
> That file has a list of sha1s (one per line). These shas are object
> IDs for blobs that have the notes or whatever that you want attached
> to the item.
This is slightly different than the current proposal. You are proposing
that each item have a "list of notes". My thinking was to have "named
notes" using a tree for each entry full of blobs. So you could look up
the "foo" note for a given commit, but that note would be a single
scalar (which could, of course, be interpreted according to its name).
> I think you get the idea. When looking up an item, it should be
> fairly easy to have the notes tree and subtrees available for doing
> lookups. And as far as I know stuff under .git/refs can be
It is easy, but it's slow because we have to do a linear search in the
(potentially huge) notes tree. And that's what held up the initial
implementation. I did a proof-of-concept a month or so ago that
pre-seeded an in-memory hash using the tree contents and got pretty
reasonable performance.
> pushed/pulled even if its not under heads or remotes or tags using
> already existing machinery. I am not sure, but I think that would
> satisfy gc operations as well. Also, these trees and blobs never have
> to be put in the working directory.
Right, though I think one of the benefits of this approach is that you
_could_ do a checkout on the notes tree if you wanted to do very
flexible editing.
> Does this sound like something that is workable? I thought it might
> appeal since it uses only features that are already present.
Yes, it sounds workable, though if you diverge from what has already
been discussed, I think you should make an argument about why your
approach is better.
> This could be extended so that you have different sets of notes under
> .git/refs/notes/<my note set> or whatever. So that you can have some
> notes you keep private and some that you publish or whatever.
Oops, I should have read your whole mail. Yes, that is a good idea. :)
For reference, here are the previous discussions that I think are
relevant:
Johan Herland's original notes proposal (which I think is largely
dead, replaced by the one below):
http://thread.gmane.org/gmane.comp.version-control.git/46770
Johannes Schindelin's notes proposal (which is more or less the
current proposal, but I think the on-disk notes index was not
well liked):
http://thread.gmane.org/gmane.comp.version-control.git/52598
My test with using a hash to speed it up:
http://article.gmane.org/gmane.comp.version-control.git/99415
Some discussion of the interaction of notes and rebase:
http://thread.gmane.org/gmane.comp.version-control.git/100533
Some thoughts from me on naming issues:
http://article.gmane.org/gmane.comp.version-control.git/100402
Some thoughts from me on the tree speedup:
http://article.gmane.org/gmane.comp.version-control.git/101460
which I think should bring you up to speed. :)
-Peff
^ permalink raw reply
* Re: Can I use git protocol to push change to remote repo?
From: Jeff King @ 2008-12-16 8:52 UTC (permalink / raw)
To: Emily Ren; +Cc: git
In-Reply-To: <856bfe0e0812160048l7d901658tca96f5055c69743c@mail.gmail.com>
On Tue, Dec 16, 2008 at 04:48:34PM +0800, Emily Ren wrote:
> It failed with another error, is there anything I missed to config daemon ?
> $ git push git://host.xz/testgit test_push2
> updating 'refs/heads/test_push2'
> from 0000000000000000000000000000000000000000
> to eebb60caae38a38361d002cdace043124a2fc871
> Generating pack...
> Done counting 3 objects.
> Deltifying 3 objects...
> 100% (3/3) done
> Writing 3 objects...
> 100% (3/3) done
> Total 3 (delta 0), reused 0 (delta 0)
> unpack unpacker exited with error code
> ng refs/heads/test_push2 n/a (unpacker error)
> error: failed to push to 'git://host.xz/testgit'
Does the user running git-daemon have permissions to write to the repo?
-Peff
^ permalink raw reply
* Re: Git Notes idea.
From: Jeff King @ 2008-12-16 8:53 UTC (permalink / raw)
To: Govind Salinas; +Cc: Git Mailing List
In-Reply-To: <20081216085108.GA3031@coredump.intra.peff.net>
On Tue, Dec 16, 2008 at 03:51:08AM -0500, Jeff King wrote:
> I think you look at the previous suggestions, because yours is very
Sorry, there is a typo there. I meant "I think you _should_ look at the
previous suggestions." Not saying in broken English that you already
have looked at them.
-Peff
^ permalink raw reply
* Re: Can I use git protocol to push change to remote repo?
From: Emily Ren @ 2008-12-16 8:59 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081216085205.GB3031@coredump.intra.peff.net>
Peff,
Yes, you are right ! I changed the permission of the repo, and it's OK now. :)
Thank you very much for your kindly help !
Emily
On Tue, Dec 16, 2008 at 4:52 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Dec 16, 2008 at 04:48:34PM +0800, Emily Ren wrote:
>
>> It failed with another error, is there anything I missed to config daemon ?
>> $ git push git://host.xz/testgit test_push2
>> updating 'refs/heads/test_push2'
>> from 0000000000000000000000000000000000000000
>> to eebb60caae38a38361d002cdace043124a2fc871
>> Generating pack...
>> Done counting 3 objects.
>> Deltifying 3 objects...
>> 100% (3/3) done
>> Writing 3 objects...
>> 100% (3/3) done
>> Total 3 (delta 0), reused 0 (delta 0)
>> unpack unpacker exited with error code
>> ng refs/heads/test_push2 n/a (unpacker error)
>> error: failed to push to 'git://host.xz/testgit'
>
> Does the user running git-daemon have permissions to write to the repo?
>
> -Peff
>
^ permalink raw reply
* Re: [PATCH] gitweb: unify boolean feature subroutines
From: Junio C Hamano @ 2008-12-16 9:03 UTC (permalink / raw)
To: Matt Kraai; +Cc: git, Jakub Narebski
In-Reply-To: <1229408179-7655-1-git-send-email-kraai@ftbfs.org>
I'll queue this in 'pu' for now; it has obvious and trivial conflicts with
other gitweb series that introduce new features ;-)
And regarding your follow-up patch you called "churn", I think it is
probably a good idea in the longer term, although I haven't really
looked at all the callers to make sure everybody would be happy.
But a change to the function signature of feature subroutines is not
something I'd like to apply while other series that want to add new
features are still cooking. How about doing these two patches as the
first thing that goes to 'next' after 1.6.1, and then force other series
rebase on top of your change? Alternatively, we could make you wait until
other series do settle in 'next' and then apply your change rebased on
them, but I think that is probably less optimal.
Thanks.
^ permalink raw reply
* [PATCHv5 1/3] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-12-16 10:11 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1229422290-6213-1-git-send-email-giuseppe.bilotta@gmail.com>
The output of commitdiff_plain is not intended for git-am:
* when given a range of commits, commitdiff_plain publishes a single
patch with the message from the first commit, instead of a patchset
* the hand-built email format replicates the commit summary both as
email subject and as first line of the email itself, resulting in
a duplication if the output is used with git-am.
We thus create a new view that can be fed to git-am directly, allowing
patch exchange via gitweb. The new view exposes the output of git
format-patch directly, limiting it to a single patch in the case of a
single commit.
A configurable upper limit defaulting to 16 is imposed on the number of
commits which will be included in a patchset, to prevent DoS attacks on
the server. Setting the limit to 0 will disable the patch view, setting
it to a negative number will remove the limit.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6eb370d..1006dfe 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -330,6 +330,21 @@ our %feature = (
'ctags' => {
'override' => 0,
'default' => [0]},
+
+ # The maximum number of patches in a patchset generated in patch
+ # view. Set this to 0 or undef to disable patch view, or to a
+ # negative number to remove any limit.
+
+ # To disable system wide have in $GITWEB_CONFIG
+ # $feature{'patches'}{'default'} = [0];
+ # To have project specific config enable override in $GITWEB_CONFIG
+ # $feature{'patches'}{'override'} = 1;
+ # and in project config gitweb.patches = 0|n;
+ # where n is the maximum number of patches allowed in a patchset.
+ 'patches' => {
+ 'sub' => \&feature_patches,
+ 'override' => 0,
+ 'default' => [16]},
);
sub gitweb_get_feature {
@@ -411,6 +426,16 @@ sub feature_pickaxe {
return ($_[0]);
}
+sub feature_patches {
+ my @val = (git_get_project_config('patches', '--int'));
+
+ if (@val) {
+ return @val;
+ }
+
+ return ($_[0]);
+}
+
# checking HEAD file with -e is fragile if the repository was
# initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
# and then pruned.
@@ -504,6 +529,7 @@ our %actions = (
"heads" => \&git_heads,
"history" => \&git_history,
"log" => \&git_log,
+ "patch" => \&git_patch,
"rss" => \&git_rss,
"atom" => \&git_atom,
"search" => \&git_search,
@@ -5387,6 +5413,13 @@ sub git_blobdiff_plain {
sub git_commitdiff {
my $format = shift || 'html';
+
+ my $patch_max;
+ if ($format eq 'patch') {
+ ($patch_max) = gitweb_get_feature('patches');
+ die_error(403, "Patch view not allowed") unless $patch_max;
+ }
+
$hash ||= $hash_base || "HEAD";
my %co = parse_commit($hash)
or die_error(404, "Unknown commit object");
@@ -5484,7 +5517,23 @@ sub git_commitdiff {
open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
'-p', $hash_parent_param, $hash, "--"
or die_error(500, "Open git-diff-tree failed");
-
+ } elsif ($format eq 'patch') {
+ # For commit ranges, we limit the output to the number of
+ # patches specified in the 'patches' feature.
+ # For single commits, we limit the output to a single patch,
+ # diverging from the git-format-patch default.
+ my @commit_spec = ();
+ if ($hash_parent) {
+ if ($patch_max > 0) {
+ push @commit_spec, "-$patch_max";
+ }
+ push @commit_spec, '-n', "$hash_parent..$hash";
+ } else {
+ push @commit_spec, '-1', '--root', $hash;
+ }
+ open $fd, "-|", git_cmd(), "format-patch", '--encoding=utf8',
+ '--stdout', @commit_spec
+ or die_error(500, "Open git-format-patch failed");
} else {
die_error(400, "Unknown commitdiff format");
}
@@ -5533,6 +5582,14 @@ sub git_commitdiff {
print to_utf8($line) . "\n";
}
print "---\n\n";
+ } elsif ($format eq 'patch') {
+ my $filename = basename($project) . "-$hash.patch";
+
+ print $cgi->header(
+ -type => 'text/plain',
+ -charset => 'utf-8',
+ -expires => $expires,
+ -content_disposition => 'inline; filename="' . "$filename" . '"');
}
# write patch
@@ -5554,6 +5611,11 @@ sub git_commitdiff {
print <$fd>;
close $fd
or print "Reading git-diff-tree failed\n";
+ } elsif ($format eq 'patch') {
+ local $/ = undef;
+ print <$fd>;
+ close $fd
+ or print "Reading git-format-patch failed\n";
}
}
@@ -5561,6 +5623,11 @@ sub git_commitdiff_plain {
git_commitdiff('plain');
}
+# format-patch-style patches
+sub git_patch {
+ git_commitdiff('patch');
+}
+
sub git_history {
if (!defined $hash_base) {
$hash_base = git_get_head_hash($project);
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 0/3] gitweb: patch view
From: Giuseppe Bilotta @ 2008-12-16 10:11 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
Fifth iteration of the patch view in gitweb, that exposes the
git-format-patch output directly, allowing patchset exchange via gitweb.
No new functionality, just cleanups suggested by Jakub.
Giuseppe Bilotta (3):
gitweb: add patch view
gitweb: add patches view
gitweb: link to patch(es) view in commit(diff) and (short)log view
gitweb/gitweb.perl | 109 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 108 insertions(+), 1 deletions(-)
^ permalink raw reply
* [PATCHv5 2/3] gitweb: add patches view
From: Giuseppe Bilotta @ 2008-12-16 10:11 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1229422290-6213-2-git-send-email-giuseppe.bilotta@gmail.com>
The only difference between patch and patches view is in the treatement
of single commits: the former only displays a single patch, whereas the
latter displays a patchset leading to the specified commit.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1006dfe..e7a6477 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -530,6 +530,7 @@ our %actions = (
"history" => \&git_history,
"log" => \&git_log,
"patch" => \&git_patch,
+ "patches" => \&git_patches,
"rss" => \&git_rss,
"atom" => \&git_atom,
"search" => \&git_search,
@@ -5413,6 +5414,7 @@ sub git_blobdiff_plain {
sub git_commitdiff {
my $format = shift || 'html';
+ my %params = @_;
my $patch_max;
if ($format eq 'patch') {
@@ -5529,7 +5531,15 @@ sub git_commitdiff {
}
push @commit_spec, '-n', "$hash_parent..$hash";
} else {
- push @commit_spec, '-1', '--root', $hash;
+ if ($params{-single}) {
+ push @commit_spec, '-1';
+ } else {
+ if ($patch_max > 0) {
+ push @commit_spec, "-$patch_max";
+ }
+ push @commit_spec, "-n";
+ }
+ push @commit_spec, '--root', $hash;
}
open $fd, "-|", git_cmd(), "format-patch", '--encoding=utf8',
'--stdout', @commit_spec
@@ -5625,6 +5635,10 @@ sub git_commitdiff_plain {
# format-patch-style patches
sub git_patch {
+ git_commitdiff('patch', -single=> 1);
+}
+
+sub git_patches {
git_commitdiff('patch');
}
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 3/3] gitweb: link to patch(es) view in commit(diff) and (short)log view
From: Giuseppe Bilotta @ 2008-12-16 10:11 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1229422290-6213-3-git-send-email-giuseppe.bilotta@gmail.com>
We link to patch view in commit and commitdiff view, and to patches view
in log and shortlog view.
In (short)log view, the link is only offered when the number of commits
shown is no more than the allowed maximum number of patches.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 30 ++++++++++++++++++++++++++++--
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e7a6477..168deb7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5024,6 +5024,15 @@ sub git_log {
my $paging_nav = format_paging_nav('log', $hash, $head, $page, $#commitlist >= 100);
+ my ($patch_max) = gitweb_get_feature('patches');
+ if ($patch_max) {
+ if ($patch_max < 0 || @commitlist <= $patch_max) {
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"patches", -replay=>1)},
+ "patches");
+ }
+ }
+
git_header_html();
git_print_page_nav('log','', $hash,undef,undef, $paging_nav);
@@ -5103,6 +5112,11 @@ sub git_commit {
} @$parents ) .
')';
}
+ if (gitweb_check_feature('patches')) {
+ $formats_nav .= " | " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ "patch");
+ }
if (!defined $parent) {
$parent = "--root";
@@ -5416,9 +5430,8 @@ sub git_commitdiff {
my $format = shift || 'html';
my %params = @_;
- my $patch_max;
+ my ($patch_max) = gitweb_get_feature('patches');
if ($format eq 'patch') {
- ($patch_max) = gitweb_get_feature('patches');
die_error(403, "Patch view not allowed") unless $patch_max;
}
@@ -5436,6 +5449,11 @@ sub git_commitdiff {
$formats_nav =
$cgi->a({-href => href(action=>"commitdiff_plain", -replay=>1)},
"raw");
+ if ($patch_max) {
+ $formats_nav .= " | " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ "patch");
+ }
if (defined $hash_parent &&
$hash_parent ne '-c' && $hash_parent ne '--cc') {
@@ -5992,6 +6010,14 @@ sub git_shortlog {
$cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
}
+ my $patch_max = gitweb_check_feature('patches');
+ if ($patch_max) {
+ if ($patch_max < 0 || @commitlist <= $patch_max) {
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"patches", -replay=>1)},
+ "patches");
+ }
+ }
git_header_html();
git_print_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);
--
1.5.6.5
^ permalink raw reply related
* Re: [RFCv4 3/3] gitweb: link to patch(es) view from commit and log views
From: Jakub Narebski @ 2008-12-16 10:14 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0812160202n1f4f7f4fi7f71455eb42bcd31@mail.gmail.com>
You lost CC, somehow...
On Tue, 16 Dec 2008, Giuseppe Bilotta wrote:
> On Tue, Dec 16, 2008 at 2:03 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> > On Sat, 6 Dec 2008, Giuseppe Bilotta wrote:
>>> + if ($patch_max) {
>>> + if ($patch_max < 0 || @commitlist <= $patch_max) {
>>> + $paging_nav .= " ⋅ " .
>>> + $cgi->a({-href => href(action=>"patches", -replay=>1)},
>>> + @commitlist > 1 ? "patchset" : "patch");
[...]
>> I wonder if it would make sense to pass
>>
>> href(..., hash_parent => $commitlist[-1]{'id'}, ...)
>>
>> here. But I think having separate "patches" action, with intent being
>> displaying series of patches, is a better solution. This way you can
>> see in URL and in the page title (thus also in window title, or in
>> bookmark name) if it is single patch or patch series (perhaps consisting
>> of single patch).
>
> I'm not sure I'm following you here. Do you mean as in manually adding
> the parent endpoint to the URL when it's not specified in the log view
> itself? I think that would change the behaviour for > 100 patches.
First, I meant here that having separate "patches" action is a good
idea in itself, whether we pass explicitly and always $hash_parent
parameter here or not.
Second, I haven't thought about interaction with (short)log
pagination; in $patch_max < 0, i.e. unlimited patches, and most
common case of running 'shortlog' action without 'hp' (hash_parent)
limiter used, one would make 'patches' limited to page size,
other unlimited. On one hand side limiting to page size makes
"patches" be more of equivalent of current "shortlog" view; on the
other hand it makes 'unlimited' actually be limited to page size,
at least in this situation...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFCv4 2/3] gitweb: add patches view
From: Jakub Narebski @ 2008-12-16 10:16 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0812160149j1dcaefccv1caf4a2e589ffebb@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Tue, Dec 16, 2008 at 4:14 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Sat, 6 Dec 2008 16:02, Giuseppe Bilotta wrote:
>>
>>> The only difference between patch and patches view is in the treatement
>>> of single commits: the former only displays a single patch, whereas the
>>> latter displays a patchset leading to the specified commit.
>>
>> I like that fact that we have "patches" action which intent is to
>> show series of patches, and "patch" action which intent is to show
>> single patch. I'm just not sure if "patch" view should not simply
>> ignore $hash_parent...
>
> I had doubts on this myself. In the end I decided to make patch
> consider hash_parent if present because IMO it's what a user would
> expect in case e.g. of hand-crafted URLs.
Ah. I can understand that.
[...]
>>> sub git_commitdiff {
>>> my $format = shift || 'html';
>>> + # for patch view: should we limit ourselves to a single patch
>>> + # if only a single commit is passed?
>>> + my $single_patch = shift && 1;
>>
>> What does this "shift && 1" does? Equivalent of "!!shift"?
>> Is it really needed?
>>
>> Perhaps it would be better to use %opts trick, like for some other
>> gitweb subroutines (-single=>1, or -single_patch=>1, or -nmax=>1)?
>> Or perhaps not...
>
> It would be MUCH better, I'll do it this way. I'll pass the -single
> param in both cases, having value true/false, even though the false
> case is not needed since undef is false in perl anyway. (I like
> symmetry.)
--
Jakub Narebski
Poland
^ 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