summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-12-10clone: use git protocol for cloning shallow repo locallyLibravatar Nguyễn Thái Ngọc Duy2-2/+16
clone_local() does not handle $SRC/shallow. It could be made so, but it's simpler to use fetch-pack/upload-pack instead. This used to be caught by the check in upload-pack, which is triggered by transport_get_remote_refs(), even in local clone case. The check is now gone and check_everything_connected() should catch the result incomplete repo. But check_everything_connected() will soon be skipped in local clone case, opening a door to corrupt repo. This patch should close that door. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10send-pack: support pushing from a shallow clone via httpLibravatar Nguyễn Thái Ngọc Duy3-5/+42
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10receive-pack: support pushing to a shallow clone via httpLibravatar Nguyễn Thái Ngọc Duy2-3/+35
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10smart-http: support shallow fetch/cloneLibravatar Nguyễn Thái Ngọc Duy6-9/+81
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10remote-curl: pass ref SHA-1 to fetch-pack as wellLibravatar Nguyễn Thái Ngọc Duy2-1/+9
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10send-pack: support pushing to a shallow cloneLibravatar Nguyễn Thái Ngọc Duy3-4/+43
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10receive-pack: allow pushes that update .git/shallowLibravatar Nguyễn Thái Ngọc Duy5-13/+201
The basic 8 steps to update .git/shallow does not fully apply here because the user may choose to accept just a few refs (while fetch always accepts all refs). The steps are modified a bit. 1-6. same as before. After calling assign_shallow_commits_to_refs at step 6, each shallow commit has a bitmap that marks all refs that require it. 7. mark all "ours" shallow commits that are reachable from any refs. We will need to do the original step 7 on them later. 8. go over all shallow commit bitmaps, mark refs that require new shallow commits. 9. setup a strict temporary shallow file to plug all the holes, even if it may cut some of our history short. This file is used by all hooks. The hooks could use --shallow-file=$GIT_DIR/shallow to overcome this and reach everything in current repo. 10. go over the new refs one by one. For each ref, do the reachability test if it needs a shallow commit on the list from step 7. Remove it if it's reachable from our refs. Gather all required shallow commits, run check_everything_connected() with the new ref, then install them to .git/shallow. This mode is disabled by default and can be turned on with receive.shallowupdate Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10connected.c: add new variant that runs with --shallow-fileLibravatar Nguyễn Thái Ngọc Duy2-8/+36
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10add GIT_SHALLOW_FILE to propagate --shallow-file to subprocessesLibravatar Nguyễn Thái Ngọc Duy5-3/+12
This may be needed when a hook is run after a new shallow pack is received, but .git/shallow is not settled yet. A temporary shallow file to plug all loose ends should be used instead. GIT_SHALLOW_FILE is overriden by --shallow-file. --shallow-file does not work in this case because the hook may spawn many git subprocesses and the launch commands do not have --shallow-file as it's a recent addition. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10receive/send-pack: support pushing from a shallow cloneLibravatar Nguyễn Thái Ngọc Duy5-11/+146
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10receive-pack: reorder some code in unpack()Libravatar Nguyễn Thái Ngọc Duy1-40/+30
This is the preparation for adding --shallow-file to both unpack-objects and index-pack. To sum up: - struct argv_array used instead of const char ** - status/code, ip/child, unpacker/keeper are moved out to function top level - successful flow now ends at the end of the function Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10fetch: add --update-shallow to accept refs that update .git/shallowLibravatar Nguyễn Thái Ngọc Duy7-1/+79
The same steps are done as in when --update-shallow is not given. The only difference is we now add all shallow commits in "ours" and "theirs" to .git/shallow (aka "step 8"). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10upload-pack: make sure deepening preserves shallow rootsLibravatar Nguyễn Thái Ngọc Duy4-4/+28
When "fetch --depth=N" where N exceeds the longest chain of history in the source repo, usually we just send an "unshallow" line to the client so full history is obtained. When the source repo is shallow we need to make sure to "unshallow" the current shallow point _and_ "shallow" again when the commit reaches its shallow bottom in the source repo. This should fix both cases: large <N> and --unshallow. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10fetch: support fetching from a shallow repositoryLibravatar Nguyễn Thái Ngọc Duy5-5/+176
This patch just put together pieces from the 8 steps patch. We stop at step 7 and reject refs that require new shallow commits. Note that, by rejecting refs that require new shallow commits, we leave dangling objects in the repo, which become "object islands" by the next "git fetch" of the same source. If the first fetch our "ours" set is zero and we do practically nothing at step 7, "ours" is full at the next fetch and we may need to walk through commits for reachability test. Room for improvement. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10clone: support remote shallow repositoryLibravatar Nguyễn Thái Ngọc Duy6-7/+71
Cloning from a shallow repository does not follow the "8 steps for new .git/shallow" because if it does we need to get through step 6 for all refs. That means commit walking down to the bottom. Instead the rule to create .git/shallow is simpler and, more importantly, cheap: if a shallow commit is found in the pack, it's probably used (i.e. reachable from some refs), so we add it. Others are dropped. One may notice this method seems flawed by the word "probably". A shallow commit may not be reachable from any refs at all if it's attached to an object island (a group of objects that are not reachable by any refs). If that object island is not complete, a new fetch request may send more objects to connect it to some ref. At that time, because we incorrectly installed the shallow commit in this island, the user will not see anything after that commit (fsck is still ok). This is not desired. Given that object islands are rare (C Git never sends such islands for security reasons) and do not really harm the repository integrity, a tradeoff is made to surprise the user occasionally but work faster everyday. A new option --strict could be added later that follows exactly the 8 steps. "git prune" can also learn to remove dangling objects _and_ the shallow commits that are attached to them from .git/shallow. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10fetch-pack.h: one statement per bitfield declarationLibravatar Nguyễn Thái Ngọc Duy1-12/+12
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10fetch-pack.c: move shallow update code out of fetch_pack()Libravatar Nguyễn Thái Ngọc Duy1-9/+13
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10shallow.c: steps 6 and 7 to select new commits for .git/shallowLibravatar Nguyễn Thái Ngọc Duy2-0/+297
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10shallow.c: the 8 steps to select new commits for .git/shallowLibravatar Nguyễn Thái Ngọc Duy4-1/+90
Suppose a fetch or push is requested between two shallow repositories (with no history deepening or shortening). A pack that contains necessary objects is transferred over together with .git/shallow of the sender. The receiver has to determine whether it needs to update .git/shallow if new refs needs new shallow comits. The rule here is avoid updating .git/shallow by default. But we don't want to waste the received pack. If the pack contains two refs, one needs new shallow commits installed in .git/shallow and one does not, we keep the latter and reject/warn about the former. Even if .git/shallow update is allowed, we only add shallow commits strictly necessary for the former ref (remember the sender can send more shallow commits than necessary) and pay attention not to accidentally cut the receiver history short (no history shortening is asked for) So the steps to figure out what ref need what new shallow commits are: 1. Split the sender shallow commit list into "ours" and "theirs" list by has_sha1_file. Those that exist in current repo in "ours", the remaining in "theirs". 2. Check the receiver .git/shallow, remove from "ours" the ones that also exist in .git/shallow. 3. Fetch the new pack. Either install or unpack it. 4. Do has_sha1_file on "theirs" list again. Drop the ones that fail has_sha1_file. Obviously the new pack does not need them. 5. If the pack is kept, remove from "ours" the ones that do not exist in the new pack. 6. Walk the new refs to answer the question "what shallow commits, both ours and theirs, are required in .git/shallow in order to add this ref?". Shallow commits not associated to any refs are removed from their respective list. 7. (*) Check reachability (from the current refs) of all remaining commits in "ours". Those reachable are removed. We do not want to cut any part of our (reachable) history. We only check up commits. True reachability test is done by check_everything_connected() at the end as usual. 8. Combine the final "ours" and "theirs" and add them all to .git/shallow. Install new refs. The case where some hook rejects some refs on a push is explained in more detail in the push patches. Of these steps, #6 and #7 are expensive. Both require walking through some commits, or in the worst case all commits. And we rather avoid them in at least common case, where the transferred pack does not contain any shallow commits that the sender advertises. Let's look at each scenario: 1) the sender has longer history than the receiver All shallow commits from the sender will be put into "theirs" list at step 1 because none of them exists in current repo. In the common case, "theirs" becomes empty at step 4 and exit early. 2) the sender has shorter history than the receiver All shallow commits from the sender are likely in "ours" list at step 1. In the common case, if the new pack is kept, we could empty "ours" and exit early at step 5. If the pack is not kept, we hit the expensive step 6 then exit after "ours" is emptied. There'll be only a handful of objects to walk in fast-forward case. If it's forced update, we may need to walk to the bottom. 3) the sender has same .git/shallow as the receiver This is similar to case 2 except that "ours" should be emptied at step 2 and exit early. A fetch after "clone --depth=X" is case 1. A fetch after "clone" (from a shallow repo) is case 3. Luckily they're cheap for the common case. A push from "clone --depth=X" falls into case 2, which is expensive. Some more work may be done at the sender/client side to avoid more work on the server side: if the transferred pack does not contain any shallow commits, send-pack should not send any shallow commits to the receive-pack, effectively turning it into a normal push and avoid all steps. This patch implements all steps except #3, already handled by fetch-pack and receive-pack, #6 and #7, which has their own patch due to their size. (*) in previous versions step 7 was put before step 3. I reorder it so that the common case that keeps the pack does not need to walk commits at all. In future if we implement faster commit reachability check (maybe with the help of pack bitmaps or commit cache), step 7 could become cheap and be moved up before 6 again. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10shallow.c: extend setup_*_shallow() to accept extra shallow commitsLibravatar Nguyễn Thái Ngọc Duy4-11/+24
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10connect.c: teach get_remote_heads to parse "shallow" linesLibravatar Nguyễn Thái Ngọc Duy6-8/+20
No callers pass a non-empty pointer as shallow_points at this stage. As a result, all clients still refuse to talk to shallow repository on the other end. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10make the sender advertise shallow commits to the receiverLibravatar Nguyễn Thái Ngọc Duy5-3/+26
If either receive-pack or upload-pack is called on a shallow repository, shallow commits (*) will be sent after the ref advertisement (but before the packet flush), so that the receiver has the full "shape" of the sender's commit graph. This will be needed for the receiver to update its .git/shallow if necessary. This breaks the protocol for all clients trying to push to a shallow repo, or fetch from one. Which is basically the same end result as today's "is_repository_shallow() && die()" in receive-pack and upload-pack. New clients will be made aware of shallow upstream and can make use of this information. The sender must send all shallow commits that are sent in the following pack. It may send more shallow commits than necessary. upload-pack for example may choose to advertise no shallow commits if it knows in advance that the pack it's going to send contains no shallow commits. But upload-pack is the server, so we choose the cheaper way, send full .git/shallow and let the client deal with it. Smart HTTP is not affected by this patch. Shallow support on smart-http comes later separately. (*) A shallow commit is a commit that terminates the revision walker. It is usually put in .git/shallow in order to keep the revision walker from going out of bound because there is no guarantee that objects behind this commit is available. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10clone: prevent --reference to a shallow repositoryLibravatar Nguyễn Thái Ngọc Duy1-0/+6
If we borrow objects from another repository, we should also pay attention to their $GIT_DIR/shallow (and even info/grafts). But current alternates code does not. Reject alternate repos that are shallow because we do not do it right. In future the alternate code may be updated to check $GIT_DIR/shallow properly so that this restriction could be lifted. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10send-pack: forbid pushing from a shallow repositoryLibravatar Nguyễn Thái Ngọc Duy1-0/+3
send-pack can send a pack with loose ends to the server. receive-pack before 6d4bb38 (fetch: verify we have everything we need before updating our ref - 2011-09-01) does not detect this and keeps the pack anyway, which corrupts the repository, at least from fsck point of view. send-pack will learn to safely push from a shallow repository later. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10remote.h: replace struct extra_have_objects with struct sha1_arrayLibravatar Nguyễn Thái Ngọc Duy6-22/+14
The latter can do everything the former can and is used in many more places. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10transport.h: remove send_pack prototype, already defined in send-pack.hLibravatar Nguyễn Thái Ngọc Duy1-6/+0
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-27Git 1.8.5Libravatar Junio C Hamano2-1/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-27Sync with maintLibravatar Junio C Hamano0-0/+0
* maint: remote-hg: don't decode UTF-8 paths into Unicode objects
2013-11-27remote-hg: don't decode UTF-8 paths into Unicode objectsLibravatar Richard Hansen1-1/+1
The internal mercurial API expects ordinary 8-bit string objects, not Unicode string objects. With this change, the test-hg.sh unit tests pass again. Signed-off-by: Richard Hansen <rhansen@bbn.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-25Merge branch 'rh/remote-hg-bzr-updates' (early part)Libravatar Junio C Hamano1-1/+1
Unbreaks a recent breakage due to use of unquote-c-style. This may need to be cherry-picked down to 1.8.4.x series. * 'rh/remote-hg-bzr-updates' (early part): remote-hg: don't decode UTF-8 paths into Unicode objects
2013-11-20Git 1.8.5-rc3Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-20Sync with 1.8.4.4Libravatar Junio C Hamano2-1/+12
2013-11-20Git 1.8.4.4Libravatar Junio C Hamano3-2/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-20Merge branch 'mb/relnotes-1.8.5-fix'Libravatar Junio C Hamano1-82/+84
* mb/relnotes-1.8.5-fix: RelNotes: spelling & grammar fixes
2013-11-18RelNotes: spelling & grammar fixesLibravatar Marc Branchaud1-82/+84
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18Merge branch 'nd/literal-pathspecs'Libravatar Junio C Hamano6-5/+30
Fixes a regression on 'master' since v1.8.4. * nd/literal-pathspecs: pathspec: stop --*-pathspecs impact on internal parse_pathspec() uses
2013-11-18remote-hg: don't decode UTF-8 paths into Unicode objectsLibravatar Richard Hansen1-1/+1
The internal mercurial API expects ordinary 8-bit string objects, not Unicode string objects. With this change, the test-hg.sh unit tests pass again. Signed-off-by: Richard Hansen <rhansen@bbn.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18Merge branch 'maint'Libravatar Junio C Hamano1-1/+0
Hotfix for recent regression while talking to upload-pack in a repository with many symbolic refs. * maint: Revert "upload-pack: send non-HEAD symbolic refs"
2013-11-18Merge branch 'jx/branch-vv-always-compare-with-upstream'Libravatar Junio C Hamano2-12/+20
Hot-fix for a regression. * jx/branch-vv-always-compare-with-upstream: branch: fix --verbose output column alignment
2013-11-18branch: fix --verbose output column alignmentLibravatar Torstein Hegge2-12/+20
Commit f2e0873 (branch: report invalid tracking branch as gone) removed an early return from fill_tracking_info() in the path taken when 'git branch -v' lists a branch in sync with its upstream. This resulted in an unconditionally added space in front of the subject line: $ git branch -v * master f5eb3da commit pushed to upstream topic f935eb6 unpublished topic Instead, only add the trailing space if a decoration have been added. To catch this kind of whitespace breakage in the tests, be a bit less smart when filtering the output through sed. Signed-off-by: Torstein Hegge <hegge@resisty.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18Revert "upload-pack: send non-HEAD symbolic refs"Libravatar Junio C Hamano1-1/+0
This reverts commit 5e7dcad771cb873e278a0571b46910d7c32e2f6c; there may be unbounded number of symbolic refs in the repository, but the capability header line in the on-wire protocol has a rather low length limit.
2013-11-13Git 1.8.5-rc2Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-12Merge git://github.com/git-l10n/git-poLibravatar Junio C Hamano7-7412/+9045
* git://github.com/git-l10n/git-po: l10n: de.po: improve error message when pushing to unknown upstream l10n: de.po: translate 68 new messages po/TEAMS: update Thomas Rast's email address l10n: Update Swedish translation (2194t0f0u) l10n: fr.po 2194/1294 messages translated l10n: zh_CN.po: translate 68 messages (2194t0f0u) l10n: vi.po (2194t): Update and minor fix l10n: git.pot: v1.8.5 round 1 (68 new, 9 removed)
2013-11-12Correct word usage of "timezone" in "Documentation" directoryLibravatar Jason St. John7-22/+22
"timezone" is two words, not one (i.e. "time zone" is correct). Correct this in these files: -- date-formats.txt -- git-blame.txt -- git-cvsimport.txt -- git-fast-import.txt -- git-svn.txt -- gitweb.conf.txt -- rev-list-options.txt Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-12l10n: de.po: improve error message when pushing to unknown upstreamLibravatar Ralf Thielow1-1/+1
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Acked-by: Thomas Rast <tr@thomasrast.ch>
2013-11-12l10n: de.po: translate 68 new messagesLibravatar Ralf Thielow1-1216/+1498
Translate 68 new messages came from git.pot update in 727b957 (l10n: git.pot: v1.8.5 round 1 (68 new, 9 removed)). Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Acked-by: Thomas Rast <tr@thomasrast.ch>
2013-11-12po/TEAMS: update Thomas Rast's email addressLibravatar Ralf Thielow1-1/+1
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Acked-by: Thomas Rast <tr@thomasrast.ch>
2013-11-10Merge remote-tracking branch 'sv/nafmo/master'Libravatar Jiang Xin1-1217/+1499
* sv/nafmo/master: l10n: Update Swedish translation (2194t0f0u)
2013-11-09l10n: Update Swedish translation (2194t0f0u)Libravatar Peter Krefting1-1217/+1499
And fix a typo. Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2013-11-08l10n: fr.po 2194/1294 messages translatedLibravatar Jean-Noel Avila1-1230/+1513
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr> Signed-off-by: Sebastien Helleu <flashcode@flashtux.org>