* Re: [PATCH] gitweb: unify boolean feature subroutines
From: Junio C Hamano @ 2008-12-15 22:21 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <1229352709-4663-2-git-send-email-kraai@ftbfs.org>
Matt Kraai <kraai@ftbfs.org> writes:
> The boolean feature subroutines were identical except for the name of
> the configuration option, so make that a parameter and unify them.
I think this makes sense but unfortunately it comes after the other one
that I do not know what its point is...
^ permalink raw reply
* Re: [PATCH] gitweb: make feature_blame return a list
From: Giuseppe Bilotta @ 2008-12-15 22:52 UTC (permalink / raw)
To: git
In-Reply-To: <7v7i61w06k.fsf@gitster.siamese.dyndns.org>
On Monday 15 December 2008 23:20, Junio C Hamano wrote:
> Matt Kraai <kraai@ftbfs.org> writes:
>
>> The feature defaults are expected to be a list, but feature_blame was
>> returning a scalar. This change makes it consistent with the other
>> boolean feature subroutines.
>>
>> Signed-off-by: Matt Kraai <kraai@ftbfs.org>
>> ---
>> gitweb/gitweb.perl | 6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index 6eb370d..145e712 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -367,12 +367,12 @@ sub feature_blame {
>> my ($val) = git_get_project_config('blame', '--bool');
>>
>> if ($val eq 'true') {
>> - return 1;
>> + return (1);
>> } elsif ($val eq 'false') {
>> - return 0;
>> + return (0);
>> }
>>
>> - return $_[0];
>> + return ($_[0]);
>> }
>
> My Perl may be getting rusty, but does the above make any difference?
> How?
It's formally more correct and makes the blame feature fit with the
general feature framework, although the feature works correctly even
without the (). I was actually going to send a similar patch myself,
having missed it during the cleanup and get/check splitup patchset.
Matt's patch gets my Ack, for what it's worth.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: ETA for release of gjit 0.4?
From: Farrukh Najmi @ 2008-12-15 22:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Robin Rosenberg, git
In-Reply-To: <493D4CDB.2010100@wellfleetsoftware.com>
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.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Clemens Buchacher @ 2008-12-15 23:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, johannes.schindelin, raa.lkml
In-Reply-To: <7vej09w0hy.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 15, 2008 at 02:13:13PM -0800, Junio C Hamano wrote:
> You can do a merge inside a dirty work tree, and the merge will fail
> without clobbering your work tree files that are dirty when it needs to be
> able to overwrite to do its job. The set of "dirty files" in this
> sentence of course includes paths that are modified since HEAD, but it
> also includes also paths that do not exist in HEAD (i.e. "new files").
>
> But we already caution users that you need to know what you are doing when
> working in such a dirty work tree. Namely, after a failed merge, your
> next "git reset --hard" will blow away your local modifications. And
> local modifications in this context includes the files you could have
> added to the index but you haven't.
I strongly disagree. With the suggested behavior I would have to
double-check every single untracked file in my tree for conflicts before
trying a throw-away merge followed by git reset --hard, for example. The
file could even be ignored! Whatever happened to git reset doesn't touch
untracked files?
I would even prefer breaking t6023 (until we can properly implement this
feature) in order to avoid that.
^ permalink raw reply
* Re: New script to convert p4 repositories to git - git-p4c version 1.
From: John Chapman @ 2008-12-15 21:52 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Git Mailing List
In-Reply-To: <20081215193058.GA5098@osc.edu>
On Mon, 2008-12-15 at 14:30 -0500, Pete Wyckoff wrote:
<snip>
> I'm running into a different limitation with p4c.
>
> The command:
>
> p4 -G changes -l -t
>
> is adminstratively limited to a paltry six-digit number, and
> produces only an error message.
Hmm, I'm not sure how to resolve this, the repo I use this with so far
only uses 6 digit numbers, will have to review the p4 client documents
on this.
>
> The other feature I need is the ability to use a client
> specification. We merge together 40-odd different chunks of //depot
> into a single checked-out client, and use some other number of
> "-//depot/..." rules to exclude some parts of the full depot.
>
> If I hack p4c to limit the changes with "-m 10" or so, then things
> are a bit better in that I get two objects (changesets) but no
> diffs. Had to hack the on_branch() code somewhat, in that no form
> of --branches seemed to produce an "interesting" changeset by your
> definition. Could be my lack of understanding here.
Modifying the on_branch code is the right place to do what you want,
however I was hoping that specifying your 'interesting' branches by
regexp would be sufficient? All those places that do not get matched
are effectively ignored and do not become part of the git repo.
There is a bug in which the case of the branch name sometimes seems to
change in my repo, and thus my newer version always lower-cases the
names.
Do you need to use a client spec here, or is it possible to just use
regexps? I'd like to try and avoid the need to parse the clientspec,
that's all.
> If you think you want to handle client specifications, and can think
> of a way around the "p4 changes" limitation, I'll be happy to poke
> at your next version. Perhaps I'm not in your target audience,
> though. I don't necessarily need to have a full git history of the
> entire p4, but this seems to be a fundamental part of your approach.
I'm not sure about client specifications, but I definetly do want to
think of a way around the p4 changes limitation.
I'll get a new version out to you soon (Which includes several bug
fixes), however before I go, I should mention that a deliberate design
decision was to allow the git administrator maximum flexibility.
The script does try to import the full history, however it starts that
history only at the most recent change, which is defined as a tag.
Thus, if your main branch is 'trunk', then you should be able to
manually import your changes, tag it as 'trunk/102388', to indicate
that's p4's revision 102388 of trunk, and the script should then begin
checking out changeset 102389. I haven't had a chance to test that
theory yet, but it should work.
Thankyou for your valuable feedback.
>
> -- Pete
> --
> 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
* git-clone --how-much-disk-space-will-this-cost-me? [--depth n]
From: jidanni @ 2008-12-15 23:53 UTC (permalink / raw)
To: git
The git-clone manpage should mention how to determine how much disk
space will be used.
You see we beginners (who haven't learned git yet, so no patches
forthcoming, thank you) are often told "Just do git-clone
git://git.example.org/bla/ to get started!". Being smart, we read up on
--depth 1 to limit potential disk occupation, but we still have no
idea of how much disk space we will need. We cant just use HEAD(1)
because this is not HTTP.
Therefore the git-clone man page, one of the main entry points for the
beginner, should say how to determine how much disk space we will need
for git-clone or git-clone --depth 1 etc.
And don't tell us to just figure it out from the progress messages
after the download begins, and hit ^C if we don't like it.
Let's take a look at those messages while were at it,
$ git-clone --depth 1 git://git.sv.gnu.org/coreutils/
Initialized empty Git repository in /usr/local/src/jidanni/coreutils/.git/
remote: Counting objects: 26240, done.
remote: Compressing objects: 100% (14001/14001), done.
remote: Total 26240 (delta 21577), reused 15354 (delta 12095)
Receiving objects: 100% (26240/26240), 15.76 MiB | 26 KiB/s, done.
Resolving deltas: 100% (21577/21577), done.
$ du -sh
27M .
Nope, nowhere does it directly say "You Holmes, are in for 27
Megabytes (on your piddly modem)". There obviously is math involved to
figure it out... math!
Also add examples of how one first probes a remote tree one has been
told about, determines what parts of it he might want, and then
finally git-clones just those parts.
Also document what --depth 0 or even -1 will do.
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Junio C Hamano @ 2008-12-16 0:16 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, johannes.schindelin, raa.lkml
In-Reply-To: <20081215230205.GA19538@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> I strongly disagree. With the suggested behavior I would have to
> double-check every single untracked file in my tree for conflicts before
> trying a throw-away merge followed by git reset --hard, for example.
AFAICS, that's not "suggested behaviour" for merge, but it is the
behaviour that has been true for eternity.
You can suggest to fix "reset --hard", though.
^ permalink raw reply
* git-diff should not fire up $PAGER if there is no diff
From: jidanni @ 2008-12-16 0:21 UTC (permalink / raw)
To: git
git-diff should not fire up $PAGER if there is no diff output.
Just exit. The man page doesn't even mention $PAGER too.
^ permalink raw reply
* Re: git-clone --how-much-disk-space-will-this-cost-me? [--depth n]
From: Jean-Luc Herren @ 2008-12-16 0:22 UTC (permalink / raw)
To: jidanni, git
In-Reply-To: <878wqhxaex.fsf@jidanni.org>
Hi!
jidanni@jidanni.org wrote:
> The git-clone manpage should mention how to determine how much disk
> space will be used.
> [...]
> And don't tell us to just figure it out from the progress messages
> after the download begins, and hit ^C if we don't like it.
Maybe that's a dumb answer, but... why not? This works pretty
well for me.
> Nope, nowhere does it directly say "You Holmes, are in for 27
> Megabytes (on your piddly modem)". There obviously is math involved to
> figure it out... math!
So maybe what you really want is an ETA display during the cloning
process? Sounds like a good idea to me.
jlh
^ permalink raw reply
* Re: git-clone --how-much-disk-space-will-this-cost-me? [--depth n]
From: jidanni @ 2008-12-16 0:37 UTC (permalink / raw)
To: jlh; +Cc: git
In-Reply-To: <4946F4D9.8050803@gmx.ch>
>> And don't tell us to just figure it out from the progress messages
>> after the download begins, and hit ^C if we don't like it.
JH> Maybe that's a dumb answer, but... why not? This works pretty
JH> well for me.
Sounds like my last marriage. "Just hit ^C if you don't like it". How
do you think the in-laws will feel? Nope, plan ahead I now say.
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.
The key is to now allow the user to get such an estimate too, before
deciding to git-clone or not.
^ permalink raw reply
* Re: git-clone --how-much-disk-space-will-this-cost-me? [--depth n]
From: Jeff King @ 2008-12-16 0:43 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <878wqhxaex.fsf@jidanni.org>
On Tue, Dec 16, 2008 at 07:53:42AM +0800, jidanni@jidanni.org wrote:
> The git-clone manpage should mention how to determine how much disk
> space will be used.
OK. Do you have a suggestion for how to figure that out?
> Let's take a look at those messages while were at it,
> $ git-clone --depth 1 git://git.sv.gnu.org/coreutils/
> Initialized empty Git repository in /usr/local/src/jidanni/coreutils/.git/
> remote: Counting objects: 26240, done.
> remote: Compressing objects: 100% (14001/14001), done.
> remote: Total 26240 (delta 21577), reused 15354 (delta 12095)
> Receiving objects: 100% (26240/26240), 15.76 MiB | 26 KiB/s, done.
> Resolving deltas: 100% (21577/21577), done.
> $ du -sh
> 27M .
> Nope, nowhere does it directly say "You Holmes, are in for 27
> Megabytes (on your piddly modem)". There obviously is math involved to
> figure it out... math!
That's because we don't know that it will be 27 megabytes. That progress
counter is counting the number of _objects_, not bytes. So you can make
a rough estimate, but only after receiving some objects, and even then
it can be wildly off (because you are assuming the size of the objects
still to get averages the same as the size of the objects you have
already gotten).
AFAIK, nowhere in the sent data is there an indication of how many bytes
are in the resulting pack (and in many cases, the pack is generated on
the fly and the information not only is not sent, but is not available
anywhere).
-Peff
^ permalink raw reply
* Re: git-diff should not fire up $PAGER if there is no diff
From: Jeff King @ 2008-12-16 0:56 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <874p15x94i.fsf@jidanni.org>
On Tue, Dec 16, 2008 at 08:21:33AM +0800, jidanni@jidanni.org wrote:
> git-diff should not fire up $PAGER if there is no diff output.
> Just exit. The man page doesn't even mention $PAGER too.
I agree that would be nice, but it is a little difficult to implement.
The current behavior forks early and then pipes the output to the pager.
So we would have to:
1. change that behavior to instead delay starting the pager until the
first output. Which means intercepting every
write/fwrite/printf/fputs/etc call.
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).
3. a hacky solution to (2) above would be to make _2_ pipes, one of
which signals to the pager sub-process either "exit now" or "proceed
with running the pager".
The usual workaround is to ask the pager to exit immediately if the
output is small. I.e., putting "F" in your LESS variable (which git does
automatically if you don't already have LESS set).
-Peff
^ permalink raw reply
* Re: [RFCv4 3/3] gitweb: link to patch(es) view from commit and log views
From: Jakub Narebski @ 2008-12-16 1:03 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1228575755-13432-4-git-send-email-giuseppe.bilotta@gmail.com>
On Sat, 6 Dec 2008, Giuseppe Bilotta wrote:
> 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>
A few remarks, but otherwise:
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 30 ++++++++++++++++++++++++++++--
> 1 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index dfc7128..8198875 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -5019,6 +5019,15 @@ sub git_log {
>
> my $paging_nav = format_paging_nav('log', $hash, $head, $page, $#commitlist >= 100);
>
> + my $patch_max = gitweb_check_feature('patches');
If you change other places to use git_get_feature, then you should
change it too. I'm not sure if it is worth it...
> + 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 think it would be better to always use "patches" here, as it is
series of patches by design, only by accident it is one commit long.
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).
> + }
> + }
> +
> git_header_html();
> git_print_page_nav('log','', $hash,undef,undef, $paging_nav);
>
> @@ -5098,6 +5107,11 @@ sub git_commit {
> } @$parents ) .
> ')';
> }
> + if (gitweb_check_feature('patches')) {
> + $formats_nav .= " | " .
> + $cgi->a({-href => href(action=>"patch", -replay=>1)},
> + "patch");
> + }
Here using gitweb_check_feature makes perfect sense.
>
> if (!defined $parent) {
> $parent = "--root";
> @@ -5413,9 +5427,8 @@ sub git_commitdiff {
> # if only a single commit is passed?
> my $single_patch = shift && 1;
>
> - my $patch_max;
> + my $patch_max = gitweb_check_feature('patches');
gitweb_check_feature or gitweb_get_feature?...
> if ($format eq 'patch') {
> - $patch_max = gitweb_check_feature('patches');
> die_error(403, "Patch view not allowed") unless $patch_max;
> }
>
> @@ -5433,6 +5446,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");
> + }
Nice reusing $patch_max in different way, as $have_patch if $format is
'html', and as limiter ($patch_max) if $format is 'patch'/'patches'
>
> if (defined $hash_parent &&
> $hash_parent ne '-c' && $hash_parent ne '--cc') {
> @@ -5989,6 +6007,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)},
> + @commitlist > 1 ? "patchset" : "patch");
> + }
> + }
Same comment as for git_log...
>
> git_header_html();
> git_print_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Jakub Narebski @ 2008-12-16 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Clemens Buchacher, git, johannes.schindelin, raa.lkml
In-Reply-To: <7vprjtug8u.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Clemens Buchacher <drizzd@aon.at> writes:
>
> > I strongly disagree. With the suggested behavior I would have to
> > double-check every single untracked file in my tree for conflicts before
> > trying a throw-away merge followed by git reset --hard, for example.
>
> AFAICS, that's not "suggested behaviour" for merge, but it is the
> behaviour that has been true for eternity.
>
> You can suggest to fix "reset --hard", though.
Errr... what about using "reset --merge" instead?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] pack-objects: don't use too many threads with few objects
From: Junio C Hamano @ 2008-12-16 1:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Mike Ralphson, Jeff King, git
In-Reply-To: <e2b179460812151038y5a39b33cv1d7b41faf10563e@mail.gmail.com>
"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?
And this does not fail with 'master' on Mike's AIX, but with 'next' that
has the threaded delta search.
Since the list of objects packed (obj-list in the test script) contains
302 objects, which is way bigger than the window size, I can understand
that packing with or without threading would produce different results.
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...
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.
Does the second test this patch adds fail?
t/t5302-pack-index.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git i/t/t5302-pack-index.sh w/t/t5302-pack-index.sh
index 884e242..bd5db03 100755
--- i/t/t5302-pack-index.sh
+++ w/t/t5302-pack-index.sh
@@ -39,6 +39,17 @@ test_expect_success \
git verify-pack -v "test-1-${pack1}.pack"'
test_expect_success \
+ 'pack-objects with index version 1 (again)' \
+ 'pack1=$(git pack-objects --index-version=1 test-1again <obj-list) &&
+ git verify-pack -v "test-1again-${pack1}.pack"'
+
+test_expect_success 'both should match' '
+ cmp "test-1-${pack1}.pack" "test-1again-${pack1}.pack"
+'
+
+exit
+
+test_expect_success \
'pack-objects with index version 2' \
'pack2=$(git pack-objects --index-version=2 test-2 <obj-list) &&
git verify-pack -v "test-2-${pack2}.pack"'
^ permalink raw reply related
* Re: git-diff should not fire up $PAGER if there is no diff
From: jidanni @ 2008-12-16 1:16 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0812160153340.14632@racer>
>>>>> "JS" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
JS> Maybe you are not aware just how annoying these "this should do that, that
JS> should do this" without a patch are?
Yes but I must first learn the thing I am about to make a patch for.
In the mean time I could like most beginners, just feel dumb.
Or I could let you have my valuable insights on how things look to a
beginner. You would else have no way of knowing. Sorry I always come
across as Don Rickles the pushy customer... it's all a charade... now
let's get back to business,
>>>>> "JK" == Jeff King <peff@peff.net> writes:
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.
^ permalink raw reply
* Re: hooks/post-update execs git-update-server-info
From: Sitaram Chamarty @ 2008-12-16 1:27 UTC (permalink / raw)
To: git
In-Reply-To: <m3zlixcqrb.fsf@localhost.localdomain>
On 2008-12-15, Jakub Narebski <jnareb@gmail.com> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>> shouldn't .git/hooks/post-update contain "exec git
>> update-server-info" (note the space not hyphen) instead of
> If I understand correctly hooks run with GIT_EXEC_PATH prepended to
> PATH, so everything should work; and it has to work to not force users
you're right -- it does. There was something else wrong in
my quick-and-dirty testing that caused me to jump to the
wrong conclusion; sorry for the noise!
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Nguyen Thai Ngoc Duy @ 2008-12-16 1:35 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0812151423390.19665@iabervon.org>
On 12/16/08, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > + grep: skip files outside sparse checkout area
> > + 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.
I have made a fixup patch for CE_VALID. Unfortunately I have not had
time to write tests and finish it before submitting. I may have free
time this weekend to complete.
--
Duy
^ permalink raw reply
* Re: [TortoiseGit]: Anyone seen this challenge?
From: Frank Li @ 2008-12-16 1:38 UTC (permalink / raw)
To: Tim Visher, git
In-Reply-To: <c115fd3c0812150820m158d3c9fuc01a05771f445fa5@mail.gmail.com>
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
>
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Junio C Hamano @ 2008-12-16 1:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0812151423390.19665@iabervon.org>
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.
^ permalink raw reply
* Re: [TortoiseGit]: Anyone seen this challenge?
From: Scott Chacon @ 2008-12-16 2:06 UTC (permalink / raw)
To: Frank Li; +Cc: Tim Visher, git
In-Reply-To: <1976ea660812151738m4d63739dv6c07a0d97f3c176f@mail.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: git-clone --how-much-disk-space-will-this-cost-me? [--depth n]
From: Jean-Luc Herren @ 2008-12-16 2:07 UTC (permalink / raw)
To: jidanni, git
In-Reply-To: <87zlixvtu9.fsf@jidanni.org>
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.
jlh
^ permalink raw reply
* Re: [PATCH] gitweb: make feature_blame return a list
From: Matt Kraai @ 2008-12-16 2:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i61w06k.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 15, 2008 at 02:20:03PM -0800, Junio C Hamano wrote:
> Matt Kraai <kraai@ftbfs.org> writes:
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -367,12 +367,12 @@ sub feature_blame {
> > my ($val) = git_get_project_config('blame', '--bool');
> >
> > if ($val eq 'true') {
> > - return 1;
> > + return (1);
> > } elsif ($val eq 'false') {
> > - return 0;
> > + return (0);
> > }
> >
> > - return $_[0];
> > + return ($_[0]);
> > }
>
> My Perl may be getting rusty, but does the above make any difference?
I'm still relatively new to Perl, but at least in my limited testing,
I couldn't generate a case in which these different constructs had
different results.
I made this change so that all of the boolean feature subroutines
would have the same body, modulo the name of the option; that way,
replacing them with a single routine only involves making the option
name a parameter.
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.
--
Matt http://ftbfs.org/
^ permalink raw reply
* Re: [RFCv4 2/3] gitweb: add patches view
From: Jakub Narebski @ 2008-12-16 3:14 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1228575755-13432-3-git-send-email-giuseppe.bilotta@gmail.com>
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...
Signoff?
> ---
> gitweb/gitweb.perl | 20 ++++++++++++++++++--
> 1 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 71d5af4..dfc7128 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -525,6 +525,7 @@ our %actions = (
> "history" => \&git_history,
> "log" => \&git_log,
> "patch" => \&git_patch,
> + "patches" => \&git_patches,
> "rss" => \&git_rss,
> "atom" => \&git_atom,
> "search" => \&git_search,
> @@ -5408,6 +5409,9 @@ sub git_blobdiff_plain {
>
> 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...
>
> my $patch_max;
> if ($format eq 'patch') {
> @@ -5524,7 +5528,15 @@ sub git_commitdiff {
> }
> push @commit_spec, '-n', "$hash_parent..$hash";
> } else {
> - push @commit_spec, '-1', '--root', $hash;
> + if ($single_patch) {
> + push @commit_spec, '-1';
> + } else {
> + if ($patch_max > 0) {
> + push @commit_spec, "-$patch_max";
> + }
> + push @commit_spec, "-n";
> + }
> + push @commit_spec, '--root', $hash;
Nice.
> }
> open $fd, "-|", git_cmd(), "format-patch", '--encoding=utf8',
> '--stdout', @commit_spec
> @@ -5620,7 +5632,11 @@ sub git_commitdiff_plain {
>
> # format-patch-style patches
> sub git_patch {
> - git_commitdiff('patch');
> + git_commitdiff('patch', 1);
> +}
> +
> +sub git_patches {
> + git_commitdiff('patch', 0);
I quite like it.
> }
>
> sub git_history {
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* 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
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