Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 18 11月, 2014 1 次提交
  3. 16 11月, 2014 2 次提交
  5. 15 11月, 2014 2 次提交
  7. 13 11月, 2014 4 次提交
  9. 12 11月, 2014 2 次提交
  11. 11 11月, 2014 8 次提交
  13. 08 11月, 2014 1 次提交
  15. 07 11月, 2014 7 次提交
  17. 05 11月, 2014 6 次提交
    • B
      gitignore.txt: fix spelling of "backslash" · 03af7cd1
      由 Ben North 提交于 
      Signed-off-by: NBen North <ben@redfrontdoor.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      03af7cd1
    • J
      diff-highlight: exit when a pipe is broken · 251e7dad
      由 John Szakmeister 提交于 
      While using diff-highlight with other tools, I have discovered that Python
ignores SIGPIPE by default.  Unfortunately, this also means that tools
attempting to launch a pager under Python--and don't realize this is
happening--means that the subprocess inherits this setting.  In this case, it
means diff-highlight will be launched with SIGPIPE being ignored.  Let's work
with those broken scripts by restoring the default SIGPIPE handler.
Signed-off-by: NJohn Szakmeister <john@szakmeister.net>
Acked-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      251e7dad
    • T
      Documentation: typofixes · f745acb0
      由 Thomas Ackermann 提交于 
      In addition to fixing trivial and obvious typos, be careful about
the following points:

 - Spell ASCII, URL and CRC in ALL CAPS;
 - Spell Linux as Capitalized;
 - Do not omit periods in "i.e." and "e.g.".
Signed-off-by: NThomas Ackermann <th.acker@arcor.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f745acb0
    • T
      line-log: fix crash when --first-parent is used · a8787c5c
      由 Tzvetan Mikov 提交于 
      line-log tries to access all parents of a commit, but only the first
parent has been loaded if "--first-parent" is specified, resulting
in a crash.

Limit the number of parents to one if "--first-parent" is specified.
Reported-by: NEric N. Vander Weele <ericvw@gmail.com>
Signed-off-by: NTzvetan Mikov <tmikov@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a8787c5c
    • J
      ignore stale directories when checking reflog existence · 9233887c
      由 Jeff King 提交于 
      When we update a ref, we have two rules for whether or not
we actually update the reflog:

  1. If the reflog already exists, we will always append to
     it.

  2. If log_all_ref_updates is set, we will create a new
     reflog file if necessary.

We do the existence check by trying to open the reflog file,
either with or without O_CREAT (depending on log_all_ref_updates).
If it fails, then we check errno to see what happened.

If we were not using O_CREAT and we got ENOENT, the file
doesn't exist, and we return success (there isn't a reflog
already, and we were not told to make a new one).

If we get EISDIR, then there is likely a stale directory
that needs to be removed (e.g., there used to be "foo/bar",
it was deleted, and the directory "foo" was left. Now we
want to create the ref "foo"). If O_CREAT is set, then we
catch this case, try to remove the directory, and retry our
open. So far so good.

But if we get EISDIR and O_CREAT is not set, then we treat
this as any other error, which is not right. Like ENOENT,
EISDIR is an indication that we do not have a reflog, and we
should silently return success (we were not told to create
it). Instead, the current code reports this as an error, and
we fail to update the ref at all.

Note that this is relatively unlikely to happen, as you
would have to have had reflogs turned on, and then later
turned them off (it could also happen due to a bug in fetch,
but that was fixed in the previous commit). However, it's
quite easy to fix: we just need to treat EISDIR like ENOENT
for the non-O_CREAT case, and silently return (note that
this early return means we can also simplify the O_CREAT
case).

Our new tests cover both cases (O_CREAT and non-O_CREAT).
The first one already worked, of course.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9233887c
    • J
      fetch: load all default config at startup · 72549dfd
      由 Jeff King 提交于 
      When we start the git-fetch program, we call git_config to
load all config, but our callback only processes the
fetch.prune option; we do not chain to git_default_config at
all.

This means that we may not load some core configuration
which will have an effect. For instance, we do not load
core.logAllRefUpdates, which impacts whether or not we
create reflogs in a bare repository.

Note that I said "may" above. It gets even more exciting. If
we have to transfer actual objects as part of the fetch,
then we call fetch_pack as part of the same process. That
function loads its own config, which does chain to
git_default_config, impacting global variables which are
used by the rest of fetch. But if the fetch is a pure ref
update (e.g., a new ref which is a copy of an old one), we
skip fetch_pack entirely. So we get inconsistent results
depending on whether or not we have actual objects to
transfer or not!

Let's just load the core config at the start of fetch, so we
know we have it (we may also load it again as part of
fetch_pack, but that's OK; it's designed to be idempotent).

Our tests check both cases (with and without a pack). We
also check similar behavior for push for good measure, but
it already works as expected.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      72549dfd
  19. 04 11月, 2014 1 次提交
  21. 03 11月, 2014 1 次提交
  23. 02 11月, 2014 4 次提交
  25. 01 11月, 2014 1 次提交