summaryrefslogtreecommitdiff
path: root/git-parse-remote.sh
AgeCommit message (Collapse)AuthorFilesLines
2010-12-12Merge branch 'mz/pull-rebase-rebased'Libravatar Junio C Hamano1-2/+8
* mz/pull-rebase-rebased: Use reflog in 'pull --rebase . foo'
2010-12-06parse-remote: handle detached HEADLibravatar Santi Béjar1-1/+1
get_remote_merge_branch with zero or one arguments returns the upstream branch. But a detached HEAD does no have an upstream branch, as it is not tracking anything. Handle this case testing the exit code of "git symbolic-ref -q HEAD". Reported-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Santi Béjar <santi@agolina.net> Tested-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-29Use reflog in 'pull --rebase . foo'Libravatar Martin von Zweigbergk1-2/+8
Since c85c792 (pull --rebase: be cleverer with rebased upstream branches, 2008-01-26), "git pull --rebase" has used the reflog to try to rebase from the old upstream onto the new upstream. Make this work if the local repository is explicitly passed on the command line as in 'git pull --rebase . foo'. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Acked-by: Santi Béjar <santi@agolina.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-31Do not install shell libraries executableLibravatar Jonathan Nieder1-0/+0
Some scripts are expected to be sourced instead of executed on their own. Avoid some confusion by not marking them executable. The executable bit was confusing the valgrind support of our test scripts, which assumed that any executable without a #!-line should be intercepted and run through valgrind. So during valgrind-enabled tests, any script sourcing these files actually sourced the valgrind interception script instead. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-11parse-remote: remove unused functionsLibravatar Santi Béjar1-204/+0
Signed-off-by: Santi Béjar <santi@agolina.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-11parse-remote: support default reflist in get_remote_merge_branchLibravatar Santi Béjar1-1/+7
Expand get_remote_merge_branch to compute the tracking branch to merge when called without arguments (or only the remote name). This allows "git pull --rebase" without arguments (default upstream branch) to work with a rebased upstream. With explicit arguments it already worked. Also add a test to check for this case. Signed-off-by: Santi Béjar <santi@agolina.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-11parse-remote: function to get the tracking branch to be mergeLibravatar Santi Béjar1-0/+29
The only user of get_remote_refs_for_fetch was "git pull --rebase" and it only wanted the tracking branch to be merge. So, add a simple function (get_remote_merge_branch) with this new meaning. No behavior changes. The new function behaves like the old code in "git pull --rebase". In particular, it only works with the default refspec mapping and with remote branches, not tags. Signed-off-by: Santi Béjar <santi@agolina.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-22Convert to use quiet option when availableLibravatar Dan Loewenherz1-1/+1
A minor fix that eliminates usage of "2>/dev/null" when --quiet or -q has already been implemented. Signed-off-by: Dan Loewenherz <daniel.loewenherz@yale.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-12/+12
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-12Allow fetching references from any namespaceLibravatar Alex Riesen1-2/+2
not only from the three defined: heads, tags and remotes. Noticed when I tried to fetch the references created by git-p4-import.bat: they are placed into separate namespace (refs/p4import/, to avoid showing them in git-branch output). As canon_refs_list_for_fetch always prepended refs/heads/ it was impossible, and annoying: it worked before. Normally, the p4import references are useless anywhere but in the directory managed by perforce, but in this special case the cloned directory was supposed to be a backup, including the p4import branch: it keeps information about where the imported perforce state came from. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-16git-fetch, git-branch: Support local --track via a special remote '.'Libravatar Paolo Bonzini1-2/+12
This patch adds support for a dummy remote '.' to avoid having to declare a fake remote like [remote "local"] url = . fetch = refs/heads/*:refs/heads/* Such a builtin remote simplifies the operation of "git-fetch", which will populate FETCH_HEAD but will not pretend that two repositories are in use, will not create a thin pack, and will not perform any useless remapping of names. The speed improvement is around 20%, and it should improve more if "git-fetch" is converted to a builtin. To this end, git-parse-remote is grown with a new kind of remote, 'builtin'. In git-fetch.sh, we treat the builtin remote specially in that it needs no pack/store operations. In fact, doing git-fetch on a builtin remote will simply populate FETCH_HEAD appropriately. The patch also improves of the --track/--no-track support, extending it so that branch.<name>.remote items referring '.' can be created. Finally, it fixes a typo in git-checkout.sh. Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13Use stdin reflist passing in parse-remoteLibravatar Julian Phillips1-1/+2
Use the new stdin reflist passing mechanism for the call to fetch--tool expand-refs-wildcard, allowing passing of more than ~128K of reflist data. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13git-fetch: rewrite expand_ref_wildcard in CLibravatar Junio C Hamano1-45/+1
This does not seem to make measurable improvement when dealing with 1000 unpacked refs, but we would need something like it if we were to do a full rewrite in C somedaoy. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04Revert "Allow branch.*.merge to talk about remote tracking branches."Libravatar Junio C Hamano1-6/+2
This reverts commit 80c797764a6b6a373f0f1f47d7f56b0d950418a9. Back when I committed this, it seemed to be a good idea. People who always use remote tracking branches can optionally use the local name they happen to use to specify what to merge, which meant that I did not have to teach them why we use the name at the remote side every time they are confused. But allowing it seems to break other people's scripts. The real solution is not to allow more ways to express the same thing, but to educate people to use the right syntax. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-30git-fetch: Allow fetching the remote HEADLibravatar Santi Béjar1-1/+1
... 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 <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28[PATCH] Rename git-repo-config to git-config.Libravatar Tom Prince1-7/+7
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-25parse-remote: do not barf on a remote shorthand without any refs to fetch.Libravatar Junio C Hamano1-1/+8
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-24make --upload-pack option to git-fetch configurableLibravatar Uwe Kleine-König1-0/+13
This introduces the config item remote.<name>.uploadpack to override the default value (which is "git-upload-pack"). Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15Fix git-fetch while on detached HEAD not to give needlessly alarming errorsLibravatar Junio C Hamano1-2/+2
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 <junkio@cox.net>
2006-12-31Do not merge random set of refs out of wildcarded refsLibravatar Junio C Hamano1-1/+22
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 <junkio@cox.net>
2006-12-24Allow branch.*.merge to talk about remote tracking branches.Libravatar Junio C Hamano1-2/+6
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 <junkio@cox.net>
2006-12-22Do not support "partial URL shorthand" anymore.Libravatar Junio C Hamano1-27/+7
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 <junkio@cox.net>
2006-12-22default pull: forget about "newbie protection" for now.Libravatar Junio C Hamano1-7/+0
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 <junkio@cox.net>
2006-12-21parse-remote: mark all refs not for merge only when fetching more than oneLibravatar Junio C Hamano1-2/+9
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 <junkio@cox.net>
2006-12-21Revert "git-pull: refuse default merge without branch.*.merge"Libravatar Junio C Hamano1-2/+1
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-pullLibravatar Josef Weidendorfer1-10/+0
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 <weidendo@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-19Merge branch 'jc/test-clone' into jc/cloneLibravatar Junio C Hamano1-5/+3
* 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()Libravatar Junio C Hamano1-5/+3
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 <junkio@cox.net>
2006-12-16git-pull: refuse default merge without branch.*.mergeLibravatar Junio C Hamano1-1/+2
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 <junkio@cox.net>
2006-12-08Add branch.*.merge warning and documentation updateLibravatar Josef Weidendorfer1-0/+11
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 <Josef.Weidendorfer@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-04git-fetch: ignore dereferenced tags in expand_refs_wildcardLibravatar Michael Loeffler1-1/+1
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 <zvpunry@zvpunry.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-25git-fetch: allow forcing glob pattern in refspecLibravatar Junio C Hamano1-4/+8
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 <junkio@cox.net>
2006-11-23git-fetch: allow glob pattern in refspecLibravatar Junio C Hamano1-0/+35
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 <junkio@cox.net>
2006-09-24fetch: get the remote branches to merge from the branch propertiesLibravatar Santi Béjar1-8/+29
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 <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24Fetch: default remote repository from branch propertiesLibravatar Santi Béjar1-0/+6
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 <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-04fetch, pull: ask config for remote informationLibravatar Johannes Schindelin1-4/+24
Now you can say [remote.junio] url = git://git.kernel.org/pub/scm/git/git.git fetch = next:next in your .git/config. [jc: fixed up the log message that still said "pull" ] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-13Fix-up previous expr changes.Libravatar Junio C Hamano1-1/+1
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 <junkio@cox.net>
2006-04-13Shell utilities: Guard against expr' magic tokens.Libravatar Mark Wooding1-10/+10
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 <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-10fetch,parse-remote,fmt-merge-msg: refs/remotes/* supportLibravatar Eric Wong1-4/+4
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>
2005-11-25parse-remote and ls-remote clean-up.Libravatar Junio C Hamano1-1/+3
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 <junkio@cox.net>
2005-10-15Refuse to create funny refs in clone-pack, git-fetch and receive-pack.Libravatar Junio C Hamano1-0/+6
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 <junkio@cox.net>
2005-10-06Do not require ls-remote to be run inside a git repository.Libravatar Alex Riesen1-1/+1
The scripts work perfectly without a repository. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-28Fix default pull not to do an unintended Octopus.Libravatar Junio C Hamano1-2/+9
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>
2005-09-17Teach rsync transport about alternates.Libravatar Junio C Hamano1-0/+21
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>
2005-09-07Big tool rename.Libravatar Junio C Hamano1-0/+155
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>