* Re: [PATCH 5/5] git-add: add ignored files when asked explicitly.
From: Nicolas Pitre @ 2006-12-25 19:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vslf3khsc.fsf@assigned-by-dhcp.cox.net>
On Mon, 25 Dec 2006, Junio C Hamano wrote:
> An alternative is to use the mechanism I added here to _detect_
> the attempt to add an ignored file with explicitly spelled out
> pathspec, and issue an info message that says something like:
>
> Path 'xyzzy/filfre.o' is not being ignored by one of
> your .gitignore files. If you really want to add it,
> please add this entry to .gitignore file:
>
> !/xyzzy/filfre.o
What about this instead:
Path 'xyzzy/filfre.o' should be ignored according to one of
your .gitignore files. If you really want to add it, you must
use the -f flag.
Nicolas
^ permalink raw reply
* merry gitmas
From: Nicolas Pitre @ 2006-12-25 21:01 UTC (permalink / raw)
To: git
Happy holidays to all, and here's a bit of nice programming style to
inspire you for your git hacking during the Christmas season (yes that
really compiles and runs):
----- >8
#include <stdio.h>
main(t,_,a)
char *a;
{
return!0<t?t<3?main(-79,-13,a+main(-87,1-_,main(-86,0,a+1)+a)):
1,t<_?main(t+1,_,a):3,main(-94,-27+t,a)&&t==2?_<13?
main(2,_+1,"%s %d %d\n"):9:16:t<0?t<-72?main(_,t,
"@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l+,/n{n+,/+#n+,/#\
;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l \
q#'+d'K#!/+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# \
){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#n'wk nw' \
iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c \
;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'{n' \
')# \
}'+}##(!!/")
:t<-50?_==*a?putchar(31[a]):main(-65,_,a+1):main((*a=='/')+t,_,a+1)
:0<t?main(2,2,"%s"):*a=='/'||main(0,main(-61,*a,
"!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry"),a+1);
}
^ permalink raw reply
* Re: cgit vs. gitweb
From: Jakub Narebski @ 2006-12-25 22:19 UTC (permalink / raw)
To: git
In-Reply-To: <8c5c35580612250921o765e141cq27f81b06364d0a4@mail.gmail.com>
[Cc: git@vger.kernel.org]
Lars Hjemli wrote:
> I wanted to compare cgit against gitweb to see the effect of using
> libgit and internal caching. So I ran the attached scripts against
> http://hjemli.net/git/ and http://hjemli.net/cgi-bin/gitweb.cgi as a
> very simplistic benchmark.
First, could you try this also with mod_perl, not only CGI?
> The scripts forks a number of similar child processes (specified by
> $1) and then uses curl(1) to request the first log page of three
> repositories $2 times. This is an attempt to simulate concurrent
> requests for different pages/repositories (I chose the log-pages since
> they're pretty similar in cgit and gitweb, both showing info for 100
> commits).
Could you include ApacheBench (ab) results?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-add: warn when adding an ignored file with an explicit request.
From: Jakub Narebski @ 2006-12-25 22:24 UTC (permalink / raw)
To: git
In-Reply-To: <7vodprizuw.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> We allow otherwise ignored paths to be added to the index by
> spelling its path out on the command line, but we would warn the
> user about them when we do so.
I'm for warning user that the file to be added is ignored file and
telling how to make an exception in .gitignore _AND_ that -f option
can be used to bypass that check. And adding ignored path as above
with -f option.
But otherwise: nice series of patches.
P.S. Were all the patches sent as replies to introductory letter?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/8] gitweb: We do longer need the --parents flag in rev-list.
From: Jakub Narebski @ 2006-12-25 22:49 UTC (permalink / raw)
To: git
In-Reply-To: <11669707094097-git-send-email-robfitz@273k.net>
Robert Fitzsimons wrote:
> We only want to know the direct parents of a given commit object,
> these parents are available in the --header output of rev-list. If
> --parents is supplied with --full-history the output includes merge
> commits that aren't relevant.
Actually --header output gives us original parents. Rewritten parents
(available with --parents) include also grafts and shallow clone grafts.
For parse_commit we want --parents, for parse_commits we don't want it
because --parents affects --full-history.
The problem is that we cannot detect if git-rev-list was called with
--parents and commit is root commit (parentless), or we didn't use
--parents option.
In few other places we pass options specifying subroutine behavior
as hash after all other requred parameters, e.g.
esc_html($line, -nbsp=>1),
parse_ls_tree_line($line, -z=>1),
git_print_log($co{'comment'}, -final_empty_line=> 1, -remove_title => 1);
In this case it wouldn't work (unless we pass reference to array,
via parse_commit_text( [ <$fd> ], -parents=>1);
Perhaps it would be better to use reference to hash of options as _first_
parameter, e.g. parse_commit_text({-parents=>1}, <$fd>);, and use something
like if (ref($[0]) == 'HASH') { $opts = shift @_; } to get options.
So for now gitweb might not show what we want in very rare cases of
repositories with grafts or shallow clones.
But apart from this small matter, this series is excellent work. Thanks!
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] commit encoding: store it in commit header rather than mucking with NUL
From: Jakub Narebski @ 2006-12-25 22:54 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6uoo2ow.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I was afraid that there might be something we did (or we did not
> do) that encouraged people to have their names (via environment
> variables, or perhaps user.name) always in UTF-8 while recording
> the log messages in the legacy encoding, and if that kind of use
> is already done in the wild, we would end up having to not
> reencode the header field but reencode the body.
>
> But I do not think we ever encouraged encoding names in UTF-8 or
> anything else (we did encourage use of UTF-8 in the commit log),
> so I think we are Ok.
By the way, it would be nice to have .mailmap like mechanism to tell git
that those two (three or more) names are the same comitter and should be
shown (at least in git-shortlog) as this. This is because some people
changed their email, some people have sometimes middle initial and
sometimes not, some people have name outside US-ASCII and it is sometimes
broken...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: cgit vs. gitweb
From: Lars Hjemli @ 2006-12-26 0:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List
In-Reply-To: <empikd$s32$1@sea.gmane.org>
On 12/25/06, Jakub Narebski <jnareb@gmail.com> wrote:
> [Cc: git@vger.kernel.org]
>
> Lars Hjemli wrote:
>
> > I wanted to compare cgit against gitweb to see the effect of using
> > libgit and internal caching. So I ran the attached scripts against
> > http://hjemli.net/git/ and http://hjemli.net/cgi-bin/gitweb.cgi as a
> > very simplistic benchmark.
>
> First, could you try this also with mod_perl, not only CGI?
Well, not easily I'm afraid: I'm running slackware 11 w. apache
1.3.37, w.o. mod_perl, and when trying to install mod_perl tonight I
ended up w.o. a working httpd :-(
But I guess someone who has tested gitweb w. and w.o. mod_perl could
come up with an estimate on the difference between them?
> Could you include ApacheBench (ab) results?
Sure (I didn't know about this tool, thanks for the pointer)
Here's the result of a few requests:
$ ab -n 1000 -c 1 http://box1/git/cgit/log/?h=master
This is ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3
[...snip...]
Document Path: /git/cgit/log/?h=master
Document Length: 9373 bytes
Concurrency Level: 1
Time taken for tests: 5.788 seconds
Complete requests: 1000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 9604000 bytes
HTML transferred: 9373000 bytes
Requests per second: 172.77 [#/sec] (mean)
Time per request: 5.79 [ms] (mean)
Time per request: 5.79 [ms] (mean, across all concurrent requests)
Transfer rate: 1659.30 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 3 5 19.0 3 206
Waiting: 3 5 19.0 3 206
Total: 3 5 19.0 3 206
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 4
95% 4
98% 4
99% 4
100% 206 (last request)
$ ab -n 1000 -c 10 http://box1/git/cgit/log/?h=master
[..snip..]
Concurrency Level: 10
Time taken for tests: 3.421 seconds
Complete requests: 1000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 9604000 bytes
HTML transferred: 9373000 bytes
Requests per second: 292.31 [#/sec] (mean)
Time per request: 34.21 [ms] (mean)
Time per request: 3.42 [ms] (mean, across all concurrent requests)
Transfer rate: 2807.37 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 1
Processing: 3 31 98.8 13 1037
Waiting: 3 31 98.8 13 1037
Total: 3 31 98.8 13 1037
ERROR: The median and mean for the initial connection time are more
than twice the standard
deviation apart. These results are NOT reliable.
Percentage of the requests served within a certain time (ms)
50% 13
66% 16
75% 17
80% 20
90% 27
95% 61
98% 335
99% 665
100% 1037 (last request)
$ ab -n 1000 -c 100 http://box1/git/cgit/log/?h=master
[..snip..]Concurrency Level: 100
Time taken for tests: 3.450 seconds
Complete requests: 1000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 9612547 bytes
HTML transferred: 9381316 bytes
Requests per second: 289.86 [#/sec] (mean)
Time per request: 345.00 [ms] (mean)
Time per request: 3.45 [ms] (mean, across all concurrent requests)
Transfer rate: 2786.25 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 3
Processing: 9 322 143.8 311 1780
Waiting: 6 322 143.8 311 1780
Total: 9 322 143.6 311 1780
Percentage of the requests served within a certain time (ms)
50% 311
66% 316
75% 321
80% 323
90% 334
95% 383
98% 737
99% 1146
100% 1780 (last request)
$ ab -n 100 -c 1 http://box1/cgi-bin/gitweb.cgi?p=cgit;a=shortlog
[...snip...]
Document Path: /cgi-bin/gitweb.cgi?p=cgit
Document Length: 16636 bytes
Concurrency Level: 1
Time taken for tests: 21.908 seconds
Complete requests: 100
Failed requests: 0
Broken pipe errors: 0
Total transferred: 1678100 bytes
HTML transferred: 1663600 bytes
Requests per second: 4.56 [#/sec] (mean)
Time per request: 219.08 [ms] (mean)
Time per request: 219.08 [ms] (mean, across all concurrent requests)
Transfer rate: 76.60 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 216 219 1.0 219 222
Waiting: 216 219 0.9 219 221
Total: 216 219 1.0 219 222
Percentage of the requests served within a certain time (ms)
50% 219
66% 219
75% 220
80% 220
90% 221
95% 221
98% 221
99% 222
100% 222 (last request)
$ ab -n 100 -c 10 http://box1/cgi-bin/gitweb.cgi?p=cgit;a=shortlog
[...snip...]
Concurrency Level: 10
Time taken for tests: 23.480 seconds
Complete requests: 100
Failed requests: 0
Broken pipe errors: 0
Total transferred: 1744006 bytes
HTML transferred: 1728636 bytes
Requests per second: 4.26 [#/sec] (mean)
Time per request: 2348.00 [ms] (mean)
Time per request: 234.80 [ms] (mean, across all concurrent requests)
Transfer rate: 74.28 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 216 2244 897.8 2044 4905
Waiting: 216 2244 897.8 2043 4905
Total: 216 2244 897.8 2044 4905
Percentage of the requests served within a certain time (ms)
50% 2044
66% 2566
75% 3008
80% 3119
90% 3487
95% 3591
98% 4094
99% 4171
100% 4905 (last request)
$ ab -n 100 -c 50 http://box1/cgi-bin/gitweb.cgi?p=cgit;a=shortlog
[...snip...]
Concurrency Level: 50
Time taken for tests: 29.552 seconds
Complete requests: 100
Failed requests: 0
Broken pipe errors: 0
Total transferred: 1978127 bytes
HTML transferred: 1958697 bytes
Requests per second: 3.38 [#/sec] (mean)
Time per request: 14776.00 [ms] (mean)
Time per request: 295.52 [ms] (mean, across all concurrent requests)
Transfer rate: 66.94 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.0 1 1
Processing: 221 11464 5725.4 11769 22556
Waiting: 221 11464 5725.5 11769 22556
Total: 221 11465 5725.6 11770 22557
ERROR: The median and mean for the initial connection time are more
than twice the standard
deviation apart. These results are NOT reliable.
Percentage of the requests served within a certain time (ms)
50% 11770
66% 14899
75% 16229
80% 16535
90% 19184
95% 20065
98% 22227
99% 22397
100% 22557 (last request)
This does seem to confirm the results of my homemade scripts.
--
larsh
^ permalink raw reply
* Re: cgit vs. gitweb
From: Jakub Narebski @ 2006-12-26 0:32 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Git Mailing List
In-Reply-To: <8c5c35580612251604s5e211518yd958fdc2e73232ef@mail.gmail.com>
Lars Hjemli wrote:
> On 12/25/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Lars Hjemli wrote:
>>
>>> I wanted to compare cgit against gitweb to see the effect of using
>>> libgit and internal caching. So I ran the attached scripts against
>>> http://hjemli.net/git/ and http://hjemli.net/cgi-bin/gitweb.cgi as a
>>> very simplistic benchmark.
[...]
>> Could you include ApacheBench (ab) results?
>
> Sure (I didn't know about this tool, thanks for the pointer)
>
> Here's the result of a few requests:
[snip]
> This does seem to confirm the results of my homemade scripts.
By the way, which version of gitweb did you use (shortened sha1 of
commit, or result of git-describe)? I'm interested if it is before
or after Robert Fitzsimons patches which replaced 101 forks in
log-like views with 1 fork, which I think affects gitweb performance
a lot.
The page which is optimized is summary view, if you use projects_list
and not projectroot directory...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: cgit vs. gitweb
From: Robert Fitzsimons @ 2006-12-26 0:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Lars Hjemli, Git Mailing List
In-Reply-To: <200612260132.41062.jnareb@gmail.com>
> By the way, which version of gitweb did you use (shortened sha1 of
> commit, or result of git-describe)? I'm interested if it is before
> or after Robert Fitzsimons patches which replaced 101 forks in
> log-like views with 1 fork, which I think affects gitweb performance
> a lot.
Here are the numbers for a few tests I ran yesterday, this is with
gitweb without mod_perl.
v267, 1842 38.5 +/- ms (with v1.4.4.3 git tools)
v1.4.4.3, 445 2.5 +/- ms
master, 445 2.5 +/- ms
master + bulk patches, 340 3.7 +/- ms (--skip patch)
(/usr/sbin/ab -n 20 -k "http://localhost/git/?p=home/bob/src/git/git/.git;a=summary")
Robert
^ permalink raw reply
* Re: cgit vs. gitweb
From: Lars Hjemli @ 2006-12-26 0:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List
In-Reply-To: <200612260132.41062.jnareb@gmail.com>
On 12/26/06, Jakub Narebski <jnareb@gmail.com> wrote:
> By the way, which version of gitweb did you use (shortened sha1 of
> commit, or result of git-describe)?
Results from ab used gitweb/1.4.4.3.gd4ada (pulled tonight), but my
homemade scripts used c902c9a6 (from dec 21)
> I'm interested if it is before
> or after Robert Fitzsimons patches which replaced 101 forks in
> log-like views with 1 fork, which I think affects gitweb performance
> a lot.
ab is after the patches, my homemade scripts was before
> The page which is optimized is summary view, if you use projects_list
> and not projectroot directory...
I tested 'a=shortlog', since it seems to be functionally equivalent to
cgits log view.
--
larsh
^ permalink raw reply
* private file add/checkout
From: SungHyun Nam @ 2006-12-26 2:00 UTC (permalink / raw)
To: GIT
Hello,
Though I set 'shared=false' or umask=0077,
I cannot add a file with mode=0600.
GIT always added it as mode=0644.
How I can add/checkout a file with mode=0600?
Is it impossible?
Thanks,
namsh
^ permalink raw reply
* Re: private file add/checkout
From: Junio C Hamano @ 2006-12-26 2:16 UTC (permalink / raw)
To: SungHyun Nam; +Cc: git
In-Reply-To: <4590822C.3070206@gmail.com>
SungHyun Nam <goweol@gmail.com> writes:
> Though I set 'shared=false' or umask=0077,
> I cannot add a file with mode=0600.
> GIT always added it as mode=0644.
> How I can add/checkout a file with mode=0600?
> Is it impossible?
Git is about source code control and uses file mode only for
executable bits.
^ permalink raw reply
* What's in git.git (stable) and announcing GIT 1.5.0 preview
From: Junio C Hamano @ 2006-12-26 3:22 UTC (permalink / raw)
To: git; +Cc: linux-kernel
GIT v1.5.0 preview
This is not yet -rc1 where all new topics close, but I think it
is getting pretty closer. I'd still want to merge updates to
fsck/prune to honor reflog entries before -rc1.
I think there are quite a lot of documentation updates remaining
after that. There is no patch for "fixed HEAD" yet, and while I
would not object people to try to get it working in time, it is
purely a feature enhancement and does not have backward
compatibility issues, so it does not have to block v1.5.0; it
can wait for later releases. So is sliding mmap().
* The 'master' branch has these since the last announcement.
Alexandre Julliard (1):
vc-git: Ignore errors caused by a non-existent directory
in vc-git-registered.
Brian Gernhardt (2):
Keep "git --git-dir" from causing a bus error.
Make git-show-branch options similar to git-branch.
Eric Wong (3):
Remove NO_ACCURATE_DIFF options from build systems
git-svn: enable common fetch/commit options for dcommit
Makefile: add quick-install-doc for installing pre-built manpages
Johannes Schindelin (4):
move read_mmfile() into xdiff-interface
Add a test for git-rerere
Make git-rerere a builtin
commit-tree: encourage UTF-8 commit messages.
Junio C Hamano (19):
git-add --interactive
git-add --interactive: hunk splitting
revision: --skip=<n>
merge and reset: adjust for "reset --hard" messages
default pull: forget about "newbie protection" for now.
Do not support "partial URL shorthand" anymore.
Really fix headers for __FreeBSD__
git-tag: lose exit after die
Allow branch.*.merge to talk about remote tracking branches.
git-add --interactive: add documentation
match_pathspec() -- return how well the spec matched
git-rm: update to saner semantics
t3600: update the test for updated git rm
git-rm: Documentation
read_directory: show_both option.
git-add: add ignored files when asked explicitly.
git-add: warn when adding an ignored file with an explicit request.
git-add -f: allow adding otherwise ignored files.
GIT v1.5.0 preview
Nicolas Pitre (1):
checkout: make the message about the need for a new branch a bit clearer
Robert Fitzsimons (16):
gitweb: Add missing show '...' links change.
gitweb: optimize git_get_last_activity.
gitweb: optimize git_shortlog_body.
gitweb: optimize git_summary.
gitweb: Use rev-list pattern search options.
gitweb: Require a minimum of two character for the search text.
gitweb: Allow search to be disabled from the config file.
gitweb: Paginate commit/author/committer search output
gitweb: Add parse_commits, used to bulk load commit objects.
gitweb: We do longer need the --parents flag in rev-list.
gitweb: Change summary, shortlog actions to use parse_commits.
gitweb: Change log action to use parse_commits.
gitweb: Change header search action to use parse_commits.
gitweb: Change atom, rss actions to use parse_commits.
gitweb: Change history action to use parse_commits.
gitweb: Use rev-list --skip option.
Shawn Pearce (4):
Use extended SHA1 syntax in merge-recursive conflicts.
Display 'theirs' branch name when possible in merge.
Rename gitfakemmap to git_mmap.
Switch git_mmap to use pread.
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2006-12-26 3:25 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* jc/fsck-reflog (Fri Dec 22 23:42:30 2006 -0800) 9 commits
+ reflog expire: do not punt on tags that point at non commits.
+ reflog expire: prune commits that are not incomplete
+ Don't crash during repack of a reflog with pruned commits.
+ git reflog expire
+ Move in_merge_bases() to commit.c
+ reflog: fix warning message.
+ Teach git-repack to preserve objects referred to by reflog
entries.
+ Protect commits recorded in reflog from pruning.
+ add for_each_reflog_ent() iterator
I'd like to push this out before we go -rc1, since the reflogs
are now enabled by default, and otherwise would grow unbounded.
* jc/utf8 (Mon Dec 25 11:48:35 2006 -0800) 3 commits
- Teach log family --encoding
- i18n.logToUTF8: convert commit log message to UTF-8
- Move encoding conversion routine out of mailinfo to utf8.c
This allows repositories to have commit messages in "wrong"
encodings, and converts them to UTF-8 upon "git log" output. I
think it is much nicer solution than insisting the commit log
message to always be in UTF-8, especially with automated
conversion when making a commit. If the conversion is botched
(or involves non-reversible conversion) at commit time, the
information is lost forever, but even if the conversion at the
output time fails or loses information, the log message can be
recovered in the original encoding, and conversion can later be
fixed/improved.
This is not a must-have for v1.5.0, but I feel it would be
better to push it out as it can introduce slight backward
incompatibility to people's scripts, if they are expecting to
get messages in original encodings. If we are going to break
them, we would be better off breaking them at a major revision
boundary than later.
* sp/mmap (Sun Dec 24 00:47:23 2006 -0500) 20 commits
- Replace mmap with xmmap, better handling MAP_FAILED.
- Release pack windows before reporting out of memory.
- Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
- Test suite for sliding window mmap implementation.
- Create pack_report() as a debugging aid.
- Support unmapping windows on 'temporary' packfiles.
- Improve error message when packfile mmap fails.
- Ensure core.packedGitWindowSize cannot be less than 2 pages.
- Load core configuration in git-verify-pack.
- Fully activate the sliding window pack access.
- Unmap individual windows rather than entire files.
- Document why header parsing won't exceed a window.
- Loop over pack_windows when inflating/accessing data.
- Replace use_packed_git with window cursors.
- Refactor how we open pack files to prepare for multiple windows.
- Create read_or_die utility routine.
- Use off_t for index and pack file lengths.
- Refactor packed_git to prepare for sliding mmap windows.
- Introduce new config option for mmap limit.
- Replace unpack_entry_gently with unpack_entry.
I wanted to have this in 'next' but it appears that this makes
git-push with a non-trivial amount of data to fail. v1.5.0 does
not have to wait for this because this should not change any UI.
All the rest are post v1.5.0; some of them will never be merged.
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
+ git-merge: preserve and merge local changes when doing fast
forward
* js/shallow (Fri Nov 24 16:00:13 2006 +0100) 15 commits
+ fetch-pack: Do not fetch tags for shallow clones.
+ get_shallow_commits: Avoid memory leak if a commit has been
reached already.
+ git-fetch: Reset shallow_depth before auto-following tags.
+ upload-pack: Check for NOT_SHALLOW flag before sending a shallow
to the client.
+ fetch-pack: Properly remove the shallow file when it becomes
empty.
+ shallow clone: unparse and reparse an unshallowed commit
+ Why didn't we mark want_obj as ~UNINTERESTING in the old code?
+ Why does it mean we do not have to register shallow if we have
one?
+ We should make sure that the protocol is still extensible.
+ add tests for shallow stuff
+ Shallow clone: do not ignore shallowness when following tags
+ allow deepening of a shallow repository
+ allow cloning a repository "shallowly"
+ support fetching into a shallow repository
+ upload-pack: no longer call rev-list
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
+ git-diff/git-apply: make diff output a bit friendlier to GNU patch
(part 2)
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
- git-explain
* jn/web (Sat Dec 16 17:12:55 2006 +0100) 1 commit
- gitweb: Add some mod_perl specific support
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
- gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
- blame: --show-stats for easier optimization work.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Shawn Pearce @ 2006-12-26 4:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz5bfidj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> * sp/mmap (Sun Dec 24 00:47:23 2006 -0500) 20 commits
>
> I wanted to have this in 'next' but it appears that this makes
> git-push with a non-trivial amount of data to fail. v1.5.0 does
> not have to wait for this because this should not change any UI.
Really? Not good. Do you have some sort of test case that has
caused this? I'll try to reproduce it here on my own.
--
Shawn.
^ permalink raw reply
* [PATCH] add .mailmap for git-shortlog output with the git repository
From: Nicolas Pitre @ 2006-12-26 4:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1711 bytes --]
The git repository itself was messed up in a couple cases.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/.mailmap b/.mailmap
new file mode 100644
index 0000000..2c658f4
--- /dev/null
+++ b/.mailmap
@@ -0,0 +1,37 @@
+#
+# This list is used by git-shortlog to fix a few botched name translations
+# in the git archive, either because the author's full name was messed up
+# and/or not always written the same way, making contributions from the
+# same person appearing not to be so.
+#
+
+Aneesh Kumar K.V <aneesh.kumar@gmail.com>
+Chris Shoemaker <c.shoemaker@cox.net>
+Daniel Barkalow <barkalow@iabervon.org>
+David Kågedal <davidk@lysator.liu.se>
+Fredrik Kuivinen <freku045@student.liu.se>
+H. Peter Anvin <hpa@bonde.sc.orionmulti.com>
+H. Peter Anvin <hpa@tazenda.sc.orionmulti.com>
+H. Peter Anvin <hpa@trantor.hos.anvin.org>
+Horst H. von Brand <vonbrand@inf.utfsm.cl>
+Joachim Berdal Haga <cjhaga@fys.uio.no>
+Jon Loeliger <jdl@freescale.com>
+Jon Seymour <jon@blackcubes.dyndns.org>
+Karl Hasselström <kha@treskal.com>
+Kent Engstrom <kent@lysator.liu.se>
+Lars Doelle <lars.doelle@on-line.de>
+Lars Doelle <lars.doelle@on-line ! de>
+Lukas Sandström <lukass@etek.chalmers.se>
+Martin Langhoff <martin@catalyst.net.nz>
+Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
+Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
+René Scharfe <rene.scharfe@lsrfire.ath.cx>
+Robert Fitzsimons <robfitz@273k.net>
+Santi Béjar <sbejar@gmail.com>
+Sean Estabrooks <seanlkml@sympatico.ca>
+Shawn O. Pearce <spearce@spearce.org>
+Tony Luck <tony.luck@intel.com>
+Ville Skyttä <scop@xemacs.org>
+YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
+anonymous <linux@horizon.com>
+anonymous <linux@horizon.net>
^ permalink raw reply related
* [PATCH] Cleanup read_cache_from error handling.
From: Shawn O. Pearce @ 2006-12-26 4:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When I converted the mmap() call to xmmap() I failed to cleanup the
way this routine handles errors and left some crufty code behind.
This is a small cleanup, suggested by Johannes.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This is on top of my sp/mmap topic.
read-cache.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index ca3efbb..29cf9ab 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -793,16 +793,16 @@ int read_cache_from(const char *path)
die("index file open failed (%s)", strerror(errno));
}
- cache_mmap = MAP_FAILED;
if (!fstat(fd, &st)) {
cache_mmap_size = st.st_size;
errno = EINVAL;
if (cache_mmap_size >= sizeof(struct cache_header) + 20)
cache_mmap = xmmap(NULL, cache_mmap_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
- }
+ else
+ die("index file smaller than expected");
+ } else
+ die("cannot stat the open index (%s)", strerror(errno));
close(fd);
- if (cache_mmap == MAP_FAILED)
- die("index file mmap failed (%s)", strerror(errno));
hdr = cache_mmap;
if (verify_hdr(hdr, cache_mmap_size) < 0)
--
1.4.4.3.gd2e4
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Shawn Pearce @ 2006-12-26 4:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20061226042110.GA28084@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> > * sp/mmap (Sun Dec 24 00:47:23 2006 -0500) 20 commits
> >
> > I wanted to have this in 'next' but it appears that this makes
> > git-push with a non-trivial amount of data to fail. v1.5.0 does
> > not have to wait for this because this should not change any UI.
>
> Really? Not good. Do you have some sort of test case that has
> caused this? I'll try to reproduce it here on my own.
I've pushed all of git.git into an empty repository, and then
pushed another 1639 objects on top of that, without any errors.
So I can't seem to reproduce the problem here in my Mac OS X system.
BTW, I do agree that sp/mmap should not be in v1.5.0.
--
Shawn.
^ permalink raw reply
* Re: [RFC] git reflog show
From: Shawn Pearce @ 2006-12-26 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vwt4fj1cs.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> A sensible way to reuse existing code to implement Shawn's one
> is to add the revisions to rev.pending, and iterate over that
> array like "git show" does. This does not need to touch the
> existing revision walking code at all. The most valuable parts
> of the revision walking code are about ancestry traversal and
> history simplification with pathspec, neither of which makes
> much sense to use when "walking" reflog. Reflog walking might
> want to use the filtering by commit_match() but then it is only
> the matter of renaming the function to a bit more specific name
> and exporting it.
>
> You can largely reuse the display side of the code that way, and
> I think you should be able to hook into the code without making
> it too specific to the reflog (perhaps using object->util and/or
> a callback) if you need to give extra information (e.g. comments
> and commit information from the log).
So what you are proposing is to make the reflog visible in 'git log'
by a new option? Or to just try to reuse all of its display code
but keep the reflog under 'git reflog show' ?
--
Shawn.
^ permalink raw reply
* Re: [RFC] git reflog show
From: Junio C Hamano @ 2006-12-26 6:14 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <20061226054815.GC28084@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> So what you are proposing is to make the reflog visible in 'git log'
> by a new option? Or to just try to reuse all of its display code
> but keep the reflog under 'git reflog show' ?
I am not specifically proposing anything, but the part you
quoted is about the latter.
What Johannes brought up would involve hooking into the usual
log walking machinery to show the commits in "merge order" (more
precisely, "local appearance order"). I do not think it is
about "showing the reflog data", but about using reflog data to
give a different presentation order to the usual log output.
Your "reflog show" is more about showing what are recorded in
the reflog.
It is not like implementing the sorting of the logs in local
appearance order would make your "reflog show" redundant or
useless; both are independently useful, I think.
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Jeff King @ 2006-12-26 7:33 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0612241544250.18171@xanadu.home>
On Sun, Dec 24, 2006 at 03:49:50PM -0500, Nicolas Pitre wrote:
> What would be nice as well is to be able to provide only the _name_ of
> the tracking branch without the refs/remotes/$origin/ prefix. Since
> there is already a 'branch."blah".remote = $origin' entry, then having
> 'branch."blah".merge = $foo' could mean "refs/remotes/$origin/$foo" when
> $foo contains no slash.
NAK. That makes branch names like "jc/foo" second-class citizens. You
would do better to say "entries without refs/ are implicitly local refs
in refs/remotes/".
-Peff
^ permalink raw reply
* Re: What's in git.git (stable) and announcing GIT 1.5.0 preview
From: Jakub Narebski @ 2006-12-26 11:14 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7v3b73gx43.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Robert Fitzsimons (16):
[...]
> gitweb: Allow search to be disabled from the config file.
Hmmmm... IIRC this did not removed the search form. Besides it is not like
the basic search is expensive...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2006-12-26 11:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vmz5bfidj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'. The topics list the commits in reverse chronological
> order.
>
>
> * jc/fsck-reflog (Fri Dec 22 23:42:30 2006 -0800) 9 commits
> + reflog expire: do not punt on tags that point at non commits.
> + reflog expire: prune commits that are not incomplete
> + Don't crash during repack of a reflog with pruned commits.
> + git reflog expire
> + Move in_merge_bases() to commit.c
> + reflog: fix warning message.
> + Teach git-repack to preserve objects referred to by reflog
> entries.
> + Protect commits recorded in reflog from pruning.
> + add for_each_reflog_ent() iterator
>
> I'd like to push this out before we go -rc1, since the reflogs
> are now enabled by default, and otherwise would grow unbounded.
I'd still like the preserving reflogged data during pruning and
repacking to be optional (default to on). But failing that I'd
like to have option to "reflog expire" to remove only specific
(pattern match, prefix match?) entries, for example to remove
all the "commit --amend" and StGIT work, but leaving rebases,
resets, merges and other stuff.
> * jn/web (Sat Dec 16 17:12:55 2006 +0100) 1 commit
> - gitweb: Add some mod_perl specific support
I'm about to send improved series of patches, few first ready to
be applied, the rest for review.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Adding spell checker to GIT
From: Deepak Barua @ 2006-12-26 12:02 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]
Hi All,
I just need some more help on how to check the file in
concerned in the pre commit hook , i have attached a document which
containes the basic perl code i am going to use.
Regards
Deepak
--
Code Code Code Away
[-- Attachment #2: test --]
[-- Type: application/octet-stream, Size: 705 bytes --]
#!/usr/bin/perl -w
#Spell checking script in perl for GIT source tracker program.
#Should be part of pre-commit hook
use Text::Aspell;
my $filename;
my $continue = 0;
open($filename,"./checker.sh") or die "Could not open file";
my $speller = Text::Aspell->new;
die unless $speller;
while(<$filename>) {
if(m/\/\*/ || $continue == 1) {
@words = split / /,$_;
foreach $word (@words) {
if($word eq "*/") {
$continue = 0;
last;
}
else {
print $speller->check($word)
? "$word found\n"
: "$word not fouund \n";
}
$continue = 1;
}
}
next;
}
close $filename;
^ permalink raw reply
* Re: What's in git.git (stable) and announcing GIT 1.5.0 preview
From: Robert Fitzsimons @ 2006-12-26 13:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <emr01i$hcb$1@sea.gmane.org>
> > gitweb: Allow search to be disabled from the config file.
>
> Hmmmm... IIRC this did not removed the search form. Besides it is not like
> the basic search is expensive...
I just double checked. The search feature is enabled by default, when
the feature is disable the search form isn't shown.
I don't mind if this change is reverted.
Robert
^ 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