summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Add "git_path()" and "head_ref()" helper functions.Linus Torvalds2005-07-057-14/+37
| | | | | | | "git_path()" returns a static pathname pointer into the git directory using a printf-like format specifier. "head_ref()" works like "for_each_ref()", except for just the HEAD.
* git-rev-list: make sure the output is sorted by recencyLinus Torvalds2005-07-041-1/+1
| | | | | We didn't sort the refs by date, so if you had multiple refs, the end result would not be properly sorted.
* Make rev-list flush the stdio buffers after each rev.Linus Torvalds2005-07-041-1/+2
| | | | | We'd rather get the revisions in a slow but timely manner than have to wait for them.
* Make git-fetch-pack actually do all the unpacking etc.Linus Torvalds2005-07-042-25/+100
| | | | | | | | | | It returns the result SHA1 on stdout, so you can do remote=$(git-fetch-pack host:dir branchname) and it will unpack the objects and "remote" will be the SHA1 name of the branch on the other side. You can then save that off, or merge it, or whatever.
* Make git-fetch-pack and git-upload-pack negotiate needs/haves fullyLinus Torvalds2005-07-042-10/+116
| | | | Now the only piece missing is actually generating the pack-file.
* Clean up output of "for_each_ref()" when GIT_DIR is "."Linus Torvalds2005-07-041-0/+5
| | | | Remove the "./" at the head, it just looks much nicer.
* Commit first cut at "git-fetch-pack"Linus Torvalds2005-07-043-4/+216
| | | | | | | It's meant to be used by "git fetch" for the local and ssh case. It doesn't actually do the fetching now, but it does discover the common commit point.
* Move ref path matching to connect.c libraryLinus Torvalds2005-07-043-21/+22
| | | | It's a generic thing for matching refs from the other side.
* Factor out the ssh connection stuff from send-pack.cLinus Torvalds2005-07-044-74/+92
| | | | I want to use it for git-fetch-pack too.
* [PATCH] Fixup t/t5300 unit tests broken by ↵Jon Seymour2005-07-041-15/+15
| | | | | | | | | | | 5f3de58ff85c49620ae2a1722d8d4d37c881a054 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: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* git-rev-parse: support show sha1 names for pack entriesLinus Torvalds2005-07-031-0/+49
| | | | | | | | | | 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.
* Make git-rev-parse support cogito-style "short hex names"Linus Torvalds2005-07-031-3/+76
| | | | | Currently only for unpacked objects, but the infrastructure is there to do it for packed objects too.
* Make the name of a pack-file depend on the objects packed there-in.Linus Torvalds2005-07-032-17/+20
| | | | | | | | | | 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.
* Add "git-prune-packed" that removes objects that exist in a pack.Linus Torvalds2005-07-032-1/+68
| | | | | This, together with "git repack" can be used to clean up unpacked git archives.
* Add "git repack" command that does an incremental packLinus Torvalds2005-07-032-1/+19
|
* Add "--non-empty" flag to git-pack-objectsLinus Torvalds2005-07-031-0/+7
| | | | It skips writing the pack-file if it ends up being empty.
* "git rev-list --unpacked" shows only unpacked commitsLinus Torvalds2005-07-031-0/+11
| | | | More infrastructure to do efficient incremental packs.
* Add "--incremental" flag to git-pack-objectsLinus Torvalds2005-07-031-1/+9
| | | | It won't add an object that is already in a pack to the new pack.
* Add "--all" flag to rev-parse that shows all refsLinus Torvalds2005-07-032-3/+14
| | | | | And make git-rev-list just silently ignore non-commit refs if we're not asking for all objects.
* Add "has_sha1_pack()" function to query whether the object is available in a ↵Linus Torvalds2005-07-032-0/+7
| | | | | | pack We'll want this for incremental packing.
* Make git-fsck-cache check HEAD integrityLinus Torvalds2005-07-031-0/+26
| | | | | | | 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.
* Fix sparse warnings.Linus Torvalds2005-07-039-18/+18
| | | | | Mainly making a lot of local functions and variables be marked "static", but there was a "zero as NULL" warning in there too.
* Fix up header file dependencies and add sparse checking rulesLinus Torvalds2005-07-031-1/+10
| | | | | We're pretty sparse-clean already, thanks to earlier efforts, but some things inevitably creep in.
* Fix up "for_each_ref()" to be more usable, and use it in git-fsck-cacheLinus Torvalds2005-07-034-63/+18
| | | | | It needed to take the GIT_DIR information into account, something that the original receive-pack usage just never cared about.
* Fix gcc warning in send-pack.cLinus Torvalds2005-07-031-0/+1
| | | | | send_pack() was declared to return "int" (although nobody cared), but didn't actually return anything.
* Avoid gcc warnings in sha1_file.cLinus Torvalds2005-07-031-4/+4
| | | | | A couple of bogus "might be used undefined" warnings are avoided by moving the initializations unnecessarily early.
* Generalize the "show each ref" code in receice-packLinus Torvalds2005-07-023-53/+77
| | | | This turns it into a generic "do xyz for each ref" library function.
* [PATCH] Show more details of packfile with verify-pack -v.Junio C Hamano2005-06-303-1/+84
| | | | | | | | | | | | | | | | | | | | | | | 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: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] verify-pack updates.Junio C Hamano2005-06-307-44/+156
| | | | | | | | | | | | | | | | | | | | 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: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Avoid unnecessarily inflating and interpreting deltaJunio C Hamano2005-06-302-38/+44
| | | | | | | | | | 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: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Do ref matching on the sender side rather than on receiverLinus Torvalds2005-06-302-39/+32
| | | | | | | | | | | | 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".
* Add support for "forcing" a ref on the remote sideLinus Torvalds2005-06-301-2/+18
| | | | | | | | | 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.
* git-send-pack: actually send the object packLinus Torvalds2005-06-301-12/+79
| | | | | | | | 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.
* git-receive-pack: implement ref switch command handlingLinus Torvalds2005-06-301-5/+59
| | | | | | 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.
* Add comment on what send-pack still needs to doLinus Torvalds2005-06-291-0/+11
| | | | Me tired.
* git-receive-pack: start parsing ref update commandsLinus Torvalds2005-06-291-17/+35
| | | | We don't act on them yet, but we parse them.
* Slow but steady progress on git pack receive/sendLinus Torvalds2005-06-292-27/+42
|
* git-send-pack: start parsing local/remote reference differencesLinus Torvalds2005-06-291-3/+58
| | | | | Right now it just shows which refs it picks up, and whether they are the same or changed on the remote end. Getting there..
* Turn on optimization againLinus Torvalds2005-06-291-1/+1
| | | | | It got turned off by mistake just because I had been doing debugging, and committed the Makefile that had other changes ...
* [PATCH] Remove unnecessary sort from t6001 testcaseJon Seymour2005-06-291-8/+8
| | | | | | | | | | | | | | 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: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Fix broken t6001 test caseJon Seymour2005-06-291-3/+3
| | | | | | | | This fix fixes a t/t6001 test case break that was hidden by a bug in the test case infrastructure. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Demonstrate broken t6001 test case functionJon Seymour2005-06-291-3/+2
| | | | | | | | | | | | | | | 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: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Fix for git-rev-list --merge-order B ^A (A,B share common base) [rev 2]Jon Seymour2005-06-292-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Test case that demonstrates problem with --merge-order ^ processingJon Seymour2005-06-291-0/+5
| | | | | | | | | | | | | | | | | | | | | 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: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Make send/receive-pack be closer to doing something interestingLinus Torvalds2005-06-295-126/+148
|
* Start of "git-send-pack", the local part of sending off a packLinus Torvalds2005-06-292-1/+120
| | | | Like git-receive-pack, this is only partway done.
* Add first cut at "git-receive-pack"Linus Torvalds2005-06-293-1/+326
| | | | | | | | 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.
* Remove bogus dup commit warning with --merge-orderLinus Torvalds2005-06-291-4/+1
| | | | | It makes gitk unhappy, and besides, non-merge-order doesn't complain, so why do it here..
* Teach git-rev-list about non-commit objectsLinus Torvalds2005-06-291-13/+91
| | | | | | | | 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.
* Prepare git-rev-list for tracking tag objects tooLinus Torvalds2005-06-291-6/+20
| | | | | | We want to be able to just say "give a difference between these objects", rather than limiting it to commits only. This isn't there yet, but it sets things up to be a bit easier.
View Lorry Controller Status