Staging
v0.5.1
swh:1:snp:c5feb7ee9221a3820c8879e85e8a18470c0b3afa

sort by:
Revision Author Date Message Commit Date
b6da18b GIT 1.5.1-rc2 Signed-off-by: Junio C Hamano <junkio@cox.net> 26 March 2007, 01:01:50 UTC
0b59451 git-svn: fix rel_path() when not connected to the repository root This should fix fetching for people who did not use "git svn --minimize" or cannot connect to the repository root due to the lack of permissions. I'm not sure what I was on when I made the change to the rel_path() function in 4e9f6cc78e5d955bd0faffe76ae9aea6590189f1 that made it die() when we weren't connected to the repository root :x Thanks to Sven Verdoolaege for reporting this bug. Signed-off-by: Junio C Hamano <junkio@cox.net> 26 March 2007, 01:01:28 UTC
3301521 use xmalloc in git.c and help.c Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 26 March 2007, 01:00:23 UTC
3a81b9f Merge branch 'jc/fpl' * jc/fpl: git-log --first-parent: show only the first parent log 26 March 2007, 00:47:07 UTC
620d3f4 Update README to point at a few key periodical messages to the list They give a good starting point to new people who want to get involved. This owes suggestions by Martin Langhoff and Steven Grimm. Signed-off-by: Junio C Hamano <junkio@cox.net> 26 March 2007, 00:42:32 UTC
2603fa5 Merge branch 'maint' * maint: user-manual: introduce "branch" and "branch head" differently glossary: clean up cross-references glossary: stop generating automatically user-manual: Use def_ instead of ref_ for glossary references. user-manual.txt: fix a tiny typo. user-manual: run xsltproc without --nonet option 25 March 2007, 22:08:11 UTC
fd2a759 Merge branch 'maint' of git://linux-nfs.org/~bfields/git into maint * 'maint' of git://linux-nfs.org/~bfields/git: user-manual: introduce "branch" and "branch head" differently glossary: clean up cross-references glossary: stop generating automatically user-manual: Use def_ instead of ref_ for glossary references. user-manual.txt: fix a tiny typo. user-manual: run xsltproc without --nonet option 25 March 2007, 22:07:27 UTC
c5a07b3 Merge branch 'js/remote-show-push' * js/remote-show-push: Teach git-remote to list pushed branches. 25 March 2007, 08:45:06 UTC
12d6697 Merge branch 'maint' * maint: gitweb: Add some installation notes in gitweb/INSTALL gitweb: Fix not marking signoff lines in "log" view gitweb: Don't escape attributes in CGI.pm HTML methods gitweb: Change to use explicitly function call cgi->escapHTML() 25 March 2007, 07:21:40 UTC
06aff47 Use diff* with --exit-code in git-am, git-rebase and git-merge-ours This simplifies the shell code, reduces its memory footprint, and speeds things up. The performance improvements should be noticable when git-rebase works on big commits. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 06:01:36 UTC
2a18c26 Document --quiet option to git-diff Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:32:55 UTC
b5b8d81 write_sha1_from_fd() should make new objects read-only ... like it is done everywhere else. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:32:41 UTC
0e55181 make it more obvious that temporary files are temporary files When some operations are interrupted (or "die()'d" or crashed) then the partial object/pack/index file may remain around. Make it more obvious in their name that those files are temporary stuff and can be cleaned up if no operation is in progress. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:32:39 UTC
46d409d update-hook: remove e-mail sending hook. The update hook's only job is to decide is a particular update is allowed or not. It was not the right place to send out update notification e-mails from to begin with, as the final stage of updating refs can fail after this hook runs. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:30:53 UTC
cd67c8e gitweb: Add some installation notes in gitweb/INSTALL Add some installation and configuration notes for gitweb in gitweb/INSTALL. Make use of filling gitweb configuration by Makefile. It does not cover (yet?) all the configuration variables and options. Some of contents duplicates information in gitweb/README file (it is referred from gitweb/INSTALL). Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:26:33 UTC
4ae89b7 gitweb: Fix not marking signoff lines in "log" view The CSS selector for signoff lines style was too strict: in the "log" view the commit message is not encompassed in container "page_body" div. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:25:55 UTC
346d5e1 gitweb: Don't escape attributes in CGI.pm HTML methods There is no need to escape HTML tag's attributes in CGI.pm HTML methods (like CGI::a()), because CGI.pm does attribute escaping automatically. $cgi->a({ ... -attribute => atribute_value }, tag_contents) is translated to <a ... attribute="attribute_value">tag_contents</a> The rules for escaping attribute values (which are string contents) are different. For example you have to take care about escaping embedded '"' and "'" characters; CGI::a() does that for us automatically. CGI::a() does not HTML escape tag_contents; we would need to write <a href="URL">some <b>bold</b> text</a> for example. So we use esc_html (or esc_path) to escape tag_contents as needed. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:25:47 UTC
290b146 gitweb: Change to use explicitly function call cgi->escapHTML() Change to use explicitly function call cgi->escapHTML(). This fix the problem on some systems that escapeHTML() is not functioning, as default CGI is not setting 'escape' parameter. Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:25:40 UTC
2499857 git-am documentation: describe what is taken from where. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 10:08:54 UTC
e43b010 git-revert: Revert revert message to old behaviour When converting from the shell script, based on a misreading of the sed invocation, the builtin included the abbreviated commit name, and did _not_ include the quotes around the oneline message. This fixes it. [jc: with a fix for the typo/thinko spotted by Linus, and also removing the unwanted abbrev at the beginning.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 09:50:22 UTC
b08bbae Merge branch 'maint' * maint: gitweb: Fix "next" link in commit view 24 March 2007, 06:29:37 UTC
6cea055 Documentation: bisect: make a comment fit better in the man page. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 06:29:29 UTC
1207f9e Documentation: bisect: add some titles to some paragraphs. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 06:29:09 UTC
fed820a Documentation: bisect: reformat more paragraphs. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 06:26:11 UTC
cc070d1 Documentation: bisect: reword one paragraph. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 06:26:02 UTC
7891a28 Documentation: bisect: reformat some paragraphs. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 06:25:54 UTC
a4e9d71 Fix path-limited "rev-list --bisect" termination condition. In a path-limited bisection, when the $bad commit is not changing the limited path, and the number of suspects is 1, the code miscounted and returned $bad from find_bisection(), which is not marked with TREECHANGE. This is of course filtered by the output routine, resulting in an empty output, in turn causing git-bisect driver to say "$bad was both good and bad". Illustration. Suppose you have these four commits, and only C changes path P. You know D is bad and A is good. A---B---C*--D git-bisect driver runs this to find a bisection point: $ git rev-list --bisect A..D -- P which calls find_bisection() with B, C and D. The set of commits that is given to this function is the same set of commits as rev-list without --bisect option and pathspec returns. Among them, only C is marked with TREECHANGE. Let's call the set of commits given to find_bisection() that are marked with TREECHANGE (or all of them if no path limiter is in effect) "the bisect set". In the above example, the size of the bisect set is 1 (contains only "C"). For each commit in its input, find_bisection() computes the number of commits it can reach in the bisect set. For a commit in the bisect set, this number includes itself, so the number is 1 or more. This number is called "depth", and computed by count_distance() function. When you have a bisect set of N commits, and a commit has depth D, how good is your bisection if you returned that commit? How good this bisection is can be measured by how many commits are effectively tested "together" by testing one commit. Currently you have (N-1) untested commits (the tip of the bisect set, although it is included in the bisect set, is already known to be bad). If the commit with depth D turns out to be bad, then your next bisect set will have D commits and you will have (D-1) untested commits left, which means you tested (N-1)-(D-1) = (N-D) commits with this bisection. If it turns out to be good, then your next bisect set will have (N-D) commits, and you will have (N-D-1) untested commits left, which means you tested (N-1)-(N-D-1) = D commits with this bisection. Therefore, the goodness of this bisection is is min(N-D, D), and find_bisection() function tries to find a commit that maximizes this, by initializing "closest" variable to 0 and whenever a commit with the goodness that is larger than the current "closest" is found, that commit and its goodness are remembered by updating "closest" variable. The "the commit with the best goodness so far" is kept in "best" variable, and is initialized to a commit that happens to be at the beginning of the list of commits given to this function (which may or may not be in the bisect set when path-limit is in use). However, when N is 1, then the sole tree-changing commit has depth of 1, and min(N-D, D) evaluates to 0. This is not larger than the initial value of "closest", and the "so far the best one" commit is never replaced in the loop. When path-limit is not in use, this is not a problem, as any commit in the input set is tree-changing. But when path-limit is in use, and when the starting "bad" commit does not change the specified path, it is not correct to return it. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 00:20:43 UTC
f9308a1 gitweb: Fix "next" link in commit view Fix copy'n'paste error in commit c9d193df which caused that "next" link for merge commits in "commit" view (merge: _commit_ _commit_ ...) was to "commitdiff" view instead of being to "commit" view. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 21:54:52 UTC
12cb813 git-bisect.sh: properly dq $GIT_DIR Otherwise you would be in trouble if your GIT_DIR has IFS letters in it. Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 20:29:55 UTC
673e583 git-bisect: typofix The branch you are on while bisecting is always "bisect", and checking for "refs/heads/bisect*" is wrong. Only check if it is exactly "refs/heads/bisect". Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 20:15:21 UTC
abba9db checkout: report where the new HEAD is upon detaching HEAD After "git reset" moves the HEAD around, it reports which commit you are on, which gives the user a warm fuzzy feeling of assurance. Give the same assurance from git-checkout when moving the detached HEAD around. Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 09:48:09 UTC
a17c410 Bisect: implement "git bisect run <cmd>..." to automatically bisect. This idea was suggested by Bill Lear (Message-ID: <17920.38942.364466.642979@lisa.zopyra.com>) and I think it is a very good one. This patch adds a new test file for "git bisect run", but there is currently only one basic test. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 08:54:47 UTC
cc65343 Bisect: convert revs given to good and bad to commits Without this the rev could be (e.g.) a tag and then the condition to end the bisect might fail and you have to check the already known to be bad revision once more. Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 08:48:29 UTC
3007a78 t4118: be nice to non-GNU sed Elias Pipping: > I'm on a mac, hence /usr/bin/sed is not gnu sed, which makes > t4118 fail. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Ack'd-by: Elias Pipping <pipping@macports.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 01:08:37 UTC
cc96fd0 git-apply: Do not free the wrong buffer when we convert the data for writeout When we write out the result of patch application, we sometimes need to munge the data (e.g. under core.autocrlf). After doing so, what we should free is the temporary buffer that holds the converted data returned from convert_to_working_tree(), not the original one. This patch also moves the call to open() up in the function, as the caller expects us to fail cheaply if leading directories need to be created (and then the caller creates them and calls us again). For that calling pattern, attempting conversion before opening the file adds unnecessary overhead. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 00:32:51 UTC
00cec84 Merge git://git2.kernel.org/pub/scm/gitk/gitk * git://git2.kernel.org/pub/scm/gitk/gitk: [PATCH] prefer "git COMMAND" over "git-COMMAND" in gitk 22 March 2007, 10:05:34 UTC
aa576e6 Merge branch 'maint' * maint: Documentation/pack-format.txt: Clear up description of types. fix typo in git-am manpage 22 March 2007, 10:05:25 UTC
979ea58 Documentation/pack-format.txt: Clear up description of types. Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net> 22 March 2007, 10:05:19 UTC
605fac8 update HEAD reflog when branch pointed to by HEAD is directly modified The HEAD reflog is updated as well as the reflog for the branch pointed to by HEAD whenever it is referenced with "HEAD". There are some cases where a specific branch may be modified directly. In those cases, the HEAD reflog should be updated as well if it is a symref to that branch in order to be consistent. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 22 March 2007, 10:02:48 UTC
0a0d080 update-hook: abort early if the project description is unset It was annoying to always have the first email from a project be from the "Unnamed repository; edit this file to name it for gitweb project"; just because it's so easy to forget to set it. This patch checks to see if the description file is still default (or empty) and aborts if so - allowing you to fix the problem before sending out silly looking emails to every developer. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 22 March 2007, 10:02:31 UTC
85295a5 git-merge: Put FETCH_HEAD data in merge commit message This makes git-fetch <URL> && git-merge FETCH_HEAD produce the same merge message as git-pull <URL>. Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il> Signed-off-by: Junio C Hamano <junkio@cox.net> 22 March 2007, 10:01:43 UTC
a1bf91e git-rebase: make 'rebase HEAD branch' work as expected. When you want to amend the commit message of 3 commits before the tip of the current branch, say 'master', A--B--C--D--E(master) it is sometimes handy to make your head detached at that commit with: $ git checkout HEAD~3 ;# check out B $ git commit --amend ;# without modifying contents... to create: .B'(HEAD) / A--B--C--D--E(master) and then rebase 'master' branch onto HEAD with this: $ git rebase HEAD master to result in: .B'-C'-D'-E(master=HEAD) / A--B--C--D--E However, the current code interprets HEAD after it switches to the branch 'master', which means the rebase will not do anything. You have to say something unwieldly like this instead: $ git rebase $(git rev-parse HEAD) master This fixes it by expanding the $onto commit name before switching to the target branch. Signed-off-by: Junio C Hamano <junkio@cox.net> 22 March 2007, 09:56:53 UTC
1d848f6 tree_entry_interesting(): allow it to say "everything is interesting" In addition to optimizing pathspecs that would never match, which was done earlier, this optimizes pathspecs that would always match (e.g. "arch/" while the traversal is already in "arch/i386/" hierarchy). This patch makes the worst case slightly more palatable, while improving average case. Signed-off-by: Junio C Hamano <junkio@cox.net> 22 March 2007, 07:36:00 UTC
ccc744a tree-diff: avoid strncmp() If we already know that some of the pathspecs can match later entries in the tree we are looking at, we do not have to do more expensive strncmp() upfront before comparing the length of the match pattern and the path, as a path longer than the match pattern will not match it, and a path shorter than the match pattern will match only if the path is a directory-component wise prefix of the match pattern. Signed-off-by: Junio C Hamano <junkio@cox.net> 22 March 2007, 07:34:39 UTC
7d2f667 Teach tree_entry_interesting() that the tree entries are sorted. When we are looking at a tree entry with pathspecs, if all the pathspecs sort strictly earlier than the entry we are currently looking at, there is no way later entries in the same tree would match our pathspecs, because the entries are sorted. Signed-off-by: Junio C Hamano <junkio@cox.net> 22 March 2007, 07:29:49 UTC
4651ece Switch over tree descriptors to contain a pre-parsed entry This makes the tree descriptor contain a "struct name_entry" as part of it, and it gets filled in so that it always contains a valid entry. On some benchmarks, it improves performance by up to 15%. That makes tree entry "extract" trivial, and means that we only actually need to decode each tree entry just once: we decode the first one when we initialize the tree descriptor, and each subsequent one when doing "update_tree_entry()". In particular, this means that we don't need to do strlen() both at extract time _and_ at update time. Finally, it also allows more sharing of code (entry_extract(), that wanted a "struct name_entry", just got totally trivial, along with the "tree_entry()" function). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 March 2007, 18:15:26 UTC
6fda5e5 Initialize tree descriptors with a helper function rather than by hand. This removes slightly more lines than it adds, but the real reason for doing this is that future optimizations will require more setup of the tree descriptor, and so we want to do it in one place. Also renamed the "desc.buf" field to "desc.buffer" just to trigger compiler errors for old-style manual initializations, making sure I didn't miss anything. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 March 2007, 17:21:57 UTC
a8c4047 Remove "pathlen" from "struct name_entry" Since we have the "tree_entry_len()" helper function these days, and don't need to do a full strlen(), there's no point in saving the path length - it's just redundant information. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 March 2007, 17:21:56 UTC
1ce09dd [PATCH] prefer "git COMMAND" over "git-COMMAND" in gitk Preferring git _space_ COMMAND over git _dash_ COMMAND allows the user to have only git and gitk in their path. e.g. when git and gitk are symbolic links in a personal bin directory to the real git and gitk. Signed-off-by: Paul Mackerras <paulus@samba.org> 21 March 2007, 11:02:19 UTC
a947ab7 fix typo in git-am manpage Fix typo in git-am manpage Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 March 2007, 09:22:28 UTC
171dccd blame: cmp_suspect is not "cmp" anymore. The earlier round makes the function return "is it different" and it does not return a value suitable for sorting anymore. Reverse the logic to return "are they the same suspect" instead, and rename it to "same_suspect()". Signed-off-by: Junio C Hamano <junkio@cox.net> 21 March 2007, 06:37:51 UTC
3254d21 minor git-prune optimization Don't try to remove the containing directory for every pruned object but try only once after the directory has been scanned instead. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 March 2007, 05:17:47 UTC
5721685 improve checkout message when asking for same branch Change the feedback message if doing 'git checkout foo' when already on branch "foo". Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 March 2007, 05:17:44 UTC
ac54c27 Be more careful about zlib return values When creating a new object, we use "deflate(stream, Z_FINISH)" in a loop until it no longer returns Z_OK, and then we do "deflateEnd()" to finish up business. That should all work, but the fact is, it's not how you're _supposed_ to use the zlib return values properly: - deflate() should never return Z_OK in the first place, except if we need to increase the output buffer size (which we're not doing, and should never need to do, since we pre-allocated a buffer that is supposed to be able to hold the output in full). So the "while()" loop was incorrect: Z_OK doesn't actually mean "ok, continue", it means "ok, allocate more memory for me and continue"! - if we got an error return, we would consider it to be end-of-stream, but it could be some internal zlib error. In short, we should check for Z_STREAM_END explicitly, since that's the only valid return value anyway for the Z_FINISH case. - we never checked deflateEnd() return codes at all. Now, admittedly, none of these issues should ever happen, unless there is some internal bug in zlib. So this patch should make zero difference, but it seems to be the right thing to do. We should probablybe anal and check the return value of "deflateInit()" too! Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 March 2007, 05:17:32 UTC
acdeec6 Don't ever return corrupt objects from "parse_object()" Looking at the SHA1 validation code due to the corruption that Alexander Litvinov is seeing under Cygwin, I notice that one of the most central places where we read objects, we actually do end up verifying the SHA1 of the result, but then we happily parse it anyway. And using "printf" to write the error message means that it not only can get lost, but will actually mess up stdout, and cause other strange and hard-to-debug failures downstream. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 March 2007, 05:17:17 UTC
9096c66 index-pack: more validation checks and cleanups When appending objects to a pack, make sure the appended data is really what we expect instead of simply loading potentially corrupted objects and legitimating them by computing a SHA1 of that corrupt data. With this the sha1_object() can lose its test_for_collision parameter which is now redundent. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 March 2007, 05:09:59 UTC
ce9fbf1 index-pack: use hash_sha1_file() Use hash_sha1_file() instead of duplicating code to compute object SHA1. While at it make it accept a const pointer. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 March 2007, 05:09:57 UTC
8685da4 don't ever allow SHA1 collisions to exist by fetching a pack Waaaaaaay back Git was considered to be secure as it never overwrote an object it already had. This was ensured by always unpacking the packfile received over the network (both in fetch and receive-pack) and our already existing logic to not create a loose object for an object we already have. Lately however we keep "large-ish" packfiles on both fetch and push by running them through index-pack instead of unpack-objects. This would let an attacker perform a birthday attack. How? Assume the attacker knows a SHA-1 that has two different data streams. He knows the client is likely to have the "good" one. So he sends the "evil" variant to the other end as part of a "large-ish" packfile. The recipient keeps that packfile, and indexes it. Now since this is a birthday attack there is a SHA-1 collision; two objects exist in the repository with the same SHA-1. They have *very* different data streams. One of them is "evil". Currently the poor recipient cannot tell the two objects apart, short of by examining the timestamp of the packfiles. But lets say the recipient repacks before he realizes he's been attacked. We may wind up packing the "evil" version of the object, and deleting the "good" one. This is made *even more likely* by Junio's recent rearrange_packed_git patch (b867092f). It is extremely unlikely for a SHA1 collisions to occur, but if it ever happens with a remote (hence untrusted) object we simply must not let the fetch succeed. Normally received packs should not contain objects we already have. But when they do we must ensure duplicated objects with the same SHA1 actually contain the same data. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 March 2007, 05:08:25 UTC
8bf0e3d Teach git-remote to list pushed branches. The configured refspecs are printed almost verbatim, i.e. both the local and the remote branch name separated by a colon are printed; only the prefix 'refs/heads/' is removed, like this: Local branch(es) pushed with 'git push' master refs/tags/*:refs/tags/* next:next Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <junkio@cox.net> 20 March 2007, 08:54:49 UTC
08727ea git-fetch: Fix single_force in append_fetch_head This fixes the single force (+) when fetched with fetch_per_ref. Also use $LF as separator because IFS is $LF. Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 20 March 2007, 08:52:11 UTC
bb95e19 Merge git://git2.kernel.org/pub/scm/gitk/gitk * git://git2.kernel.org/pub/scm/gitk/gitk: [PATCH] gitk: bind <F5> key to Update (reread commits) 20 March 2007, 06:47:22 UTC
7e8c825 make git clone -q suppress the noise with http fetch We already have -q in git clone. So for those who care to suppress the noise during an http based clone, make -q actually do a quiet http fetch. Signed-off-by: Chris Wright <chrisw@sous-sol.org> Cc: Fernando Herrera <fherrera@onirica.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 20 March 2007, 06:46:30 UTC
456cdf6 Fix loose object uncompression check. The thing is, if the output buffer is empty, we should *still* actually use the zlib routines to *unpack* that empty output buffer. But we had a test that said "only unpack if we still expect more output". So we wouldn't use up all the zlib stream, because we felt that we didn't need it, because we already had all the bytes we wanted. And it was "true": we did have all the output data. We just needed to also eat all the input data! We've had this bug before - thinking that we don't need to inflate() anything because we already had it all.. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 20 March 2007, 06:13:17 UTC
3e993bb contrib/continuous: a continuous integration build manager This is a simple but powerful continuous integration build system for Git. It works by receiving push events from repositories through the post-receive hook, aggregates them on a per-branch basis into a first-come-first-serve build queue, and lets a background build daemon perform builds one at a time. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 20 March 2007, 05:21:19 UTC
1b89ef1 Provide some technical documentation for shallow clones There has not been any work on the shallow stuff lately, so it is hard to find out what it does, and how. This document describes the ideas as well as the current problems, and can serve as a starting point for shallow people. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 20 March 2007, 05:19:29 UTC
e29b96d Add a HOWTO for setting up a standalone git daemon Setting up a git-daemon came up the other day on IRC, and it is slightly non trivial for the uninitiated. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 20 March 2007, 05:17:38 UTC
824f782 xdiff/xutils.c(xdl_hash_record): factor out whitespace handling Since in at least one use case, xdl_hash_record() takes over 15% of the CPU time, it makes sense to even micro-optimize it. For many cases, no whitespace special handling is needed, and in these cases we should not even bother to check for whitespace in _every_ iteration of the loop. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 20 March 2007, 05:17:25 UTC
57584d9 blame: micro-optimize cmp_suspect() The commit structures are guaranteed their uniqueness by the object layer, so we can check their address and see if they are the same without going down to the object sha1 level. Signed-off-by: Junio C Hamano <junkio@cox.net> 20 March 2007, 05:17:10 UTC
567fb65 Replace remaining instances of strdup with xstrdup. Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 20 March 2007, 01:16:03 UTC
5e08ecb use a LRU eviction policy for the delta base cache This provides a smoother degradation in performance when the cache gets trashed due to the delta_base_cache_limit being reached. Limited testing with really small delta_base_cache_limit values appears to confirm this. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 20 March 2007, 01:16:02 UTC
3358004 clean up the delta base cache size a bit Currently there are 3 different ways to deal with the cache size. Let's stick to only one. The compiler is smart enough to produce the exact same code in those cases anyway. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 20 March 2007, 01:15:59 UTC
ceb8442 GIT 1.5.1-rc1 I think we can start to slow down, as we now have covered everything I listed earlier in the short-term release plan. The last release 1.5.0 took painfully too long. Signed-off-by: Junio C Hamano <junkio@cox.net> 19 March 2007, 09:56:29 UTC
843d49a Fix merge-index An earlier conversion to run_command() from execlp() forgot that run_command() takes an array that is terminated with NULL. Signed-off-by: Junio C Hamano <junkio@cox.net> 19 March 2007, 09:48:37 UTC
5d86501 Set up for better tree diff optimizations This is mainly just a cleanup patch, and sets up for later changes where the tree-diff.c "interesting()" function can return more than just a yes/no value. In particular, it should be quite possible to say "no subsequent entries in this tree can possibly be interesting any more", and thus allow the callers to short-circuit the tree entirely. In fact, changing the callers to do so is trivial, and is really all this patch really does, because changing "interesting()" itself to say that nothing further is going to be interesting is definitely more complicated, considering that we may have arbitrary pathspecs. But in cleaning up the callers, this actually fixes a potential small performance issue in diff_tree(): if the second tree has a lot of uninterestign crud in it, we would keep on doing the "is it interesting?" check on the first tree for each uninteresting entry in the second one. The answer is obviously not going to change, so that was just not helping. The new code is clearer and simpler and avoids this issue entirely. I also renamed "interesting()" to "tree_entry_interesting()", because I got frustrated by the fact that - we actually had *another* function called "interesting()" in another file, and I couldn't tell from the profiles which one was the one that mattered more. - when rewriting it to return a ternary value, you can't just do if (interesting(...)) ... any more, but want to assign the return value to a local variable. The name of choice for that variable would normally be "interesting", so I just wanted to make the function name be more specific, and avoid that whole issue (even though I then didn't choose that name for either of the users, just to avoid confusion in the patch itself ;) In other words, this doesn't really change anything, but I think it's a good thing to do, and if somebody comes along and writes the logic for "yeah, none of the pathspecs you have are interesting", we now support that trivially. It could easily be a meaningful optimization for things like "blame", where there's just one pathspec, and stopping when you've seen it would allow you to avoid about 50% of the tree traversals on average. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 March 2007, 09:01:39 UTC
c711a21 Trivial cleanup of track_tree_refs() This makes "track_tree_refs()" use the same "tree_entry()" function for counting the entries as it does for actually traversing them a few lines later. Not a biggie, but the reason I care was that this was the only user of "update_tree_entry()" that didn't actually *extract* the tree entry first. It doesn't matter as things stand now, but it meant that a separate test-patch I had that avoided a few more "strlen()" calls by just saving the entry length in the entry descriptor and using it directly when updating wouldn't work without this patch. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 March 2007, 08:48:56 UTC
d55552f git.el: Add support for commit hooks. Run the pre-commit and post-commit hooks at appropriate places, and display their output if any. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 March 2007, 08:40:27 UTC
94b9816 Merge branch 'jb/gc' * jb/gc: Make gc a builtin. 19 March 2007, 05:46:30 UTC
de5e61e Merge branch 'fl/cvsserver' * fl/cvsserver: cvsserver: further improve messages on commit and status cvsserver: Be more chatty 19 March 2007, 05:44:25 UTC
18bdec1 Limit the size of the new delta_base_cache The new configuration variable core.deltaBaseCacheLimit allows the user to control how much memory they are willing to give to Git for caching base objects of deltas. This is not normally meant to be a user tweakable knob; the "out of the box" settings are meant to be suitable for almost all workloads. We default to 16 MiB under the assumption that the cache is not meant to consume all of the user's available memory, and that the cache's main purpose was to cache trees, for faster path limiters during revision traversal. Since trees tend to be relatively small objects, this relatively small limit should still allow a large number of objects. On the other hand we don't want the cache to start storing 200 different versions of a 200 MiB blob, as this could easily blow the entire address space of a 32 bit process. We evict OBJ_BLOB from the cache first (credit goes to Junio) as we want to favor OBJ_TREE within the cache. These are the objects that have the highest inflate() startup penalty, as they tend to be small and thus don't have that much of a chance to ammortize that penalty over the entire data. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 March 2007, 05:43:37 UTC
3635a18 Merge branch 'sp/run-command' * sp/run-command: Use run_command within send-pack Use run_command within receive-pack to invoke index-pack Use run_command within merge-index Use run_command for proxy connections Use RUN_GIT_CMD to run push backends Correct new compiler warnings in builtin-revert Replace fork_with_pipe in bundle with run_command Teach run-command to redirect stdout to /dev/null Teach run-command about stdout redirection 19 March 2007, 05:21:06 UTC
abec100 Make git-send-email aware of Cc: lines. In the Linux kernel, for example, it's common to include Cc: lines for cases when you want to remember to cc someone on a patch without necessarily claiming they signed off on it. Make git-send-email aware of these. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 March 2007, 04:10:03 UTC
81b6c95 user-manual: introduce "branch" and "branch head" differently I was using "branch" to mean "head", but that's perhaps a little sloppy; so instead start by using the terms "branch head" and "head", while still quickly falling back on "branch", since that's what people actually say more frequently. Also include glossary references on the first uses of "head" and "tag". Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 19 March 2007, 03:06:00 UTC
cbd9192 glossary: clean up cross-references Manual clean-up of cross-references, and also clean up a few definitions (e.g. git-rebase). Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 19 March 2007, 03:06:00 UTC
f562e6f glossary: stop generating automatically The sort_glossary.pl script sorts the glossary, checks for duplicates, and automatically adds cross-references. But it's not so hard to do all that by hand, and sometimes the automatic cross-references are a little wrong; so let's run the script one last time and check in its output. Note: to make the output fit better into the user manual I also deleted the acknowledgements at the end, which was maybe a little rude; feel free to object and I can find a different solution. Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 19 March 2007, 03:06:00 UTC
d6678c2 mergetool: print an appropriate warning if merge.tool is unknown Also add support for vimdiff Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> 19 March 2007, 02:30:10 UTC
9cec653 mergetool: Add support for vimdiff. Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> 19 March 2007, 02:13:48 UTC
06e7ea3 user-manual: Use def_ instead of ref_ for glossary references. I'd like to start using references to the glossary in the user manual. The "ref_" prefix for these references seems a little generic; so replace with "def_". Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 19 March 2007, 01:53:50 UTC
21f13ee user-manual.txt: fix a tiny typo. "file patch" was doubtless intended to be "file path", but "directory name" is clearer. Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 19 March 2007, 01:53:29 UTC
0a3985d user-manual: run xsltproc without --nonet option The --nonet option prevents xsltproc from going to the network to find anything. But it always tries to find them locally first, so for a user with the necessary docbook stylesheets installed the build will work just fine without xsltproc attempting to use the network; all --nonet does is make it fail rather than falling back on that. That doesn't seem particularly helpful. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 19 March 2007, 01:53:19 UTC
7976ce1 Update main git.html page to point at 1.5.0.5 documentation Signed-off-by: Junio C Hamano <junkio@cox.net> 18 March 2007, 22:58:07 UTC
d54fe39 Merge branch 'ar/diff' * ar/diff: Add tests for --quiet option of diff programs try-to-simplify-commit: use diff-tree --quiet machinery. revision.c: explain what tree_difference does Teach --quiet to diff backends. diff --quiet Remove unused diffcore_std_no_resolve Allow git-diff exit with codes similar to diff(1) 18 March 2007, 22:48:06 UTC
304de2d Avoid unnecessary strlen() calls This is a micro-optimization that grew out of the mailing list discussion about "strlen()" showing up in profiles. We used to pass regular C strings around to the low-level tree walking routines, and while this worked fine, it meant that we needed to call strlen() on strings that the caller always actually knew the size of anyway. So pass the length of the string down wih the string, and avoid unnecessary calls to strlen(). Also, when extracting a pathname from a tree entry, use "tree_entry_len()" instead of strlen(), since the length of the pathname is directly calculable from the decoded tree entry itself without having to actually do another strlen(). This shaves off another ~5-10% from some loads that are very tree intensive (notably doing commit filtering by a pathspec). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>" Signed-off-by: Junio C Hamano <junkio@cox.net> 18 March 2007, 22:36:59 UTC
a0cba10 Reuse cached data out of delta base cache. A malloc() + memcpy() will always be faster than mmap() + malloc() + inflate(). If the data is already there it is certainly better to copy it straight away. With this patch below I can do 'git log drivers/scsi/ > /dev/null' about 7% faster. I bet it might be even more on those platforms with bad mmap() support. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 March 2007, 22:36:59 UTC
e5e0161 Implement a simple delta_base cache This trivial 256-entry delta_base cache improves performance for some loads by a factor of 2.5 or so. Instead of always re-generating the delta bases (possibly over and over and over again), just cache the last few ones. They often can get re-used. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 March 2007, 22:36:59 UTC
62f255a Make trivial wrapper functions around delta base generation and freeing This doesn't change any code, it just creates a point for where we'd actually do the caching of delta bases that have been generated. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 March 2007, 22:36:59 UTC
5bb44a5 Merge 1.5.0.5 in from 'maint' 18 March 2007, 22:36:44 UTC
6bf035f GIT 1.5.0.5 Signed-off-by: Junio C Hamano <junkio@cox.net> 18 March 2007, 21:43:29 UTC
6757ada Make gc a builtin. Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 March 2007, 07:34:19 UTC
1589e05 Merge branch 'maint' * maint: git-merge: finish when git-read-tree fails 17 March 2007, 07:33:17 UTC
4287307 [PATCH] clean up pack index handling a bit Especially with the new index format to come, it is more appropriate to encapsulate more into check_packed_git_idx() and assume less of the index format in struct packed_git. To that effect, the index_base is renamed to index_data with void * type so it is not used directly but other pointers initialized with it. This allows for a couple pointer cast removal, as well as providing a better generic name to grep for when adding support for new index versions or formats. And index_data is declared const too while at it. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 March 2007, 04:27:36 UTC
back to top