swh:1:snp:87728f882295b5ba27035837248a04c5be121c53

sort by:
Revision Author Date Message Commit Date
129adf4 git-rev-list: fix "--dense" flag Right now --dense will _always_ show the root commit. I didn't do the logic that does the diff against an empty tree. I was lazy. This patch does that. The first round was incorrect but this patch is even slightly tested, and might do a better job. Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 05:53:24 UTC
8548ea8 Add some missing commands to the git.txt commands list Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 05:51:39 UTC
f6ab5bb Add usage string to git-update-index This patch adds usage string to git-update-index, can be printed by the -h or --help parameter. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 05:51:18 UTC
d43367a Documentation for git-shell Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 05:51:13 UTC
05ff564 Check another error condition in git-mv When moving multiple files at once, it can happen that files get the same target name, like in git-mv a/foo b/foo destdir Both a/foo and b/foo target destdir/foo. Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 05:50:49 UTC
979e32f fix daemon.c to compile on OpenBSD I can confirm that the following patch lets the current origin compile on OpenBSD. If you could apply this until you sort out the rest of the namespace issue, I would be happy. Thanks. Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 00:37:59 UTC
af2d3aa Revert recent fetch-pack/upload-pack updates. Let's have it simmer a bit longer in the proposed updates branch and shake the problems out. Signed-off-by: Junio C Hamano <junkio@cox.net> 25 October 2005, 21:55:24 UTC
7efc8e4 upload-pack: fix thinko in common-commit finder code. The code to check if we have the object the other side has was bogus (my fault). Signed-off-by: Junio C Hamano <junkio@cox.net> 24 October 2005, 22:13:38 UTC
40a1046 git-fetch-pack: Implement client part of the multi_ack extension This patch concludes the series, which makes git-fetch-pack/git-upload-pack negotiate a potentially better set of common revs. It should make a difference when fetching from a repository with a few branches. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 October 2005, 22:13:37 UTC
69779a5 git-fetch-pack: Do not use git-rev-list The code used to call git-rev-list to enumerate the local revisions. A disadvantage of that method was that git-rev-list, lacking a control apart from the command line, would happily enumerate ancestors of acknowledged common commits, which was just taking unnecessary bandwidth. Therefore, do not use git-rev-list on the fetching side, but rather construct the list on the go. Send the revisions starting from the local heads, ignoring the revisions known to be common. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 October 2005, 22:13:37 UTC
0f8fdc3 git-upload-pack: Support sending multiple ACK messages The current fetch/upload protocol works like this: - client sends revs it wants to have via "want" messages - client sends a flush message (message with len 0) - client sends revs it has via "have" messages - after one window (32 revs), a flush is sent - after each subsequent window, a flush is sent, and an ACK/NAK is received. (NAK means that server does not have any of the transmitted revs; ACK sends also the sha1 of the rev server has) - when the first ACK is received, client sends "done", and does not expect any further messages One special case, though: - if no ACK is received (only NAK's), and client runs out of revs to send, "done" is sent, and server sends just one more "NAK" A smarter scheme, which actually has a chance to detect more than one common rev, would be to send more than just one ACK. This patch implements the server side of the following extension to the protocol: - client sends at least one "want" message with "multi_ack" appended, like "want 1234567890123456789012345678901234567890 multi_ack" - if the server understands that extension, it will send ACK messages for all revs it has, not just the first one - server appends "continue" to the ACK messages like "ACK 1234567890123456789012345678901234567890 continue" until it has MAX_HAS-1 revs. In this manner, client knows when to stop sending revs by checking for the substring "continue" (and further knows that server understands multi_ack) In this manner, the protocol stays backwards compatible, since both client must send "want ... multi_ack" and server must answer with "ACK ... continue" to enable the extension. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 October 2005, 22:13:37 UTC
794f9fe git-upload-pack: More efficient usage of the has_sha1 array This patch is based on Junio's proposal. It marks parents of common revs so that they do not clutter up the has_sha1 array. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 October 2005, 22:13:36 UTC
35eb2d3 Add git-shell. This adds a very git specific restricted shell, that can be added to /etc/shells and set to the pw_shell in the /etc/passwd file, to give users ability to push into repositories over ssh without giving them full interactive shell acount. [jc: I updated Linus' patch to match what the current sq_quote() does.] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 October 2005, 22:12:41 UTC
38cc7ab Clarify git status output. What we list as "Ignored files" are not "ignored". Rather, it is the list of "not listed in the to-be-ignored files, but exists -- you may be forgetting to add them". Pointed out by Daniel. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 October 2005, 22:11:47 UTC
7744f3b Require zlib >= 1.2 for RPM. git-update-index requires zlib >= 1.2, which introduced the *Bound functions. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 October 2005, 10:23:46 UTC
1114b26 Add git-mv It supersedes git-rename by adding functionality to move multiple files, directories or symlinks into another directory. It also provides according documentation. The implementation renames multiple files, using the arguments from the command line to produce an array of sources and destinations. In a first pass, all requested renames are checked for errors, and overwriting of existing files is only allowed with '-f'. The actual renaming is done in a second pass. This ensures that any error condition is checked before anything is changed. Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 October 2005, 00:25:08 UTC
e2029eb Silence confusing and false-positive curl error message git-http-fetch spits out curl 404 error message when unable to fetch an object, but that's confusing since no error really happened and the object is usually found in a pack it tries right after that. And if the object still cannot be retrieved, it will say another error message anyway. OTOH other HTTP errors (403 etc) are likely fatal and the user should be still informed about them. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 October 2005, 18:49:25 UTC
a1c7a69 GIT 0.99.8g 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> 23 October 2005, 09:04:01 UTC
02b54b3 Merge branch 'fixes' 23 October 2005, 08:57:42 UTC
8ac3a61 Merge branch 'fixes' 23 October 2005, 08:20:41 UTC
79778e4 git-show-branch: Fix off-by-one error. Signed-off-by: Junio C Hamano <junkio@cox.net> 23 October 2005, 08:19:48 UTC
1b9e059 git-rev-list: add "--dense" flag This is what the recent git-rev-list changes have all been gearing up for. When we use a path filter to git-rev-list, the new "--dense" flag asks git-rev-list to compress the history so that it _only_ contains commits that change files in the path filter. It also rewrites the parent information so that tools like "gitk" will see the result as a dense history tree. For example, on the current kernel archive: [torvalds@g5 linux]$ git-rev-list HEAD | wc -l 9904 [torvalds@g5 linux]$ git-rev-list HEAD -- kernel | wc -l 5442 [torvalds@g5 linux]$ git-rev-list --dense HEAD -- kernel | wc -l 356 which shows that while we have almost ten thousand commits, we can prune down the work to slightly more than half by only following the merges that are interesting. But further, we can then compress the history to just 356 entries that actually make changes to the kernel subdirectory. To see this in action, try something like gitk --dense -- gitk to see just the history that affects gitk. Or, to show that true parallel development still remains parallel, do gitk --dense -- daemon.c which shows some parallel commits in the current git tree. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 October 2005, 05:49:52 UTC
cf48454 Teach git-rev-list to follow just a specified set of files This is the first cut at a git-rev-list that knows to ignore commits that don't change a certain file (or set of files). NOTE! For now it only prunes _merge_ commits, and follows the parent where there are no differences in the set of files specified. In the long run, I'd like to make it re-write the straight-line history too, but for now the merge simplification is much more fundamentally important (the rewriting of straight-line history is largely a separate simplification phase, but the merge simplification needs to happen early if we want to optimize away unnecessary commit parsing). If all parents of a merge change some of the files, the merge is left as is, so the end result is in no way guaranteed to be a linear history, but it will often be a lot /more/ linear than the full tree, since it prunes out parents that didn't matter for that set of files. As an example from the current kernel: [torvalds@g5 linux]$ git-rev-list HEAD | wc -l 9885 [torvalds@g5 linux]$ git-rev-list HEAD -- Makefile | wc -l 4084 [torvalds@g5 linux]$ git-rev-list HEAD -- drivers/usb | wc -l 5206 and you can also use 'gitk' to more visually see the pruning of the history tree, with something like gitk -- drivers/usb showing a simplified history that tries to follow the first parent in a merge that is the parent that fully defines drivers/usb/. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 October 2005, 05:49:52 UTC
ac1b3d1 Split up tree diff functions into tree-diff.c library This makes the tree diff functionality independent of the "git-diff-tree" program, by splitting the core functionality up into a library file. This will be needed for when we teach git-rev-list to only follow a specified set of pathnames, rather than the global revision history. Most of it is a fairly straightforward code move, but it also involves some calling convention cleanup, and moving some of the static variables from diff-tree.c into the options structure. The actual tree change callback routines also become paramterized by the diff_options structure, allowing the library functionality to do something else than just show the diff on stdout. Right now the only user of this functionality remains git-diff-tree itself. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 October 2005, 05:49:51 UTC
4f692b1 Allow git-merge not to commit. Martin Langhoff wants to use git-merge from outside git-pull and wants to do further processing; for this, he wants git-merge no to commit even when it cleanly merges. I think other script writers would want something like that as well, so here it is. Instead of the "merge commit message" parameter (which usually is made for you by "git-pull" which calls this command), you pass an empty string to it. Then it will not update your HEAD -- you can do whatever you want with the resulting index file, which contains the merge results. Signed-off-by: Junio C Hamano <junkio@cox.net> 22 October 2005, 11:45:15 UTC
6b32884 upload-pack: Increase MAX_HAS. Later round would further improve fetch-pack not to send useless "have", but in the meantime, increase it to help upload-pack to find more common commits, as discussed on the list. Signed-off-by: Junio C Hamano <junkio@cox.net> 22 October 2005, 09:28:27 UTC
05625af Fix malformatted git-am documentation. Signed-off-by: Junio C Hamano <junkio@cox.net> 22 October 2005, 03:57:34 UTC
7b9ae53 [PATCH 3/3] Allow running requests to finish after a pull error Allow running requests to finish after a pull error Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 22 October 2005, 02:20:18 UTC
f7eb290 [PATCH 2/3] Switched back to loading alternates as needed Switched back to loading alternates as needed Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 22 October 2005, 02:20:18 UTC
f1a906a [PATCH 1/3] Clean up CURL handles in unused request slots Clean up CURL handles in unused request slots Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 22 October 2005, 02:20:17 UTC
4ae22d9 Merge branch 'fixes' 21 October 2005, 06:21:50 UTC
f680493 Merge branch 'fixes' 21 October 2005, 06:19:47 UTC
a935c39 daemon.c: remove trailing whitespace. Signed-off-by: Junio C Hamano <junkio@cox.net> 21 October 2005, 06:19:36 UTC
147a1ab Fix git-daemon argument-parsing bug 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> 21 October 2005, 05:56:34 UTC
54e31a2 Fix git-daemon argument-parsing bug 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> 21 October 2005, 05:46:03 UTC
2707da9 Update git-daemon's documentation wrt. new options New options --timeout, --init-timeout, --export-all and whitelist support were added to git-daemon, but noone bothered to also add the proper documentation. This patch aims to fix that. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 October 2005, 05:32:08 UTC
baa720f Finish git-am documentation. Signed-off-by: Junio C Hamano <junkio@cox.net> 21 October 2005, 05:32:07 UTC
42e2cba Brief documentation for the mysterious git-am script The git-am script is nowhere called and nowhere (including itself) explained, and the name isn't helpful either. For those like me who will wonder what is it about, add some documentation stub for it to the documentation. I probably got something wrong and I don't feel like investigating all the options - this is just kind of "emergency" docs. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 October 2005, 05:32:07 UTC
a08b650 git-rev-parse: pass on "--" flag when required If rev-parse output includes both flags and files, we should pass on any "--" marker we see, so that the end result can also tell the difference between a flag and a filename that begins with '-'. [jc: merged a later one liner updates from Linus] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 October 2005, 05:32:07 UTC
adc3dbc Use sensible domain name (the DNS one) when guessing ident information Currently, the code would use getdomainname() call, which however returns something usually unset and not necessarily related at all to the DNS domain name (it seems to be mostly some scary NIS/YP thing). This patch changes the code to actually use the DNS domain name, which is also what tends to be used in emails, and we aim at emails with our ident code. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 October 2005, 05:32:07 UTC
4eba0f3 Make git-cherry-pick in target "all" Since git-cherry-pick is simply a copy of git-revert, it can be created before installing (so that it can be used without installing, too). Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 October 2005, 05:32:07 UTC
2c67419 Fix missing exports in git-am Signed-off-by: Junio C Hamano <junkio@cox.net> 21 October 2005, 05:31:56 UTC
7872e05 git-daemon poll() spinning out of control With the '0' timeout given to poll, it returns instantly without any events on my system, causing git-daemon to consume all the CPU time. Use -1 as the timeout so poll() only returns in case of EINTR or actually events being available. Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 October 2005, 04:26:31 UTC
bfadbed Merge /pub/scm/git/git to recover lost side branch Sorry for the mistake of rewinding something already pushed out. This recovers the side branch lost by that mistake, specifically ea5a65a59916503d2a14369c46b1023384d51645 commit. Signed-off-by: Junio C Hamano <junio@hera.kernel.org> 21 October 2005, 00:06:15 UTC
6e1c6c1 Make sure we barf on ref^{type} failure. Martin Langhoff noticed that ref^0 barfed correctly when we did not have the commit in a broken repository, but ref^{commit} didn't. Signed-off-by: Junio C Hamano <junkio@cox.net> 20 October 2005, 05:49:31 UTC
f1f0a2b Be more careful tangling object chains while marking commits. Also Johannes noticed we use parse_object to look up if we know that object already -- we should just ask the in-core object registry with lookup_object() for that. Signed-off-by: Junio C Hamano <junkio@cox.net> 20 October 2005, 04:55:49 UTC
d6a7359 git-fetch/push/pull: documentation. The documentation was lazily sharing the argument description across these commands. Lazy may be a way of life, but that does not justify confusing others ;-). Signed-off-by: Junio C Hamano <junkio@cox.net> 20 October 2005, 04:25:39 UTC
4dab94d Do not feed rev-list an invalid SHA1 expression. The previous round to optimize fetch-pack has a small bug that feeds SHA1^ ("parent commit") before making sure SHA1 is actually a commit (or a tag that eventually dereferences to a commit). Also it did not help culling the known-to-be-common parents if the common one was a merge. Signed-off-by: Junio C Hamano <junkio@cox.net> 20 October 2005, 04:04:53 UTC
0a8944d [PATCH] Do not send "want" lines for complete objects It was all good and well to check if all remote refs are complete (local refs or descendants thereof), but we can just as easily use the same information to avoid sending "want" lines just for the complete objects in the case that not all remote refs are complete (or their names differ). Also, git-fetch-pack does not have to ask for descendants of remote refs which are complete (for now, git-rev-list is told to ignore only the first parent). That change also eliminates a code path where a popen()ed handle was not pclose()ed. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 October 2005, 23:14:34 UTC
d6a461e count-objects: squelch error from find on sparse object directory. Signed-off-by: Junio C Hamano <junkio@cox.net> 19 October 2005, 22:01:50 UTC
b7080d8 git-daemon: timeout, eliminate double DWIM 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> 19 October 2005, 21:44:43 UTC
76e712f git-clone: always keep pack sent from remote (documentation). This adjusts the documentation. Signed-off-by: Junio C Hamano <junkio@cox.net> 19 October 2005, 21:43:43 UTC
e1c7ada git-clone: always keep pack sent from remote. This deprecates --keep and -q flags and always keeps the pack sent from the remote site. Corresponding configuration variables are also removed. Signed-off-by: Junio C Hamano <junkio@cox.net> 19 October 2005, 21:43:43 UTC
49bb805 Do not ask for objects known to be complete. 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> 19 October 2005, 21:27:02 UTC
e0004e2 Support for HTTP transfer timeouts based on transfer speed Add configuration settings to abort HTTP requests if the transfer rate drops below a threshold for a specified length of time. Environment variables override config file settings. Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 October 2005, 21:27:01 UTC
960decc git-daemon: timeout, eliminate double DWIM 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> 19 October 2005, 21:27:01 UTC
c9ed27b GIT 0.99.8f 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> 19 October 2005, 09:31:27 UTC
750a09a Fix cvsimport warning when called without --no-cvs-direct 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> 19 October 2005, 07:01:02 UTC
acfcb8d Do not ask for objects known to be complete. 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> 19 October 2005, 07:01:01 UTC
0910e8c Optimize common case of git-rev-list 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> 19 October 2005, 07:01:01 UTC
e51fd86 revised^2: git-daemon extra paranoia, and path DWIM 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> 19 October 2005, 07:01:01 UTC
844ac7f git-fetch-pack: avoid unnecessary zero packing 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> 19 October 2005, 06:52:08 UTC
ea5a65a Do not ask for objects known to be complete. 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> 19 October 2005, 01:42:19 UTC
f876579 Even when overwriting tags, report if they are changed or not. Signed-off-by: Junio C Hamano <junkio@cox.net> 19 October 2005, 01:42:14 UTC
fe5f51c Optimize common case of git-rev-list 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> 19 October 2005, 01:41:28 UTC
3e04c62 revised^2: git-daemon extra paranoia, and path DWIM 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> 19 October 2005, 01:26:52 UTC
5e5f809 Remove unused include. Signed-off-by: Junio C Hamano <junkio@cox.net> 18 October 2005, 22:41:43 UTC
2759cbc git-fetch-pack: avoid unnecessary zero packing 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> 18 October 2005, 18:35:17 UTC
5f93926 No funny names on cygwin... 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> 18 October 2005, 18:35:17 UTC
542a01e Ignore more generated files 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> 18 October 2005, 18:35:17 UTC
e175768 Fix cvsimport warning when called without --no-cvs-direct 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> 18 October 2005, 18:35:16 UTC
4aaa702 git-checkout: revert specific paths to either index or a given tree-ish. 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> 18 October 2005, 08:29:27 UTC
4bfe119 Teach git-add and git-commit to handle filenames starting with '-'. 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> 18 October 2005, 07:27:50 UTC
694a764 Handle "-" at beginning of filenames, part 3 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> 18 October 2005, 07:16:45 UTC
ea51d41 Teach "git diff" to handle filenames starting with '-' 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> 18 October 2005, 07:16:45 UTC
7a3dd47 Avoid ambiguity between refname and filename in rev-parse 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> 18 October 2005, 07:16:45 UTC
c99ec04 GIT 0.99.8e 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> 18 October 2005, 04:52:10 UTC
cdb3950 Forward port the "funny ref avoidance" in clone and fetch from maint branch. 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> 18 October 2005, 04:47:06 UTC
508c1d1 Adjust tests for not quoting SP. Signed-off-by: Junio C Hamano <junkio@cox.net> 18 October 2005, 00:41:59 UTC
28fba29 Do not quote SP. 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> 18 October 2005, 00:41:58 UTC
58452f9 git-apply: remove unused --show-files flag. 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> 18 October 2005, 00:41:58 UTC
973d6a2 update-index --index-info: adjust for funny-path quoting. 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> 18 October 2005, 00:41:57 UTC
4d2060e Add tests for funny pathnames. Signed-off-by: Junio C Hamano <junkio@cox.net> 18 October 2005, 00:41:57 UTC
d88156e Update documentation for C-style quoting. Signed-off-by: Junio C Hamano <junkio@cox.net> 18 October 2005, 00:41:56 UTC
71ac835 Update git-status to new git-diff-* and git-ls-files output. Signed-off-by: Junio C Hamano <junkio@cox.net> 18 October 2005, 00:41:56 UTC
cf9dfc6 Update git-diff-* to use C-style quoting for funny pathnames. Signed-off-by: Junio C Hamano <junkio@cox.net> 18 October 2005, 00:41:56 UTC
caf4f58 Improve "git add" again. 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> 18 October 2005, 00:41:55 UTC
22ddf71 Update ls-files and ls-tree to use C-style quoting for funny pathnames. Signed-off-by: Junio C Hamano <junkio@cox.net> 18 October 2005, 00:41:55 UTC
22943f1 Update git-apply to use C-style quoting for funny pathnames. Signed-off-by: Junio C Hamano <junkio@cox.net> 18 October 2005, 00:41:54 UTC
4f6fbcd Functions to quote and unquote pathnames in C-style. 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> 18 October 2005, 00:41:54 UTC
2b2dabc Merge branch 'fixes' 18 October 2005, 00:41:37 UTC
82ed2bc Merge branch 'fixes' 18 October 2005, 00:39:11 UTC
fd25c82 git-checkout-index: documentation updates. Now the behaviour of '-a' has been straightened out, document it. Signed-off-by: Junio C Hamano <junkio@cox.net> 18 October 2005, 00:38:09 UTC
a65a686 make checkout-index '-a' flag saner. 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> 18 October 2005, 00:32:12 UTC
2578519 Do not quote SP. 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> 17 October 2005, 20:34:42 UTC
622ef9d ref-format documentation. Signed-off-by: Junio C Hamano <junkio@cox.net> 17 October 2005, 05:41:59 UTC
b8041fe Sparse-directory safety fix. 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> 16 October 2005, 21:09:50 UTC
f865a2a Merge branch 'fixes' 16 October 2005, 19:23:59 UTC
b71d01e Merge branch 'fixes' 16 October 2005, 19:21:38 UTC
a34484e We do not depend on patch. 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> 16 October 2005, 19:01:28 UTC
back to top