* Re: [PATCH] pack-objects: don't use too many threads with few objects
From: Jeff King @ 2008-12-16 3:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Mike Ralphson, git
In-Reply-To: <7vy6ygudhb.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 15, 2008 at 05:15:44PM -0800, Junio C Hamano wrote:
> Perhaps the two runs are seeing different number of CPUs (hence threads)
> available? That would then change the distribution of the work itself
> (i.e. what slice of obj-list goes as a single chunk to be processed) and
> would affect the outcome.
I am seeing the same failure as Mike on one of my boxen. Each run sees
the same number of threads (4 in my case).
> Does the second test this patch adds fail?
With your patch, the added "both should match" test fails. So it seems
to be about doing a second run at all, not the difference in index
versions.
-Peff
^ permalink raw reply
* Re: [TortoiseGit]: Anyone seen this challenge?
From: Frank Li @ 2008-12-16 3:34 UTC (permalink / raw)
To: Scott Chacon, git
In-Reply-To: <d411cc4a0812151806v47f96245mb770faef7d423ead@mail.gmail.com>
I don't know If I understand your means correctly.
You need some account to push code.
TortoiseGit is open source project.
If you contribute enough code, I can open account for you.
2008/12/16 Scott Chacon <schacon@gmail.com>:
> By the way, this project already comes pretty close to what we were
> trying to get people to do. If you would like a free large account
> for your work on this (you won't need it for this project since it's
> open source, but for any commercial or private stuff you do), I would
> be happy to set you up. Thanks for your work on it, it looks
> incredibly promising.
>
> Scott
>
> On Mon, Dec 15, 2008 at 5:38 PM, Frank Li <lznuaa@gmail.com> wrote:
>> I add comments at this page to tell tortoisegit project.
>>
>> 2008/12/16 Tim Visher <tim.visher@gmail.com>:
>>> Anyone aware of this challenge?
>>>
>>> http://github.com/blog/256-tortoisegit-challenge
>>>
>>> They've noted the existence of the google code project.
>>>
>>> --
>>>
>>> In Christ,
>>>
>>> Timmy V.
>>>
>>> http://burningones.com/
>>> http://five.sentenc.es/ - Spend less time on e-mail
>>> --
>>> 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
>>>
>> --
>> 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: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Daniel Barkalow @ 2008-12-16 3:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr648uc88.fsf@gitster.siamese.dyndns.org>
On Mon, 15 Dec 2008, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > On Sun, 14 Dec 2008, Junio C Hamano wrote:
> >
> >> [On Hold]
> >>
> >> * nd/narrow (Sun Nov 30 17:54:38 2008 +0700) 17 commits
> >> - wt-status: show sparse checkout info
> >> - Introduce default sparse patterns (core.defaultsparse)
> >> - checkout: add new options to support sparse checkout
> >> - clone: support sparse checkout with --sparse-checkout option
> >> - unpack_trees(): add support for sparse checkout
> >> - unpack_trees(): keep track of unmerged entries
> >> - Introduce "sparse patterns"
> >> - Merge branch 'master' into nd/narrow
> >> + t2104: touch portability fix
> >> + grep: skip files outside sparse checkout area
> >> + checkout_entry(): CE_NO_CHECKOUT on checked out entries.
> >> + Prevent diff machinery from examining worktree outside sparse
> >> checkout
> >
> > I think this patch (slightly reframed) would be good to have independantly
> > of the series; it also means that we won't do weird things if someone
> > changes a file in the worktree which is marked as CE_VALID, and may well
> > may CE_VALID sufficient for the index representation of paths outside the
> > checkout.
>
> It is a bit unclear which one you meant by "this patch", sorry.
"Prevent diff machinery from examining worktree outside sparse checkout",
which (possibly in the next version) will prevent the diff machinery from
examining worktree files for paths that are CE_VALID in the index.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [TortoiseGit]: Anyone seen this challenge?
From: Geoffrey Lee @ 2008-12-16 3:39 UTC (permalink / raw)
To: Frank Li; +Cc: Scott Chacon, git
In-Reply-To: <1976ea660812151934s421afb8v36244d33f2025c03@mail.gmail.com>
On Mon, Dec 15, 2008 at 7:34 PM, Frank Li <lznuaa@gmail.com> wrote:
> I don't know If I understand your means correctly.
Frank,
Scott is offering you a free account on Github as reward for the
TortoiseGit project.
-Geoffrey Lee
^ permalink raw reply
* Re: ETA for release of gjit 0.4?
From: Robin Rosenberg @ 2008-12-16 3:56 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: Shawn O. Pearce, git
In-Reply-To: <4946DFBB.6030300@wellfleetsoftware.com>
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.
I cannot deploy it seems (I get a 401 or dav not supported), but since we have a
tagged v0.4.0 commit you have a handle to make your own local deployment. It
is at least defined what commit the v0.4.0 is. You'll need to modify the pom.xml
to make it name the jars properly,
diff --git a/jgit-maven/jgit/pom.xml b/jgit-maven/jgit/pom.xml
index c370783..467e620 100644
--- a/jgit-maven/jgit/pom.xml
+++ b/jgit-maven/jgit/pom.xml
@@ -39,7 +39,7 @@ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
<groupId>org.spearce</groupId>
<artifactId>jgit</artifactId>
<packaging>jar</packaging>
- <version>0.4-SNAPSHOT</version>
+ <version>0.4.0</version>
<name>jgit</name>
<url>http://repo.or.cz/w/egit.git</url>
<mailingLists>
-- robin
^ permalink raw reply related
* Re: [TortoiseGit]: Anyone seen this challenge?
From: Frank Li @ 2008-12-16 4:06 UTC (permalink / raw)
To: Geoffrey Lee; +Cc: Scott Chacon, git
In-Reply-To: <83d7aaa40812151939s3b4e828cl12033efabc55fc50@mail.gmail.com>
I am sorry that I miss understand scott means.
Thank you!
Scott, you help set up account on github for TortoiseGit project.
2008/12/16 Geoffrey Lee <geoffreyj.lee@gmail.com>:
> On Mon, Dec 15, 2008 at 7:34 PM, Frank Li <lznuaa@gmail.com> wrote:
>> I don't know If I understand your means correctly.
>
> Frank,
> Scott is offering you a free account on Github as reward for the
> TortoiseGit project.
>
> -Geoffrey Lee
>
^ permalink raw reply
* Re: git-diff should not fire up $PAGER if there is no diff
From: Jeff King @ 2008-12-16 4:07 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87oczcx6ky.fsf@jidanni.org>
On Tue, Dec 16, 2008 at 09:16:29AM +0800, jidanni@jidanni.org wrote:
> JK> The usual workaround is to ask the pager to exit immediately if the
> JK> output is small. I.e., putting "F" in your LESS variable (which git does
> JK> automatically if you don't already have LESS set).
>
> Ah, but who doesn't have LESS set these days? OK, the man page should
> mention that so people will put the F on their LESS variable, like I
> recall another man page already does.
Not unreasonable. Care to make a patch to the documentation?
-Peff
^ permalink raw reply
* 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
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