Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 26 4月, 2012 1 次提交
  3. 11 4月, 2012 13 次提交
  5. 13 2月, 2012 1 次提交
  7. 18 1月, 2012 2 次提交
    • M
      add_packed_ref(): new function in the refs API. · 30249ee6
      由 Michael Haggerty 提交于 
      Add a new function add_packed_ref() that adds a reference directly to
the in-memory packed reference cache.  This will be useful for
creating local references while cloning.
Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      30249ee6
    • M
      ref_array: keep track of whether references are sorted · e6ed3ca6
      由 Michael Haggerty 提交于 
      Keep track of how many entries at the beginning of a ref_array are already
sorted.  In sort_ref_array(), return early if the the array is already
sorted (i.e., if no new references has been appended to the end of the
list since the last call to sort_ref_array()).

Sort ref_arrays only when needed, namely in search_ref_array() and in
do_for_each_ref().  However, never call sort_ref_array() on the
extra_refs, because extra_refs can contain multiple entries with the same
name and because sort_ref_array() not only sorts, but de-dups its
contents.

This change is currently not useful, because entries are not added to
ref_arrays after they are created.  But in a moment they will be...

Implementation note: we could store a binary "sorted" value instead of
an integer, but storing the number of sorted entries leaves the way
open for a couple of possible future optimizations:

* In sort_ref_array(), sort *only* the unsorted entries, then merge
  them with the sorted entries.  This should be faster if most of the
  entries are already sorted.

* Teach search_ref_array() to do a binary search of any sorted
  entries, and if unsuccessful do a linear search of any unsorted
  entries.  This would avoid the need to sort the list every time that
  search_ref_array() is called, and (given some intelligence about how
  often to sort) could significantly improve the speed in certain
  hypothetical usage patterns.
Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e6ed3ca6
  9. 14 12月, 2011 2 次提交
  11. 13 12月, 2011 15 次提交
  13. 17 11月, 2011 1 次提交
    • J
      refs: loosen over-strict "format" check · 09116a1c
      由 Junio C Hamano 提交于 
      The add_extra_ref() interface is used to add an extra-ref that is _not_
our ref for the purpose of helping auto-following of tags and reducing
object transfer from remote repository, and they are typically formatted
as a tagname followed by ^{} to make sure no valid refs match that
pattern. In other words, these entries are deliberately formatted not to
pass check-refname-format test.

A recent series however added a test unconditionally to the add_ref()
function that is called from add_extra_ref(). The check may be sensible
for other two callsites of the add_ref() interface, but definitely is
a wrong thing to do in add_extra_ref(). Disable it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
Acked-by: NMichael Haggerty <mhagger@alum.mit.edu>
      09116a1c
  15. 14 11月, 2011 1 次提交
  17. 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
  19. 20 10月, 2011 2 次提交
    • J
      resolve_ref(): report breakage to the caller without warning · 55956350
      由 Junio C Hamano 提交于 
      629cd3ac (resolve_ref(): emit warnings for improperly-formatted references,
2011-09-15) made resolve_ref() warn against files that are found in the
directories the ref dwimmery looks at. The intent may be good, but these
messages come from a wrong level of the API hierarchy.

Instead record the breakage in "flags" whose purpose is to explain the
result of the function to the caller, who is in a much better position to
make intelligent decision based on the information.

This updates sha1_name.c::dwim_ref() to warn against such a broken
candidate only when it does not appear directly below $GIT_DIR to restore
the traditional behaviour, as we know many files directly underneath
$GIT_DIR/ are not refs.

Warning against "git show config --" with "$GIT_DIR/config does not look
like a well-formed ref" does not make sense, and we may later tweak the
dwimmery not to even consider them as candidates, but that is a longer
term topic.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      55956350
    • J
      resolve_ref(): expose REF_ISBROKEN flag · 98ac34b2
      由 Junio C Hamano 提交于 
      Instead of keeping this as an internal API, let the callers find
out the reason why resolve_ref() returned NULL is not because there
was no such file in $GIT_DIR but because a file was corrupt.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      98ac34b2