- 04 7月, 2005 17 次提交
-
-
由 Jon Seymour 提交于
This patch fixes up the t/t5300 unit tests which were broken by the changes in: Make the name of a pack-file depend on the objects packed there-in. Signed-off-by: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
This is actually subtly wrong. If a short match is found in the object directory, but would _also_ match another SHA1 ID in a pack (or it shows in one pack but not another), we'll never have done the pack lookup, and we think it's unique. I can't find it in myself to care. You really want to use enough of a SHA1 that there is never any ambiguity.
-
由 Linus Torvalds 提交于
Currently only for unpacked objects, but the infrastructure is there to do it for packed objects too.
-
由 Linus Torvalds 提交于
This means that the .git/objects/pack directory is also rsync'able, since the filenames created there-in are either unique or refer to the same data. Otherwise you might not be able to pull from a directory that is partly packed without having to worry about missing objects due to pack-file name clashes.
-
由 Linus Torvalds 提交于
This, together with "git repack" can be used to clean up unpacked git archives.
-
由 Linus Torvalds 提交于
-
由 Linus Torvalds 提交于
It skips writing the pack-file if it ends up being empty.
-
由 Linus Torvalds 提交于
More infrastructure to do efficient incremental packs.
-
由 Linus Torvalds 提交于
It won't add an object that is already in a pack to the new pack.
-
由 Linus Torvalds 提交于
And make git-rev-list just silently ignore non-commit refs if we're not asking for all objects.
-
由 Linus Torvalds 提交于
We'll want this for incremental packing.
-
由 Linus Torvalds 提交于
In particular, check that it's a symlink, and points to refs/heads/. We depend on that these days not only for "git checkout", but also because fsck and others only check for references in the .git/refs/ subdirectory, not things like HEAD itself.
-
由 Linus Torvalds 提交于
Mainly making a lot of local functions and variables be marked "static", but there was a "zero as NULL" warning in there too.
-
由 Linus Torvalds 提交于
We're pretty sparse-clean already, thanks to earlier efforts, but some things inevitably creep in.
-
由 Linus Torvalds 提交于
It needed to take the GIT_DIR information into account, something that the original receive-pack usage just never cared about.
-
由 Linus Torvalds 提交于
send_pack() was declared to return "int" (although nobody cared), but didn't actually return anything.
-
由 Linus Torvalds 提交于
A couple of bogus "might be used undefined" warnings are avoided by moving the initializations unnecessarily early.
-
- 03 7月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
This turns it into a generic "do xyz for each ref" library function.
-
- 01 7月, 2005 7 次提交
-
-
由 Junio C Hamano 提交于
This implements show_pack_info() function used in verify-pack command when -v flag is used to obtain something like unpack-objects used to give when it was first written. It shows the following for each non-deltified object found in the pack: SHA1 type size offset For deltified objects, it shows this instead: SHA1 type size offset depth base_sha1 In order to get the output in the order that appear in the pack file for debugging purposes, you can do this: $ git-verify-pack -v packfile | sort -n -k 4,4 Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Junio C Hamano 提交于
Nico pointed out that having verify_pack.c and verify-pack.c was confusing. Rename verify_pack.c to pack-check.c as suggested, and enhances the verification done quite a bit. - Built-in sha1_file unpacking knows that a base object of a deltified object _must_ be in the same pack, and takes advantage of that fact. - Earlier verify-pack command only checked the SHA1 sum for the entire pack file and did not look into its contents. It now checks everything idx file claims to have unpacks correctly. - It now has a hook to give more detailed information for objects contained in the pack under -v flag. Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Junio C Hamano 提交于
This teaches packed_delta_info() that it only needs to look at the type of the base object to figure out both type and size of a deltified object. This saves quite a many calls to inflate() when dealing with a deep delta chain. Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
This makes the receiver always send a full list of valid refs, which will allow us to do better packs, as well as handle creation of new refs. Eventually. Right now we just moved the matching and enabled it. So now you can do git-send-pack host:path branch1 branch2 to only send branches "branch1" and "branch2".
-
由 Linus Torvalds 提交于
A "old ref" of all zeroes is considered a "don't care" ref, and allows us to say "write the new ref regardless of what the old ref contained (or even if it existed at all)". This allows (if git-send-pack were to do it) creating new refs, and fixing up old ones.
-
由 Linus Torvalds 提交于
This concludes this lesson. I've actually successfully sent an update using the git-send-pack command. Probably tons of work still to do, and nasty debugging, but it's now actually potentially useful.
-
由 Linus Torvalds 提交于
After unpacking the object pack successfully, we go through the list of refs, and verify that they still contain their expected values. Then we replace them with the new ones.
-
- 30 6月, 2005 15 次提交
-
-
由 Linus Torvalds 提交于
Me tired.
-
由 Linus Torvalds 提交于
We don't act on them yet, but we parse them.
-
由 Linus Torvalds 提交于
-
由 Linus Torvalds 提交于
Right now it just shows which refs it picks up, and whether they are the same or changed on the remote end. Getting there..
-
由 Linus Torvalds 提交于
It got turned off by mistake just because I had been doing debugging, and committed the Makefile that had other changes ...
-
由 Jon Seymour 提交于
This patch removes an unnecessary sort from the t6001 testcase. Sorts were previously necessary when testing non --merge-order cases because the output order wasn't entirely deterministic unless commit date was fixed. However, commit dates are now fixed, so the need for a sort has disappeared. So the sort has been removed. Signed-off-by: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Jon Seymour 提交于
This fix fixes a t/t6001 test case break that was hidden by a bug in the test case infrastructure. Signed-off-by: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Jon Seymour 提交于
Junio discovered a problem where an actual test case break was hidden because pipelines are not handled properly by the test infrastructure in t6001. This patch fixes the broken infrastructure (and demonstrates the break explicitly). A subsequent patch in this series will fix the test case so that it doesn't fail. Signed-off-by: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Jon Seymour 提交于
This patch makes --merge-order produce the same list as git-rev-list without --merge-order specified. In particular, if the graph looks like this: A | B |/ C | D The both git-rev-list B ^A and git-rev-list --merge-order will produce B. The unit tests have been changed to reflect the fact that the prune points are now formally part of the start list that is used to perform the --merge-order sort. That is: git-rev-list --merge-order A ^D used to produce = A | C It now produces: ^ A | C Signed-off-by: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Jon Seymour 提交于
Added a test case that shows that --merge-order doesn't produce the correct result in the following case. A | | B |/ C | D git-rev-list --merge-order A ^B should produce just A. Instead it produces BCD. A subsequent patch will fix this defect. Signed-off-by: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
-
由 Linus Torvalds 提交于
Like git-receive-pack, this is only partway done.
-
由 Linus Torvalds 提交于
It's not working yet, but it's at the point where I want to be able to track my changes. The theory of operation is that this is the "remote" side of a "git push". It can tell us what references the remote side has, receives out reference update commands and a pack-file, and can execute the unpacking command.
-
由 Linus Torvalds 提交于
It makes gitk unhappy, and besides, non-merge-order doesn't complain, so why do it here..
-
由 Linus Torvalds 提交于
Now you can give git-rev-list tags, trees and blobs, and it will do the proper reachability for them all. Knock wood. Of course, you need the "--objects" flag to do anything but plain commits.
-