AgeCommit message (Collapse)Author
2005-10-29make t5501 less annoyingJohannes Schindelin
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 <> Signed-off-by: Junio C Hamano <>
2005-10-29fix multi_ack.Johannes Schindelin
Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2005-10-29git-fetch-pack: Support multi_ack extensionJohannes Schindelin
The client side support for multi_ack. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2005-10-29git-upload-pack: Support the multi_ack protocolJohannes Schindelin
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 <> Signed-off-by: Junio C Hamano <>
2005-10-29Support receiving server capabilitiesJohannes Schindelin
This patch implements the client side of backward compatible upload-pack protocol extension, <> 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 <> Signed-off-by: Junio C Hamano <>
2005-10-29git-upload-pack: More efficient usage of the has_sha1 arrayJohannes Schindelin
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 <> Signed-off-by: Junio C Hamano <>
2005-10-29Implement an interoperability test for fetch-pack/upload-packJohannes Schindelin
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 <> Signed-off-by: Junio C Hamano <>
2005-10-29Implement a test for git-fetch-pack/git-upload-packJohannes Schindelin
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 <> Signed-off-by: Junio C Hamano <>
2005-10-29Make maximal use of the remote refsJohannes Schindelin
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 <> Signed-off-by: Junio C Hamano <>
2005-10-29Subject: [PATCH] git-fetch-pack: Do not use git-rev-listJohannes Schindelin
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 <> Signed-off-by: Junio C Hamano <>
2005-10-29git-apply --numstatJunio C Hamano
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 <>
2005-10-29Add usage help to
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> Signed-off-by: Junio C Hamano <>
2005-10-29Add usage help for
Signed-off-by: Chris Shoemaker <c.shoemaker at> Signed-off-by: Junio C Hamano <>
2005-10-29Minor clarifications in diffcore
Signed-off-by: Chris Shoemaker <c.shoemaker at> Signed-off-by: Junio C Hamano <>
2005-10-29Remove -r from common diff options documentation in one more
Signed-off-by: Chris Shoemaker <c.shoemaker at> Signed-off-by: Junio C Hamano <>
2005-10-29update usage string for
Signed-off-by: Chris Shoemaker <c.shoemaker at> Signed-off-by: Junio C Hamano <> Retain cuteness, add
Signed-off-by: Chris Shoemaker <c.shoemaker at> Signed-off-by: Junio C Hamano <>
2005-10-28Be more careful about reference parsingLinus Torvalds
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 <> Signed-off-by: Junio C Hamano <>
2005-10-28Be marginally more careful about removing objectsLinus Torvalds
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 <> Signed-off-by: Junio C Hamano <>
2005-10-28Documentation changes to recursive option for git-diff-treeChris Shoemaker
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 Sync the synopsis and usage string for git-diff-tree. Signed-off-by: Chris Shoemaker <c.shoemaker at> Signed-off-by: Junio C Hamano <>
2005-10-28fix testsuite to tolerate spaces in pathPavel Roskin
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 <> Signed-off-by: Junio C Hamano <>
2005-10-28Document git-patch-id a bit better.Junio C Hamano
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 <>
2005-10-28Add more generated files to .gitignoreJohannes Schindelin
git-name-rev, git-mv and git-shell are recent additions to git. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2005-10-28Link git-name-rev and git-symbolic-ref from the main git pageJohannes Schindelin
According to my checks, these were the only commands not yet linked. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2005-10-28Create object subdirectories on demand (phase II)Linus Torvalds
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 <>
2005-10-27Merge branch 'js-fat'Junio C Hamano
2005-10-27Merge branch 'lt-dense'Junio C Hamano
2005-10-27Merge C Hamano
2005-10-27[PATCH] Make "gitk" work better with dense revlistsLinus Torvalds
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 <> Signed-off-by: Paul Mackerras <>
2005-10-26git-rev-list: do not forget non-commit refsLinus Torvalds
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 <>
2005-10-26git-rev-list: make --dense the default (and introduce "--sparse")Linus Torvalds
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 <> Signed-off-by: Junio C Hamano <>
2005-10-26Test in git-init-db if the filemode can be trustedJohannes Schindelin
... 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 <> Signed-off-by: Junio C Hamano <>
2005-10-26Add git-name-revJohannes Schindelin
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 <> Signed-off-by: Junio C Hamano <>
2005-10-26pack-objects: Allow use of pre-generated pack.Junio C Hamano
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 <>
2005-10-26Fix what to do and how to detect when hardlinking failsLinus Torvalds
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 <>
2005-10-26Fix cloning (memory corruption)Johannes Schindelin
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 <> Signed-off-by: Junio C Hamano <>
2005-10-26upload-pack: tighten request validation.Junio C Hamano
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 <>
2005-10-26Work around missing hard links on FAT formatted mediaJohannes Schindelin
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 <> Signed-off-by: Junio C Hamano <>
2005-10-26create_symref: if symlink fails, fall back to writing a "symbolic ref"Johannes Schindelin
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 <> Signed-off-by: Junio C Hamano <>
2005-10-26Add [v]iew patch in git-am interactive.Junio C Hamano
Signed-off-by: Junio C Hamano <>
2005-10-26git-am: make it easier after fixing up an unapplicable patch.Junio C Hamano
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 <>
2005-10-26git-rev-list: fix "--dense" flagLinus Torvalds
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 <>
2005-10-26Add some missing commands to the git.txt commands listPetr Baudis
Signed-off-by: Junio C Hamano <>
2005-10-26Add usage string to git-update-indexPetr Baudis
This patch adds usage string to git-update-index, can be printed by the -h or --help parameter. Signed-off-by: Petr Baudis <> Signed-off-by: Junio C Hamano <>
2005-10-26Documentation for git-shellPetr Baudis
Signed-off-by: Junio C Hamano <>
2005-10-26Check another error condition in git-mvJosef Weidendorfer
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 <> Signed-off-by: Junio C Hamano <>
2005-10-26fix daemon.c to compile on OpenBSDRandal L. Schwartz
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 <>
2005-10-25Revert recent fetch-pack/upload-pack updates.Junio C Hamano
Let's have it simmer a bit longer in the proposed updates branch and shake the problems out. Signed-off-by: Junio C Hamano <>
2005-10-24upload-pack: fix thinko in common-commit finder code.Junio C Hamano
The code to check if we have the object the other side has was bogus (my fault). Signed-off-by: Junio C Hamano <>
2005-10-24git-fetch-pack: Implement client part of the multi_ack extensionJohannes Schindelin
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 <> Signed-off-by: Junio C Hamano <>