path: root/
AgeCommit message (Collapse)Author
2006-01-06git-fetch --tags: reject malformed tags.Junio C Hamano
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 <>
2005-12-27Do not mark tags fetched via --tags flag as mergeableJunio C Hamano
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 <>
2005-12-14git-fetch: Usage string clean-up, emit usage string at unrecognized
Signed-off-by: Fredrik Kuivinen <> Signed-off-by: Junio C Hamano <>
2005-11-25git-sh-setup: die if outside git repository.Junio C Hamano
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 <>
2005-11-18Make "git fetch" less verbose by defaultLinus Torvalds
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 * refs/tags/v0.99.7c: same as tag 'v0.99.7c' of ... 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 * refs/tags/v1.0rc3: storing tag 'v1.0rc3' of * refs/tags/v1.0rc1: storing tag 'v1.0rc1' of 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 <> Signed-off-by: Junio C Hamano <>
2005-11-10Let git-clone/git-fetch follow HTTP redirectionsJosef Weidendorfer
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 <> Signed-off-by: Junio C Hamano <>
2005-10-19Even when overwriting tags, report if they are changed or not.Junio C Hamano
Signed-off-by: Junio C Hamano <>
2005-10-18Forward port the "funny ref avoidance" in clone and fetch from maint branch.Junio C Hamano
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 <>
2005-10-15Show peeled onion from upload-pack and server-info.Junio C Hamano
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 <>
2005-10-12git-fetch --tags: deal with tags with spaces in them.Junio C Hamano
"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 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 <>
2005-10-05[PATCH] Quote the missing GIT_DIR.Santi_Béjar
Signed-off-by: Santi Béjar <> Signed-off-by: Junio C Hamano <>
2005-10-02[PATCH] git fetch --tagsLinus Torvalds
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 <> Signed-off-by: Junio C Hamano <>
2005-09-28Use git-update-ref in scripts.Junio C Hamano
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 <>
2005-09-28Fix default pull not to do an unintended Octopus.Junio C Hamano
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 <>
2005-09-27git-fetch: send informational output to >&2 consistently.Junio C Hamano
Only the "Fetching ... using http" was leaking to stdout. Signed-off-by: Junio C Hamano <>
2005-09-21Revert "Make Octopus merge message a bit nicer."Junio C Hamano
This reverts 63f1aa6c72c46928f1b6959437aed4becbc42ff3 commit.
2005-09-21Make Octopus merge message a bit nicer.Junio C Hamano
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 <>
2005-09-20Do not give alarming error message from rsync in fetch and clone.Junio C Hamano
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 <>
2005-09-17Teach rsync transport about alternates.Junio C Hamano
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 <>
2005-09-13Propagate errors from fetch-pack correctly to git-fetch.Junio C Hamano
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 <>
2005-09-10Make sure we have leading directories under refs/{heads,tags}Junio C Hamano
Otherwise having subdirectories under refs/heads becomes rather unwieldy. Signed-off-by: Junio C Hamano <>
2005-09-08Big tool rename.Junio C Hamano
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 <>