path: root/
AgeCommit message (Collapse)Author
2007-01-01Do not merge random set of refs out of wildcarded refsJunio C Hamano
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 <>
2006-12-24Allow branch.*.merge to talk about remote tracking branches.Junio C Hamano
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 <>
2006-12-22Do not support "partial URL shorthand" anymore.Junio C Hamano
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 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 <>
2006-12-22default pull: forget about "newbie protection" for now.Junio C Hamano
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 <>
2006-12-22parse-remote: mark all refs not for merge only when fetching more than oneJunio C Hamano
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 <>
2006-12-22Revert "git-pull: refuse default merge without branch.*.merge"Junio C Hamano
This reverts commit a71fb0a1412c82405f078fb536797d3f5de68d53. The logic to decide when to refuse to use the default "first set of refs fetched" for merge was utterly bogus. In a repository that happily worked correctly without any of the per-branch configuration crap did not have (and did not have to have) any branch.<current>.merge. With that broken commit, pulling from origin no longer would work.
2006-12-19Move "no merge candidate" warning into git-pullJosef Weidendorfer
The warning triggered even when running "git fetch" only when resulting .git/FETCH_HEAD only contained branches marked as 'not-for-merge'. Signed-off-by: Josef Weidendorfer <> Signed-off-by: Junio C Hamano <>
2006-12-19Merge branch 'jc/test-clone' into jc/cloneJunio C Hamano
* jc/test-clone: (35 commits) Introduce GIT_TEMPLATE_DIR Revert "fix testsuite: make sure they use templates freshly built from the source" fix testsuite: make sure they use templates freshly built from the source rerere: fix breakage of resolving. Add config example with respect to branch Add documentation for show-branch --topics make git a bit less cryptic on fetch errors make patch_delta() error cases a bit more verbose racy-git: documentation updates. show-ref: fix --exclude-existing parse-remote::expand_refs_wildcard() vim syntax: follow recent changes to commit template show-ref: fix --verify --hash=length show-ref: fix --quiet --verify avoid accessing _all_ loose refs in git-show-ref --verify git-fetch: Avoid reading packed refs over and over again Teach show-branch how to show ref-log data. markup fix in svnimport documentation. Documentation: new option -P for git-svnimport Fix mis-mark-up in git-merge-file.txt documentation ...
2006-12-18parse-remote::expand_refs_wildcard()Junio C Hamano
Work around dash incompatibility by not using "${name%'^{}'}". Noticed by Jeff King; dash seems to mistake the closing brace inside the single quote as the terminating brace for parameter expansion. Signed-off-by: Junio C Hamano <>
2006-12-16git-pull: refuse default merge without branch.*.mergeJunio C Hamano
Everybody hated the pull behaviour of merging the first branch listed on remotes/* file (or remote.*.fetch config) into the current branch. This finally corrects that UI wart by forbidding "git pull" without an explicit branch name on the command line or branch.$current.merge for the current branch. The matching change to git-clone was made to prepare the default branch.*.merge entry for the primary branch some time ago. Signed-off-by: Junio C Hamano <>
2006-12-09Add branch.*.merge warning and documentation updateJosef Weidendorfer
This patch clarifies the meaning of the branch.*.merge option. Previously, if branch.*.merge was specified but did not match any ref, the message "No changes." was not really helpful regarding the misconfiguration. This patch adds a warning for this. Signed-off-by: Josef Weidendorfer <> Signed-off-by: Junio C Hamano <>
2006-12-04git-fetch: ignore dereferenced tags in expand_refs_wildcardMichael Loeffler
There was a little bug in the brace expansion which should remove the ^{} from the tagname. It used ${name#'^{}'} instead of $(name%'^{}'}, the difference is that '#' will remove the given pattern only from the beginning of a string and '%' only from the end of a string. Signed-off-by: Michael Loeffler <> Signed-off-by: Junio C Hamano <>
2006-11-25git-fetch: allow forcing glob pattern in refspecJunio C Hamano
Building on top of the earlier refspec glob pattern enhancement, this allows a glob pattern to say the updates should be forced by prefixing it with '+' as usual, like this: Pull: +refs/heads/*:refs/remotes/origin/* Signed-off-by: Junio C Hamano <>
2006-11-24git-fetch: allow glob pattern in refspecJunio C Hamano
This adds Andy's refspec glob. You can have a single line: Pull: refs/heads/*:refs/remotes/origin/* in your ".git/remotes/origin" and say "git fetch" to retrieve all refs under heads/ at the remote side to remotes/origin/ in the local repository. Signed-off-by: Junio C Hamano <>
2006-09-24fetch: get the remote branches to merge from the branch propertiesSanti Béjar
If in branch "foo" and this in config: [branch "foo"] merge=bar "git fetch": fetch from the default repository and program the "bar" branch to be merged with pull. Signed-off-by: Santi Béjar <> Signed-off-by: Junio C Hamano <>
2006-09-24Fetch: default remote repository from branch propertiesSanti Béjar
If in branch "foo" and this in config: [branch "foo"] remote=bar "git fetch" = "git fetch bar" "git pull" = "git pull bar" Signed-off-by: Santi Béjar <> Signed-off-by: Junio C Hamano <>
2006-05-04fetch, pull: ask config for remote informationJohannes Schindelin
Now you can say [remote.junio] url = git:// fetch = next:next in your .git/config. [jc: fixed up the log message that still said "pull" ] Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2006-04-14Fix-up previous expr changes.Junio C Hamano
The regexp on the right hand side of expr : operator somehow was broken. expr 'z+pu:refs/tags/ko-pu' : 'z\+\(.*\)' does not strip '+'; write 'z+\(.*\)' instead. We probably should switch to shell based substring post 1.3.0; that's not bashism but just POSIX anyway. Signed-off-by: Junio C Hamano <>
2006-04-13Shell utilities: Guard against expr' magic tokens.Mark Wooding
Some words, e.g., `match', are special to expr(1), and cause strange parsing effects. Track down all uses of expr and mangle the arguments so that this isn't a problem. Signed-off-by: Mark Wooding <> Signed-off-by: Junio C Hamano <>
2006-03-11fetch,parse-remote,fmt-merge-msg: refs/remotes/* supportEric Wong
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 <> Signed-off-by: Junio C Hamano <>
2005-11-25parse-remote and ls-remote clean-up.Junio C Hamano
There is no reason to use git-sh-setup from git-ls-remote. git-parse-remote can help the caller to use .git/remotes shortcut if it is run inside a git repository, but can still be useful outside a git repositoryas long as the caller does not use any shortcut. Use "git-rev-parse --git-dir" to figure out where the GIT_DIR is, instead of using git-sh-setup. This also makes "git-ls-remote origin" to work from inside a subdirectory of a git managed repository as a side effect. Signed-off-by: Junio C Hamano <>
2005-10-15Refuse to create funny refs in clone-pack, git-fetch and receive-pack.Junio C Hamano
Using git-check-ref-format, make sure we do not create refs with funny names when cloning from elsewhere (clone-pack), fast forwarding local heads (git-fetch), or somebody pushes into us (receive-pack). Signed-off-by: Junio C Hamano <>
2005-10-06Do not require ls-remote to be run inside a git repository.Alex Riesen
The scripts work perfectly without a repository. Signed-off-by: Alex Riesen <> 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-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-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 <>