* Re: Change in git-svn dcommit semantics?
From: Johannes Schindelin @ 2006-12-19 23:57 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Seth Falcon, git
In-Reply-To: <94FF72E0-F8BD-4773-803E-F179754BF0ED@silverinsanity.com>
Hi,
On Tue, 19 Dec 2006, Brian Gernhardt wrote:
> Mine also has a few variables like "COLLISION_CHECK=paranoid" and my own
> prefix.
Just to wake sleeping tigers: have you done a "grep COLLISION_CHECK *"
recently (where recently means any date after May 3rd, 2005)?
Ciao,
Dscho
^ permalink raw reply
* Re: Can git be tweaked to work cross-platform, on FAT32?
From: Dan Nicholson @ 2006-12-19 23:55 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Johannes Schindelin, Florian v. Savigny, git
In-Reply-To: <46a038f90612170221u4c3b5c2asef378d3d4e159ba7@mail.gmail.com>
On 12/17/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
>
> Note that under windows you can use ext2 -- haven't used it, and don't
> know how cygwin behaves with it, but it may be *just* what you need to
> avoid case sensitivity problems and have symlink support.
>
> http://sourceforge.net/projects/ext2fsd
>
> http://www.fs-driver.org/
I've used both of these guys, but not the most recent versions. Both
were previously read-only, but now it appears both have write support
from looking at the release notes. Both were a bit heavy handed to get
setup, but a decently computer literate person could probably handle
it. Ext2IFS in particular looks dramatically improved from when I last
used it.
Both worked fine through Cygwin for simple usage. I never did anything
with serious disk usage on either of them, so I can't say how it
stacks up to FAT32 on Linux in terms of really hammering the disk.
A little more reading says ext2ifs can't handle permissions or symbolic links.
http://www.fs-driver.org/faq.html
I don't recall the details of ext2fsd, but I think symbolic links
worked. I'd like to look at this again, but I spend all my time in
Linux at home.
--
^ permalink raw reply
* Question on rerere
From: Johannes Schindelin @ 2006-12-19 23:53 UTC (permalink / raw)
To: git
Hi,
while studying the code of rerere I found myself wondering if the code of
compute_conflict_name and record_preimage is correct.
IIUC then each conflict hunk is handled _separately_ like this: the
lexicographically smaller between the two file sections is displayed
first, regardless if a previous hunk had a different order. Not that it
matters most of the time, but isn't this dangerous?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] git reflog expire
From: Linus Torvalds @ 2006-12-19 23:29 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061219102741.GA21324@spearce.org>
On Tue, 19 Dec 2006, Shawn Pearce wrote:
>
> Smaller mmap units may help on some larger projects. For example
> 'git whatchanged' shouldn't need to setup page table entries for
> the entire pack file when only the front and middle are needed to
> obtain the data for the most recent 25 commits, before the user
> kills the pager.
At least on Linux, we do NOT set up page table entries unnecessarily. The
cost of a mmap() is largely independent of the size of the mmap, and the
costs will be on page fault time (which is obviously O(n) in number of
pages you need).
The same is _largely_ true of munmap() too. There's a small cost to large
mmaps that were only sparsely accessed being unmapped (we have to look at
the page tables closely, even if they end up being empty), but quite
frankly, it's not going to be all that noticeable.
So mmap() costs end up largely being one (fairly small) fixed cost, plus a
(fairly small) cost for each page beign demand-mapped in.
Of course, Linux is just _better_ than the competition, so things that
don't help Linux might still help other systems. Linux does both page
faults and the mmap system call well, other systems will generally be an
order of magnitude worse in both. And as we've seen, it can be more.
(Things that are really fast on Linux: VM manipulation, and filename path
lookup. Those are both ops that Linux _really_ shines on. It may not sound
like much, but when you do millions of them, it's the difference between
seconds and hours).
^ permalink raw reply
* Re: Change in git-svn dcommit semantics?
From: Brian Gernhardt @ 2006-12-19 23:02 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2mz5jegka.fsf@ziti.local>
On Dec 19, 2006, at 4:12 PM, Seth Falcon wrote:
> git version 1.4.4.2.gee60-dirty
> (the dirty is a hand edit to Makefile for prefix)
Just FYI: You can save Makefile variables in a "config.mak" file
instead of having to dirty your working tree (and dealing with
conflicts, etc). For example:
cat > config.mak <<EOF
prefix=/your/prefix/path/here/
EOF
Mine also has a few variables like "COLLISION_CHECK=paranoid" and my
own prefix.
^ permalink raw reply
* [PATCH] git-cvsserver: fix breakage when calling git merge-file
From: Eric Wong @ 2006-12-19 22:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git
In the same vein as 8336afa563fbeff35e531396273065161181f04c,
this fixes the the RCS merge to git-merge-file conversion in
commit e2b70087.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-cvsserver.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 2a8447e..df39512 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -946,7 +946,7 @@ sub req_update
$log->debug("Temporary directory for merge is $dir");
- my $return = system("git merge-file", $file_local, $file_old, $file_new);
+ my $return = system("git", "merge-file", $file_local, $file_old, $file_new);
$return >>= 8;
if ( $return == 0 )
--
1.4.4.2.ga184
^ permalink raw reply related
* Re: [RFC] Possible optimization for gitweb
From: Jakub Narebski @ 2006-12-19 22:22 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wmvpmef.fsf@assigned-by-dhcp.cox.net>
[Please Cc: git@vger.kernel.org]
Junio C Hamano wrote:
> Robert Fitzsimons <robfitz@273k.net> writes:
>
>> The new workflows I'm proposing would be:
>> get/parse ~100 commit's using rev-list
>> foreach commit
>> output commit
>
> Absolutely.
>
> And Ok on rev-list part, but perhaps --skip would be more
> appropriate name.
The only problem that you can't use --parents with "history" view, because
together with --full-history it shows also all merges (--full-history
without --parents doesn't show merges which does not affect given file or
directory; the sequence in which --parents and --full-history are taken is
a bit strange to me). So you have to keep current parse_commit (or extend
it), and if I remember correctly you do that.
I'm also for --skip (not --start-count), although... --start-count with
--max-count seems more natural; one place it can be confusing is that we
count skipped commits or not? I.e. we use --start-count=10 --max-count=20
to get second 10 of commits, or --skip=10 --max-count=10 to get second 10
of commits?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Can git be tweaked to work cross-platform, on FAT32?
From: David Lang @ 2006-12-19 21:57 UTC (permalink / raw)
To: Florian v. Savigny; +Cc: git
In-Reply-To: <0MKwpI-1GuWVF2znk-0006fC@mrelayeu.kundenserver.de>
On Wed, 13 Dec 2006, Florian v. Savigny wrote:
> I would like to use git to develop a somewhat larger Perl project
> which I would need to test and develop under both Linux and Windows,
> i.e. I would need a repository on a FAT32 partition (to my knowledge,
> still the only filesystem that can be fully accessed from both OSes -
> correct me if I'm wrong)
there are drivers available for windows to let it access ext2/3 partitions. I
don't know if that would help any in this situation.
David Lang
^ permalink raw reply
* Re: [RFC] Possible optimization for gitweb
From: Junio C Hamano @ 2006-12-19 22:10 UTC (permalink / raw)
To: Robert Fitzsimons; +Cc: git
In-Reply-To: <20061219205422.GA17864@localhost>
Robert Fitzsimons <robfitz@273k.net> writes:
> The new workflows I'm proposing would be:
> get/parse ~100 commit's using rev-list
> foreach commit
> output commit
Absolutely.
And Ok on rev-list part, but perhaps --skip would be more
appropriate name.
^ permalink raw reply
* Re: Change in git-svn dcommit semantics?
From: Eric Wong @ 2006-12-19 22:09 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2mz5jegka.fsf@ziti.local>
Seth Falcon <sethfalcon@gmail.com> wrote:
> Hi Eric,
>
> I just updated to the latest git/git-svn (on branch 'master') and the
> workflow I've been using no longer seems to work:
>
> # review the commits I'm going to send to svn
> ziti:~/proj/bioc-2.0-git seth$ git log remotes/git-svn..HEAD
>
> # now send them
> ziti:~/proj/bioc-2.0-git seth$ git svn dcommit remotes/git-svn..HEAD
>
> fatal: ambiguous argument
> 'refs/remotes/git-svn..remotes/git-svn..HEAD': unknown revision or
> path not in the working tree. Use '--' to separate paths from
> revisions 32768 at /Users/seth/scm/bin/git-svn line 2190
> main::safe_qx('git-rev-list', '--no-merges', 'refs/remotes/git-svn..remotes/git-svn..HEAD') called at /Users/seth/scm/bin/git-svn line 610
> main::dcommit('remotes/git-svn..HEAD') called at /Users/seth/scm/bin/git-svn line 197
>
>
> At this point, my last commit seems to have been reset (although the
> changes are thankfully still in my working tree). If this happens to
> you, you can recover the last commit like:
>
> git commit -a -v -c ORIG_HEAD
Huh? safe_qx should've croaked or died, causing git-svn to exit before
it could do any damage (via git-reset or git-rebase). dcommit is not
called inside any eval blocks, either...
> And it seems that the new interface requires no extra args:
>
> git svn dcommit
>
> The new interface seems ok until things like
>
> git svn dcommit remotes/git-svn..HEAD~2
>
> are allowed (if ever). But it would be nice for the failure mode to
> not undo commits :-)
Before, the 'remotes/git-svn..HEAD' argument meant absolutely nothing to
dcommit (it silently ignored it). Nowadays, you only need 'HEAD~2', the
'remotes/git-svn..' is already implied.
git-svn dcommit HEAD~2
Not specifying any argument implies that it is called with 'HEAD'
--
^ permalink raw reply
* Re: GIT - error: no such remote ref refs/heads/TestBranch
From: Junio C Hamano @ 2006-12-19 22:06 UTC (permalink / raw)
To: git
In-Reply-To: <89b129c60612191233s5a7f36f2hd409c4b9a2bbbc5c@mail.gmail.com>
"Sean Kelley" <sean.v.kelley@gmail.com> writes:
> Hi,
>
> I was wondering if someone could help me. I had a branch on our
> remote GIT server called TestBranch. I logged into the Remote server
> and ran:
>
> <from remote server>
> git branch -D TestBranch
>
> But in my local clone:
>
> kelleys@oifig:~/Work/kernel$ git pull origin
> kelleys@git.example.com's password:
> error: no such remote ref refs/heads/TestBranch
> Fetch failure: git+ssh://git.example.com/data/git/proj/kernel/mh.git
> kelleys@oifig:~/Work/kernel$
>
> Any ideas how to correct this?
If you know remote does not have it, then probably not fetching
from it would be a good idea.
Look at your local $GIT_DIR/remotes/origin (or [remote "origin"]
section in $GIT_DIR/config) and remove the refspec that tells
git to fetch it.
In $GIT_DIR/remotes/origin, you may want to remove a like like this:
Pull: refs/heads/TestBranch:<something>
If it is coming from $GIT_DIR/config, it would probably look
like:
[remote "origin"]
fetch = refs/heads/TestBranch:<something>
and you would want to remove the "fetch = " line.
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Alex Riesen @ 2006-12-19 20:28 UTC (permalink / raw)
To: Marco Roeland
Cc: Shawn Pearce, Linus Torvalds, Theodore Tso, Nicolas Pitre,
Johannes Schindelin, Randal L. Schwartz, git
In-Reply-To: <20061219091319.GC30448@fiberbit.xs4all.nl>
Marco Roeland, Tue, Dec 19, 2006 10:13:19 +0100:
> > Not that I personally frequently clone large projects on Mac OS X.
> > But new users to Git might. :-)
>
> And perhaps the Cygwin version might benefit too.
Does not work there at all. Even errno is not set (0).
^ permalink raw reply
* Re: [RFC] Possible optimization for gitweb
From: Jakub Narebski @ 2006-12-19 21:45 UTC (permalink / raw)
To: git
In-Reply-To: <20061219205422.GA17864@localhost>
[Please send replies Cc: git mailing list]
Robert Fitzsimons wrote:
> While looking at the gitweb source yesterday, I noticed a number of
> similar expensive workflows used by a number of actions (summary,
> shortlog, log, rss, atom, and history).
>
> The current workflows are:
> get ~100 sha1's using rev-list
> foreach sha1
> get/parse 1 commit using rev-list
> output commit
>
> The new workflows I'm proposing would be:
> get/parse ~100 commit's using rev-list
> foreach commit
> output commit
I have tried this approach too. Take a look at
http://repo.or.cz/w/git/jnareb-git.git?a=log;h=Attic/gitweb/parse_rev_list
or at discussion started with
Message-Id: <200609061504.40725.jnareb@gmail.com>
http://mid.gmane.org/200609061504.40725.jnareb@gmail.com
> The following simplified commands gives an idea of the git only overhead
> between these two workflows.
>
> time \
> for r in `git-rev-list --max-count=100 HEAD --` ; \
> do git-rev-list --header --parents --max-count=1 $r -- ; \
> done > /dev/null
>
> real 0m0.490s
> user 0m0.224s
> sys 0m0.228s
>
> time \
> git-rev-list --header --parents --max-count=100 HEAD -- > /dev/null
>
> real 0m0.058s
> user 0m0.008s
> sys 0m0.004s
>
> There would seems to be a benefit from making the proposed change to
> these workflows, when run on my machine against a clone of Linus's tree.
The problem is that it works only for "log" and "shortlog" views, but
it doesn't work for "history" view. Now both share the same infrastructure.
The problem is that when there is path limiter (be it file or directory)
the history is simplified, and parents are _rewritten_ according to
simplified history. And this happen depending on strange combination
of --header, --parents and --full-history. Should be somewhere in archives.
And we don't want to use parents from commit object, because there might
be grafts, or it might be shallow clone.
On the other hand, we don't really need parents for log, shortlog and
history...
> One issue with this change is that, gitweb is page orientated. Page 0
> shows the first 100 items from a given hash, page 1 uses the same given
> hash but show 100 to 199 items, etc. Using 'git-rev-list --header
> --parents' and then throwing away most of the result is very wasteful.
>
> So I'm suggesting we add a new option to git-rev-list which will only
> start show results once its has iterated past a given number of items.
> Using a caret or tilde doesn't seem to return the same result.
>
> I've attached a discussion patch which adds a new option --start-count
> to git-rev-list and changed the summary and showlog actions of gitweb to
> use this new option.
Very nice idea.
> I'm sure there are many improvements to this patch, comments?
Perhaps this patch should be split in two? (Usually either second mail is
reply to first mail, or both are replies to introductory letter, usually
with table of contents and diffstat of series).
[...]
Documentation (of --start-count / --skip option), please?
P.S. Thanks for the patches.
P.P.S. Do you have any comments to latest "[RFC] gitweb wishlist and TODO
list" series?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-svn: follow parent after the fact?
From: Steven Grimm @ 2006-12-19 21:36 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061219074745.GA31338@localdomain>
Eric Wong wrote:
> The final set of files at the latest (svn) revision was inconsistent?
> That should never happen... If so, I'd very much like to look into this.
>
Yes, that's right; there are about 50 files that were in the original
trunk before it was renamed but weren't in the branch that became the
new trunk. Those files are present in the git repo if I use plain
git-svn fetch, but they're not there in an svn client or in a git repo
where I've used --follow-parent.
So far I haven't been able to come up with a from-scratch test case to
demonstrate this behavior. The svn repository in question,
unfortunately, isn't a public one. I've asked the person in charge of
the repo if he remembers what exactly he did at the time of the branch
reorganization; so far every permutation I've tried in my test repo has
worked fine and not had the problem, so something odd must have happened
in that repo's history.
I'll follow up if/when I manage to get a good test case.
^ permalink raw reply
* Change in git-svn dcommit semantics?
From: Seth Falcon @ 2006-12-19 21:12 UTC (permalink / raw)
To: git; +Cc: Eric Wong
Hi Eric,
I just updated to the latest git/git-svn (on branch 'master') and the
workflow I've been using no longer seems to work:
# review the commits I'm going to send to svn
ziti:~/proj/bioc-2.0-git seth$ git log remotes/git-svn..HEAD
# now send them
ziti:~/proj/bioc-2.0-git seth$ git svn dcommit remotes/git-svn..HEAD
fatal: ambiguous argument
'refs/remotes/git-svn..remotes/git-svn..HEAD': unknown revision or
path not in the working tree. Use '--' to separate paths from
revisions 32768 at /Users/seth/scm/bin/git-svn line 2190
main::safe_qx('git-rev-list', '--no-merges', 'refs/remotes/git-svn..remotes/git-svn..HEAD') called at /Users/seth/scm/bin/git-svn line 610
main::dcommit('remotes/git-svn..HEAD') called at /Users/seth/scm/bin/git-svn line 197
At this point, my last commit seems to have been reset (although the
changes are thankfully still in my working tree). If this happens to
you, you can recover the last commit like:
git commit -a -v -c ORIG_HEAD
And it seems that the new interface requires no extra args:
git svn dcommit
The new interface seems ok until things like
git svn dcommit remotes/git-svn..HEAD~2
are allowed (if ever). But it would be nice for the failure mode to
not undo commits :-)
+ seth
git version 1.4.4.2.gee60-dirty
^ permalink raw reply
* [RFC] Possible optimization for gitweb
From: Robert Fitzsimons @ 2006-12-19 20:54 UTC (permalink / raw)
To: git
While looking at the gitweb source yesterday, I noticed a number of
similar expensive workflows used by a number of actions (summary,
shortlog, log, rss, atom, and history).
The current workflows are:
get ~100 sha1's using rev-list
foreach sha1
get/parse 1 commit using rev-list
output commit
The new workflows I'm proposing would be:
get/parse ~100 commit's using rev-list
foreach commit
output commit
The following simplified commands gives an idea of the git only overhead
between these two workflows.
time \
for r in `git-rev-list --max-count=100 HEAD --` ; \
do git-rev-list --header --parents --max-count=1 $r -- ; \
done > /dev/null
real 0m0.490s
user 0m0.224s
sys 0m0.228s
time \
git-rev-list --header --parents --max-count=100 HEAD -- > /dev/null
real 0m0.058s
user 0m0.008s
sys 0m0.004s
There would seems to be a benefit from making the proposed change to
these workflows, when run on my machine against a clone of Linus's tree.
One issue with this change is that, gitweb is page orientated. Page 0
shows the first 100 items from a given hash, page 1 uses the same given
hash but show 100 to 199 items, etc. Using 'git-rev-list --header
--parents' and then throwing away most of the result is very wasteful.
So I'm suggesting we add a new option to git-rev-list which will only
start show results once its has iterated past a given number of items.
Using a caret or tilde doesn't seem to return the same result.
I've attached a discussion patch which adds a new option --start-count
to git-rev-list and changed the summary and showlog actions of gitweb to
use this new option.
I'm sure there are many improvements to this patch, comments?
Robert
-----
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4059894..a1e0ccc 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1260,6 +1260,30 @@ sub parse_tag {
return %tag
}
+sub parse_commits {
+ my $commit_id = shift;
+ my $start_count = shift;
+ my $max_count = shift;
+
+ my @cos;
+ my @commit_lines;
+
+ local $/ = "\0";
+ open my $fd, "-|", git_cmd(), "rev-list",
+ "--header", "--parents", "--start-count=$start_count", "--max-count=$max_count",
+ $commit_id, "--"
+ or return;
+ while (my $commit = <$fd>) {
+ @commit_lines = split '\n', $commit;
+ pop @commit_lines;
+ my %co = parse_commit(undef, \@commit_lines);
+ push @cos, \%co;
+ }
+ close $fd or return;
+
+ return @cos;
+}
+
sub parse_commit {
my $commit_id = shift;
my $commit_text = shift;
@@ -2633,29 +2657,29 @@ sub git_project_list_body {
sub git_shortlog_body {
# uses global variable $project
- my ($revlist, $from, $to, $refs, $extra) = @_;
+ my ($commitlist, $from, $to, $refs, $extra) = @_;
$from = 0 unless defined $from;
- $to = $#{$revlist} if (!defined $to || $#{$revlist} < $to);
+ $to = $#{$commitlist} if (!defined $to || $#{$commitlist} < $to);
print "<table class=\"shortlog\" cellspacing=\"0\">\n";
my $alternate = 1;
for (my $i = $from; $i <= $to; $i++) {
- my $commit = $revlist->[$i];
+ my $co = $commitlist->[$i];
+ my $commit = $co->{'id'};
#my $ref = defined $refs ? format_ref_marker($refs, $commit) : '';
my $ref = format_ref_marker($refs, $commit);
- my %co = parse_commit($commit);
if ($alternate) {
print "<tr class=\"dark\">\n";
} else {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
- # git_summary() used print "<td><i>$co{'age_string'}</i></td>\n" .
- print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
+ # git_summary() used print "<td><i>$co->{'age_string'}</i></td>\n" .
+ print "<td title=\"$co->{'age_string_age'}\"><i>$co->{'age_string_date'}</i></td>\n" .
+ "<td><i>" . esc_html(chop_str($co->{'author_name'}, 10)) . "</i></td>\n" .
"<td>";
- print format_subject_html($co{'title'}, $co{'title_short'},
+ print format_subject_html($co->{'title'}, $co->{'title_short'},
href(action=>"commit", hash=>$commit), $ref);
print "</td>\n" .
"<td class=\"link\">" .
@@ -2952,13 +2976,9 @@ sub git_summary {
}
}
- open my $fd, "-|", git_cmd(), "rev-list", "--max-count=17",
- git_get_head_hash($project), "--"
- or die_error(undef, "Open git-rev-list failed");
- my @revlist = map { chomp; $_ } <$fd>;
- close $fd;
+ my @commitlist = parse_commits($head, 0, 17);
git_print_header_div('shortlog');
- git_shortlog_body(\@revlist, 0, 15, $refs,
+ git_shortlog_body(\@commitlist, 0, 15, $refs,
$cgi->a({-href => href(action=>"shortlog")}, "..."));
if (@taglist) {
@@ -4313,15 +4333,12 @@ sub git_shortlog {
}
my $refs = git_get_references();
- my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
- open my $fd, "-|", git_cmd(), "rev-list", $limit, $hash, "--"
- or die_error(undef, "Open git-rev-list failed");
- my @revlist = map { chomp; $_ } <$fd>;
- close $fd;
+ my $max_count = (100 * ($page+1));
+ my @commitlist = parse_commits($hash, (100 * $page), $max_count);
- my $paging_nav = format_paging_nav('shortlog', $hash, $head, $page, $#revlist);
+ my $paging_nav = format_paging_nav('shortlog', $hash, $head, $page, $max_count);
my $next_link = '';
- if ($#revlist >= (100 * ($page+1)-1)) {
+ if ($max_count >= 100) {
$next_link =
$cgi->a({-href => href(action=>"shortlog", hash=>$hash, page=>$page+1),
-title => "Alt-n"}, "next");
@@ -4332,7 +4349,7 @@ sub git_shortlog {
git_print_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);
git_print_header_div('summary', $project);
- git_shortlog_body(\@revlist, ($page * 100), $#revlist, $refs, $next_link);
+ git_shortlog_body(\@commitlist, 0, $#commitlist, $refs, $next_link);
git_footer_html();
}
diff --git a/list-objects.c b/list-objects.c
index f1fa21c..d96c8bf 100644
--- a/list-objects.c
+++ b/list-objects.c
@@ -108,8 +108,12 @@ void traverse_commit_list(struct rev_info *revs,
struct object_array objects = { 0, 0, NULL };
while ((commit = get_revision(revs)) != NULL) {
- process_tree(revs, commit->tree, &objects, NULL, "");
- show_commit(commit);
+ if (revs->start_count <= 0) {
+ process_tree(revs, commit->tree, &objects, NULL, "");
+ show_commit(commit);
+ } else {
+ revs->start_count--;
+ }
}
for (i = 0; i < revs->pending.nr; i++) {
struct object_array_entry *pending = revs->pending.objects + i;
diff --git a/revision.c b/revision.c
index 993bb66..3e3d929 100644
--- a/revision.c
+++ b/revision.c
@@ -524,6 +524,7 @@ void init_revisions(struct rev_info *revs, const char *prefix)
revs->prefix = prefix;
revs->max_age = -1;
revs->min_age = -1;
+ revs->start_count = -1;
revs->max_count = -1;
revs->prune_fn = NULL;
@@ -756,6 +757,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
const char *arg = argv[i];
if (*arg == '-') {
int opts;
+ if (!strncmp(arg, "--start-count=", 14)) {
+ revs->start_count = atoi(arg + 14);
+ continue;
+ }
if (!strncmp(arg, "--max-count=", 12)) {
revs->max_count = atoi(arg + 12);
continue;
diff --git a/revision.h b/revision.h
index 3adab95..c2dce8c 100644
--- a/revision.h
+++ b/revision.h
@@ -75,6 +75,7 @@ struct rev_info {
struct grep_opt *grep_filter;
/* special limits */
+ int start_count;
int max_count;
unsigned long max_age;
^ permalink raw reply related
* GIT - error: no such remote ref refs/heads/TestBranch
From: Sean Kelley @ 2006-12-19 20:33 UTC (permalink / raw)
To: git
Hi,
I was wondering if someone could help me. I had a branch on our
remote GIT server called TestBranch. I logged into the Remote server
and ran:
<from remote server>
git branch -D TestBranch
But in my local clone:
kelleys@oifig:~/Work/kernel$ git pull origin
kelleys@git.example.com's password:
error: no such remote ref refs/heads/TestBranch
Fetch failure: git+ssh://git.example.com/data/git/proj/kernel/mh.git
kelleys@oifig:~/Work/kernel$
Any ideas how to correct this?
^ permalink raw reply
* Re: [PATCH] Stop telling users we are 'defaulting to local storagearea'.
From: David Lang @ 2006-12-19 19:48 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, Junio C Hamano, git, Andy Parkins
In-Reply-To: <Pine.LNX.4.64.0612142059301.18171@xanadu.home>
On Thu, 14 Dec 2006, Nicolas Pitre wrote:
> On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
>
> [...]
>> It also breaks from our normal behavior of not printing
>> anything if the command was successful.
>
> Before everybody starts believing everybody agrees with this I'll have
> to throw a tile in the pond.
>
> I really don't think this is a good rule.
>
> NOte that I'm not against commands that are silent by default. I really
> think that git-add should remain silent on success by default when
> successful.
>
> But the rule of thumb should be about the importance of the action
> performed by the command. git-add is a less important command than
> git-init-db or git-commit _conceptually_. You can do multiple git-add
> in whatever order, even repeatedly, and it won't change the outcome.
> It is "conceptually lightweight". But git-init-db is really important.
> Without it you just can't do anything. It should give the user the
> impression that something did actually happen, especially since this is
> the git comand any new git user is most likely to use first. Saying
> back "git repository initialized" tells the user "OK you can start now".
> Saying nothing might just leave the user wondering if everything is
> actually fine.
how about makeing it silent on sucess unless the output is a tty? that way you
don't mess up scripts with the 'it worked' message and you still reassure the
user that something actually happened.
David Lang
^ permalink raw reply
* Re: [PATCH] index-pack usage of mmap() is unacceptably slower on many OSes other than Linux
From: Randal L. Schwartz @ 2006-12-19 20:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <86hcvr4q13.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> I can't remember now, but a couple of patches I had to submit were
Randal> because sys/types.h was included either too early or too late on OSX,
Randal> so let's be sure to get that right. Surely, my patch can be observed
Randal> somewhere, perhaps in a git repository. :)
Here's one that might be relevant for OSX:
979e32fa1483a32faa4ec331e29b357e5eb5ef25
And this is an ordering issue for OpenBSD:
ed1795fcc5f2aa3f105630429bcbed49c50053fa
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: [PATCH] index-pack usage of mmap() is unacceptably slower on many OSes other than Linux
From: Jeff Garzik @ 2006-12-19 20:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612191148270.3483@woody.osdl.org>
Linus Torvalds wrote:
> diff --git a/convert-objects.c b/convert-objects.c
> index 8812583..a630132 100644
> --- a/convert-objects.c
> +++ b/convert-objects.c
> @@ -1,7 +1,3 @@
> -#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
> -#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
> -#define _GNU_SOURCE
> -#include <time.h>
> #include "cache.h"
> #include "blob.h"
> #include "commit.h"
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 0272d04..e619e29 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -11,6 +11,10 @@
>
> #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
>
> +#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
> +#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
> +#define _GNU_SOURCE
> +
> #include <unistd.h>
> #include <stdio.h>
> #include <sys/stat.h>
> @@ -25,6 +29,10 @@
> #include <netinet/in.h>
> #include <sys/types.h>
> #include <dirent.h>
> +#include <sys/time.h>
> +#include <time.h>
> +#include <signal.h>
> +#include <sys/wait.h>
If you are going to do this, you have to audit -every- file, to make
sure git-compat-util.h is -always- the first header.
For example, builtin-mailinfo.c includes git-compat-util.h after ctype.h
and iconv.h, which renders your #define _XOPEN_SOURCE 600 useless.
/usr/include/features.h has already been included at that point.
Jeff
^ permalink raw reply
* Re: [PATCH] index-pack usage of mmap() is unacceptably slower on many OSes other than Linux
From: Randal L. Schwartz @ 2006-12-19 19:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0612191148270.3483@woody.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> May I actually suggest we handle _all_ of these issues in one central
Linus> place, namely "git-compat-util.h"
I can't remember now, but a couple of patches I had to submit were because
sys/types.h was included either too early or too late on OSX, so let's be sure
to get that right. Surely, my patch can be observed somewhere, perhaps in a
git repository. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: [PATCH] index-pack usage of mmap() is unacceptably slower on many OSes other than Linux
From: Linus Torvalds @ 2006-12-19 19:55 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612191409500.18171@xanadu.home>
On Tue, 19 Dec 2006, Nicolas Pitre wrote:
>
> Because _XOPEN_SOURCE must be defined before including unistd.h
> otherwise pread is not declared and a warning is issued.
May I actually suggest we handle _all_ of these issues in one central
place, namely "git-compat-util.h"
It's nice to have just one single file that tries to hide the details of
all the differences between systems.
Sure, that file ends up having to include a lot of standard header files
that some of the .c files don't actually _need_, but git compiles
reasonably quickly, so I don't think we need to try to optimize compile
speed much.
It's the C++ people who tend to have sucky compile times.
So how about something like the appended? And then just have the rule that
we try to include "cache.h" early, because that brings in ALL the really
basic system header files?
Linus
---
diff --git a/convert-objects.c b/convert-objects.c
index 8812583..a630132 100644
--- a/convert-objects.c
+++ b/convert-objects.c
@@ -1,7 +1,3 @@
-#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
-#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
-#define _GNU_SOURCE
-#include <time.h>
#include "cache.h"
#include "blob.h"
#include "commit.h"
diff --git a/git-compat-util.h b/git-compat-util.h
index 0272d04..e619e29 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -11,6 +11,10 @@
#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
+#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
+#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
+#define _GNU_SOURCE
+
#include <unistd.h>
#include <stdio.h>
#include <sys/stat.h>
@@ -25,6 +29,10 @@
#include <netinet/in.h>
#include <sys/types.h>
#include <dirent.h>
+#include <sys/time.h>
+#include <time.h>
+#include <signal.h>
+#include <sys/wait.h>
/* On most systems <limits.h> would have given us this, but
^ permalink raw reply related
* Re: StGit repo & gitweb, was Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Jakub Narebski @ 2006-12-19 19:39 UTC (permalink / raw)
To: git
In-Reply-To: <20061219185015.GK9399@pasky.or.cz>
Petr Baudis wrote:
> On Wed, Dec 13, 2006 at 12:46:56PM CET, Johannes Schindelin wrote:
>> Not that it matters: repo.or.cz has a nice mirror. Pasky, how powerful is
>> that machine? I am a happy user of the gitweb interface on that box...
>
> See http://repo.or.cz/about.html - two-processor P3 800MHz with 2G RAM,
> and it does quite some work besides doing repo.or.cz as well - there are
> no load problems so far, though. The gitweb load in particular is pretty
> low, though - I think it's about 350 requests per day; the periodical
> mirroring is far more intensive, but the intervals for this could be
> reduced greatly if that would become a problem.
Do you do "git repack -a -d" (and "git prune-packed"), or do you use
some kept packs?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] index-pack usage of mmap() is unacceptably slower on many OSes other than Linux
From: Nicolas Pitre @ 2006-12-19 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Randal L. Schwartz, git
In-Reply-To: <7vk60npv7x.fsf@assigned-by-dhcp.cox.net>
On Tue, 19 Dec 2006, Junio C Hamano wrote:
> > diff --git a/index-pack.c b/index-pack.c
> > index 6d6c92b..e08a687 100644
> > --- a/index-pack.c
> > +++ b/index-pack.c
> > @@ -1,3 +1,8 @@
> > +#define _XOPEN_SOURCE 500
> > +#include <unistd.h>
> > +#include <sys/time.h>
> > +#include <signal.h>
> > +
> > #include "cache.h"
> > #include "delta.h"
> > #include "pack.h"
> > @@ -6,8 +11,6 @@
> > #include "commit.h"
> > #include "tag.h"
> > #include "tree.h"
> > -#include <sys/time.h>
> > -#include <signal.h>
>
> Most of the rest of the sources seem to do our includes first
> and source-file specific system includes at the end. What's the
> rationale for this change?
Because _XOPEN_SOURCE must be defined before including unistd.h
otherwise pread is not declared and a warning is issued.
> Do we need _XOPEN_SOURCE=500 because pread() is XSI?
The pread man page says Unix98.
> Also nobody other than convert-objects.c has _XOPEN_SOURCE level
> specified. If _XOPEN_SOURCE matters I wonder if we should do so
> in some central place to make it consistent across source files?
Your call I guess.
^ permalink raw reply
* Re: [PATCH] Enter interactive mode if no parameters are given to git-add
From: Linus Torvalds @ 2006-12-19 19:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vy7p3pxyr.fsf@assigned-by-dhcp.cox.net>
On Tue, 19 Dec 2006, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
>
> > git-add with no parameters previously adds every modified file. This
> > patch instead makes git-add enter interactive mode.
> > ...
> > It seemed a bit nasty to add content without explicit instructions to do
> > so.
>
> Does anybody rely on the current behaviour?
I don't know about "rely", but yes, it's what I normally do. When I import
a tar-ball, I'll just do
..untar..
cd result-x.y.z
git init-db
git add
git commit
and I don't usually use the "." at all, since it's unnecessary.
But hey, if it enters some interactive mode, maybe I can teach myself to
either just do "git add .", or if the interactive mode has a choice of "a"
for "all", then why not?
> While I think nobody should drive 'git add' from script, the
> behaviour to add everything when there is no explicit parameter
> (or fall back to interactive for that matter) has a problem if
> you say "some command | xargs git-add --" (you need "xargs -r"
> to fix it, which is GNU).
That's a really good argument against the current behaviour of "git add",
so while I actually use it without any parameters, I will concur that we
should probably change it.
^ 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