git/git-parse-remote.sh, branch v1.5.0-rc3

git-fetch: Allow fetching the remote HEAD

2007-01-30T10:30:25Z

... with: $ git fetch ${remote} HEAD Also $ git fetch ${remote} :${localref} worked, but $ git fetch ${remote} HEAD:{localref} didn't. Now both are equivalent. Signed-off-by: Santi Béjar Signed-off-by: Junio C Hamano

[PATCH] Rename git-repo-config to git-config.

2007-01-29T00:16:53Z

Signed-off-by: Tom Prince Signed-off-by: Junio C Hamano

parse-remote: do not barf on a remote shorthand without any refs to fetch.

2007-01-26T06:03:16Z

Signed-off-by: Junio C Hamano

make --upload-pack option to git-fetch configurable

2007-01-25T07:06:30Z

This introduces the config item remote..uploadpack to override the default value (which is "git-upload-pack"). Signed-off-by: Uwe Kleine-König Signed-off-by: Junio C Hamano

Fix git-fetch while on detached HEAD not to give needlessly alarming errors

2007-01-15T23:35:07Z

When we are on a detached HEAD, there is no current branch. There is no reason to leak the error messages to the end user since this is a situation we expect to see. This adds -q option to git-symbolic-ref to exit without issuing an error message if the given name is not a symbolic ref. By the way, with or without this patch, there currently is no good way to tell failure modes between "git symbolic-ref HAED" and "git symbolic-ref HEAD". Both says "is not a symbolic ref". We may want to do something about it. Signed-off-by: Junio C Hamano

Do not merge random set of refs out of wildcarded refs

2007-01-01T02:53:26Z

When your fetch configuration has only the wildcards, we would pick the lexicographically first ref from the remote side for merging, which was complete nonsense. Make sure nothing except the one that is specified with branch.*.merge is merged in this case. Signed-off-by: Junio C Hamano

Allow branch.*.merge to talk about remote tracking branches.

2006-12-24T10:18:57Z

People often get confused if the value of branch.*.merge should be the remote branch name they are fetching from, or the tracking branch they locally have. So this allows either. Signed-off-by: Junio C Hamano

Do not support "partial URL shorthand" anymore.

2006-12-22T23:37:48Z

We used to support specifying the top part of remote URL in remotes and use that as a short-hand for the URL. $ cat .git/remotes/jgarzik URL: git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/ $ git pull jgarzik/misc-2.6 This is confusing when somebody attempts to do this: $ git pull origin/foo which is not syntactically correct (unless you have origin/foo.git repository) and should fail, but it resulted in a mysterious access to the 'foo' subdirectory of the origin repository. Which was what it was designed to do, but because this is an oddball "feature" I suspect nobody uses, let's remove it. Signed-off-by: Junio C Hamano

default pull: forget about "newbie protection" for now.

2006-12-22T23:25:21Z

This will not be backward compatible no matter how you cut it. Shelve it for now until somebody comes up with a better way to determine when we can safely refuse to use the first set of branchse for merging without upsetting valid workflows. Signed-off-by: Junio C Hamano

parse-remote: mark all refs not for merge only when fetching more than one

2006-12-22T06:56:25Z

An earlier commit a71fb0a1 implemented much requested safety valve to refuse "git pull" or "git pull origin" without explicit refspecs from using the first set of remote refs obtained by reading .git/remotes/origin file or branch.*.fetch configuration variables to create a merge. The argument was that while on a branch different from the default branch, it is often wrong to merge the default remote ref suitable for merging into the master. That is fine as a theory. But many repositories already in use by people in the real world do not have any of the per branch configuration crap. They did not need it, and they do not need it now. Merging with the first remote ref listed was just fine, because they had only one ref (e.g. 'master' from linux-2.6.git) anyway. So this changes the safety valve to be a lot looser. When "git fetch" gets only one remote branch, the irritating warning would not trigger anymore. I think we could also make the warning trigger when branch.*.merge is not specified for the current branch, but is for some other branch. That is for another commit. Signed-off-by: Junio C Hamano