Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 03 9月, 2009 3 次提交
    • J
      Merge branch 'maint-1.6.2' into maint-1.6.3 · 8cc15acf
      由 Junio C Hamano 提交于 
      * maint-1.6.2:
  clone: disconnect transport after fetching
      8cc15acf
    • G
      git-cvsserver: no longer use deprecated 'git-subcommand' commands · d2feb01a
      由 Gerrit Pape 提交于 
      git-cvsserver still references git commands like 'git-config', which
is depcrecated.  This commit changes git-cvsserver to use the
'git subcommand' form.

Sylvain Beucler reported the problem through
 http://bugs.debian.org/536067Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d2feb01a
    • J
      clone: disconnect transport after fetching · 12d49966
      由 Jeff King 提交于 
      The current code just leaves the transport in whatever state
it was in after performing the fetch.  For a non-empty clone
over the git protocol, the transport code already
disconnects at the end of the fetch.

But for an empty clone, we leave the connection hanging, and
eventually close the socket when clone exits. This causes
the remote upload-pack to complain "the remote end hung up
unexpectedly". While this message is harmless to the clone
itself, it is unnecessarily scary for a user to see and may
pollute git-daemon logs.

This patch just explicitly calls disconnect after we are
done with the remote end, which sends a flush packet to
upload-pack and cleanly disconnects, avoiding the error
message.

Other transports are unaffected or slightly improved:

 - for a non-empty repo over the git protocol, the second
   disconnect is a no-op (since we are no longer connected)

 - for "walker" transports (like HTTP or FTP), we actually
   free some used memory (which previously just sat until
   the clone process exits)

 - for "rsync", disconnect is always a no-op anyway
Signed-off-by: NJeff King <peff@peff.net>
Acked-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      12d49966
  3. 28 8月, 2009 7 次提交
  5. 27 8月, 2009 1 次提交
  7. 16 8月, 2009 2 次提交
    • T
      add -p: do not attempt to coalesce mode changes · 3d792161
      由 Thomas Rast 提交于 
      In 0392513f (add-interactive: refactor mode hunk handling, 2009-04-16),
we merged the interaction loops for mode changes and hunk staging.
This was fine at the time, because 0beee4c6 (git-add--interactive:
remove hunk coalescing, 2008-07-02) removed hunk coalescing.

However, in 7a26e653 (Revert "git-add--interactive: remove hunk
coalescing", 2009-05-16), we resurrected it.  Since then, the code
would attempt in vain to merge mode changes with diff hunks,
corrupting both in the process.

We add a check to the coalescing loop to ensure it only looks at diff
hunks, thus skipping mode changes.
Noticed-by: NKirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3d792161
    • K
      git add -p: demonstrate failure when staging both mode and hunk · 87ca2eaa
      由 Kirill Smelkov 提交于 
      When trying to stage changes to file which has also pending `chmod +x`,
`git add -p` produces lots of 'Use of uninitialized value ...' warnings
and fails to do the job:

    $ echo content >> file
    $ chmod +x file
    $ git add -p
    diff --git a/file b/file
    index e69de29..d95f3ad
    --- a/file
    +++ b/file
    old mode 100644
    new mode 100755
    Stage mode change [y,n,q,a,d,/,j,J,g,?]? y
    @@ -0,0 +1 @@
    +content
    Stage this hunk [y,n,q,a,d,/,K,g,e,?]? y
    Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
    Use of uninitialized value $ofs in numeric le (<=) at .../git-add--interactive line 806.
    Use of uninitialized value $o0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
    Use of uninitialized value $n0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
    Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
    fatal: corrupt patch at line 5
    diff --git a/file b/file
    index e69de29..d95f3ad
    --- a/file
    +++ b/file
    @@ -,0 + @@
    +content
Signed-off-by: NKirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      87ca2eaa
  9. 13 8月, 2009 3 次提交
  11. 11 8月, 2009 1 次提交
  13. 08 8月, 2009 5 次提交
  15. 06 8月, 2009 1 次提交
  17. 05 8月, 2009 2 次提交
  19. 31 7月, 2009 1 次提交
  21. 29 7月, 2009 3 次提交
  23. 25 7月, 2009 4 次提交
    • J
      t8005: Nobody writes Russian in shift_jis · 54bc13ce
      由 Junio C Hamano 提交于 
      The second and third tests of this script expected that Russian strings
are converted between ISO-8859-5 and Shift_JIS in the "blame --porcelain"
format output correctly.

Sure, many platforms may convert between such a combination, but that is
only because one of the base character set of Shift_JIS, JIS X 0208,
defines codepoints for Russian characters (among others); I do not think
anybody uses Shift_JIS when seriously writing Russian, and it is perfectly
understandable if iconv() libraries on some platforms fail converting
between this combination, as it does not matter in reality.

This patch changes the test to verify Japanese strings are converted
correctly between EUC-JP and Shift_JIS in the same procedure.  The point
of the test is not about verifying the platform's iconv() library, but to
see if "git blame" makes correct iconv() library calls when it should.

We could instead use ISO-8859-5 and KOI8-R as the combination, because
they are both meant to represent Russian, in order to make this test
meaningful on more platforms, but we already use Shift_JIS vs EUC-JP
combinations to test other programs in our test suite, so this combination
is safer from the point of view of the portability.  Besides, I do not
read nor write Russian; sorry ;-)

