Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 12 4月, 2008 1 次提交
  3. 10 4月, 2008 3 次提交
  5. 07 4月, 2008 1 次提交
    • J
      Fix "git apply" to correctly enforce "match at the beginning" · ee5a317e
      由 Junio C Hamano 提交于 
      An earlier commit 4be60962 (apply --unidiff-zero: loosen sanity checks for
--unidiff=0 patches, 2006-09-17) made match_beginning and match_end
computed incorrectly.  If a hunk inserts at the beginning, old position
recorded at the hunk is line 0, and if a hunk changes at the beginning, it
is line 1.  The new test added to t4104 exposes that the old code did not
insist on matching at the beginning for a patch to add a line to an empty
file.

An even older 65aadb92 (apply: force matching at the beginning.,
2006-05-24) was equally wrong in that it tried to take hints from the
number of leading context lines, to decide if the hunk must match at the
beginning, but we can just look at the line number in the hunk to decide.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ee5a317e
  7. 28 3月, 2008 4 次提交
  9. 27 3月, 2008 1 次提交
  11. 26 3月, 2008 4 次提交
  13. 16 3月, 2008 2 次提交
  15. 15 3月, 2008 5 次提交
    • J
      format-patch: generate MIME header as needed even when there is format.header · 6bf4f1b4
      由 Junio C Hamano 提交于 
      Earlier, the callchain from pretty_print_commit() down to pp_title_line()
had an unwarranted assumption that the presense of "after_subject"
parameter, means the caller has already output MIME headers for
attachments.  The parameter's primary purpose is to give extra header
lines the caller wants to place after pp_title_line() generates the
"Subject: " line.

This assumption does not hold when the user used the format.header
configuration variable to pass extra headers, and caused a message with
non-ASCII character to lack proper MIME headers (e.g.  8-bit CTE header).
The earlier logic also failed to suppress duplicated MIME headers when
"format-patch -s --attach" is asked for and the signer's name demanded
8-bit clean transport.

This patch fixes the logic by introducing a separate need_8bit_cte
parameter passed down the callchain.  This can have one of these values:

 -1 : we've already done MIME crap and we do not want to add extra header
      to say this is 8bit in pp_title_line();

  0 : we haven't done MIME and we have not seen anything that is 8bit yet;

  1 : we haven't done MIME and we have seen something that is 8bit;
      pp_title_line() must add MIME header.

It adds two tests by Jeff King who independently diagnosed this issue.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6bf4f1b4
    • J
      Make man page building quiet when DOCBOOK_XSL_172 is defined · a0b54e7b
      由 Jonas Fonseca 提交于 
      Tell xmlto to repress printing of the lines:

	Note: meta date   : No date. Using generated date       git-xyx
	Note: Writing git-xyz.1
Signed-off-by: NJonas Fonseca <fonseca@diku.dk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a0b54e7b
    • B
      git-new-workdir: Share SVN meta data between work dirs and the repository · ac378633
      由 Bernt Hansen 提交于 
      Multiple work dirs with git svn caused each work dir to have its own
stale copy of the SVN meta data in .git/svn

git svn rebase updates commits with git-svn-id: in the repository and
stores the SVN meta data information only in that work dir.  Attempting to
git svn rebase in other work dirs for the same branch would fail because
the last revision fetched according to the git-svn-id is greater than the
revision in the SVN meta data for that work directory.
Signed-off-by: NBernt Hansen <bernt@norang.ca>
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ac378633
    • L
      rev-parse: fix meaning of rev~ vs rev~0. · 621ff675
      由 Linus Torvalds 提交于 
      I think it would make more sense for rev~ to have the same guarantees that
rev^ has, namely to always return a commit. I would also suggest that not
giving a number would have the same effect of defaulting to 1, not 0.

Right now it's a bit illogical, but at least it's an _undocumented_
illogical behaviour.

This patch makes '^' and '~' act the same for the default count (i.e. both
default to 1), and also have the same behaviour for a count of zero.

