- 16 8月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
This is a stop-gap to work around problem with git-init without intrusive changes. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 8月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
This changes the behaviour of cloning from a repository on the local machine, by defaulting to "-l" (use hardlinks to share files under .git/objects) and making "-l" a no-op. A new option, --no-hardlinks, is also added to cause file-level copy of files under .git/objects while still avoiding the normal "pack to pipe, then receive and index pack" network transfer overhead. The old behaviour of local cloning without -l nor -s is availble by specifying the source repository with the newly introduced file:///path/to/repo.git/ syntax (i.e. "same as network" cloning). * With --no-hardlinks (i.e. have all .git/objects/ copied via cpio) would not catch the source repository corruption, and also risks corrupted recipient repository if an alpha-particle hits memory cell while indexing and resolving deltas. As long as the recipient is created uncorrupted, you have a good back-up. * same-as-network is expensive, but it would catch the breakage of the source repository. It still risks corrupted recipient repository due to hardware failure. As long as the recipient is created uncorrupted, you have a good back-up. * The new default on the same filesystem, as long as the source repository is healthy, it is very likely that the recipient would be, too. Also it is very cheap. You do not get any back-up benefit, though. None of the method is resilient against the source repository corruption, so let's discount that from the comparison. Then the difference with and without --no-hardlinks matters primarily if you value the back-up benefit or not. If you want to use the cloned repository as a back-up, then it is cheaper to do a clone with --no-hardlinks and two git-fsck (source before clone, recipient after clone) than same-as-network clone, especially as you are likely to do a git-fsck on the recipient if you are so paranoid anyway. Which leads me to believe that being able to use file:/// is probably a good idea, if only for testability, but probably of little practical value. We default to hardlinked clone for everyday use, and paranoids can use --no-hardlinks as a way to make a back-up. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 7月, 2007 2 次提交
-
-
由 Matthias Lederhofer 提交于
If GIT_WORK_TREE is set git-clone will use that path for the working tree. Signed-off-by: NMatthias Lederhofer <matled@gmx.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Matthias Lederhofer 提交于
Signed-off-by: NMatthias Lederhofer <matled@gmx.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 7月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 7月, 2007 1 次提交
-
-
由 Sven Verdoolaege 提交于
git-clone supports cloning from a repo with detached HEAD, but if this HEAD is not behind any branch tip then it would not have been fetched over dumb http, resulting in a fatal: Not a valid object name HEAD Since 928c210a, this would also happen on a http repo with a HEAD that is a symbolic link where someone has forgotton to run update-server-info. Signed-off-by: NSven Verdoolaege <skimo@liacs.nl> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 6月, 2007 1 次提交
-
-
由 Jeffrey C. Ollie 提交于
Now that git-init has an option to quiet itself, use it if the -q option was specified on the clone command line. Signed-off-by: NJeffrey C. Ollie <jeff@ocjtech.us> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 6月, 2007 1 次提交
-
-
由 Nanako Shiraishi 提交于
If the remote repository does not have a "current branch", git-clone was confused and did not set up the resulting new repository correctly. It did not reset HEAD from the default 'master', and did not write the SHA1 to the master branch. Signed-off-by: NNanako Shiraishi <nanako3@bluebottle.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 6月, 2007 2 次提交
-
-
由 Junio C Hamano 提交于
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Alex Riesen 提交于
The problem is visible when cloning a local repo. The cloned repository will have the origin url setup incorrectly: the origin name will be copied verbatim in origin url of the cloned repository. Normally, the name is to be expanded into absolute path. Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 5月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
c2f599e0 introduced a buglet while cloning from a remote URL; we forgot to squelch the unnecessary error message when we try to cd to the given "remote" name, in order to see if it is a local directory. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 11 5月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
If you have /home/me/git symlink pointing at /pub/git/mine, trying to clone from /pub/git/his/ using relative path would not work as expected: $ cd /home/me $ cd git $ ls ../ his mine $ git clone -l -s -n ../his/stuff.git This is because "cd ../his/stuff.git" done inside git-clone to check if the repository is local is confused by $PWD, which is set to /home/me, and tries to go to /home/his/stuff.git which is different from /pub/git/his/stuff.git. We could probably say "set -P" (or "cd -P") instead, if we know the shell is POSIX, but the way the patch is coded is probably more portable. [jc: this is updated with Andy Whitcroft's improvements] Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 21 4月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
This forward-ports a fix from 2986c022 to git-clone. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 28 3月, 2007 1 次提交
-
-
由 Gerrit Pape 提交于
Please see http://bugs.debian.org/409887 http-fetch expected the URL given at the command line to have a trailing slash anyway, and then added '/objects...' when requesting objects files from the http server. Now it doesn't require the trailing slash in <url> anymore, and strips trailing slashes if given nonetheless. Signed-off-by: NGerrit Pape <pape@smarden.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 20 3月, 2007 1 次提交
-
-
由 Chris Wright 提交于
We already have -q in git clone. So for those who care to suppress the noise during an http based clone, make -q actually do a quiet http fetch. Signed-off-by: NChris Wright <chrisw@sous-sol.org> Cc: Fernando Herrera <fherrera@onirica.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 2月, 2007 1 次提交
-
-
由 Johannes Schindelin 提交于
The intent of the commit 'fetch & clone: do not output progress when not on a tty' was to make fetching and cloning less chatty when output was not redirected (such as in a cron job). However, there was a serious thinko in that commit. It assumed that the client _and_ the server got this update at the same time. But this is obviously not the case, and therefore upload-pack died on seeing the option "--no-progress". This patch fixes that issue by making it a protocol option. So, until your server is updated, you still see the progress, but once the server has this patch, it will be quiet. A minor issue was also fixed: when cloning, the checkout did not heed no_progress. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 20 2月, 2007 1 次提交
-
-
由 Johannes Schindelin 提交于
This adds the option "--no-progress" to fetch-pack and upload-pack, and makes fetch and clone pass this option when stdout is not a tty. While at documenting that option, also document --strict and --timeout options for upload-pack. Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 07 2月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
Earlier we only used loose refs to anchor already existing objects. When cloning from a repository that forked relatively long time ago from the reference repository, this made the want/have exchange by fetch-pack to do unnecessary work. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 04 2月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
When using --reference to borrow objects from a neighbouring repository while cloning, we copy the entire set of refs under temporary "refs/reference-tmp/refs" space and set up the object alternates. However, a textual symref copied this way would not point at the right place, and causes later steps to emit error messages (which is harmless but still alarming). This is most visible when using a clone created with the separate-remote layout as a reference, because such a repository would have refs/remotes/origin/HEAD with 'ref: refs/remotes/origin/master' as its contents. Although we do not create symbolic-link based refs anymore, they have the same problem because they are always supposed to be relative to refs/ hierarchy (we dereference by hand, so it only is good for HEAD and nothing else). In either case, the solution is simply to remove them after copying under refs/reference-tmp; if a symref points at a true ref, that true ref itself is enough to ensure that objects reachable from it do not needlessly get fetched. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 01 2月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Recent commit ae1dffcb by Junio changed the way --upload-pack was passed around between clone, fetch and ls-remote and modified the handling of the command line parameter parsing. Unfortunately FreeBSD 6.1 insists that the expression expr --upload-pack=git-upload-pack : '-[^=]*=\(.*\)' is illegal, as the --upload-pack option is not supported by their implementation of expr. Elsewhere in Git we use z as a leading prefix of both arguments, ensuring the -- isn't seen by expr. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 29 1月, 2007 2 次提交
-
-
Signed-off-by: NSimon 'corecode' Schubert <corecode@fs.ei.tum.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Tom Prince 提交于
Signed-off-by: NTom Prince <tom.prince@ualberta.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 25 1月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
This makes them consistent with other commands that take the path to the upload-pack program. We also pass --upload-pack instead of --exec to the underlying fetch-pack, although it is not strictly necessary. [jc: original motivation from Uwe] Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 13 1月, 2007 1 次提交
-
-
由 Nicolas Pitre 提交于
While 'init-db' still is and probably will always remain a valid git command for obvious backward compatibility reasons, it would be a good idea to move shipped tools and docs to using 'init' instead. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 10 1月, 2007 1 次提交
-
-
由 Alexandre Julliard 提交于
Otherwise we get an error like this on stderr: cat: [...]/.git/refs/remotes/origin/master: No such file or directory which makes it look like git-clone failed. Signed-off-by: NAlexandre Julliard <julliard@winehq.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 29 12月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
This changes the default remote.origin.fetch configuration created by git-clone so that it allows non-fast-forward updates. When using the separate-remote layout with reflog enabled, it does not make much sense to refuse to update the remote tracking branch just because some of them do not fast-forward. git-fetch issues warnings on non-fast-forwardness, and the user can peek at what the previous state was using the reflog. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 17 12月, 2006 3 次提交
-
-
由 Junio C Hamano 提交于
Finally. The separate-remote layout is so much more organized than traditional and easier to work with especially when you need to deal with remote repositories with multiple branches and/or you need to deal with more than one remote repositories, and using traditional layout for new repositories simply does not make much sense. Internally we still have code for 1:1 mappings to create a bare clone; that is a good thing and will not go away. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Now we lost the "first refspec is the one that is merged by default" rule, there is no reason for clone to list the remote primary branch in the config file explicitly anymore. We still need it for the traditional layout for other reasons, though. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This stops enumerating the set of branches found on the remote side when a clone was made in the configuration file. Instead, a single entry that maps each remote branch to the local tracking branch for the remote under the same name is created. Doing it this way not only shortens the configuration file, but automatically adjusts to a new branch added on the remote side after the clone is made. Unfortunately this cannot be done for the traditional layout, where we always need to special case the 'master' to 'origin' mapping within the local branch namespace. But that is Ok; it will be going away before v1.5.0. We could also lose the "primary branch" mapping at the beginning, but that has to wait until we implement the "forbid 'git pull' when we do not have branch.$current.merge for the current branch" policy we earlier discussed. That should also be in v1.5.0 Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 07 12月, 2006 1 次提交
-
-
由 Andy Parkins 提交于
Without any specification in the .git/config file, git-pull will execute "git-pull origin"; which in turn defaults to pull from the first "pull" definition for the remote, "origin". This is a difficult set of defaults to track for a new user, and it's difficult to see what tells git to do this (especially when it is actually hard-coded behaviour). To ameliorate this slightly, this patch explicitly specifies the default behaviour during a clone using the "branch" section of the config. For example, a clone of a typical repository would create a .git/config containing: [remote "origin"] url = proto://host/repo.git fetch = refs/heads/master:refs/remotes/origin/master [branch "master"] remote = origin merge = refs/heads/master The [branch "master"] section is such that there is no change to the functionality of git-pull, but that functionality is now explicitly documented. Signed-off-by: NAndy Parkins <andyparkins@gmail.com>
-
- 05 12月, 2006 1 次提交
-
-
由 Jakub Narebski 提交于
With making --use-separate-remote default when creating non-bare clone, there was need for the flag which would turn off this behavior. It was called --use-immingled-remote. Immingle means to blend, to combine into one, to intermingle, but it is a bit obscure word. I think it would be better to use simply --no-separate-remote as the opposite to --use-separate-remote option to git clone. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 28 11月, 2006 1 次提交
-
-
由 Andy Parkins 提交于
Rather than use a separate config .git/remotes/ for remote shortcuts, this patch adds the analagous definitions to .git/config using git-repo-config calls. For example what was previously .git/remotes/origin URL: proto://host/path Pull: refs/heads/master:refs/heads/origin Is now added to .git/config as [remote "origin"] url = proto://host/path fetch = refs/heads/master:refs/heads/origin Signed-off-by: NAndy Parkins <andyparkins@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 25 11月, 2006 2 次提交
-
-
由 Junio C Hamano 提交于
Most notably, the original code first copied refs/remotes/ that remote side had to local, and overwrote them by mapping refs/heads/ from the remote when a dumb protocol transport was used. This makes the clone behaviour by dumb protocol in line with the git native and rsync transports. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Johannes Schindelin 提交于
By specifying a depth, you can now clone a repository such that all fetched ancestor-chains' length is at most "depth". For example, if the upstream repository has only 2 branches ("A" and "B"), which are linear, and you specify depth 3, you will get A, A~1, A~2, A~3, B, B~1, B~2, and B~3. The ends are automatically made shallow commits. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 11月, 2006 1 次提交
-
-
由 Petr Baudis 提交于
We've talked about this for quite some time on the list, and it is a sane thing to do for a repository with an associcated working tree. For somebody who wants to use the traditional layout, there is a backward compatibility option --use-immingled-remote, but it is expected to be removed before the next major release. Signed-off-by: NPetr Baudis <pasky@suse.cz> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 10月, 2006 1 次提交
-
-
由 Jim Meyering 提交于
I noticed that a cron-launched "git-clone --quiet" was generating progress output to standard error -- and thus always spamming me. The offending output was due to git-clone invoking git-read-tree with its undocumented -v option. This change turns off "-v" for --quiet. Signed-off-by: NJim Meyering <jim@meyering.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 21 10月, 2006 1 次提交
-
-
由 Dmitry V. Levin 提交于
Signed-off-by: NDmitry V. Levin <ldv@altlinux.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 15 10月, 2006 1 次提交
-
-
由 Yasushi SHOJI 提交于
the repository argument for git-clone should be relative to $PWD instead of the given target directory. The old behavior gave us surprising success and you need a few minute to know why it worked. GIT_DIR is already exported so no need to cd into $D. And this makes $PWD for git-fetch-pack, which is the actual command to take the given repository dir, the same as git-clone. Signed-off-by: NYasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 29 9月, 2006 1 次提交
-
-
由 Sasha Khapyorsky 提交于
If http.noEPSV config variable is defined and true, or if GIT_CURL_FTP_NO_EPSV environment variable is defined, disable using of EPSV ftp command (PASV will be used instead). This is helpful with some "poor" ftp servers which does not support EPSV mode. Signed-off-by: NSasha Khapyorsky <sashak@voltaire.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 14 9月, 2006 1 次提交
-
-
由 Sasha Khapyorsky 提交于
This adds trivial support for cloning and fetching via ftp://. Signed-off-by: NSasha Khapyorsky <sashak@voltaire.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-