Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 14 9月, 2007 4 次提交
  3. 13 9月, 2007 3 次提交
  5. 12 9月, 2007 2 次提交
  7. 10 9月, 2007 3 次提交
    • S
      Make --no-thin the default in git-push to save server resources · a4503a15
      由 Shawn O. Pearce 提交于 
      1) pushes happen less often than fetches, so the bandwidth saving is
   much less visible in that case overall.

2) thin packs have to be complemented with missing delta bases to be
   valid, so many received thin packs will take more disk space.

3) the bother of repacking should be distributed amongst "clients"
   i.e. fetchers and pushers as much as possible, and not the server
   being fetched or pushed, to keep disk and CPU usage low on the
   server.

This is why a fetch should get thin packs but a push should not.

Both Nico and I have been assuming that --no-thin was the default
behavior of git-push ever since Nico introduced --fix-thin into the
index-pack process, which allowed fetch and receive-pack to avoid
exploding packfiles received during transfer.  This patch finally
makes it so.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a4503a15
    • N
      fix doc for --compression argument to pack-objects · 05cc2ffc
      由 Nicolas Pitre 提交于 
      Remove obsolete details (core.legacyheaders is always true now).
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      05cc2ffc
    • C
      git-tag -s must fail if gpg cannot sign the tag. · aba91192
      由 Carlos Rica 提交于 
      Most of this patch code and message was written by Shawn O. Pearce.
I made some tests to know what the problem was, and then I changed
the code related with the SIGPIPE signal.

If the user has misconfigured `user.signingkey` in their .git/config
or just doesn't have any secret keys on their keyring and they ask
for a signed tag with `git tag -s` we better make sure the resulting
tag was actually signed by gpg.

Prior versions of builtin git-tag allowed this failure to slip
by without error as they were not checking the return value of
the finish_command() so they did not notice when gpg exited with
an error exit status.  They also did not fail if gpg produced an
empty output or if read_in_full received an error from the read
system call while trying to read the pipe back from gpg.

Finally, we did not actually honor any return value from the do_sign
function as it returns ssize_t but was being stored into an unsigned
long.  This caused the compiler to optimize out the die condition,
allowing git-tag to continue along and create the tag object.

However, when gpg gets a wrong username, it exits before any read was done
and then the writing process receives SIGPIPE and program is terminated.
By ignoring this signal, anyway, the function write_or_die gets EPIPE from
write_in_full and exits returning 0 to the system without a message.
Here we better call to write_in_full directly so we can fail
printing a message and return safely to the caller.

With these issues fixed `git-tag -s` will now fail to create the
tag and will report a non-zero exit status to its caller, thereby
allowing automated helper scripts to detect (and recover from)
failure if gpg is not working properly.
Proposed-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NCarlos Rica <jasampler@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      aba91192
  9. 09 9月, 2007 2 次提交
  11. 08 9月, 2007 3 次提交
  13. 06 9月, 2007 5 次提交
    • S
      Include a git-push example for creating a remote branch · 4e560158
      由 Shawn O. Pearce 提交于 
      Many users get confused when `git push origin master:foo` works
when foo already exists on the remote repository but are confused
when foo doesn't exist as a branch and this form does not create
the branch foo.

This new example highlights the trick of including refs/heads/
in front of the desired branch name to create a branch.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4e560158
    • S
      Cleanup unnecessary file modifications in t1400-update-ref · 432e93a1
      由 Shawn O. Pearce 提交于 
      Kristian Høgsberg pointed out that the two file modifications
we were doing during the 'creating initial files' step are not even
used within the test suite.  This was actually confusing as we do
not even need these changes for the tests to pass.  All that really
matters here is the specific commit dates are used so that these
appear in the branch's reflog, and that the dates are different so
that the branch will update when asked and the reflog entry is
also updated.  There is no need for the file modification.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      432e93a1
    • D
      Makefile: Add cache-tree.h to the headers list · 6b1b40d9
      由 Dmitry V. Levin 提交于 
      The dependency was missing.
Signed-off-by: NDmitry V. Levin <ldv@altlinux.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6b1b40d9
    • S
      Don't allow contrib/workdir/git-new-workdir to trash existing dirs · ea09ea22
      由 Shawn O. Pearce 提交于 
      Recently I found that doing a sequence like the following:

  git-new-workdir a b
  ...
  git-new-workdir a b

by accident will cause a (and now also b) to have an infinite cycle
in its refs directory.  This is caused by git-new-workdir trying
to create the "refs" symlink over again, only during the second
time it is being created within a's refs directory and is now also
pointing back at a's refs.

This causes confusion in git as suddenly branches are named things
like "refs/refs/refs/refs/refs/refs/refs/heads/foo" instead of the
more commonly accepted "refs/heads/foo".  Plenty of commands start
to see ambiguous ref names and others just take ages to compute.

git-clone has the same safety check, so git-new-workdir should
behave just like it.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ea09ea22
    • J
      git-apply: do not read past the end of buffer · 6b763c42
      由 Junio C Hamano 提交于 
      When the preimage we are patching is shorter than what the patch
text expects, we tried to match the buffer contents at the
"original" line with the fragment in full, without checking we
have enough data to match in the preimage.  This caused the size
of a later memmove() to wrap around and attempt to scribble
almost the entire address space.  Not good.

The code that follows the part this patch touches tries to match
the fragment with line offsets.  Curiously, that code does not
have the problem --- it guards against reading past the end of
the preimage.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6b763c42
  15. 03 9月, 2007 2 次提交
  17. 02 9月, 2007 3 次提交
  19. 01 9月, 2007 13 次提交