Before (no discernible pattern):

	[torvalds@woody git]$ git rev-parse v1.5.1 v1.5.1^0 v1.5.1~0 v1.5.1^ v1.5.1~
	45354a57ee7e3e42c7137db6c94fa968c6babe8d
	89815cab
	45354a57ee7e3e42c7137db6c94fa968c6babe8d
	045f5759
	45354a57ee7e3e42c7137db6c94fa968c6babe8d

After (fairly logical):

	[torvalds@woody git]$ git rev-parse v1.5.1 v1.5.1^0 v1.5.1~0 v1.5.1^ v1.5.1~
	45354a57ee7e3e42c7137db6c94fa968c6babe8d
	89815cab
	89815cab
	045f5759
	045f5759Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      621ff675
    • E
      git-svn: don't blindly append '*' to branch/tags config · ed0b9d43
      由 Eric Wong 提交于 
      Previously, git-svn would blindly append '*' even if it was specified by
the user during initialization (for certain SVN setups, it is
necessary).

Now, the following command will work correctly:

  git svn init -T trunk/docutils \
               -t 'tags/*/docutils' \
               -b 'branches/*/docutils' \
               svn://svn.berlios.de/docutils

Thanks to martin f krafft for the bug report:
> My git-svn target configuration is
>
>   [svn-remote "svn"]
>     url = svn://svn.berlios.de/docutils
>     fetch = trunk/docutils:refs/remotes/trunk
>     branches = branches/*/docutils:refs/remotes/*
>     tags = tags/*/docutils:refs/remotes/tags/*
>
> Unfortunately, when I run
>
>   git-svn init -T trunk/docutils -t 'tags/*/docutils'
>    -b 'branches/*/docutils'
>
> then I get (note the two asterisks on the left hand side):
>
>     branches = branches/*/docutils/*:refs/remotes/*
>     tags = tags/*/docutils/*:refs/remotes/tags/*
>
> I took a brief stab at the code but I can't even figure out where
> the /* is appended, so I defer to you.
>
> It should be trivial to keep git-svn from appending /* if the left
> side already contains an asterisk.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Tested-by: Nmartin f krafft <madduck@madduck.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ed0b9d43
  17. 14 3月, 2008 4 次提交
  19. 13 3月, 2008 4 次提交
  21. 12 3月, 2008 4 次提交
  23. 11 3月, 2008 2 次提交
  25. 10 3月, 2008 2 次提交
  27. 09 3月, 2008 3 次提交
    • J
      GIT 1.5.4.4 · 56d5fe28
      由 Junio C Hamano 提交于 
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      56d5fe28
    • S
      ident.c: reword error message when the user name cannot be determined · 6c293d40
      由 Santi Béjar 提交于 
      The "config --global" suggested in the message is a valid one-shot fix,
and hopefully one-shot across machines that NFS mounts the home directories.

This knowledge can hopefully be reused when you are forced to use git on
Windows, but the fix based on GECOS would not be applicable, so
it is not such a useful hint to mention the exact reason why the
name cannot be determined.
Signed-off-by: NSanti Béjar <sbejar@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6c293d40
    • J
      Fix dcommit, rebase when rewriteRoot is in use · 0bb91d9a
      由 John Goerzen 提交于 
      When the rewriteRoot setting is used with git-svn, it causes the svn
IDs added to commit messages to bear a different URL than is actually
used to retrieve Subversion data.

It is common for Subversion repositories to be available multiple
ways: for instance, HTTP to the public, and svn+ssh to people with
commit access.  The need to switch URLs for access is fairly common as
well -- perhaps someone was just given commit access.  To switch URLs
without having to rewrite history, one can use the old url as a
rewriteRoot, and use the new one in the svn-remote url setting.

This works well for svn fetching and general git commands.

However, git-svn dcommit, rebase, and perhaps other commands do not
work in this scenario.  They scan the svn ID lines in commit messages
and attempt to match them up with url lines in [svn-remote] sections
in the git config.

This patch allows them to match rewriteRoot options, if such options
are present.
Signed-off-by: NJohn Goerzen <jgoerzen@complete.org>
Acked-by: NEric Wong <normalperson@yhbt.net>
      0bb91d9a