This change allows tests to pass on my (friend's) Solaris 5.11 box.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      54bc13ce
    • J
      Fix severe breakage in "git-apply --whitespace=fix" · 422a82f2
      由 Junio C Hamano 提交于 
      735c6744 (Trailing whitespace and no newline fix, 2009-07-22) completely
broke --whitespace=fix, causing it to lose all the empty lines in a patch.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      422a82f2
    • J
      SunOS grep does not understand -C<n> nor -e · 01ae841c
      由 Junio C Hamano 提交于 
      The first "grep -C1" test in t7002 does not pass on my SunOS-5.11-i86pc,
and that is not because our way to spawn external grep is broken, but
because the native grep does not understand -C<n>.

It turns out that Peff was also using this option himself because our
Makefile doesn't do that automatically.  Brandon Casey uses SUNWspro
compiler without having to set this, and it turns out that the compiler
does not define preprocessor macro __unix__ which made him always use the
built-in grep, never an external one.

Let's be more explicit and say that we do not use external grep on Suns.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      01ae841c
    • M
      Fix export_marks() error handling. · 96d69b55
      由 Matthias Andree 提交于 
      - Don't leak one FILE * on error per export_marks() call. Found with
  cppcheck and reported by Martin Ettl.

- Abort the potentially long for(;idnums.size;) loop on write errors.

- Record error if fprintf() fails for reasons not required to set the
  stream error indicator, such as ENOMEM.

- Add a trailing full-stop to error message when fopen() fails.
Signed-off-by: NMatthias Andree <matthias.andree@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      96d69b55
  25. 24 7月, 2009 3 次提交
  27. 23 7月, 2009 4 次提交
    • J
      do_one_ref(): null_sha1 check is not about broken ref · eafb4526
      由 Junio C Hamano 提交于 
      f8948e2f (remote prune: warn dangling symrefs, 2009-02-08) introduced a
more dangerous variant of for_each_ref() family that skips the check for
dangling refs, but it also made another unrelated check optional by
mistake.

The check to see if a ref points at 0{40} is not about brokenness, but is
about a possible future plan to represent a deleted ref by writing 40 "0"
in a loose ref when there is a stale version of the same ref already in
.git/packed-refs, so that we can implement deletion of a ref without
having to rewrite the packed refs file excluding the ref being deleted.

This check has to live outside of the conditional.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      eafb4526
    • S
      Trailing whitespace and no newline fix · 735c6744
      由 SZEDER Gábor 提交于 
      If a patch adds a new line to the end of a file and this line ends with
one trailing whitespace character and has no newline, then
'--whitespace=fix' currently does not remove that trailing whitespace.

This patch fixes this by removing the check for trailing whitespace at
the end of the line at a hardcoded offset which does not take the
eventual absence of newline into account.
Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      735c6744
    • J
      diff --cc: a lost line at the beginning of the file is shown incorrectly · b810cbbd
      由 Junio C Hamano 提交于 
      When combine-diff inspected the diff from one parent to the merge result,
it misinterpreted a header in the form @@ -l,k +0,0 @@.

This hunk header means that K lines were removed from the beginning of the
file, so the lost lines must be queued to the sline that represents the
first line of the merge result, but we incremented our pointer incorrectly
and ended up queuing it to the second line, which in turn made the lossage
appear _after_ the first line.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b810cbbd
    • J
      combine-diff.c: fix performance problem when folding common deleted lines · 55d5d5ba
      由 Junio C Hamano 提交于 
      For a deleted line in a patch with the parent we are looking at, the
append_lost() function finds the same line among a run of lines that were
deleted from the same location by patches from parents we previously
checked.  This is so that patches with two parents

    @@ -1,4 +1,3 @@    @@ -1,4 +1,3 @@
     one                   one
    -two                  -two
     three                 three
    -quatro               -fyra
    +four                 +four

can be coalesced into this sequence, reusing one line that describes the
removal of "two" for both parents.

   @@@ -1,4 -1,4 +1,3 @@@
     one
   --two
     three
   - quatro
    -frya
   ++four

While reading the second patch (that removes "two" and then "fyra"), after
finding where removal of the "two" matches, we need to find existing
removal of "fyra" (if exists) in the removal list, but the match has to
happen after all the existing matches (in this case "two").  The code used
a naïve O(n^2) algorithm to compute this by scanning the whole removal
list over and over again.

This patch remembers where the next scan should be started in the existing
removal list to avoid this.

Noticed by Linus Torvalds.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      55d5d5ba