swh:1:snp:6df5a50b8107b6bbe1e51d0239d816a7503c536a

sort by:
Revision Author Date Message Commit Date
235d521 GIT 0.99.9b This contains the changes made on the master branch since 0.99.9a. The workaround for building RPMs has not changed since 0.99.9a, mainly because I haven't heard back if it was good enough for kernel.org consumption, or otherwise what changes are needed. Signed-off-by: Junio C Hamano <junkio@cox.net> 02 November 2005, 05:58:53 UTC
8e6ae4a Add -P to the documentation head. This is a companion patch for 211dcac6430cdf77fcf2a968ffaf9313b5c059b0 commit, to add the newly introduced -P option to the list of options. Signed-off-by: Junio C Hamano <junkio@cox.net> 02 November 2005, 01:07:21 UTC
9acb552 cvsimport: cvsps should be quiet too Tell cvsps to be quiet, unless we've been told to be verbose. Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net> 02 November 2005, 00:57:53 UTC
211dcac cvsimport: introduce -P <cvsps-output-file> option -P:: <cvsps-output-file> Instead of calling cvsps, read the provided cvsps output file. Useful for debugging or when cvsps is being handled outside cvsimport. Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net> 02 November 2005, 00:57:38 UTC
d44e8cf cvsimport: catch error condition where cvs host disappears Add error handling for cases where the cvs server goes away unexpectedly. While I don't know why the cvs server is so erratic, we should definitely exit here before committing bogus files. Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net> 02 November 2005, 00:57:14 UTC
319f8b3 Do not install backward compatibility links anymore. This is a companion patch to 4f9dcf7e5cf6c82455925102d315daf3b833e6d6 which stops mentioning the old command names. As promised, we do not install symlinks to let people use backward compatibility names anymore. cmd-rename.sh script is still shipped to help people who installed previous git by hand to clean up the leftover symlinks. Signed-off-by: Junio C Hamano <junkio@cox.net> 02 November 2005, 00:46:38 UTC
f676fa7 Strip any trailing slash on destination argument Needed because generating a target paths will add another slash. This fixes e.g. "git-mv file dir/", which removed "file" from version control by renaming it to "dir//file", as git-update-index does not accept such paths. Thanks goes to Ben Lau for noting this bug. Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 01 November 2005, 22:45:49 UTC
085c1e2 git-am.txt is no stub anymore That notice was added by me for the emergency documentation, but Junio already expanded it to a full-fledged manual page. This patch removes the notice. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 01 November 2005, 22:45:49 UTC
3c64314 Documentation for git-fmt-merge-msg Simple description. It appears to be mostly internal command, but hey, it is (it seems) the only undocumented one, so let's fix it up... Also add a note about it to git-merge documentation. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 01 November 2005, 22:45:49 UTC
e3a3900 Remove git-findtags.perl This script was superseded by git-name-rev, which is more versatile, actually documented, faster, and everything else... Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 01 November 2005, 22:45:48 UTC
4f9dcf7 Remove 'Previously this command was known as ...' messages. For a 1.0 release, there is no need to maintain the historical "Previously this command was known as..." information on the doc splash page. It is noise; command names should stand on their own now. Signed-off-by: Jon Loeliger <jdl@freescale.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 01 November 2005, 22:45:48 UTC
77ab879 Fix constness of input in mozilla-sha1/sha1.c::SHA1_Update(). Among the three of our own implementations, only this one lacked "const" from the second argument. Signed-off-by: Junio C Hamano <junkio@cox.net> 01 November 2005, 22:05:12 UTC
710c97d Document the use of "current directory" as pull source. The repository to pull from can be a local repository, and as a special case the current directory can be specified to perform merges across local branches. Signed-off-by: Junio C Hamano <junkio@cox.net> 01 November 2005, 22:03:13 UTC
d92ddb5 Merge branch 'fixes' 01 November 2005, 02:08:22 UTC
bd66361 Add examples for git-log documentation and others. I don't think people really follow the links or think very abstractly at all in the first place. So I was thinking more of some explicit examples. I actually think every command should have an example in the man-page, and hey, here's a patch to start things off. Of course, I'm not exactly "Mr Documentation", and I don't know that this is the prettiest way to do this, but I checked that the resulting html and man-page seems at least reasonable. And hey, if the examples look like each other, that's just because I'm also not "Mr Imagination". Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 31 October 2005, 06:54:39 UTC
e634aec GIT 0.99.9a ... to contain the RPM workaround. Signed-off-by: Junio C Hamano <junkio@cox.net> 31 October 2005, 02:06:39 UTC
80e0c0a Work around an RPM build problem. The require statement at the top of git-svnimport seems to confuse rpmbuild dependency generation. It uses the newer notation "v5.8.0", and rpm ends up requiring "perl(v5.8.0)", while we would want it to say something like "perl >= 0:5.008". Ryan suggests old-style "require 5.008" might fix this problem, so here it is. Signed-off-by: Junio C Hamano <junkio@cox.net> 31 October 2005, 01:28:04 UTC
64b1f6e Fix rev-list documentation again (--sparse and pathspec) Signed-off-by: Junio C Hamano <junkio@cox.net> 31 October 2005, 01:28:03 UTC
12ea5be Update git-pack-objects documentation. Signed-off-by: Junio C Hamano <junkio@cox.net> 31 October 2005, 01:28:03 UTC
5a83f3b Update git-rev-list options list in rev-parse. Signed-off-by: Junio C Hamano <junkio@cox.net> 31 October 2005, 01:28:02 UTC
69e0c25 Update usage string and documentation for git-rev-list. Signed-off-by: Junio C Hamano <junkio@cox.net> 31 October 2005, 01:28:02 UTC
918db54 Add to usage and docs for git-add.sh Signed-off-by: Chris Shoemaker <c.shoemaker@cox.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 31 October 2005, 01:28:01 UTC
14470c0 Add to documentation of git-update-index arguments and usage. Removed unknown [--version] option. Signed-off-by: Chris Shoemaker <c.shoemaker@cox.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 31 October 2005, 01:28:01 UTC
b0bafe0 Add usage statement to git-checkout.sh Signed-off-by: Chris Shoemaker <c.shoemaker@cox.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 31 October 2005, 01:28:00 UTC
c2d07d2 GIT 0.99.9 master branch. Signed-off-by: Junio C Hamano <junkio@cox.net> 31 October 2005, 01:27:38 UTC
46774a8 GIT 0.99.9 Done in 0.99.9 ============== Ports ~~~~~ * Cygwin port [HPA]. * OpenBSD build [Merlyn and others]. Fixes ~~~~~ * clone request over git native protocol from a repository with too many refs did not work; this has been fixed. * git-daemon got safer for kernel.org use [HPA]. * Extended SHA1 parser was not enforcing uniqueness for abbreviated SHA1; this has been fixed. * http transport does not barf on funny characters in URL. * The ref naming restrictions have been formalized and the coreish refuses to create funny refs; we still need to audit importers. See git-check-ref-format(1). New Features and Commands ~~~~~~~~~~~~~~~~~~~~~~~~~ * .git/config file as a per-repository configuration mechanism, and some commands understand it [Linus]. See git(7). * The core.filemode configuration item can be used to make us a bit more FAT friendly. See git(7). * The extended SHA1 notation acquired Peel-the-onion operator ^{type} and ^{}. See git-rev-parse(1). * SVN importer [Matthias]. See git-svnimport(1). * .git/objects/[0-9a-f]{2} directories are created on demand, and removed when becomes empty after prune-packed [Linus]. * Filenames output from various commands without -z option are quoted when they embed funny characters (TAB and LF) using C-style quoting within double-quotes, to match the proposed GNU diff/patch notation [me, but many people contributed in the discussion]. * git-mv is expected to be a better replacement for git-rename. While the latter has two parameter restriction, it acts more like the regular 'mv' that can move multiple things to one destinatino directory [Josef Weidendorfer]. * git-checkout can take filenames to revert the changes to them. See git-checkout(1) * The new program git-am is a replacement for git-applymbox that has saner command line options and a bit easier to use when a patch does not apply cleanly. * git-ls-remote can show unwrapped onions using ^{} notation, to help Cogito to track tags. * git-merge-recursive backend can merge unrelated projects. * git-clone over native transport leaves the result packed. * git-http-fetch issues multiple requests in parallel when underlying cURL library supports it [Nick and Daniel]. * git-fetch-pack and git-upload-pack try harder to figure out better common commits [Johannes]. * git-read-tree -u removes a directory when it makes it empty. * git-diff-* records abbreviated SHA1 names of original and resulting blob; this sometimes helps to apply otherwise an unapplicable patch by falling back to 3-way merge. * git-format-patch now takes series of from..to rev ranges and with '-m --stdout', writes them out to the standard output. This can be piped to 'git-am' to implement cheaper cherry-picking. * git-tag takes '-u' to specify the tag signer identity [Linus]. * git-rev-list can take optional pathspecs to skip commits that do not touch them (--dense) [Linus]. * Comes with new and improved gitk [Paulus and Linus]. Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 21:35:11 UTC
5773c9f Documentation updates. Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 21:32:56 UTC
52e4478 Do not mmap-copy the whole thing; just use copy_fd() Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 20:11:36 UTC
0ffdbbf Teach local-fetch about lazy object directories. The latest init-db does not create .git/objects/??/ directories anymore and expects the users of the repository to create them as they are needed. local-fetch was not taught about it, which broke local cloning with Cogito. Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 20:02:18 UTC
a67c1d0 Fix recent documentation format breakage. Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 07:50:42 UTC
8d7d167 make t5501 less annoying On Linux, "mktemp tmp-XXXX" will not work. Also, redirect stderr on which, so it does not complain too loudly. After all, this test should only be executed when old binaries are available. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:57:01 UTC
1f5881b fix multi_ack. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:57:01 UTC
c4c86f0 git-fetch-pack: Support multi_ack extension The client side support for multi_ack. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:57:01 UTC
1bd8c8f git-upload-pack: Support the multi_ack protocol This implements three things (trying very hard to be backwards compatible): It sends the "multi_ack" capability via the mechanism proposed by Sergey Vlasov. When the client sends "multi_ack" with at least one "want", multi_ack is enabled. When multi_ack is enabled, "continue" is appended to each "ACK" until either the server can not store more refs, or "done" is received. In contrast to the original protocol, as long as "continue" is sent, flushes are answered by a "NAK" (not just until an "ACK" was sent), and if "continue" was sent at least once, the last message is an "ACK" without "continue". Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:57:00 UTC
211b5f9 Support receiving server capabilities This patch implements the client side of backward compatible upload-pack protocol extension, <20051027141619.0e8029f2.vsu@altlinux.ru> by Sergey. The updated server can append "server_capabilities" which is supposed to be a string containing space separated features of the server, after one of elements in the initial list of SHA1-refname line, hidden with an embedded NUL. After get_remote_heads(), check if the server supports the feature like if (server_supports("multi_ack")) do_something(); Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:57:00 UTC
f0243f2 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> 29 October 2005, 05:56:59 UTC
eebda31 Implement an interoperability test for fetch-pack/upload-pack The next patches will extend the pack protocol. This test assures that this extension is compatible to earlier versions of git-fetch-pack/git-upload-pack. All you need to do to take advantage of this test, is to install older known-to-be-working binaries in the path as "old-git-fetch-pack" and "old-git-upload-pack". Note that the warning when testing with old-git-fetch-pack is to be expected (it just says that the old version was not taking advantage of all the information which the server sent). Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:56:59 UTC
6b17c67 Implement a test for git-fetch-pack/git-upload-pack This test provides a minimal example of what went wrong with the old git-fetch-pack (and now works beautifully). Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:56:58 UTC
1baaae5 Make maximal use of the remote refs When git-fetch-pack gets the remote refs, it does not need to filter them right away, but it can see which refs are common (taking advantage of the patch which makes git-fetch-pack not use git-rev-list). This means that we ask get_remote_heads() to return all remote refs, including the funny refs, and filtering them with a separate function later. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:56:58 UTC
23d61f8 Subject: [PATCH] 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> 29 October 2005, 05:56:58 UTC
7d8b7c2 git-apply --numstat The new option, --numstat, shows number of inserted and deleted lines for each path. It is similar to --stat output but is meant to be more machine friendly by giving number of added and deleted lines and unabbreviated paths. Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:28:57 UTC
c485104 Add usage help to git-push.sh Also clarify failure to push to read-only remote. Especially, state why rsync:// is not used for pushing. [jc: ideally rsync should not be used for anything] Signed-off-by: Chris Shoemaker <c.shoemaker at cox.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:26:16 UTC
2f9d685 Add usage help for git-reset.sh Signed-off-by: Chris Shoemaker <c.shoemaker at cox.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:26:15 UTC
59df2a1 Minor clarifications in diffcore documentation Signed-off-by: Chris Shoemaker <c.shoemaker at cox.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:21:35 UTC
1cb7f22 Remove -r from common diff options documentation in one more place Signed-off-by: Chris Shoemaker <c.shoemaker at cox.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:21:32 UTC
0363ecf update usage string for git-commit.sh Signed-off-by: Chris Shoemaker <c.shoemaker at cox.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:21:29 UTC
f9362de git-push.sh: Retain cuteness, add helpfulness. Signed-off-by: Chris Shoemaker <c.shoemaker at cox.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 October 2005, 05:21:27 UTC
af13cdf Be more careful about reference parsing This does two things: - we don't allow "." and ".." as components of a refname. Thus get_sha1() will not accept "./refname" as being the same as "refname" any more. - git-rev-parse stops doing revision translation after seeing a pathname, to match the brhaviour of all the tools (once we see a pathname, everything else will also be parsed as a pathname). Basically, if you did git log * and "gitk" was somewhere in the "*", we don't want to replace the filename "gitk" with the SHA1 of the branch with the same name. Of course, if there is any change of ambiguity, you should always use "--" to make it explicit what are filenames and what are revisions, but this makes the normal cases sane. The refname rule also means that instead of the "--", you can do the same thing we're used to doing with filenames that start with a slash: use "./filename" instead, and now it's a filename, not an option (and not a revision). So "git log ./*.c" is now actually a perfectly valid thing to do, even if the first C-file might have the same name as a branch. Trivial test: git-rev-parse gitk ./gitk gitk should output something like 9843c3074dfbf57117565f6b7c93e3e6812857ee ./gitk gitk where the "./gitk" isn't seen as a revision, and the second "gitk" is a filename simply because we've seen filenames already, and thus stopped doing revision parsing. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 October 2005, 21:25:05 UTC
41f222e Be marginally more careful about removing objects The git philosophy when it comes to disk accesses is "Laugh in the face of danger". Notably, since we never modify an existing object, we don't really care that deeply about flushing things to disk, since even if the machine crashes in the middle of a git operation, you can never really have lost any old work. At most, you'd need to figure out the proper heads (which git-fsck-objects can do for you) and re-do the operation. However, there's two exceptions to this: pruning and repacking. Those operations will actually _delete_ old objects that they know about in other ways (ie that they just repacked, or that they have found in other places). However, since they actually modify old state, we should thus be a bit more careful about them. If the machine crashes and the duplicate new objects haven't been flushed to disk, you can actually be in trouble. This is trivially stupid about it by calling "sync" before removing the objects. Not very smart, but we're talking about special operations than are usually done once a week if that. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 October 2005, 21:25:02 UTC
50b8e35 Documentation changes to recursive option for git-diff-tree Update docs and usages regarding '-r' recursive option for git-diff-tree. Remove '-r' from common diff options, mention it only for git-diff-tree. Remove one extraneous use of '-r' with git-diff-files in get-merge.sh. Sync the synopsis and usage string for git-diff-tree. Signed-off-by: Chris Shoemaker <c.shoemaker at cox.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 October 2005, 20:37:38 UTC
f07a524 fix testsuite to tolerate spaces in path This patch allows the testsuite to run properly when the full path to the git sources contains spaces or other symbols that need to be quoted. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 October 2005, 09:59:01 UTC
a77a922 Document git-patch-id a bit better. Pavel Roskin wondered what the SHA1 output at the beginning of git-diff-tree was about. The only consumer of that information so far is this git-patch-id command, which was inadequately documented. Signed-off-by: Junio C Hamano <junkio@cox.net> 28 October 2005, 09:39:56 UTC
6d0de31 Add more generated files to .gitignore git-name-rev, git-mv and git-shell are recent additions to git. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 October 2005, 09:15:18 UTC
a60d2d8 Link git-name-rev and git-symbolic-ref from the main git page According to my checks, these were the only commands not yet linked. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 October 2005, 09:15:14 UTC
9106c09 Create object subdirectories on demand (phase II) This removes the unoptimization. The previous round does not mind missing fan-out directories, but still makes sure they exist, lest older versions choke on a repository created/packed by it. This round does not play that nicely anymore -- empty fan-out directories are not created by init-db, and will stay removed by prune-packed. The prune command also removes empty fan-out directories. Signed-off-by: Junio C Hamano <junkio@cox.net> 28 October 2005, 09:01:42 UTC
c1aaa5d Merge branch 'js-fat' 27 October 2005, 07:15:24 UTC
5ef1862 Merge branch 'lt-dense' 27 October 2005, 07:15:15 UTC
1301c6e Merge http://www.kernel.org/pub/scm/gitk/gitk 27 October 2005, 07:14:46 UTC
8b7e5d7 [PATCH] Make "gitk" work better with dense revlists To generate the diff for a commit, gitk used to do git-diff-tree -p -C $p $id (and same thing to generate filenames, except using just "-r" there) which does actually generate the diff from the parent to the $id, exactly like it meant to do. However, that really sucks with --dense, where the "parent" information has all been rewritten to point to the previous commit. The diff actually works exactly right, but now it's the diff of the _whole_ sequence of commits all the way to the previous commit that last changed the file(s) that we are looking at. And that's really not what we want 99.9% of the time, even if it may be perfectly sensible. Not only will the diff not actually match the commit message, but it will usually be _huge_, and all of it will be totally uninteresting to us, since we were only interested in a particular set of files. It also doesn't match what we do when we write the patch to a file. So this makes gitk just show the diff of _that_ commit. We might even want to have some way to limit the diff to only the filenames we're interested in, but it's often nice to see what else changed at the same time, so that's secondary. The merge diff handling is left alone, although I think that should also be changed to only look at what that _particular_ merge did, not what it did when compared to the faked-out parents. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org> 27 October 2005, 06:01:15 UTC
19a7e71 git-rev-list: do not forget non-commit refs What happens is that the new logic decides that if it can't look up a commit reference (ie "get_commit_reference()" returns NULL), the thing must be a pathname. Fair enough. But wrong. The thing is, it may be a perfectly fine ref that _isn't_ a commit. In git, you have a tag that points to your PGP key, and in the kernel, I have a tag that points to a tree (and a direct ref that points to that tree too, for that matter). So the rule is (as for all the other programs that mix revs and pathnames) not that we only accept commit references, but _any_ valid object ref. If the object then isn't a commit ref, git-rev-list will either ignore it, or add it to the list of non-commit objects (if using "--objects"). The solution is to move the "get_sha1()" out of get_commit_reference(), and into the callers. In fact, we already _have_ the SHA1 in the case of the handle_all() loop, since for_each_ref() will have done it for us, so this is the correct thing to do anyway. This patch (on top of the original one) does exactly that. Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 23:49:38 UTC
7b34c2f git-rev-list: make --dense the default (and introduce "--sparse") This actually does three things: - make "--dense" the default for git-rev-list. Since dense is a no-op if no filenames are given, this doesn't actually change any historical behaviour, but it's logically the right default (if we want to prune on filenames, do it fully. The sparse "merge-only" thing may be useful, but it's not what you'd normally expect) - make "git-rev-parse" show the default revision control before it shows any pathnames. This was a real bug, but nobody would ever have noticed, because the default thing tends to only make sense for git-rev-list, and git-rev-list didn't use to take pathnames. - it changes "git-rev-list" to match the other commands that take a mix of revisions and filenames - it no longer requires the "--" before filenames (although you still need to do it if a filename could be confused with a revision name, eg "gitk" in the git archive) This all just makes for much more pleasant and obvous usage. Just doing a gitk t/ does the obvious thing: it will show the history as it concerns the "t/" subdirectory. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 23:49:38 UTC
e24317b Test in git-init-db if the filemode can be trusted ... and if not, write an appropriate .git/config. Of course, that happens only if no config file was yet created (by a template or a hook). Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 23:48:26 UTC
bd321bc Add git-name-rev git-name-rev tries to find nice symbolic names for commits. It does so by walking the commits from the refs. When the symbolic name is ambiguous, the following heuristic is applied: Try to avoid too many ~'s, and if two ambiguous names have the same count of ~'s, take the one whose last number is smaller. With "--tags", the names are derived only from tags. With "--stdin", the stdin is parsed, and after every sha1 for which a name could be found, the name is appended. (Try "git log | git name-rev --stdin".) Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 23:31:58 UTC
f3123c4 pack-objects: Allow use of pre-generated pack. git-pack-objects can reuse pack files stored in $GIT_DIR/pack-cache directory, when a necessary pack is found. This is hopefully useful when upload-pack (called from git-daemon) is expected to receive requests for the same set of objects many times (e.g full cloning request of any project, or updates from the set of heads previous day to the latest for a slow moving project). Currently git-pack-objects does *not* keep pack files it creates for reusing. It might be useful to add --update-cache option to it, which would allow it store pack files it created in the pack-cache directory, and prune rarely used ones from it. Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 19:37:49 UTC
7ebb6fc Fix what to do and how to detect when hardlinking fails Recent FAT workaround caused compilation trouble on OpenBSD; different platforms use different error codes when we try to hardlink the temporary file to its final location. Existing Coda hack also checks its own error code, but the thing is, the case we care about is if link failed for a reason other than that the final file has already existed (which would be normal, or it could mean collision). So just check the error code against EEXIST. Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 18:58:24 UTC
b5c367f Fix cloning (memory corruption) upload-pack would set create_full_pack=1 if nr_has==0, but would ask later if nr_needs<MAX_NEEDS. If that proves true, it would ignore create_full_pack, and arguments would be written into unreserved memory. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 18:52:19 UTC
565ebbf upload-pack: tighten request validation. This makes sure what the other end asks for are among what we offered to give them. Otherwise we would end up running git-rev-list with 20-byte nonsense, only to find it either die (because the object was not found) or waste time (because we ended up serving that phony 'client'). Also avoid wasting needs_sha1 pool to record duplicates, and detect cloning requests better. [this used to be on top of Johannes fetch-pack enhancements, which we are rewinding it for further testing for now, so the commit is rebased.] Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 06:53:28 UTC
9e48b38 Work around missing hard links on FAT formatted media FAT -- like Coda -- does not like cross-directory hard links. To be precise, FAT does not like links at all. But links are not needed either. So get rid of them. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 06:49:43 UTC
303958d create_symref: if symlink fails, fall back to writing a "symbolic ref" There are filesystems out there which do not understand symlinks, even if the OS is perfectly capable of writing them. So, do not fail right away, but try to write a symbolic ref first. If that fails, you can die(). Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 06:46:15 UTC
f89ad67 Add [v]iew patch in git-am interactive. Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 06:43:59 UTC
271440e git-am: make it easier after fixing up an unapplicable patch. Instead of having the user to edit the mail message, let the hand merge result stored in .dotest/patch and continue, which is easier to manage. Signed-off-by: Junio C Hamano <junkio@cox.net> 26 October 2005, 06:35:37 UTC
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
back to top