aboutsummaryrefslogtreecommitdiff
path: root/git-fetch.sh
Commit message (Collapse)AuthorAge
* Merge branch 'jc/fetch' into nextJunio C Hamano2006-03-17
|\ | | | | | | | | * jc/fetch: fetch: exit non-zero when fast-forward check fails.
| * fetch: exit non-zero when fast-forward check fails.Junio C Hamano2006-03-17
| | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* | fetch,parse-remote,fmt-merge-msg: refs/remotes/* supportEric Wong2006-03-10
|/ | | | | | | | | | | | We can now easily fetch and merge things from heads in the refs/remotes/ hierarchy in remote repositories. The refs/remotes/ hierarchy is likely to become the standard for tracking foreign SCMs, as well as the location of Pull: targets for tracking remote branches in newly cloned repositories. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-fetch: print the new and old ref when fast-forwardingLukas Sandström2006-02-25
| | | | | Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
*-. Merge branches 'jc/rev-list' and 'jc/pack-thin'Junio C Hamano2006-02-24
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jc/rev-list: rev-list --objects: use full pathname to help hashing. rev-list --objects-edge: remove duplicated edge commit output. rev-list --objects-edge * jc/pack-thin: pack-objects: hash basename and direname a bit differently. pack-objects: allow "thin" packs to exceed depth limits pack-objects: use full pathname to help hashing with "thin" pack. pack-objects: thin pack micro-optimization. Use thin pack transfer in "git fetch". Add git-push --thin. send-pack --thin: use "thin pack" delta transfer. Thin pack - create packfile with missing delta base. Conflicts: pack-objects.c (taking "next") send-pack.c (taking "next")
| | * Use thin pack transfer in "git fetch".Junio C Hamano2006-02-20
| |/ | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-fetch: follow tag only when tracking remote branch.v1.2.3Junio C Hamano2006-02-22
|/ | | | | | | | | | | | | | | | | | Unless --no-tags flag was given, git-fetch tried to always follow remote tags that point at the commits we picked up. It is not very useful to pick up tags from remote unless storing the fetched branch head in a local tracking branch. This is especially true if the fetch is done to merge the remote branch into our current branch as one-shot basis (i.e. "please pull"), and is even harmful if the remote repository has many irrelevant tags. This proposed update disables the automated tag following unless we are storing the a fetched branch head in a local tracking branch. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-fetch --upload-pack: disambiguate.Junio C Hamano2006-01-26
| | | | | | | | | Johannes noticed the recent addition of this new flag inadvertently took over existing --update-head-ok (-u). Require longer abbreviation to this new option which would be needed in a rare setup. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-{fetch,peek-remote} handling of --upload-packMichal Ostrowski2006-01-24
| | | | | | | | | | git-peek-remote needs to handle a -u|--upload-pack parameter just like git-fetch (and git-fetch has to pass it on to git-peek-remote). (This is actually a follow-up to my previous git-fetch patch.) Signed-off-by: Michal Ostrowski <mostrows@heater.watson.ibm.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-fetch: pass --upload-pack to fetch-packMichal Ostrowski2006-01-24
| | | | | | | | | | | | | | | | | Without this, there is no way to specify a remote executable when invoking git-pull/git-fetch as there is for git-clone. [jc: I have a mild suspicion that this is a broken environment (aka sysadmin disservice). It may be legal to configure your sshd to spawn named program without involving shell at all, and if your sysadmin does so and you have your git programs under your home directory, you would need something like this, but then I suspect you would need such workaround everywhere, not just git. But we have these options we can use to work around the issue, so there is no strong reason not to reject this patch, either. ] Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Add --keep option to keep downloaded packs to git-fetch.Tom Prince2006-01-10
| | | | | Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-fetch: auto-following tags.Junio C Hamano2006-01-07
| | | | | | | | | | | I added things to ls-remote so that Cogito can auto-follow tags easily and correctly a while ago, but git-fetch did not use the facility. Recently added git-describe command relies on repository keeping up-to-date set of tags, which made it much more attractive to automatically follow tags, so we do that as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-fetch --tags: reject malformed tags.Junio C Hamano2006-01-05
| | | | | | | | | | When the other end was prepared with older git and has tags that do not follow the naming convention (see check-ref-format), do not barf but simply reject to copy them. Initial fix by Simon Richter, but done differently. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Do not mark tags fetched via --tags flag as mergeableJunio C Hamano2005-12-27
| | | | | | | Otherwise "git pull --tags" would mistakenly try to merge all of them, which is never what the user wants. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-fetch: Usage string clean-up, emit usage string at unrecognized optionfreku045@student.liu.se2005-12-14
| | | | | Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-sh-setup: die if outside git repository.Junio C Hamano2005-11-25
| | | | | | | | Now all the users of this script detect its exit status and die, complaining that it is outside git repository. So move the code that dies from all callers to git-sh-setup script. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make "git fetch" less verbose by defaultLinus Torvalds2005-11-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing something like git fetch --tags origin the excessively verbose output of git fetch makes the result totally unreadable. It's impossible to tell if it actually fetched anything new or not, since the screen will fill up with an endless supply of ... * committish: 9165ec17fde255a1770886189359897dbb541012 tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git * refs/tags/v0.99.7c: same as tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git ... and any new tags that got fetched will be totally hidden. So add a new "--verbose" flag to "git fetch" to enable this verbose mode, but make the default be quiet. NOTE! The quiet mode will still report about new or changed heads, so if you are really fetching a new head, you'll see something like this: [torvalds@g5 git]$ git fetch --tags parent Packing 6 objects Unpacking 6 objects 100% (6/6) done * refs/tags/v1.0rc2: storing tag 'v1.0rc2' of master.kernel.org:/pub/scm/git/git * refs/tags/v1.0rc3: storing tag 'v1.0rc3' of master.kernel.org:/pub/scm/git/git * refs/tags/v1.0rc1: storing tag 'v1.0rc1' of master.kernel.org:/pub/scm/git/git which actually tells you something useful that isn't hidden by all the useless crud that you already had. Extensively tested (hey, for me, this _is_ extensive) by doing a rm .git/refs/tags/v1.0rc* and re-fetching with both --verbose and without. NOTE! This means that if the fetch didn't actually fetch anything at all, git fetch will be totally quiet. I think that's much better than being so verbose that you can't even tell whether something was fetched or not, but some people might prefer to get a "nothing to fetch" message in that case. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Let git-clone/git-fetch follow HTTP redirectionsJosef Weidendorfer2005-11-10
| | | | | | | | | | | Otherwise, git-clone silently failed to clone a remote repository where redirections (ie. a response with a "Location" header line) are used. This includes the fixes from Nick Hengeveld. Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Even when overwriting tags, report if they are changed or not.Junio C Hamano2005-10-18
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Forward port the "funny ref avoidance" in clone and fetch from maint branch.Junio C Hamano2005-10-17
| | | | | | | | Somehow I forgot to forward port these fixes. "git clone" from a repository prepared with the latest update-server-info would fail without this patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Show peeled onion from upload-pack and server-info.Junio C Hamano2005-10-15
| | | | | | | | | | | | | | | | | | | | | This updates git-ls-remote to show SHA1 names of objects that are referred by tags, in the "ref^{}" notation. This would make git-findtags (without -t flag) almost trivial. git-peek-remote . | sed -ne "s:^$target "'refs/tags/\(.*\)^{}$:\1:p' Also Pasky could do: git-ls-remote --tags $remote | sed -ne 's:\( refs/tags/.*\)^{}$:\1:p' to find out what object each of the remote tags refers to, and if he has one locally, run "git-fetch $remote tag $tagname" to automatically catch up with the upstream tags. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-fetch --tags: deal with tags with spaces in them.Junio C Hamano2005-10-11
| | | | | | | | | | | | | | "git-fetch --tags" can get confused with tags with spaces in their names, it used to use shell IFS to split the list of tags and also used curl which insists the URL to be escaped. Fix it so it can work with Martin's moodle repository http://locke.catalyst.net.nz/git/moodle.git/. We still reserve characters like leading plus-sign '+' and colon ':' anywhere to represent refspec src-dst pair, and obviously we cannot use LF (that terminates Pull: line in .git/remotes files), but now you can have spaces with this patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
* [PATCH] Quote the missing GIT_DIR.Santi_Béjar2005-10-05
| | | | | Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* [PATCH] git fetch --tagsLinus Torvalds2005-10-01
| | | | | | | | | | | | | | | | You can do git fetch --tags <linus-kernel-repo> and it should fetch all my tags automatically. [jc: The original by Linus fetched and overwrote branch heads with --all, which felt dangerous and wrong, so I removed it. Also this version does not use any refs that resulted as --tags for later merge. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Use git-update-ref in scripts.Junio C Hamano2005-09-28
| | | | | | | | | This uses the git-update-ref command in scripts for safer updates. Also places where we used to read HEAD ref by using "cat" were fixed to use git-rev-parse. This will matter when we start using symbolic references. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix default pull not to do an unintended Octopus.Junio C Hamano2005-09-28
| | | | | | | | | | | | The refspecs specified in the .git/remotes/<remote> on the "Pull: " lines are for fetching multiple heads in one go, but most of the time making an Octopus out of them is not what is wanted. Make git-fetch leave the marker in .git/FETCH_HEAD file so that later stages can tell which heads are for merging and which are not. Tom Prince made me realize how stupid the original behaviour was. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-fetch: send informational output to >&2 consistently.Junio C Hamano2005-09-26
| | | | | | Only the "Fetching ... using http" was leaking to stdout. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Revert "Make Octopus merge message a bit nicer."Junio C Hamano2005-09-21
| | | | This reverts 63f1aa6c72c46928f1b6959437aed4becbc42ff3 commit.
* Make Octopus merge message a bit nicer.Junio C Hamano2005-09-20
| | | | | | | Linus says that 'of .' to mean the commits came from the local repository was too confusing and ugly -- I tend to agree with him. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Do not give alarming error message from rsync in fetch and clone.Junio C Hamano2005-09-20
| | | | | | | | | When we check the optional objects/info/alternates file at the remote repository, we forgot to really squelch error message from rsync. Not having that file is not a crime. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Teach rsync transport about alternates.Junio C Hamano2005-09-17
| | | | | | | | | | | | | | For local operations and downloading and uploading via git aware protocols, use of $GIT_OBJECT_DIRECTORY/info/alternates is recommended on the server side for big projects that are derived from another one (like Linux kernel). However, dumb protocols and rsync transport needs to resolve this on the client end, which we did not bother doing until this week. I noticed we use "rsync -z" but most of our payload is already compressed, which was not quite right. This commit also fixes it. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Propagate errors from fetch-pack correctly to git-fetch.Junio C Hamano2005-09-12
| | | | | | | When git-fetch-pack fails, the command does not notice the failure and instead pretended nothing was fetched and there was nothing wrong. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make sure we have leading directories under refs/{heads,tags}Junio C Hamano2005-09-10
| | | | | | | Otherwise having subdirectories under refs/heads becomes rather unwieldy. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Big tool rename.Junio C Hamano2005-09-07
As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano <junkio@cox.net>