Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 10 10月, 2009 2 次提交
    • J
      Describe DOCBOOK_XSL_172, ASCIIDOC_NO_ROFF options in Makefile · 162213d2
      由 Jonathan Nieder 提交于 
      There is excellent documentation for these options in
Documentation/Makefile, but some users may never find it.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      162213d2
    • J
      pull: improve advice for unconfigured error case · a8c9bef4
      由 Jeff King 提交于 
      There are several reasons a git-pull invocation might not
have anything marked for merge:

  1. We're not on a branch, so there is no branch
     configuration.

  2. We're on a branch, but there is no configuration for
     this branch.

  3. We fetched from the configured remote, but the
     configured branch to merge didn't get fetched (either
     it doesn't exist, or wasn't part of the fetch refspec).

  4. We fetched from the non-default remote, but didn't
     specify a branch to merge. We can't use the configured
     one because it applies to the default remote.

  5. We fetched from a specified remote, and a refspec was
     given, but it ended up not fetching anything (this is
     actually hard to do; if the refspec points to a remote
     branch and it doesn't exist, then fetch will fail and
     we never make it to this code path. But if you provide
     a wildcard refspec like

       refs/bogus/*:refs/remotes/origin/*

     then you can see this failure).

We have handled (1) and (2) for some time. Recently, commit
a6dbf881 added code to handle case (3).

This patch handles cases (4) and (5), which previously just
fell under other cases, producing a confusing message.

While we're at it, let's rewrap the text for case (3), which
looks terribly ugly as it is.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a8c9bef4
  3. 09 10月, 2009 10 次提交
    • J
      Merge git://git.bogomips.org/git-svn · 63d129d9
      由 Junio C Hamano 提交于 
      * git://git.bogomips.org/git-svn:
  git-svn: Avoid spurious errors when rewriteRoot is used.
      63d129d9
    • A
      git-svn: Avoid spurious errors when rewriteRoot is used. · c03c1f79
      由 Alexander Gavrilov 提交于 
      After doing a rebase, git-svn checks that the SVN URL
is what it expects. However, it does not account for
rewriteRoot, which is a legitimate way for the URL
to change. This produces a lot of spurious errors.

[ew: fixed line wrapping]
Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com>
Acked-by: NEric Wong <normalperson@yhbt.net>
      c03c1f79
    • J
      Merge branch 'ms/msvc' · 8ba5effa
      由 Junio C Hamano 提交于 
      * ms/msvc:
  Fix the exit code of MSVC build scripts on cygwin
  Fix MSVC build on cygwin
      8ba5effa
    • J
      Update draft release notes to 1.6.5 · dc3c7a72
      由 Junio C Hamano 提交于
      dc3c7a72
    • J
      Merge branch 'maint' · bf8fc21c
      由 Junio C Hamano 提交于 
      * maint:
  ls-files: die instead of fprintf/exit in -i error
      bf8fc21c
    • B
      Makefile: add a note about the NO_MMAP setting on IRIX and IRIX64 · 651aef34
      由 Brandon Casey 提交于 
      When git is compiled with the MIPSpro 7.4.4m compiler, and NO_PTHREADS is
set, and NO_MMAP is _not_ set, then git segfaults when trying to access the
first entry in a reflog.  If NO_PTHREADS is not set (which implies that the
pthread library is linked in), or NO_MMAP _is_ set, then the segfault is
not encountered.  The conservative choice has been made to set NO_MMAP in
the Makefile to avoid this flaw.  The GNU C compiler does not produce this
behavior.

The segfault happens in refs.c:read_ref_at().  The mmap succeeds, and the
loop is executed properly until rec is rewound into the first line (reflog
entry) of the file.  The segfault is caught by test 28 of
t1400-update-ref.sh which fails when 'git rev-parse --verify "master@{May 25
2005}"' is called.

So, add a comment in the Makefile to describe why NO_MMAP is set and as a
hint to those who may be interested in unsetting it.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      651aef34
    • B
      ls-files: die instead of fprintf/exit in -i error · ac78b009
      由 Ben Walton 提交于 
      When ls-files was called with -i but no exclude pattern, it was
calling fprintf(stderr, "...", NULL) and then exiting.  On Solaris,
passing NULL into fprintf was causing a segfault.  On glibc systems,
it was simply producing incorrect output (eg: "(null)": ...).  The
NULL pointer was a result of argv[0] not being preserved by the option
parser.  Instead of requesting that the option parser preserve
argv[0], use die() with a constant string.

A trigger for this bug was: `git ls-files -i`
Signed-off-by: NBen Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ac78b009
    • B
      Makefile: enable THREADED_DELTA_SEARCH on IRIX and IRIX64 · 817350d3
      由 Brandon Casey 提交于 
      Since commit dcda3614 removed the use of a variable length array from
builtin-pack-objects.c, it is now safe to compile with the threaded delta
search feature enabled.  Formerly, the MIPSpro 7.4.4m compiler warned that
variable length arrays should not be used with pthreads.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      817350d3
    • R
      Fix the exit code of MSVC build scripts on cygwin · b5d18b8e
      由 Ramsay Jones 提交于 
      During an MSVC build on cygwin, the make program did not notice
when the compiler or linker exited with an error. This was caused
by the scripts exiting with the value returned by system() directly.

On POSIX-like systems, such as cygwin, the return value of system()
has the exit code of the executed command encoded in the first byte
(ie the value is shifted up by 8 bits). This allows the bottom
7 bits to contain the signal number of a terminated process, while
the eighth bit indicates whether a core-dump was produced. (A value
of -1 indicates that the command failed to execute.)

The make program, however, expects the exit code to be encoded in the
bottom byte. Futhermore, it apparently masks off and ignores anything
in the upper bytes.

However, these scripts are (naturally) intended to be used on the
windows platform, where we can not assume POSIX-like semantics from
a perl implementation (eg ActiveState). So, in general, we can not
assume that shifting the return value right by eight will get us
the exit code.

In order to improve portability, we assume that a zero return from
system() indicates success, whereas anything else indicates failure.
Since we don't need to know the exact exit code from the compiler
or linker, we simply exit with 0 (success) or 1 (failure).
Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b5d18b8e
    • R
      Fix MSVC build on cygwin · f2d50d93
      由 Ramsay Jones 提交于 
      In the MSVC section of the Makefile, BASIC_CFLAGS is set to a
value which contains the string "-DWIN32-D_CONSOLE". This results
in a (single) malformed -Define being passed to the compiler.
At least on my cygwin installation, the msvc compiler seems to
ignore this parameter, without issuing an error or warning, and
results in the WIN32 and _CONSOLE macros being undefined. This
breaks the build.

In order to fix the build, we simply insert a space between the
two -Define parameters, "-DWIN32" and "-D_CONSOLE", as originally
intended.
Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f2d50d93
  5. 08 10月, 2009 6 次提交
  7. 06 10月, 2009 1 次提交
    • J
      git-pull: dead code removal · 4973aa22
      由 Junio C Hamano 提交于 
      Back when a74b1706 (git-pull: disallow implicit merging to detached HEAD,
2007-01-15) added this check, $? referred to the error status of reading
HEAD as a symbolic-ref; but cd67e4d4 (Teach 'git pull' about --rebase,
2007-11-28) moved the command away from where the check is, and nobody
noticed the breakage.  Ever since, $? has always been 0 (tr at the end of
the pipe to find merge_head never fails) and other case arms were never
reached.

These days, error_on_no_merge_candidates function is prepared to handle a
detached HEAD case, which was what the code this patch removes used to
handle.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4973aa22
  9. 05 10月, 2009 3 次提交
    • J
      Merge branch 'maint' · a7aebb9d
      由 Junio C Hamano 提交于 
      * maint:
  show-branch: fix segfault when showbranch.default exists
      a7aebb9d
    • J
      Merge branch 'jc/maint-1.6.4-show-branch-default' into maint · 04ce83e2
      由 Junio C Hamano 提交于 
      * jc/maint-1.6.4-show-branch-default:
  show-branch: fix segfault when showbranch.default exists
      04ce83e2
    • J
      show-branch: fix segfault when showbranch.default exists · 3af1cae4
      由 Junio C Hamano 提交于 
      When running "git show-branch" without any parameter in a repository that
has showbranch.default defined, we used to rely on the fact that our
handcrafted option parsing loop never looked at av[0].

The array of default strings had the first real command line argument in
default_arg[0], but the option parser wanted to look at the array starting
at av[1], so we assigned the address of -1th element to av to force the
loop start working from default_arg[0].

This no longer worked since 57343652 (show-branch: migrate to parse-options
API, 2009-05-21), as parse_options_start() saved the incoming &av[0] in
its ctx->out and later in parse_options_end() it did memmove to ctx->out
(with ctx->cpidx == 0), overwriting the memory before default_arg[] array.

I am not sure if this is a bug in parse_options(), or a bug in the caller,
and tonight I do not have enough concentration to figure out which.  In
any case, this patch works the issue around.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3af1cae4
  11. 03 10月, 2009 1 次提交
  13. 02 10月, 2009 3 次提交
    • M
      tests: make all test files executable · b4ae5e2a
      由 Mark Rada 提交于 
      For consistency with the rest of the test files.
Signed-off-by: NMark Rada <marada@uwaterloo.ca>
Signed-off-by: NJeff King <peff@peff.net>
      b4ae5e2a
    • A
      filter-branch: add --prune-empty to option summary · e3679ab4
      由 Adam Brewster 提交于 
      Signed-off-by: NAdam Brewster <adambrewster@gmail.com>
Signed-off-by: NJeff King <peff@peff.net>
      e3679ab4
    • R
      Fix some printf format warnings · 5322ef20
      由 Ramsay Jones 提交于 
      commit 51ea5519 ("make sure byte swapping is optimal for git"
2009-08-18) introduced a "sane definition for ntohl()/htonl()"
for use on some GNU C platforms. Unfortunately, for some of
these platforms, this results in the introduction of a problem
which is essentially the reverse of a problem that commit 6e1c2344
("Fix some warnings (on cygwin) to allow -Werror" 2008-07-3) was
intended to fix.

In particular, on platforms where the uint32_t type is defined
to be unsigned long, the return type of the new ntohl()/htonl()
is causing gcc to issue printf format warnings, such as:

    warning: long unsigned int format, unsigned int arg (arg 3)

(nine such warnings, covering six different files). The earlier
commit (6e1c2344) needed to suppress these same warnings, except
that the types were in the opposite direction; namely the format
specifier ("%u") was 'unsigned int' and the argument type (ie the
return type of ntohl()) was 'long unsigned int' (aka uint32_t).

In order to suppress these warnings, the earlier commit used the
(C99) PRIu32 format specifier, since the definition of this macro
is suitable for use with the uint32_t type on that platform.
This worked because the return type of the (original) platform
ntohl()/htonl() functions was uint32_t.

In order to suppress these warnings, we change the return type of
the new byte swapping functions in the compat/bswap.h header file
from 'unsigned int' to uint32_t.
Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NJeff King <peff@peff.net>
      5322ef20
  15. 30 9月, 2009 1 次提交
  17. 29 9月, 2009 8 次提交
  19. 27 9月, 2009 1 次提交
    • N
      make 'git clone' ask the remote only for objects it cares about · 5bdc32d3
      由 Nicolas Pitre 提交于 
      Current behavior of 'git clone' when not using --mirror is to fetch
everything from the peer, and then filter out unwanted refs just before
writing them out to the cloned repository.  This may become highly
inefficient if the peer has an unusual ref namespace, or if it simply
has "remotes" refs of its own, and those locally unwanted refs are
connecting to a large set of objects which becomes unreferenced as soon
as they are fetched.

Let's filter out those unwanted refs from the peer _before_ asking it
what refs we want to fetch instead, which is the most logical thing to
do anyway.
Signed-off-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      5bdc32d3
  21. 26 9月, 2009 3 次提交
  23. 23 9月, 2009 1 次提交