summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2006-10-20add the capability for index-pack to read from a streamLibravatar Nicolas Pitre1-101/+143
This patch only adds the streaming capability to index-pack. Although the code is different it has the exact same functionality as before to make sure nothing broke. This is in preparation for receiving packs over the net, parse them on the fly, fix them up if they are "thin" packs, and keep the resulting pack instead of exploding it into loose objects. But such functionality should come separately. One immediate advantage of this patch is that index-pack can now deal with packs up to 4GB in size even on 32-bit architectures since the pack is not entirely mmap()'d all at once anymore. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-18index-pack: compare only the first 20-bytes of the key.Libravatar Nicolas Pitre1-4/+10
The "union delta_base" is a strange beast. It is a 20-byte binary blob key to search a binary searchable deltas[] array, each element of which uses it to represent its base object with either a full 20-byte SHA-1 or an offset in the pack. Which representation is used is determined by another field of the deltas[] array element, obj->type, so there is no room for confusion, as long as we make sure we compare the keys for the same type only with appropriate length. The code compared the full union with memcmp(). When storing the in-pack offset, the union was first cleared before storing an unsigned long, so comparison worked fine. On 64-bit architectures, however, the union typically is 24-byte long; the code did not clear the remaining 4-byte alignment padding when storing a full 20-byte SHA-1 representation. Using memcmp() to compare the whole union was wrong. This fixes the comparison to look at the first 20-bytes of the union, regardless of the architecture. As long as ulong is smaller than 20-bytes this works fine. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-13git-repack: repo.usedeltabaseoffsetLibravatar Junio C Hamano3-1/+28
When configuration variable `repack.UseDeltaBaseOffset` is set for the repository, the command passes `--delta-base-offset` option to `git-pack-objects`; this typically results in slightly smaller packs, but the generated packs are incompatible with versions of git older than (and including) v1.4.3. We will make it default to true sometime in the future, but not for a while. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-10pack-objects: document --delta-base-offset optionLibravatar Junio C Hamano2-2/+13
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27allow delta data reuse even if base object is a preferred baseLibravatar Nicolas Pitre1-1/+1
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27zap a debug remnantLibravatar Nicolas Pitre1-1/+0
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27let the GIT native protocol use offsets to delta base when possibleLibravatar Nicolas Pitre2-5/+10
There is no reason not to always do this when both ends agree. Therefore a client that can accept offsets to delta base always sends the "ofs-delta" flag. The server will stream a pack with or without offset to delta base depending on whether that flag is provided or not with no additional cost. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27make pack data reuse compatible with both delta typesLibravatar Nicolas Pitre3-96/+130
This is the missing part to git-pack-objects allowing it to reuse delta data to/from any of the two delta types. It can reuse delta from any type, and it outputs base offsets when --allow-delta-base-offset is provided and the base is also included in the pack. Otherwise it outputs base sha1 references just like it always did. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27make git-pack-objects able to create deltas with offset to baseLibravatar Nicolas Pitre1-14/+33
This is enabled with --delta-base-offset only, and doesn't work with pack data reuse yet. The idea is to allow for the fetch protocol to use an extension flag to notify the remote end that --delta-base-offset can be used with git-pack-objects. Eventually git-repack will always provide this flag. With this, all delta base objects are now pushed before deltas that depend on them. This is a requirements for OBJ_OFS_DELTA. This is not a requirement for OBJ_REF_DELTA but always doing so makes the code simpler. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27teach git-index-pack about deltas with offset to baseLibravatar Nicolas Pitre1-31/+80
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27teach git-unpack-objects about deltas with offset to baseLibravatar Nicolas Pitre1-32/+106
For delta resolution to be possible, a list of sha1/offset tuple must be constructed in memory in order to load the appropriate base object. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27introduce delta objects with offset to baseLibravatar Nicolas Pitre5-45/+82
This adds a new object, namely OBJ_OFS_DELTA, renames OBJ_DELTA to OBJ_REF_DELTA to better make the distinction between those two delta objects, and adds support for the handling of those new delta objects in sha1_file.c only. The OBJ_OFS_DELTA contains a relative offset from the delta object's position in a pack instead of the 20-byte SHA1 reference to identify the base object. Since the base is likely to be not so far away, the relative offset is more likely to have a smaller encoding on average than an absolute offset. And for those delta objects the base must always be stored first because there is no way to know the distance of later objects when streaming a pack. Hence this relative offset is always meant to be negative. The offset encoding is slightly denser than the one used for object size -- credits to <linux@horizon.com> (whoever this is) for bringing it to my attention. This allows for pack size reduction between 3.2% (Linux-2.6) to over 5% (linux-historic). Runtime pack access should be faster too since delta replay does skip a search in the pack index for each delta in a chain. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27gitweb: Decode long title for link tooltipsLibravatar Yasushi SHOJI1-1/+1
This is a simple one liner to decode long title string in perl's internal form to utf-8 for link tooltips. This is not crucial if the commit message is all in ASCII, however, if you decide to use other encoding, such as UTF-8, tooltips ain't readable any more. Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-26git-svn: Fix fetch --no-ignore-externals with GIT_SVN_NO_LIB=1Libravatar Sergey Vlasov1-0/+1
When using Subversion 1.3.1 without Perl bindings (GIT_SVN_NO_LIB=1), "git-svn fetch --no-ignore-externals" fails with errors like: Tree (.../.git/svn/git-svn/tree) is not clean: X directory_with_external In this case the 'X' lines in the "svn status" output are not a sign of unclean tree, and therefore should be ignored. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-26Ignore executable bit when adding files if filemode=0.Libravatar Shawn Pearce3-2/+28
If the user has configured core.filemode=0 then we shouldn't set the execute bit in the index when adding a new file as the user has indicated that the local filesystem can't be trusted. This means that when adding files that should be marked executable in a repository with core.filemode=0 the user must perform a 'git update-index --chmod=+x' on the file before committing the addition. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-25Use const for interpolate argumentsLibravatar Alex Riesen2-5/+10
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-25git-archive: update documentationLibravatar Franck Bui-Huu2-0/+16
This patch documents zip backend options. It also adds git-archive command into the main git manual page. Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24gitweb: fix over-eager application of esc_html().Libravatar Petr Baudis1-6/+6
Contents of %diffinfo hash should be quoted upon output but kept unquoted internally. Later users of this hash expect filenames to be filenames, not HTML gibberish. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24Allow '(no author)' in git-svn's authors file.Libravatar Shawn Pearce1-1/+1
When trying to import an SVN revision which has no author the Git user may desire to relabel '(no author)' to another name and email address with their svn.authorsfile. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24Allow 'svn fetch' on '(no date)' revisions in Subversion.Libravatar Shawn Pearce2-1/+16
Added --ignore-nodate to allow 'git svn fetch' to import revisions from Subversion which have '(no date)' listed as the date of the revision. By default 'git svn fetch' will crash with an error when encountering such a revision. The user may restart the fetch operation by adding --ignore-nodate if they want to continue tracking that repository. I'm not entirely sure why a centralized version control system such as Subversion permits revisions to be created with absolutely no date/time associated with it but it apparently is possible as one of the Subversion repositories that I'm tracking with 'git svn' created such a revision on '(no date)' and by '(no user)'. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24Merge branch 'sk/svnimport'Libravatar Junio C Hamano1-11/+20
* sk/svnimport: git-svnimport: Parse log message for Signed-off-by: lines
2006-09-24Merge early parts of branch 'np/pack'Libravatar Junio C Hamano6-117/+111
2006-09-24Remove upload-tar and make git-tar-tree a thin wrapper to git-archiveLibravatar Junio C Hamano8-200/+53
The command now issues a big deprecation warning message and runs git-archive command with appropriate arguments. git-tar-tree $tree_ish $base always forces $base to be the leading directory name, so the --prefix parameter passed internally to git-archive is a slash appended to it, i.e. "--prefix=$base/". Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24git-tar-tree: Move code for git-archive --format=tar to archive-tar.cLibravatar Rene Scharfe3-314/+326
This patch doesn't change any functionality, it only moves code around. It makes seeing the few remaining lines of git-tar-tree code easier. ;-) Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24git-tar-tree: Remove duplicate git_config() callLibravatar Rene Scharfe1-2/+0
generate_tar() eventually calls write_tar_archive() which does all the "real" work and which also calls git_config(git_tar_config). We only need to do this once. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24Merge branch 'jc/filter-commit'Libravatar Junio C Hamano8-507/+641
* jc/filter-commit: git log: Unify header_filter and message_filter into one. Update grep internal for grepping only in head/body git-log --author and --committer are not left-anchored by default rev-list: fix segfault with --{author,committer,grep} revision traversal: --author, --committer, and --grep. revision traversal: prepare for commit log match. builtin-grep: make pieces of it available as library.
2006-09-24Merge branch 'sb/branch-attributes'Libravatar Junio C Hamano4-13/+115
* sb/branch-attributes: Add test for the default merges in fetch. fetch: get the remote branches to merge from the branch properties Add t5510 to test per branch configuration affecting git-fetch. Fetch: default remote repository from branch properties
2006-09-24Merge branch 'jl/daemon'Libravatar Junio C Hamano5-11/+229
* jl/daemon: Add virtualization support to git-daemon
2006-09-24Add test for the default merges in fetch.Libravatar Santi Béjar1-0/+25
[jc: with minor fix-ups] Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24fetch: get the remote branches to merge from the branch propertiesLibravatar Santi Béjar2-8/+33
If in branch "foo" and this in config: [branch "foo"] merge=bar "git fetch": fetch from the default repository and program the "bar" branch to be merged with pull. Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24Add t5510 to test per branch configuration affecting git-fetch.Libravatar Junio C Hamano1-0/+44
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24Fetch: default remote repository from branch propertiesLibravatar Santi Béjar3-5/+13
If in branch "foo" and this in config: [branch "foo"] remote=bar "git fetch" = "git fetch bar" "git pull" = "git pull bar" Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24builtin-upload-archive.c broken on openbsdLibravatar Randal L. Schwartz1-2/+2
Looks like ctype again. Gotta be careful with that on BSD releases: $ gmake prefix=/opt/git all GIT_VERSION = 1.4.2.GIT gcc -o builtin-upload-archive.o -c -g -O2 -Wall -I/usr/local/include -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRCASESTR builtin-upload-archive.c In file included from /usr/include/sys/poll.h:54, from builtin-upload-archive.c:11: /usr/include/ctype.h:68: error: syntax error before ']' token /usr/include/ctype.h:69: error: syntax error before ']' token ... /usr/include/sys/poll.h:53:1: unterminated #ifndef /usr/include/sys/poll.h:28:1: unterminated #ifndef gmake: *** [builtin-upload-archive.o] Error 1 This fixes it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-23gitweb: Consolidate escaping/validation of query stringLibravatar Petr Baudis1-21/+11
Consider: http://repo.or.cz/?p=glibc-cvs.git;a=tree;h=2609cb0411389325f4ee2854cc7159756eb0671e;hb=2609cb0411389325f4ee2854cc7159756eb0671e (click on the funny =__ify file) We ought to handle anything in filenames and I actually see no reason why we don't, modulo very little missing escaping that this patch hopefully also fixes. I have also made esc_param() escape [?=&;]. Not escaping [&;] was downright buggy and [?=] just feels better escaped. ;-) YMMV. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-23Deprecate git-resolve.shLibravatar Petr Baudis1-0/+4
Seriously, is anyone still using this thing? It's collecting dust and blocking the name for something potentially useful like a tool for user-friendly marking of resolved conflicts or resolving index conflicts. We've loved you when Git was young, now thank you and please go away. ;-) This makes git-resolve.sh print a big deprecation warning and sleep a bit for extra annoyance. It should be removed completely after the next release. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-23Rename builtin-zip-tree.c to archive-zip.cLibravatar Rene Scharfe2-3/+2
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-23Remove git-zip-treeLibravatar Rene Scharfe5-135/+0
git-zip-tree can be safely removed because it was never part of a formal release. This patch makes 'git-archive --format=zip' the one and only git ZIP file creation command. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-23many cleanups to sha1_file.cLibravatar Nicolas Pitre4-114/+104
Those cleanups are mainly to set the table for the support of deltas with base objects referenced by offsets instead of sha1. This means that many pack lookup functions are converted to take a pack/offset tuple instead of a sha1. This eliminates many struct pack_entry usages since this structure carried redundent information in many cases, and it increased stack footprint needlessly for a couple recursively called functions that used to declare a local copy of it for every recursion loop. In the process, packed_object_info_detail() has been reorganized as well so to look much saner and more amenable to deltas with offset support. Finally the appropriate adjustments have been made to functions that depend on the above changes. But there is no functionality changes yet simply some code refactoring at this point. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-22move pack creation to version 3Libravatar Nicolas Pitre2-3/+7
It's been quite a while now that GIT is able to read version 3 packs. Let's create them at last. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-22git-svnimport: Parse log message for Signed-off-by: linesLibravatar Sasha Khapyorsky1-11/+20
This add '-S' option. When specified svn-import will try to parse commit message for 'Signed-off-by: ...' line, and if found will use the name and email address extracted at first occurrence as this commit author name and author email address. Committer name and email are extracted in usual way. Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-22Quote arguments to tr in test-libLibravatar Robin Rosenberg1-1/+1
When there are single-character filenames in the test directory, the shell tries to expand regexps meant for tr. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-22Fix snapshot link in tree viewLibravatar Petr Baudis1-1/+1
It would just give HEAD snapshot instead of one of the particular tree. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-22gitweb: Fix @git_base_url_list usageLibravatar Petr Baudis1-1/+1
As it is now, that array was never used because the customurl accessor was broken and ''unless @url_list'' never happenned. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-22gitweb: Fix tree link associated with each commit log entry.Libravatar Petr Baudis1-1/+1
The link forgot to have hb parameter and the resulting tree view failed to show the navbar for that commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-22Make path in tree view look nicerLibravatar Petr Baudis1-5/+5
Based on talk on the IRC with Junio some evenings ago, I've updated the path showing in tree view to look better and sent updated patches privately, but it seems the old version ended up being used, so here's the new one again. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-21gitweb: Relabel "head" as "HEAD"Libravatar Petr Baudis1-4/+4
"head" is a reference in refs/heads/, while those labels mean HEAD, the latest revision of the default branch. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-21gitweb: Rename "plain" labels to "raw"Libravatar Petr Baudis1-4/+4
I don't have much preference either way and as far as I'm concerned, it may go the other way as well. Consistency is what is important. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-21gitweb: Link to associated tree from a particular log item in full log viewLibravatar Petr Baudis1-0/+2
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-21gitweb: Link to latest tree from the head line in heads listLibravatar Petr Baudis1-1/+2
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-21gitweb: Link to tree instead of snapshot in shortlogLibravatar Petr Baudis1-7/+2
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>