Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 08 11月, 2011 2 次提交
    • J
      refs DWIMmery: use the same rule for both "git fetch" and others · dd621df9
      由 Junio C Hamano 提交于 
      "git log frotz" can DWIM to "refs/remotes/frotz/HEAD", but in the remote
access context, "git fetch frotz" to fetch what the other side happened to
have fetched from what it calls 'frotz' (which may not have any relation
to what we consider is 'frotz') the last time would not make much sense,
so the fetch rules table did not include "refs/remotes/%.*s/HEAD".

When the user really wants to, "git fetch $there remotes/frotz/HEAD" would
let her do so anyway, so this is not about safety or security; it merely
is about confusion avoidance and discouraging meaningless usage.

Specifically, it is _not_ about ambiguity avoidance. A name that would
become ambiguous if we use the same rules table for both fetch and local
rev-parse would be ambiguous locally at the remote side.

So for the same reason as we added rule to allow "git fetch $there v1.0"
instead of "git fetch $there tags/v1.0" in the previous commit, here is a
bit longer rope for the users, which incidentally simplifies our code.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      dd621df9
    • J
      fetch: allow "git fetch $there v1.0" to fetch a tag · 47d84b6a
      由 Junio C Hamano 提交于 
      You can already do so with "git fetch $there tags/v1.0" but if it is not
ambiguous there is no reason to force users to type more.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      47d84b6a
  3. 18 10月, 2011 1 次提交
  5. 11 10月, 2011 3 次提交
  7. 06 10月, 2011 16 次提交
  9. 01 10月, 2011 2 次提交
    • J
      refs: Use binary search to lookup refs faster · e9c4c111
      由 Julian Phillips 提交于 
      Currently we linearly search through lists of refs when we need to
find a specific ref.  This can be very slow if we need to lookup a
large number of refs.  By changing to a binary search we can make this
faster.

In order to be able to use a binary search we need to change from
using linked lists to arrays, which we can manage using ALLOC_GROW.

We can now also use the standard library qsort function to sort the
refs arrays.
Signed-off-by: NJulian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e9c4c111
    • P
      receive-pack: don't pass non-existent refs to post-{receive,update} hooks · 160b81ed
      由 Pang Yan Han 提交于 
      When a push specifies deletion of non-existent refs, the post post-receive and
post-update hooks receive them as input/arguments.

For instance, for the following push, where refs/heads/nonexistent is a ref
which does not exist on the remote side:

	git push origin :refs/heads/nonexistent

the post-receive hook receives from standard input:

	<null-sha1> SP <null-sha1> SP refs/heads/nonexistent

and the post-update hook receives as arguments:

	refs/heads/nonexistent

which does not make sense since it is a no-op.

Teach receive-pack not to pass non-existent refs to the post-receive and
post-update hooks. If the push only attempts to delete non-existent refs,
these hooks are not even called.

The update and pre-receive hooks are still notified about attempted
deletion of non-existent refs to give them a chance to inspect the
situation and act on it.

[jc: mild fix-ups to avoid introducing an extra list; also added fixes to
some tests]
Signed-off-by: NPang Yan Han <pangyanhan@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      160b81ed
  11. 27 9月, 2011 1 次提交
    • J
      Don't sort ref_list too early · b4f223c6
      由 Julian Phillips 提交于 
      get_ref_dir is called recursively for subdirectories, which means that
we were calling sort_ref_list for each directory of refs instead of
once for all the refs.  This is a massive wast of processing, so now
just call sort_ref_list on the result of the top-level get_ref_dir, so
that the sort is only done once.

In the common case of only a few different directories of refs the
difference isn't very noticable, but it becomes very noticeable when
you have a large number of direcotries containing refs (e.g. as
created by Gerrit).

Reported by Martin Fick.
Signed-off-by: NJulian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b4f223c6
  13. 12 9月, 2011 1 次提交
  15. 28 8月, 2011 1 次提交
  17. 23 8月, 2011 1 次提交
  19. 15 8月, 2011 6 次提交
  21. 07 7月, 2011 2 次提交
    • J
      ref namespaces: infrastructure · a1bea2c1
      由 Josh Triplett 提交于 
      Add support for dividing the refs of a single repository into multiple
