summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2005-10-18Do 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-18Even when overwriting tags, report if they are changed or not.Libravatar Junio C Hamano1-1/+6
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-18Optimize 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-18revised^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. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-18Remove unused include.Libravatar Junio C Hamano2-4/+0
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-18No funny names on cygwin...Libravatar Johannes Schindelin1-0/+3
On FAT/NTFS, filenames cannot contain tabs. So t3300-funny-names would reliably fail already when trying to create such files. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-18Ignore more generated filesLibravatar Johannes Schindelin1-0/+3
Since git-status now shows the "other" files, too, bring .gitignore up-to-date. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-18Fix 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-18git-checkout: revert specific paths to either index or a given tree-ish.Libravatar Junio C Hamano2-18/+103
When extra paths arguments are given, git-checkout reverts only those paths to either the version recorded in the index or the version recorded in the given tree-ish. This has been on the TODO list for quite a while. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-18Teach git-add and git-commit to handle filenames starting with '-'.Libravatar Junio C Hamano2-3/+3
Recent '--' fixes to "git diff" by Linus made it possible to specify filenames that start with '-'. But in order to do that, you need to be able to add and commit such file to begin with. Teach git-add and git-commit to honor the same '--' convention. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-18Handle "-" at beginning of filenames, part 3Libravatar Linus Torvalds1-1/+1
This fixes the default built-in exec() of "diff" to add a "--" before the filenames, so that if a filename starts with a "-", the diff program won't think it's an option. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-18Teach "git diff" to handle filenames starting with '-'Libravatar Linus Torvalds2-4/+9
It adds "--" to the git-diff.sh scripts, to keep any filenames that start with a "-" from being confused with an option. But in order to do that, it needs to teach git-diff-files to honor "--". Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-18Avoid ambiguity between refname and filename in rev-parseLibravatar Linus Torvalds1-4/+8
Although it really is very convenient, not requiring explicit '-r' option to name revs is sometimes ambiguous. Usually we allow a "--" to say where a filename starts when it _is_ ambiguous. However, we fail that at times. In particular, git-rev-parse fails it. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Forward port the "funny ref avoidance" in clone and fetch from maint branch.Libravatar Junio C Hamano2-2/+6
Somehow I forgot to forward port these fixes. "git clone" from a repository prepared with the latest update-server-info would fail without this patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Adjust tests for not quoting SP.Libravatar Junio C Hamano1-5/+11
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-17git-apply: remove unused --show-files flag.Libravatar Junio C Hamano2-43/+2
Linus says he does not use it (and the thinking behind its initial introduction), and neither Cogito nor StGIT uses it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17update-index --index-info: adjust for funny-path quoting.Libravatar Junio C Hamano1-5/+17
Although the sole current user uses -z to read this, we should be prepared for somebody to feed non-z format to the command. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Add tests for funny pathnames.Libravatar Junio C Hamano1-0/+133
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Update documentation for C-style quoting.Libravatar Junio C Hamano4-2/+33
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Update git-status to new git-diff-* and git-ls-files output.Libravatar Junio C Hamano1-32/+35
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Update git-diff-* to use C-style quoting for funny pathnames.Libravatar Junio C Hamano1-40/+95
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Improve "git add" again.Libravatar Junio C Hamano2-15/+49
This makes it possible to add paths that have funny characters (TAB and LF) in them, and makes adding many paths more efficient in general. New flag "--stdin" to update-index was initially added for different purpose, but it turns out to be a perfect match for feeding "ls-files --others -z" output to improve "git add". It also adds "--verbose" flag to update-index for use with "git add" command. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Update ls-files and ls-tree to use C-style quoting for funny pathnames.Libravatar Junio C Hamano2-9/+19
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Update git-apply to use C-style quoting for funny pathnames.Libravatar Junio C Hamano2-46/+186
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Functions to quote and unquote pathnames in C-style.Libravatar Junio C Hamano2-2/+175
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-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-16ref-format documentation.Libravatar Junio C Hamano3-2/+66
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-16Sparse-directory safety fix.Libravatar Junio C Hamano1-1/+1
This will be removed when merging the second phase of Linus' "Create object subdirectories on demand" change anyway, but the code to recreate the empty .git/objects/??/ directory was confused. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-16Merge branch 'fixes'Libravatar Junio C Hamano1-0/+7
2005-10-16We do not depend on patch.Libravatar Junio C Hamano1-2/+2
Deb packaging claim we depend on patch, but I think we use git-apply where it matters. When a patch does not apply with git-apply, using GNU patch still is helpful sometimes. So demote it from "Depends" to "Suggests". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-16Merge branch 'svn' of http://netz.smurf.noris.de/git/gitLibravatar Junio C Hamano5-5/+859
[jc: I have my pre-commit hook enabled to catch trailing whitespaces, and fixed them up while merging.] Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-16svn commit: re-word the exit-due-to-memory-leak messageLibravatar Matthias Urlichs1-1/+2
Reworded the exit message, as per Kalle Valo's suggestion (but shorter). Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
2005-10-16Makefile entry for git-svnimport contained a small typo.Libravatar Kalle Valo1-1/+1
Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
2005-10-16Squelch compiler warnings from connect.cLibravatar Junio C Hamano1-0/+1
Forgot to include necessary header file to get the function declaration. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-16Disable hooks during tests.Libravatar Junio C Hamano1-1/+5
Individual tests for hooks would want to have their own tests when written. Also we should not pick up from random templates the user happens to have. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-16Sparse fixes for http-fetchLibravatar Peter Hagervall1-15/+17
This patch cleans out all sparse warnings from http-fetch.c I'm a bit uncomfortable with adding extra #ifdefs to avoid either 'mixing declaration with code' or 'unused variable' warnings, but I figured that since those functions are already littered with #ifdefs I might just get away with it. Comments? [jc: I adjusted Peter's patch to address uncomfortableness issues.] Signed-off-by: Peter Hagervall <hager@cs.umu.se> 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-15Show peeled onion from upload-pack and server-info.Libravatar Junio C Hamano3-0/+16
This updates git-ls-remote to show SHA1 names of objects that are referred by tags, in the "ref^{}" notation. This would make git-findtags (without -t flag) almost trivial. git-peek-remote . | sed -ne "s:^$target "'refs/tags/\(.*\)^{}$:\1:p' Also Pasky could do: git-ls-remote --tags $remote | sed -ne 's:\( refs/tags/.*\)^{}$:\1:p' to find out what object each of the remote tags refers to, and if he has one locally, run "git-fetch $remote tag $tagname" to automatically catch up with the upstream tags. 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-15Merge branch 'fixes'Libravatar Junio C Hamano3-23/+218
2005-10-15Show curl error a bit better.Libravatar Junio C Hamano1-1/+3
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15Some curl versions lack curl_easy_duphandle()Libravatar Johannes Schindelin1-16/+44
Hi, On Fri, 14 Oct 2005, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > This patch looks bigger than it really is: The code to get the > > default handle was refactored into a function, and is called > > instead of curl_easy_duphandle() if that does not exist. > > I'd like to take Nick's config file patch first, which > unfortunately interferes with your patch. I'd hate to ask you > this, but could you rebase it on top of Nick's patch, [...] No need to hate it. Here comes the rebased patch, and this time, I actually tested it a bit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-14Unlocalized isspace and friendsLibravatar Linus Torvalds16-14/+51
Do our own ctype.h, just to get the sane semantics: we want locale-independence, _and_ we want the right signed behaviour. Plus we only use a very small subset of ctype.h anyway (isspace, isalpha, isdigit and isalnum). Signed-off-by: Junio C Hamano <junkio@cox.net>