Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 10 12月, 2008 7 次提交
    • J
      Merge branch 'maint' · 5363d074
      由 Junio C Hamano 提交于 
      * maint:
  work around Python warnings from AsciiDoc
  git-svn: Make following parents atomic
      5363d074
    • J
      diff: respect textconv in rewrite diffs · 3aa1f7ca
      由 Jeff King 提交于 
      Currently we just skip rewrite diffs for binary files; this
patch makes an exception for files which will be textconv'd,
and actually performs the textconv before generating the
diff.

Conceptually, rewrite diffs should be in the exact same
format as the a non-rewrite diff, except that we refuse to
share any context. Thus it makes very little sense for "git
diff" to show a textconv'd diff, but for "git diff -B" to
show "Binary files differ".
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3aa1f7ca
    • J
      diff: fix handling of binary rewrite diffs · 0c01857d
      由 Jeff King 提交于 
      The current emit_rewrite_diff code always writes a text patch without
checking whether the content is binary. This means that if you end up with
a rewrite diff for a binary file, you get lots of raw binary goo in your
patch.

Instead, if we have binary files, then let's just skip emit_rewrite_diff
altogether. We will already have shown the "dissimilarity index" line, so
it is really about the diff contents. If binary diffs are turned off, the
"Binary files a/file and b/file differ" message should be the same in
either case. If we do have binary patches turned on, there isn't much
point in making a less-efficient binary patch that does a total rewrite;
no human is going to read it, and since binary patches don't apply with
any fuzz anyway, the result of application should be the same.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0c01857d
    • A
      Fix typos in documentation · 51ea4406
      由 Alexander Potashev 提交于 
      Signed-off-by: NAlexander Potashev <aspotashev@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      51ea4406
    • T
      git-p4: Fix regression in p4Where method. · 75bc9573
      由 Tor Arvid Lund 提交于 
      Unfortunately, I introduced a bug in commit 7f705dc3 (git-p4: Fix bug in
p4Where method). This happens because sometimes the result from
"p4 where <somepath>" doesn't contain a "depotFile" key, but instead a
"data" key that needs further parsing. This commit should ensure that both
of these cases are checked.
Signed-off-by: NTor Arvid Lund <torarvid@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      75bc9573
    • R
      Improve language in git-merge.txt and related docs · 29b802aa
      由 Ralf Wildenhues 提交于 
      Improve some minor language and format issues like hyphenation,
phrases, spacing, word order, comma, attributes.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      29b802aa
    • J
      work around Python warnings from AsciiDoc · aa971cb9
      由 Junio C Hamano 提交于 
      It appears that a reference to an anchor defined as [[anchor-name]] from
another place using <<anchor-name>> syntax, when the anchor name contains
a string "-with-" in its name, triggers these warnings from Python
interpreter.

  asciidoc -b docbook -d book user-manual.txt
  <string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
  <string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
  <string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
  <string>:1: Warning: 'with' will become a reserved keyword in Python 2.6

There currently is no reference to "Finding comments with given content",
but for consistency and for futureproofing, the anchor is also updated as
the other ones that are actually used and trigger these warnings.
Signed-off-by: NJunio C Hamano <junio@pobox.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      aa971cb9
  3. 09 12月, 2008 3 次提交
    • A
      Define linkgit macro in [macros] section · 9c0c1b1f
      由 Alexey Borzenkov 提交于 
      Starting with asciidoc 8.3.0 linkgit macro is no longer recognized by
asciidoc and user guide suggests
(http://www.methods.co.nz/asciidoc/userguide.html#_macro_definitions)
that macros are supposed to be defined in [macros] section. I'm not
sure whether undefined linkgit macro was working by pure chance or it
is a regression in asciidoc 8.3.0, but this patch adds proper
definition for the linkgit macro, allowing it to work on 8.3.0.
Signed-off-by: NAlexey Borzenkov <snaury@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9c0c1b1f
    • D
      git-svn: Make following parents atomic · 553589f7
      由 Deskin Miller 提交于 
      find_parent_branch generates branch@rev type branches when one has to
look back through SVN history to properly get the history for a branch
copied from somewhere not already being tracked by git-svn.  If in the
process of fetching this history, git-svn is interrupted, then when one
fetches again, it will use whatever was last fetched as the parent
commit and fail to fetch any more history which it didn't get to before
being terminated.  This is especially troubling in that different
git-svn copies of the same SVN repository can end up with different
commit sha1s, incorrectly showing the history as divergent and
precluding easy collaboration using git push and fetch.

To fix this, when we initialise the Git::SVN object $gs to search for
and perhaps fetch history, we check if there are any commits in SVN in
the range between the current revision $gs is at, and the top revision
for which we were asked to fill history.  If there are commits we're
missing in that range, we continue the fetch from the current revision
to the top, properly getting all history before using it as the parent
for the branch we're trying to create.
Signed-off-by: NDeskin Miller <deskinm@umich.edu>
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      553589f7
    • J
      gitweb: Fix bug in insert_file() subroutine · 4586864a
      由 Jakub Narebski 提交于 
      In insert_file() subroutine (which is used to insert HTML fragments as
custom header, footer, hometext (for projects list view), and per
project README.html (for summary view)) we used:

     map(to_utf8, <$fd>);

This doesn't work, and other form has to be used:

     map { to_utf8($_) } <$fd>;

Now with test for t9600 added, for $GIT_DIR/README.html.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4586864a
  5. 08 12月, 2008 10 次提交
  7. 07 12月, 2008 4 次提交
  9. 06 12月, 2008 3 次提交
  11. 05 12月, 2008 8 次提交
  13. 04 12月, 2008 5 次提交