Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 26 4月, 2007 8 次提交
    • R
      Perform correct quoting of recipient names. · 732263d4
      由 Robin H. Johnson 提交于 
      Always perform quoting of the recipient names if they contain periods,
previously only the author's address was treated this way. This stops sendmail
binaries from exploding the name into bad addresses.
Signed-off-by: NRobin H. Johnson <robbat2@gentoo.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      732263d4
    • R
      Change the scope of the $cc variable as it is not needed outside of send_message. · af068d27
      由 Robin H. Johnson 提交于 
      $cc is only used inside the send_message scope, so lets clean it out of the global scope.
Signed-off-by: NRobin H. Johnson <robbat2@gentoo.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      af068d27
    • R
      Debugging cleanup improvements · 8e3d436b
      由 Robin H. Johnson 提交于 
      The debug output is much more helpful if it has the parameters that were used.
Pull the sendmail parameters into a seperate array for that, and also include
similar data during the Net::SMTP case.
Signed-off-by: NRobin H. Johnson <robbat2@gentoo.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      8e3d436b
    • R
      Prefix Dry- to the message status to denote dry-runs. · 71c7da94
      由 Robin H. Johnson 提交于 
      While doing testing, it's useful to see that a dry run was actually done,
instead of a real one.
Signed-off-by: NRobin H. Johnson <robbat2@gentoo.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      71c7da94
    • R
      Document --dry-run parameter to send-email. · 238cc635
      由 Robin H. Johnson 提交于 
      Looks like --dry-run was added to the code, but never to the --help output.
Signed-off-by: NRobin H. Johnson <robbat2@gentoo.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      238cc635
    • A
      git-svn: Don't rely on $_ after making a function call · b03c7a63
      由 Adam Roben 提交于 
      Many functions and operators in perl set $_, so its value cannot be relied upon
after calling arbitrary functions. The solution is simply to copy the value of
$_ into a local variable that will not get overwritten.
Signed-off-by: NAdam Roben <aroben@apple.com>
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      b03c7a63
    • A
      Fix handle leak in write_tree · c21aa54e
      由 Alex Riesen 提交于 
      This is a quick and dirty fix for the broken "git cherry-pick -n" on
some broken OS, which does not remove the directory entry after unlink
succeeded(!) if the file is still open somewher.
The entry is left but "protected": no open, no unlink, no stat.
Very annoying.
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      c21aa54e
    • S
      Actually handle some-low memory conditions · d1efefa4
      由 Shawn O. Pearce 提交于 
      Tim Ansell discovered his Debian server didn't permit git-daemon to
use as much memory as it needed to handle cloning a project with
a 128 MiB packfile.  Filtering the strace provided by Tim of the
rev-list child showed this gem of a sequence:

  open("./objects/pack/pack-*.pack", O_RDONLY|O_LARGEFILE <unfinished ...>
  <... open resumed> )              = 5

OK, so the packfile is fd 5...

  mmap2(NULL, 33554432, PROT_READ, MAP_PRIVATE, 5, 0 <unfinished ...>
   <... mmap2 resumed> )             = 0xb5e2d000

and we mapped one 32 MiB window from it at position 0...

   mmap2(NULL, 31020635, PROT_READ, MAP_PRIVATE, 5, 0x6000 <unfinished ...>
   <... mmap2 resumed> )             = -1 ENOMEM (Cannot allocate memory)

And we asked for another window further into the file.  But got
denied.  In Tim's case this was due to a resource limit on the
git-daemon process, and its children.

Now where are we in the code?  We're down inside use_pack(),
after we have called unuse_one_window() enough times to make sure
we stay within our allowed maximum window size.  However since we
didn't unmap the prior window at 0xb5e2d000 we aren't exceeding
the current limit (which probably was just the defaults).

But we're actually down inside xmmap()...

So we release the window we do have (by calling release_pack_memory),
assuming there is some memory pressure...

   munmap(0xb5e2d000, 33554432 <unfinished ...>
   <... munmap resumed> )            = 0
   close(5 <unfinished ...>
   <... close resumed> )             = 0

And that was the last window in this packfile.  So we closed it.
Way to go us.  Our xmmap did not expect release_pack_memory to
close the fd its about to map...

   mmap2(NULL, 31020635, PROT_READ, MAP_PRIVATE, 5, 0x6000 <unfinished ...>
   <... mmap2 resumed> )             = -1 EBADF (Bad file descriptor)

And so the Linux kernel happily tells us f' off.

   write(2, "fatal: ", 7 <unfinished ...>
   <... write resumed> )             = 7
   write(2, "Out of memory? mmap failed: Bad "..., 47 <unfinished ...>
   <... write resumed> )             = 47

And we report the bad file descriptor error, and not the ENOMEM,
and die, claiming we are out of memory.  But actually that mmap
should have succeeded, as we had enough memory for that window,
seeing as how we released the prior one.

Originally when I developed the sliding window mmap feature I had
this exact same bug in fast-import, and I dealt with it by handing
in the struct packed_git* we want to open the new window for, as the
caller wasn't prepared to reopen the packfile if unuse_one_window
closed it.  The same is true here from xmmap, but the caller doesn't
have the struct packed_git* handy.  So I'm using the file descriptor
instead to perform the same test.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      d1efefa4
  3. 25 4月, 2007 2 次提交
  5. 24 4月, 2007 6 次提交
  7. 23 4月, 2007 1 次提交
    • J
      dir.c(common_prefix): Fix two bugs · c7f34c18
      由 Johannes Schindelin 提交于 
      The function common_prefix() is used to find the common subdirectory of
a couple of pathnames. When checking if the next pathname matches up with
the prefix, it incorrectly checked the whole path, not just the prefix
(including the slash). Thus, the expensive part of the loop was executed
always.

The other bug is more serious: if the first and the last pathname in the
list have a longer common prefix than the common prefix for _all_ pathnames
in the list, the longer one would be chosen. This bug was probably hidden
by the fact that bash's wildcard expansion sorts the results, and the code
just so happens to work with sorted input.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      c7f34c18
  9. 22 4月, 2007 2 次提交
  11. 21 4月, 2007 1 次提交
  13. 19 4月, 2007 9 次提交
  15. 18 4月, 2007 3 次提交
  17. 17 4月, 2007 2 次提交
  19. 16 4月, 2007 6 次提交