summaryrefslogtreecommitdiff
path: root/git-parse-remote.sh
Commit message (Collapse)AuthorAgeFilesLines
* remove #!interpreter line from shell librariesjn/scripts-updatesJonathan Nieder2013-11-261-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a shell snippet meant to be sourced by other shell scripts, an opening #! line does more harm than good. The harm: - When the shell library is sourced, the interpreter and options from the #! line are not used. Specifying a particular shell can confuse the reader into thinking it is safe for the shell library to rely on idiosyncrasies of that shell. - Using #! instead of a plain comment drops a helpful visual clue that this is a shell library and not a self-contained script. - Tools such as lintian can use a #! line to tell when an installation script has failed by forgetting to set a script executable. This check does not work if shell libraries also start with a #! line. The good: - Text editors notice the #! line and use it for syntax highlighting if you try to edit the installed scripts (without ".sh" suffix) in place. The use of the #! for file type detection is not needed because Git's shell libraries are meant to be edited in source form (with ".sh" suffix). Replace the opening #! lines with comments. This involves tweaking the test harness's valgrind support to find shell libraries by looking for "# " in the first line instead of "#!" (see v1.7.6-rc3~7, 2011-06-17). Suggested by Russ Allbery through lintian. Thanks to Jeff King and Clemens Buchacher for further analysis. Tested by searching for non-executable scripts with #! line: find . -name .git -prune -o -type f -not -executable | while read file do read line <"$file" case $line in '#!'*) echo "$file" ;; esac done The only remaining scripts found are templates for shell scripts (unimplemented.sh, wrap-for-bin.sh) and sample input used in tests (t/t4034/perl/{pre,post}). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* push/pull: adjust missing upstream help text to changed interfaceMichael J Gruber2012-11-081-1/+1
| | | | | | | | | | | | | | | | | In case of a missing upstream, the git-parse-remote script suggests: If you wish to set tracking information for this branch you can do so with: git branch --set-upstream nsiv2 origin/<branch> But --set-upstream is deprectated. Change the suggestion to: git branch --set-upstream-to=origin/<branch> nsiv2 Reported-by: Jeroen van der Ham <vdham@uva.nl> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jeff King <peff@peff.net>
* Make git-{pull,rebase} message without tracking information friendliercn/pull-rebase-messageCarlos Martín Nieto2012-03-041-23/+20
| | | | | | | | | | | | | | | | | | The current message is too long and at too low a level for anybody to understand it if they don't know about the configuration format already. The text about setting up a remote is superfluous and doesn't help understand or recover from the error that has happened. Show the usage more prominently and explain how to set up the tracking information. If there is only one remote, that name is used instead of the generic <remote>. Also simplify the message we print on detached HEAD to remove unnecessary information which is better left for the documentation. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'mz/rebase'Junio C Hamano2011-04-281-0/+38
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * mz/rebase: (34 commits) rebase: define options in OPTIONS_SPEC Makefile: do not install sourced rebase scripts rebase: use @{upstream} if no upstream specified rebase -i: remove unnecessary state rebase-root rebase -i: don't read unused variable preserve_merges git-rebase--am: remove unnecessary --3way option rebase -m: don't print exit code 2 when merge fails rebase -m: remember allow_rerere_autoupdate option rebase: remember strategy and strategy options rebase: remember verbose option rebase: extract code for writing basic state rebase: factor out sub command handling rebase: make -v a tiny bit more verbose rebase -i: align variable names rebase: show consistent conflict resolution hint rebase: extract am code to new source file rebase: extract merge code to new source file rebase: remove $branch as synonym for $orig_head rebase -i: support --stat rebase: factor out call to pre-rebase hook ...
| * rebase: use @{upstream} if no upstream specifiedMartin von Zweigbergk2011-02-101-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'git rebase' without arguments is currently not supported. Make it default to 'git rebase @{upstream}'. That is also what 'git pull [--rebase]' defaults to, so it only makes sense that 'git rebase' defaults to the same thing. Defaulting to @{upstream} will make it possible to run e.g. 'git rebase -i' without arguments, which is probably a quite common use case. It also improves the scenario where you have multiple branches that rebase against a remote-tracking branch, where you currently have to choose between the extra network delay of 'git pull' or the slightly awkward keys to enter 'git rebase @{u}'. The error reporting when no upstream is configured for the current branch or when no branch is checked out is reused from git-pull.sh. A function is extracted into git-parse-remote.sh for this purpose. Helped-by: Yann Dirson <ydirson@altern.org> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'maint'Junio C Hamano2011-03-301-1/+1
|\ \ | | | | | | | | | | | | * maint: parse-remote: typofix
| * | parse-remote: typofixJunio C Hamano2011-03-301-1/+1
| | | | | | | | | | | | | | | | | | | | | An earlier patch had a trivial typo that two people did not notice. Pointed out by Michael Schubert. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'maint'Junio C Hamano2011-03-301-1/+2
|\ \ \ | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: contrib/thunderbird-patch-inline: do not require bash to run the script t8001: check the exit status of the command being tested strbuf.h: remove a tad stale docs-in-comment and reference api-doc instead Typos: t/README Documentation/config.txt: make truth value of numbers more explicit git-pack-objects.txt: fix grammatical errors parse-remote: replace unnecessary sed invocation
| * | parse-remote: replace unnecessary sed invocationStephen Boyd2011-03-301-1/+2
| |/ | | | | | | | | | | | | Just use parameter expansion instead. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-request-pull: open-code the only invocation of get_remote_urlUwe Kleine-König2011-03-021-4/+0
| | | | | | | | | | | | | | | | So sh:get_remote_url can go now and git-request-pull doesn't need to source git-parse-remote. anymore. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | get_remote_url(): use the same data source as ls-remote to get remote urlsUwe Kleine-König2011-03-021-47/+1
|/ | | | | | | | | | | | | The formerly implemented algorithm behaved differently to remote.c:remote_get() at least for remotes that contain a slash. While the former just assumes a/b is a path the latter checks the config for remote."a/b" first which is more reasonable. This removes the last user of git-parse-remote.sh:get_data_source(), so this function is removed. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'mz/pull-rebase-rebased'Junio C Hamano2010-12-121-2/+8
|\ | | | | | | | | * mz/pull-rebase-rebased: Use reflog in 'pull --rebase . foo'
| * Use reflog in 'pull --rebase . foo'Martin von Zweigbergk2010-11-291-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>
* | parse-remote: handle detached HEADSanti Béjar2010-12-061-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>
* Do not install shell libraries executableJonathan Nieder2010-01-311-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>
* parse-remote: remove unused functionsSanti Béjar2009-06-111-204/+0
| | | | | Signed-off-by: Santi Béjar <santi@agolina.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-remote: support default reflist in get_remote_merge_branchSanti Béjar2009-06-111-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>
* parse-remote: function to get the tracking branch to be mergeSanti Béjar2009-06-111-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>
* Convert to use quiet option when availableDan Loewenherz2009-04-221-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>
* Rewrite "git-frotz" to "git frotz"Junio C Hamano2007-07-021-12/+12
| | | | | | This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Allow fetching references from any namespaceAlex Riesen2007-05-121-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>
* git-fetch, git-branch: Support local --track via a special remote '.'Paolo Bonzini2007-03-161-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>
* Use stdin reflist passing in parse-remoteJulian Phillips2007-02-131-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>
* git-fetch: rewrite expand_ref_wildcard in CJunio C Hamano2007-02-131-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>
* Revert "Allow branch.*.merge to talk about remote tracking branches."Junio C Hamano2007-02-041-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>
* git-fetch: Allow fetching the remote HEADSanti Béjar2007-01-301-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>
* [PATCH] Rename git-repo-config to git-config.Tom Prince2007-01-281-7/+7
| | | | | Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* parse-remote: do not barf on a remote shorthand without any refs to fetch.Junio C Hamano2007-01-251-1/+8
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* make --upload-pack option to git-fetch configurableUwe Kleine-König2007-01-241-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>
* Fix git-fetch while on detached HEAD not to give needlessly alarming errorsJunio C Hamano2007-01-151-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>
* Do not merge random set of refs out of wildcarded refsJunio C Hamano2006-12-311-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>
* Allow branch.*.merge to talk about remote tracking branches.Junio C Hamano2006-12-241-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>
* Do not support "partial URL shorthand" anymore.Junio C Hamano2006-12-221-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>
* default pull: forget about "newbie protection" for now.Junio C Hamano2006-12-221-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>
* parse-remote: mark all refs not for merge only when fetching more than oneJunio C Hamano2006-12-211-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>
* Revert "git-pull: refuse default merge without branch.*.merge"Junio C Hamano2006-12-211-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.
* Move "no merge candidate" warning into git-pullJosef Weidendorfer2006-12-191-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>
* Merge branch 'jc/test-clone' into jc/cloneJunio C Hamano2006-12-191-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 ...
| * parse-remote::expand_refs_wildcard()Junio C Hamano2006-12-181-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>
* | git-pull: refuse default merge without branch.*.mergeJunio C Hamano2006-12-161-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>
* Add branch.*.merge warning and documentation updateJosef Weidendorfer2006-12-081-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>
* git-fetch: ignore dereferenced tags in expand_refs_wildcardMichael Loeffler2006-12-041-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>
* git-fetch: allow forcing glob pattern in refspecJunio C Hamano2006-11-251-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>
* git-fetch: allow glob pattern in refspecJunio C Hamano2006-11-231-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>
* fetch: get the remote branches to merge from the branch propertiesSanti Béjar2006-09-241-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>
* Fetch: default remote repository from branch propertiesSanti Béjar2006-09-241-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>
* fetch, pull: ask config for remote informationJohannes Schindelin2006-05-041-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>
* Fix-up previous expr changes.Junio C Hamano2006-04-131-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>
* Shell utilities: Guard against expr' magic tokens.Mark Wooding2006-04-131-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>
* fetch,parse-remote,fmt-merge-msg: refs/remotes/* supportEric Wong2006-03-101-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>
View Lorry Controller Status