Граф коммитов

56 Коммитов

Автор SHA1 Сообщение Дата
Jonathan Nieder 11d62145b9 remove #!interpreter line from shell libraries
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>
2013-11-26 14:23:56 -08:00
Michael J Gruber a3a4391abf push/pull: adjust missing upstream help text to changed interface
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>
2012-11-08 11:32:38 -05:00
Carlos Martín Nieto 3c02396adc Make git-{pull,rebase} message without tracking information friendlier
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>
2012-03-04 23:00:57 -08:00
Junio C Hamano 78c6e0f3fa Merge branch 'mz/rebase'
* 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
  ...
2011-04-28 14:11:39 -07:00
Junio C Hamano bcef9b6327 Merge branch 'maint'
* maint:
  parse-remote: typofix
2011-03-30 19:33:53 -07:00
Junio C Hamano 2352570bf4 parse-remote: typofix
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>
2011-03-30 19:33:41 -07:00
Junio C Hamano 17a0299807 Merge branch 'maint'
* 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
2011-03-30 14:10:41 -07:00
Stephen Boyd 9ecd3ada6d parse-remote: replace unnecessary sed invocation
Just use parameter expansion instead.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 11:42:08 -07:00
Uwe Kleine-König 1a92777504 git-request-pull: open-code the only invocation of get_remote_url
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>
2011-03-02 12:26:58 -08:00
Uwe Kleine-König 45781adb9a get_remote_url(): use the same data source as ls-remote to get remote urls
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>
2011-03-02 12:26:53 -08:00
Martin von Zweigbergk 15a147e618 rebase: use @{upstream} if no upstream specified
'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>
2011-02-10 14:45:25 -08:00
Junio C Hamano 73fd7f3761 Merge branch 'mz/pull-rebase-rebased'
* mz/pull-rebase-rebased:
  Use reflog in 'pull --rebase . foo'
2010-12-12 21:49:51 -08:00
Santi Béjar f864f2615b parse-remote: handle detached HEAD
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-12-06 16:57:48 -08:00
Martin von Zweigbergk fe249b4219 Use reflog in 'pull --rebase . foo'
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-11-29 15:06:40 -08:00
Jonathan Nieder 46bac90458 Do not install shell libraries executable
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>
2010-01-31 11:53:10 -08:00
Santi Béjar 62d955fd43 parse-remote: remove unused functions
Signed-off-by: Santi Béjar <santi@agolina.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-11 19:50:45 -07:00
Santi Béjar e9460a66e0 parse-remote: support default reflist in get_remote_merge_branch
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-11 19:50:34 -07:00
Santi Béjar 97af7ff055 parse-remote: function to get the tracking branch to be merge
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-06-11 19:49:59 -07:00
Dan Loewenherz 7bd93c1c62 Convert to use quiet option when available
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>
2009-04-22 19:05:37 -07:00
Junio C Hamano 5be60078c9 Rewrite "git-frotz" to "git frotz"
This uses the remove-dashes target to replace "git-frotz" to "git frotz".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02 22:52:14 -07:00
Alex Riesen 96f12b54f7 Allow fetching references from any namespace
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-05-12 09:36:06 -07:00
Paolo Bonzini 9debc3241b git-fetch, git-branch: Support local --track via a special remote '.'
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-03-16 02:10:12 -07:00
Julian Phillips 95339912b9 Use stdin reflist passing in parse-remote
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-13 21:43:53 -08:00
Junio C Hamano 86551586da git-fetch: rewrite expand_ref_wildcard in C
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-13 21:43:53 -08:00
Junio C Hamano 756373da25 Revert "Allow branch.*.merge to talk about remote tracking branches."
This reverts commit 80c797764a.

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-02-04 16:58:30 -08:00
Santi Béjar 153e98d263 git-fetch: Allow fetching the remote HEAD
... 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-30 02:30:25 -08:00
Tom Prince e0d10e1c63 [PATCH] Rename git-repo-config to git-config.
Signed-off-by: Tom Prince <tom.prince@ualberta.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28 16:16:53 -08:00
Junio C Hamano ae9c6ffe30 parse-remote: do not barf on a remote shorthand without any refs to fetch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-25 22:03:16 -08:00
Uwe Kleine-König 5dee29ac0f make --upload-pack option to git-fetch configurable
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-24 23:06:30 -08:00
Junio C Hamano a0f4280f9e Fix git-fetch while on detached HEAD not to give needlessly alarming errors
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>
2007-01-15 15:35:07 -08:00
Junio C Hamano fbc9012307 Do not merge random set of refs out of wildcarded refs
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-31 18:53:26 -08:00
Junio C Hamano 80c797764a Allow branch.*.merge to talk about remote tracking branches.
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-24 02:18:57 -08:00
Junio C Hamano ea560e6d64 Do not support "partial URL shorthand" anymore.
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-22 15:37:48 -08:00
Junio C Hamano fb8696d9d8 default pull: forget about "newbie protection" for now.
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-22 15:25:21 -08:00
Junio C Hamano d41cb273d3 parse-remote: mark all refs not for merge only when fetching more than one
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-21 22:56:25 -08:00
Junio C Hamano 9e11554917 Revert "git-pull: refuse default merge without branch.*.merge"
This reverts commit a71fb0a141.

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-21 22:12:42 -08:00
Josef Weidendorfer 4363dfbe3d Move "no merge candidate" warning into git-pull
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-19 01:53:02 -08:00
Junio C Hamano 5fed466815 Merge branch 'jc/test-clone' into jc/clone
* 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-19 01:38:18 -08:00
Junio C Hamano 0c7a97fafd parse-remote::expand_refs_wildcard()
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-18 12:13:46 -08:00
Junio C Hamano a71fb0a141 git-pull: refuse default merge without branch.*.merge
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-16 13:01:41 -08:00
Josef Weidendorfer 62b339a544 Add branch.*.merge warning and documentation update
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-08 18:13:31 -08:00
Michael Loeffler 4cd75359ad git-fetch: ignore dereferenced tags in expand_refs_wildcard
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-12-04 13:54:57 -08:00
Junio C Hamano d945d4be20 git-fetch: allow forcing glob pattern in refspec
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-25 01:10:10 -08:00
Junio C Hamano 5677882be7 git-fetch: allow glob pattern in refspec
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-11-23 16:54:54 -08:00
Santi Béjar 5372806a84 fetch: get the remote branches to merge from the branch properties
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-24 00:13:49 -07:00
Santi Béjar 648ad18f50 Fetch: default remote repository from branch properties
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-09-24 00:13:49 -07:00
Johannes Schindelin 73136b2e8a fetch, pull: ask config for remote information
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-05-04 00:07:06 -07:00
Junio C Hamano dfdcb558ec Fix-up previous expr changes.
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-13 19:05:38 -07:00
Mark Wooding f327dbced2 Shell utilities: Guard against expr' magic tokens.
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-04-13 16:45:48 -07:00
Eric Wong 687b8be8bb fetch,parse-remote,fmt-merge-msg: refs/remotes/* support
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>
2006-03-10 22:31:20 -08:00