- 24 2月, 2006 2 次提交
-
-
由 Junio C Hamano 提交于
...so that "Makefile"s from different revs are sorted together, separate from "t/Makefile"s, but close enough. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
When creating a new pack to be used in .git/objects/pack/ directory, we carefully count the depth of deltified objects to be reused, so that the generated pack does not to exceed the specified depth limit for runtime efficiency. However, when we are generating a thin pack that does not contain base objects, such a pack can only be used during network transfer that is expanded on the other end upon reception, so being careful and artificially cutting the delta chain does not buy us anything except increased bandwidth requirement. This patch disables the delta chain depth limit check when reusing an existing delta. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 23 2月, 2006 2 次提交
-
-
由 Junio C Hamano 提交于
This uses the same hashing algorithm to the "preferred base tree" objects and the incoming pathnames, to group the same files from different revs together, while spreading files with the same basename in different directories. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Since we sort objects by type, hash, preferredness and then size, after we have a delta against preferred base, there is no point trying a delta with non-preferred base. This seems to save expensive calls to diff-delta and it also seems to save the output space as well. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 20 2月, 2006 4 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Maybe we would want to make this default before it graduates to the master branch, but in the meantime to help testing things, this allows you to say "git push --thin destination". Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
The new flag loosens the usual "self containedness" requirment of packfiles, and sends deltified representation of objects when we know the other side has the base objects needed to unpack them. This would help reducing the transfer size. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This goes together with "rev-list --object-edge" change, to feed pack-objects list of edge commits in addition to the usual object list. Upon seeing such list, pack-objects loosens the usual "self contained delta" constraints, and can produce delta against blobs and trees contained in the edge commits without storing the delta base objects themselves. The resulting packfile is not usable in .git/object/packs, but is a good way to implement "delta-only" transfer. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 18 2月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
This tries to rework the solution for the excess delta chain problem. An earlier commit worked it around ``cheaply'', but repeated repacking risks unbound growth of delta chains. This version counts the length of delta chain we are reusing from the existing pack, and makes sure a base object that has sufficiently long delta chain does not get deltified. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 17 2月, 2006 6 次提交
-
-
由 Junio C Hamano 提交于
A new flag -q makes underlying pack-objects less chatty. A new flag -f forces delta to be recomputed from scratch. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This introduces --no-reuse-delta option to disable reusing of existing delta, which is a large part of the optimization introduced by this series. This may become necessary if repeated repacking makes delta chain too long. With this, the output of the command becomes identical to that of the older implementation. But the performance suffers greatly. It still allows reusing non-deltified representations; there is no point uncompressing and recompressing the whole text. It also adds a couple more statistics output, while squelching it under -q flag, which the last round forgot to do. $ time old-git-pack-objects --stdout >/dev/null <RL Generating pack... Done counting 184141 objects. Packing 184141 objects.................... real 12m8.530s user 11m1.450s sys 0m57.920s $ time git-pack-objects --stdout >/dev/null <RL Generating pack... Done counting 184141 objects. Packing 184141 objects..................... Total 184141, written 184141 (delta 138297), reused 178833 (delta 134081) real 0m59.549s user 0m56.670s sys 0m2.400s $ time git-pack-objects --stdout --no-reuse-delta >/dev/null <RL Generating pack... Done counting 184141 objects. Packing 184141 objects..................... Total 184141, written 184141 (delta 134833), reused 47904 (delta 0) real 11m13.830s user 9m45.240s sys 0m44.330s There is one remaining issue when --no-reuse-delta option is not used. It can create delta chains that are deeper than specified. A<--B<--C<--D E F G Suppose we have a delta chain A to D (A is stored in full either in a pack or as a loose object. B is depth1 delta relative to A, C is depth2 delta relative to B...) with loose objects E, F, G. And we are going to pack all of them. B, C and D are left as delta against A, B and C respectively. So A, E, F, and G are examined for deltification, and let's say we decided to keep E expanded, and store the rest as deltas like this: E<--F<--G<--A Oops. We ended up making D a bit too deep, didn't we? B, C and D form a chain on top of A! This is because we did not know what the final depth of A would be, when we checked objects and decided to keep the existing delta. Unfortunately, deferring the decision until just before the deltification is not an option. To be able to make B, C, and D candidates for deltification with the rest, we need to know the type and final unexpanded size of them, but the major part of the optimization comes from the fact that we do not read the delta data to do so -- getting the final size is quite an expensive operation. To prevent this from happening, we should keep A from being deltified. But how would we tell that, cheaply? To do this most precisely, after check_object() runs, each object that is used as the base object of some existing delta needs to be marked with the maximum depth of the objects we decided to keep deltified (in this case, D is depth 3 relative to A, so if no other delta chain that is longer than 3 based on A exists, mark A with 3). Then when attempting to deltify A, we would take that number into account to see if the final delta chain that leads to D becomes too deep. However, this is a bit cumbersome to compute, so we would cheat and reduce the maximum depth for A arbitrarily to depth/4 in this implementation. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
When generating a new pack, notice if we have already needed objects in existing packs. If an object is stored deltified, and its base object is also what we are going to pack, then reuse the existing deltified representation unconditionally, bypassing all the expensive find_deltas() and try_deltas() calls. Also, notice if what we are going to write out exactly match what is already in an existing pack (either deltified or just compressed). In such a case, we can just copy it instead of going through the usual uncompressing & recompressing cycle. Without this patch, in linux-2.6 repository with about 1500 loose objects and a single mega pack: $ git-rev-list --objects v2.6.16-rc3 >RL $ wc -l RL 184141 RL $ time git-pack-objects p <RL Generating pack... Done counting 184141 objects. Packing 184141 objects.................... a1fc7b3e537fcb9b3c46b7505df859f0a11e79d2 real 12m4.323s user 11m2.560s sys 0m55.950s With this patch, the same input: $ time ../git.junio/git-pack-objects q <RL Generating pack... Done counting 184141 objects. Packing 184141 objects..................... a1fc7b3e537fcb9b3c46b7505df859f0a11e79d2 Total 184141, written 184141, reused 182441 real 1m2.608s user 0m55.090s sys 0m1.830s Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Aneesh Kumar 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
We run svn log against a URL without a working copy for the first fetch, so we end up a log that's sorted from highest to lowest. That's bad, we always want lowest to highest. Just default to --revision 0:HEAD now if -r isn't specified for the first fetch. Also sort the revisions after we get them just in case somebody accidentally reverses the argument to --revision for whatever reason. Thanks again to Emmanuel Guerin for helping me find this. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
Thanks to Emmanuel Guerin for finding the bug. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 2月, 2006 7 次提交
-
-
由 Eric Wong 提交于
-
由 Fernando J. Pereda 提交于
Systems using some uClibc versions do not properly support iconv stuff. This patch allows Git to be built on those systems by passing NO_ICONV=YesPlease to make. The only drawback is mailinfo won't do charset conversion in those systems. Signed-off-by: NFernando J. Pereda <ferdy@gentoo.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
* jc/add: Detect misspelled pathspec to git-add
-
由 Junio C Hamano 提交于
-
由 Josef Weidendorfer 提交于
Signed-off-by: NJosef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Fernando J. Pereda 提交于
If Git is compiled with NO_CURL=YesPlease and one tries to clone a http repository, git-clone tries to call the curl binary. This trivial patch prints an error instead in such situation. Signed-off-by: NFernando J. Pereda <ferdy@gentoo.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
The delta depth is unsigned. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 15 2月, 2006 8 次提交
-
-
由 Junio C Hamano 提交于
This is in the same spirit as an earlier patch for git-commit. It does an extra ls-files to avoid complaining when a fully tracked directory name is given on the command line (otherwise --others restriction would say the pathspec does not match). Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Earlier patch mistakenly used prefix_len when it meant prefix_offset. The latter is to strip the leading directories when run from a subdirectory. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
* kh/svn: git-svnimport: -r adds svn revision number to commit messages
-
由 Junio C Hamano 提交于
* jc/commit: commit: detect misspelled pathspec while making a partial commit. combine-diff: diff-files fix (#2) combine-diff: diff-files fix.
-
由 Junio C Hamano 提交于
* jc/rebase: rebase: allow a hook to refuse rebasing.
-
由 Junio C Hamano 提交于
* ra/email: send-email: Add --cc send-email: Add some options for controlling how addresses are automatically added to the cc: list.
-
由 Junio C Hamano 提交于
When we refused to switch branches, we incorrectly showed differences from the branch we would have switched to. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
When you say "git commit Documentaiton" to make partial commit for the files only in that directory, we did not detect that as a misspelled pathname and attempted to commit index without change. If nothing matched, there is no harm done, but if the index gets modified otherwise by having another valid pathspec or after an explicit update-index, a user will not notice without paying attention to the "git status" preview. This introduces --error-unmatch option to ls-files, and uses it to detect this common user error. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 14 2月, 2006 8 次提交
-
-
由 Karl Hasselström 提交于
New -r flag for prepending the corresponding Subversion revision number to each commit message. Signed-off-by: NKarl Hasselström <kha@treskal.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
The raw format "git-diff-files -c" to show unmerged state forgot to initialize the status fields from parents, causing NUL characters to be emitted. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Conflicts: Documentation/git-commit.txt - taking the post 1.2.0 semantics. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
* pb/bisect: Properly git-bisect reset after bisecting from non-master head
-
由 Junio C Hamano 提交于
When showing a conflicted merge from index stages and working tree file, we did not fetch the mode from the working tree, and mistook that as a deleted file. Also if the manual resolution (or automated resolution by git rerere) ended up taking either parent's version, we did not show _anything_ for that path. Either was quite bad and confusing. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Fredrik Kuivinen 提交于
With the current Makefile we don't use the shell chosen by the platform specific defines when we invoke GIT-VERSION-GEN. Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
I noticed that we forgot to clean this file and kept it that way, while trying to help with Andrew's bisect problem. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Noticed by Jon Nelson. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 13 2月, 2006 2 次提交
-
-
由 Ryan Anderson 提交于
Since Junio used this in an example, and I've personally tried to use it, I suppose the option should actually exist. Signed-off-by: NRyan Anderson <ryan@michonline.com>
-
由 Junio C Hamano 提交于
The documentation was mistakenly describing the --only semantics to be default. The 1.2.0 release and its maintenance series 1.2.X will keep the traditional --include semantics as the default. Clarify the situation. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-