summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2005-10-23GIT 0.99.8gLibravatar Junio C Hamano2-1/+7
Primarily to update the maintenance branch deployed on kernel.org machines with the git-daemon updates. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-23Merge branch 'fixes'Libravatar Junio C Hamano1-1/+1
2005-10-23git-show-branch: Fix off-by-one error.Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-20Merge branch 'fixes'Libravatar Junio C Hamano1-2/+2
2005-10-20daemon.c: remove trailing whitespace.Libravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-20Fix git-daemon argument-parsing bugLibravatar H. Peter Anvin1-1/+1
Fix stupid bug in parsing the --init-timeout option. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-19git-daemon: timeout, eliminate double DWIMLibravatar H. Peter Anvin2-7/+59
It turns out that not only did git-daemon do DWIM, but git-upload-pack does as well. This is bad; security checks have to be performed *after* canonicalization, not before. Additionally, the current git-daemon can be trivially DoSed by spewing SYNs at the target port. This patch adds a --strict option to git-upload-pack to disable all DWIM, a --timeout option to git-daemon and git-upload-pack, and an --init-timeout option to git-daemon (which is typically set to a much lower value, since the initial request should come immediately from the client.) Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-19GIT 0.99.8fLibravatar Junio C Hamano2-1/+7
Yes I said 0.99.8e was the last maintenance release for 0.99.8, but it turns out that there was another backport necessary after git-daemon was unleashed on kernel.org servers. Contains the following since 0.99.8e: H. Peter Anvin: revised^2: git-daemon extra paranoia, and path DWIM Johannes Schindelin: Fix cvsimport warning when called without --no-cvs-direct Junio C Hamano: Do not ask for objects known to be complete. Linus Torvalds: git-fetch-pack: avoid unnecessary zero packing Optimize common case of git-rev-list Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-19Fix cvsimport warning when called without --no-cvs-directLibravatar Johannes Schindelin1-1/+1
Perl was warning that $opt_p was undefined in that case. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-19Do not ask for objects known to be complete.Libravatar Junio C Hamano1-2/+62
On top of optimization by Linus not to ask refs that already match, we can walk our refs and not issue "want" for things that are known to be reachable from them. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-19Optimize common case of git-rev-listLibravatar Linus Torvalds1-0/+5
I took a look at webgit, and it looks like at least for the "projects" page, the most common operation ends up being basically git-rev-list --header --parents --max-count=1 HEAD Now, the thing is, the way "git-rev-list" works, it always keeps on popping the parents and parsing them in order to build the list of parents, and it turns out that even though we just want a single commit, git-rev-list will invariably look up _three_ generations of commits. It will parse: - the commit we want (it obviously needs this) - it's parent(s) as part of the "pop_most_recent_commit()" logic - it will then pop one of the parents before it notices that it doesn't need any more - and as part of popping the parent, it will parse the grandparent (again due to "pop_most_recent_commit()". Now, I've strace'd it, and it really is pretty efficient on the whole, but if things aren't nicely cached, and with long-latency IO, doing those two extra objects (at a minimum - if the parent is a merge it will be more) is just wasted time, and potentially a lot of it. So here's a quick special-case for the trivial case of "just one commit, and no date-limits or other special rules". Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-19revised^2: git-daemon extra paranoia, and path DWIMLibravatar H. Peter Anvin1-21/+57
This patch adds some extra paranoia to the git-daemon filename test. In particular, it now rejects pathnames containing //; it also adds a redundant test for pathname absoluteness (belts and suspenders.) A single / at the end of the path is still permitted, however, and the .git and /.git append DWIM stuff is now handled in an integrated manner, which means the resulting path will always be subjected to pathname checks. [jc: backported to 0.99.8 maintenance branch] Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-18git-fetch-pack: avoid unnecessary zero packingLibravatar Linus Torvalds1-6/+44
If everything is up-to-date locally, we don't need to even ask for a pack-file from the remote, or try to unpack it. This is especially important for tags - since the pack-file common commit logic is based purely on the commit history, it will never be able to find a common tag, and will thus always end up re-fetching them. Especially notably, if the tag points to a non-commit (eg a tagged tree), the pack-file would be unnecessarily big, just because it cannot any most recent common point between commits for pruning. Short-circuiting the case where we already have that reference means that we avoid a lot of these in the common case. NOTE! This only matches remote ref names against the same local name, which works well for tags, but is not as generic as it could be. If we ever need to, we could match against _any_ local ref (if we have it, we have it), but this "match against same name" is simpler and more efficient, and covers the common case. Renaming of refs is common for branch heads, but since those are always commits, the pack-file generation can optimize that case. In some cases we might still end up fetching pack-files unnecessarily, but this at least avoids the re-fetching of tags over and over if you use a regular git fetch --tags ... which was the main reason behind the change. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17GIT 0.99.8eLibravatar Junio C Hamano4-4/+10
Linus Torvalds: make checkout-index '-a' flag saner. Junio C Hamano: whatchanged: document -m option from git-diff-tree. Functions to quote and unquote pathnames in C-style. Update git-apply to use C-style quoting for funny pathnames. Do not quote SP. git-checkout-index: documentation updates. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Merge branch 'fixes'Libravatar Junio C Hamano2-61/+68
2005-10-17git-checkout-index: documentation updates.Libravatar Junio C Hamano1-13/+7
Now the behaviour of '-a' has been straightened out, document it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17make checkout-index '-a' flag saner.Libravatar Linus Torvalds1-48/+61
The original semantics of pretending as if all files were specified where '-a' appeared and using only the flags given so far was too confusing. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Do not quote SP.Libravatar Junio C Hamano1-2/+2
Follow the "encode minimally" principle -- our tools, including git-apply and git-status, can handle pathnames with embedded SP just fine. The only problematic ones are TAB and LF, and we need to quote the metacharacters introduced for quoting. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-16Merge branch 'fixes'Libravatar Junio C Hamano1-0/+7
2005-10-16Update git-apply to use C-style quoting for funny pathnames.Libravatar Junio C Hamano1-39/+169
This is a backport so that maintenance branch can understand diff output that uses C-style quoting produced by newer tools. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-16Functions to quote and unquote pathnames in C-style.Libravatar Junio C Hamano2-1/+172
Following the list discussion, define two functions, quote_c_style and unquote_c_style, to help adopting the proposed way for quoting funny pathname letters for GNU patch. The rule is described in: http://marc.theaimsgroup.com/?l=git&m=112927316408690&w=2 Currently we do not support the leading '!', but we probably should barf upon seeing it. Rule B4. is interpreted to require always 3 octal digits in \XYZ notation. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15whatchanged: document -m option from git-diff-tree.Libravatar Junio C Hamano1-0/+7
The documentation for git-whatchanged is meant to describe only the most frequently used options from git-diff-tree. Because "why doesn't it show merges" was asked more than once, we'd better describe '-m' option there. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15GIT v0.99.8dLibravatar Junio C Hamano5-3/+18
Contains the following changes since v0.99.8c. Johannes Schindelin: Teach git-status about spaces in file names also on MacOSX t5400-send-pack relies on a working cpio Jonas Fonseca: git.sh: quote all paths Junio C Hamano: Also force LC_ALL in test scripts. OpenBSD needs the strcasestr replacement. git-check-ref-format: reject funny ref names. Refuse to create funny refs in clone-pack, git-fetch and receive-pack. Ignore funny refname sent from remote Introduce notation "ref^{type}". Martin Langhoff: cvsimport: don't pass --cvs-direct if user options contradict us Ralf Baechle: rsh.c: typo fix Note that "funny ref" bits are not strictly fixes but rather backport from the "master" branch. They will prevent refs and heads with funny names from being created. In addition, what is in the master branch will start feeding the clients unwrapped tag information to help Martin's findtags and possibly later Cogito. These backported "funny ref" changes are to prevent clients on the "maint" branch from getting confused when talking with newer git-upload-pack and when reading from info/refs file prepared with newer git-update-server-info. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15Introduce notation "ref^{type}".Libravatar Junio C Hamano1-0/+83
Existing "tagname^0" notation means "dereference tag zero or more times until you cannot dereference it anymore, and make sure it is a commit -- otherwise barf". But tags do not necessarily reference commit objects. This commit introduces a bit more generalized notation, "ref^{type}". Existing "ref^0" is a shorthand for "ref^{commit}". If the type is empty, it just dereferences tags until it hits a non-tag object. With this, "git-rev-parse --verify 'junio-gpg-pub^{}'" shows the blob object name -- there is no need to manually read the tag object and find out the object name anymore. "git-rev-parse --verify 'HEAD^{tree}'" can be used to find out the tree object name of the HEAD commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15Ignore funny refname sent from remoteLibravatar Junio C Hamano6-6/+12
This allows the remote side (most notably, upload-pack) to show additional information without affecting the downloader. Peek-remote does not ignore them -- this is to make it useful for Pasky's automatic tag following. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15Refuse to create funny refs in clone-pack, git-fetch and receive-pack.Libravatar Junio C Hamano3-0/+16
Using git-check-ref-format, make sure we do not create refs with funny names when cloning from elsewhere (clone-pack), fast forwarding local heads (git-fetch), or somebody pushes into us (receive-pack). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15git-check-ref-format: reject funny ref names.Libravatar Junio C Hamano6-38/+103
Update check_ref_format() function to reject ref names that: * has a path component that begins with a ".", or * has a double dots "..", or * has ASCII control character, "~", "^", ":" or SP, anywhere, or * ends with a "/". Use it in 'git-checkout -b', 'git-branch', and 'git-tag' to make sure that newly created refs are well-formed. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15Revert "Adapt tutorial to cygwin and add test case"Libravatar Junio C Hamano2-212/+19
This reverts 2ae6c706749b44f05917fcd04037f545d16fb345 commit.
2005-10-15Revert "tutorial: update the initial commit example."Libravatar Junio C Hamano1-8/+6
This reverts 5990efb0c4f6d1a19c4702bf50ef8cc5ac902a78 commit.
2005-10-15Merge branch 'fixes'Libravatar Junio C Hamano3-23/+218
2005-10-13tutorial: update the initial commit example.Libravatar Junio C Hamano1-6/+8
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-13Adapt tutorial to cygwin and add test caseLibravatar Johannes Schindelin2-19/+212
Lacking reliable symlinks, the instructions in the tutorial did not work in a cygwin setup. Also, a few outputs were not correct. This patch fixes these, and adds a test case which follows the instructions of the tutorial (except git-clone, -fetch and -push, which I have not done yet). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-13rsh.c: typo fixLibravatar Ralf Baechle1-1/+1
Example in a comment used a wrong environment variable. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-11Merge branch 'fixes'Libravatar Junio C Hamano1-1/+4
2005-10-11[PATCH] cvsimport: don't pass --cvs-direct if user options contradict usLibravatar Martin Langhoff1-1/+4
Detecting if the user passed --no-cvs-direct and don't force the mode. It allows us to support all the protocol that the standard cvs client supports at the snail speed you should expect. This only affects the rlog reading stage. Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
2005-10-10Merge branch 'fixes'Libravatar Junio C Hamano5-7/+12
2005-10-10t5400-send-pack relies on a working cpioLibravatar Johannes Schindelin1-0/+3
Since cygwin does not install cpio by default, t5400 results in a very cryptic failure. So, test for cpio explicitely. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10git.sh: quote all pathsLibravatar Jonas Fonseca1-2/+2
This makes it handle spaces in paths. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10Teach git-status about spaces in file names also on MacOSXLibravatar Johannes Schindelin1-4/+4
Not all sed understands '\t' and consequently cuts off every file name at the first "t" (or backslash...). Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10OpenBSD needs the strcasestr replacement.Libravatar Junio C Hamano1-0/+1
Noticed by Randal L. Schwartz. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-09Also force LC_ALL in test scripts.Libravatar Junio C Hamano1-1/+2
Noticed by Junichi Uekawa. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-09GIT 0.99.8cLibravatar Junio C Hamano2-1/+7
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-09Merge branch 'fixes'Libravatar Junio C Hamano7-10/+23
2005-10-09git-tag: update usage string and documentation.Libravatar Junio C Hamano2-4/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-09ignore new git-diff index header when computing patch idsLibravatar Kai Ruemmler1-0/+4
Two else equal patches should not result in different checksums, only because they were applied to different versions of the file. Signed-off-by: Kai Ruemmler <kai.ruemmler@gmx.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-09Fix git-verify-tag for light-weight tagsLibravatar Paolo 'Blaisorblade' Giarrusso1-2/+6
It currently exits printing "git-cat-file SHA1: bad file", while instead we must just abort the verification for light-weight tags (e.g. referring to commit objects). [jc: tag objects can tag anything not just commits, so I fixed up the original patch slightly. you should be able to validate a signed tag that points at a blob object. ] Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-09Make sure 'make install' does not have to rebuild templates.Libravatar Junio C Hamano1-3/+6
The dependency rule in templates directory forced 'make install' that immediately followed 'make all' to rebuild boilerplates. This was problematic for a workflow that built first as yourself and then installed as root, from a working tree that is on an NFS mounted filesystem that is unwritable by root. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-08Give proper prototype to gitstrcasestr.Libravatar Junio C Hamano2-1/+5
Borrow from NO_MMAP patch by Johannes, squelch compiler warnings by declaring gitstrcasestr() when we use it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-07Merge branch 'fixes'Libravatar Junio C Hamano6-41/+228
2005-10-07teach git-status about spaces in filenamesLibravatar Kai Ruemmler1-3/+21
git-status truncates filenames up to the first occurrence of a whitespace character when displaying. More precisely, it displays the filename up to any field seperator defined in $IFS. This patch fixes it. Signed-off-by: Junio C Hamano <junkio@cox.net>