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

37 Коммитов

Автор SHA1 Сообщение Дата
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
Junio C Hamano e8cc80d039 parse-remote and ls-remote clean-up.
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-11-25 13:49:17 -08:00
Junio C Hamano d8a1deecc6 Refuse to create funny refs in clone-pack, git-fetch and receive-pack.
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-15 11:23:39 -07:00
Alex Riesen 12aac5de3d Do not require ls-remote to be run inside a git repository.
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-10-06 14:10:39 -07:00
Junio C Hamano 05dd8e2ee2 Fix default pull not to do an unintended Octopus.
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-28 16:22:00 -07:00
Junio C Hamano 4447badcd2 Teach rsync transport about alternates.
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-17 11:56:41 -07:00
Junio C Hamano 215a7ad1ef Big tool rename.
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>
2005-09-07 17:45:20 -07:00