namespaces, each of which can have its own branches, tags, and HEAD.
Git can expose each namespace as an independent repository to pull from
and push to, while sharing the object store, and exposing all the refs
to operations such as git-gc.

Storing multiple repositories as namespaces of a single repository
avoids storing duplicate copies of the same objects, such as when
storing multiple branches of the same source.  The alternates mechanism
provides similar support for avoiding duplicates, but alternates do not
prevent duplication between new objects added to the repositories
without ongoing maintenance, while namespaces do.

To specify a namespace, set the GIT_NAMESPACE environment variable to
the namespace.  For each ref namespace, git stores the corresponding
refs in a directory under refs/namespaces/.  For example,
GIT_NAMESPACE=foo will store refs under refs/namespaces/foo/.  You can
also specify namespaces via the --namespace option to git.

Note that namespaces which include a / will expand to a hierarchy of
namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under
refs/namespaces/foo/refs/namespaces/bar/.  This makes paths in
GIT_NAMESPACE behave hierarchically, so that cloning with
GIT_NAMESPACE=foo/bar produces the same result as cloning with
GIT_NAMESPACE=foo and cloning from that repo with GIT_NAMESPACE=bar.  It
also avoids ambiguity with strange namespace paths such as
foo/refs/heads/, which could otherwise generate directory/file conflicts
within the refs directory.

Add the infrastructure for ref namespaces: handle the GIT_NAMESPACE
environment variable and --namespace option, and support iterating over
refs in a namespace.
Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NJamey Sharp <jamey@minilop.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a1bea2c1
    • J
      Fix prefix handling in ref iteration functions · b3cfc406
      由 Josh Triplett 提交于 
      The do_for_each_ref iteration function accepts a prefix and a trim, and
checks for the prefix on each ref before passing in that ref; it also
supports trimming off part of the ref before passing it.  However,
do_for_each_ref used trim as the length of the prefix to check, ignoring
the actual length of the prefix.  Switch to using prefixcmp, checking
the entire length of the prefix string, to properly support a trim value
different than the length of the prefix.

Several callers passed a prefix of "refs/" to filter out everything
outside of refs/, but a trim of 0 to avoid trimming off the "refs/"; the
trim of 0 meant that the filter of "refs/" no longer applied.  Change
these callers to pass an empty prefix instead, to avoid changing the
existing behavior.  Various callers count on this lack of filtering,
such as receive-pack which uses add_extra_ref to add alternates as refs
named ".have"; adding filtering would break that, causing
t5501-fetch-push-alternates.sh to fail.  That lack of filtering doesn't
currently have any other effect, since the loose ref functions can never
supply refs outside of "refs/", and packed-refs will not normally
include such refs unless manually edited.
Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NJamey Sharp <jamey@minilop.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b3cfc406
  23. 17 6月, 2011 1 次提交
  25. 06 6月, 2011 1 次提交
    • J
      checkout -b <name>: correctly detect existing branch · c17b2294
      由 Junio C Hamano 提交于 
      When create a new branch, we fed "refs/heads/<proposed name>" as a string
to get_sha1() and expected it to fail when a branch already exists.

The right way to check if a ref exists is to check with resolve_ref().

A naïve solution that might appear attractive but does not work is to
forbid slashes in get_describe_name() but that will not work. A describe
name is is in the form of "ANYTHING-g<short sha1>", and that ANYTHING part
comes from a original tag name used in the repository the user ran the
describe command. A sick user could have a confusing hierarchical tag
whose name is "refs/heads/foobar" (stored as refs/tags/refs/heads/foobar")
to generate a describe name "refs/heads/foobar-6-g02ac9837", and we should
be able to use that name to refer to the object whose name is 02ac9837.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c17b2294
  27. 08 7月, 2010 2 次提交