Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 27 6月, 2013 4 次提交
    • J
      quote_path_relative(): remove redundant parameter · 39598f99
      由 Jiang Xin 提交于 
      quote_path_relative() used to take a counted string as its parameter
(the string to be quoted).  With an earlier change, it now uses
relative_path() that does not take a counted string, and we have
been passing only the pointer to the string since then.

Remove the length parameter from quote_path_relative() to show that
this parameter was redundant.  All the changed lines show that the
caller passed either -1 (to ask the function run strlen() on the
string), or the length of the string, so the earlier conversion was
safe.

All the callers of quote_path_relative() that used to take counted string
have been audited to make sure that they are passing length of the actual
string (or -1 to ask the callee run strlen())
Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      39598f99
    • J
      quote.c: substitute path_relative with relative_path · ad66df2d
      由 Jiang Xin 提交于 
      Substitute the function path_relative in quote.c with the function
relative_path. Function relative_path can be treated as an enhanced
and more robust version of path_relative.

Outputs of path_relative and it's replacement (relative_path) are the
same for the following cases:

    path      prefix     output of path_relative  output of relative_path
    ========  =========  =======================  =======================
    /a/b/c/   /a/b/      c/                       c/
    /a/b/c    /a/b/      c                        c
    /a/       /a/b/      ../                      ../
    /         /a/b/      ../../                   ../../
    /a/c      /a/b/      ../c                     ../c
    /x/y      /a/b/      ../../x/y                ../../x/y
    a/b/c/    a/b/       c/                       c/
    a/        a/b/       ../                      ../
    x/y       a/b/       ../../x/y                ../../x/y
    /a/b      (empty)    /a/b                     /a/b
    /a/b      (null)     /a/b                     /a/b
    a/b       (empty)    a/b                      a/b
    a/b       (null)     a/b                      a/b

But if both of the path and the prefix are the same, or the returned
relative path should be the current directory, the outputs of both
functions are different. Function relative_path returns "./", while
function path_relative returns empty string.

    path      prefix     output of path_relative  output of relative_path
    ========  =========  =======================  =======================
    /a/b/     /a/b/      (empty)                  ./
    a/b/      a/b/       (empty)                  ./
    (empty)   (null)     (empty)                  ./
    (empty)   (empty)    (empty)                  ./

But the callers of path_relative can handle such cases, or never
encounter this issue at all, because:

 * In function quote_path_relative, if the output of path_relative is
   empty, append "./" to it, like:

       if (!out->len)
           strbuf_addstr(out, "./");

 * Another caller is write_name_quoted_relative, which is only used
   by builtin/ls-files.c. git-ls-files only show files, so path of
   files will never be identical with the prefix of a directory.

The following differences show that path_relative does not handle
extra slashes properly:

    path      prefix     output of path_relative  output of relative_path
    ========  =========  =======================  =======================
    /a//b//c/ //a/b//    ../../../../a//b//c/     c/
    a/b//c    a//b       ../b//c                  c

And if prefix has no trailing slash, path_relative does not work
properly either.  But since prefix always has a trailing slash, it's
not a problem.

    path      prefix     output of path_relative  output of relative_path
    ========  =========  =======================  =======================
    /a/b/c/   /a/b       b/c/                     c/
    /a/b      /a/b       b                        ./
    /a/b/     /a/b       b/                       ./
    /a        /a/b/      ../../a                  ../
    a/b/c/    a/b        b/c/                     c/
    a/b/      a/b        b/                       ./
    a         a/b        ../a                     ../
    x/y       a/b/       ../x/y                   ../../x/y
    a/c       a/b        c                        ../c
    /a/       /a/b       (empty)                  ../
    (empty)   /a/b       ../../                   ./

One tricky part in this conversion is write_name() function in
ls-files.c.  It takes a counted string, <name, len>, that is to be
made relative to <prefix, prefix_len> and then quoted.  Because
write_name_quoted_relative() still takes these two parameters as
counted string, but ignores the count and treat these two as
NUL-terminated strings, this conversion needs to be audited for its
callers:

 - For <name, len>, all three callers of write_name() passes a
   NUL-terminated string and its true length, so this patch makes
   "len" unused.

 - For <prefix, prefix_len>, prefix could be a string that is longer
   than empty while prefix_len could be 0 when "--full-name" option
   is used.  This is fixed by checking prefix_len in write_name()
   and calling write_name_quoted_relative() with NULL when
   prefix_len is set to 0.  Again, this makes "prefix_len" given to
   write_name_quoted_relative() unused, without introducing a bug.
Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ad66df2d
    • J
      path.c: refactor relative_path(), not only strip prefix · e02ca72f
      由 Jiang Xin 提交于 
      Original design of relative_path() is simple, just strip the prefix
(*base) from the absolute path (*abs).

In most cases, we need a real relative path, such as: ../foo,
../../bar.  That's why there is another reimplementation
(path_relative()) in quote.c.

Borrow some codes from path_relative() in quote.c to refactor
relative_path() in path.c, so that it could return real relative
path, and user can reuse this function without reimplementing
his/her own.  The function path_relative() in quote.c will be
substituted, and I would use the new relative_path() function when
implementing the interactive git-clean later.

Different results for relative_path() before and after this refactor:

    abs path  base path  relative (original)  relative (refactor)
    ========  =========  ===================  ===================
    /a/b      /a/b       .                    ./
    /a/b/     /a/b       .                    ./
    /a        /a/b/      /a                   ../
    /         /a/b/      /                    ../../
    /a/c      /a/b/      /a/c                 ../c
    /x/y      /a/b/      /x/y                 ../../x/y

    a/b/      a/b/       .                    ./
    a/b/      a/b        .                    ./
    a         a/b        a                    ../
    x/y       a/b/       x/y                  ../../x/y
    a/c       a/b        a/c                  ../c

    (empty)   (null)     (empty)              ./
    (empty)   (empty)    (empty)              ./
    (empty)   /a/b       (empty)              ./
    (null)    (null)     (null)               ./
    (null)    (empty)    (null)               ./
    (null)    /a/b       (segfault)           ./

You may notice that return value "." has been changed to "./".
It is because:

 * Function quote_path_relative() in quote.c will show the relative
   path as "./" if abs(in) and base(prefix) are the same.

 * Function relative_path() is called only once (in setup.c), and
   it will be OK for the return value as "./" instead of ".".
Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e02ca72f
    • J
      test: add test cases for relative_path · 203439b2
      由 Jiang Xin 提交于 
      Add subcommand "relative_path" in test-path-utils, and add test cases
in t0060.

Johannes tested an earlier version of this patch on Windows, and
found that some relative_path tests should be skipped on
Windows. This is because the bash on Windows rewrites arguments of
regular Windows programs, such as git and the test helpers, if the
arguments look like absolute POSIX paths. As a consequence, the
actual tests performed are not what the tests scripts expect.

The tests that need *not* be skipped are those where the two paths passed
to 'test-path-utils relative_path' have the same prefix and the result is
expected to be a relative path. This is because the rewriting changes
"/a/b" to "D:/Src/MSysGit/a/b", and when both inputs are extended the same
way, this just cancels out in the relative path computation.
Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
Helped-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      203439b2
  3. 16 5月, 2013 9 次提交
  5. 15 5月, 2013 1 次提交
  7. 14 5月, 2013 1 次提交
  9. 13 5月, 2013 3 次提交
  11. 12 5月, 2013 2 次提交
  13. 11 5月, 2013 4 次提交
  15. 10 5月, 2013 9 次提交
    • J
      Sync with v1.8.2.3 · b387c77b
      由 Junio C Hamano 提交于 
      * maint:
  Git 1.8.2.3
  t5004: avoid using tar for checking emptiness of archive
  t5004: ignore pax global header file
  mergetools/kdiff3: do not use --auto when diffing
  transport-helper: trivial style cleanup
      b387c77b
    • J
      Git 1.8.2.3 · 92758dd2
      由 Junio C Hamano 提交于 
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      92758dd2
    • J
      Merge branch 'mv/sequencer-pick-error-diag' · faf8fde5
      由 Junio C Hamano 提交于 
      Fix "git cherry-pick $annotated_tag", which was mistakenly rejected.

* mv/sequencer-pick-error-diag:
  cherry-pick: picking a tag that resolves to a commit is OK
      faf8fde5
    • J
      cherry-pick: picking a tag that resolves to a commit is OK · 7c0b0d8d
      由 Junio C Hamano 提交于 
      Earlier, 21246dbb (cherry-pick: make sure all input objects are
commits, 2013-04-11) tried to catch an unlikely "git cherry-pick $blob"
as an error, but broke a more important use case to cherry-pick a
tag that points at a commit.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7c0b0d8d
    • J
      Merge branch 'tr/copy-revisions-from-stdin' into maint · 07e03d46
      由 Junio C Hamano 提交于 
      * tr/copy-revisions-from-stdin:
  read_revisions_from_stdin: make copies for handle_revision_arg
      07e03d46
    • R
      t5004: avoid using tar for checking emptiness of archive · ea2d20d4
      由 René Scharfe 提交于 
      Test 2 of t5004 checks if a supposedly empty tar archive really
contains no files.  24676f02 (t5004: fix issue with empty archive test
and bsdtar) removed our commit hash to make it work with bsdtar, but
the test still fails on NetBSD and OpenBSD, which use their own tar
that considers a tar file containing only NULs as broken.

Here's what the different archivers do when asked to create a tar
file without entries:

	$ uname -v
	NetBSD 6.0.1 (GENERIC)
	$ gtar --version | head -1
	tar (GNU tar) 1.26
	$ bsdtar --version
	bsdtar 2.8.4 - libarchive 2.8.4

	$ : >zero.tar
	$ perl -e 'print "\0" x 10240' >tenk.tar
	$ sha1 zero.tar tenk.tar
	SHA1 (zero.tar) = da39a3ee5e6b4b0d3255bfef95601890afd80709
	SHA1 (tenk.tar) = 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c

	$ : | tar cf - -T - | sha1
	da39a3ee5e6b4b0d3255bfef95601890afd80709
	$ : | gtar cf - -T - | sha1
	34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c
	$ : | bsdtar cf - -T - | sha1
	34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c

So NetBSD's native tar creates an empty file, while GNU tar and bsdtar
both give us 10KB of NULs -- just like git archive with an empty tree.
Now let's see how the archivers handle these two kinds of empty tar
files:

	$ tar tf zero.tar; echo $?
	tar: Unexpected EOF on archive file
	1
	$ gtar tf zero.tar; echo $?
	gtar: This does not look like a tar archive
	gtar: Exiting with failure status due to previous errors
	2
	$ bsdtar tf zero.tar; echo $?
	0

	$ tar tf tenk.tar; echo $?
	tar: Cannot identify format. Searching...
	tar: End of archive volume 1 reached
	tar: Sorry, unable to determine archive format.
	1
	$ gtar tf tenk.tar; echo $?
	0
	$ bsdtar tf tenk.tar; echo $?
	0

NetBSD's tar complains about both, bsdtar happily accepts any of them
and GNU tar doesn't like zero-length archive files.  So the safest
course of action is to stay with our block-of-NULs format which is
compatible with GNU tar and bsdtar, as we can't make NetBSD's native
tar happy anyway.

We can simplify our test, however, by taking tar out of the picture.
Instead of extracting the archive and checking for the non-presence of
files, check if the file has a size of 10KB and contains only NULs.
This makes t5004 pass on NetBSD and OpenBSD.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ea2d20d4
    • R
      t5004: ignore pax global header file · abdb9b2e
      由 René Scharfe 提交于 
      Versions of tar that don't know pax headers -- like the ones in NetBSD 6
and OpenBSD 5.2 -- extract them as regular files.  Explicitly ignore the
file created for our global header when checking the list of extracted
files, as this is normal and harmless fall-back behaviour.  This fixes
test 3 of t5004 on these platforms.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      abdb9b2e
    • D
      mergetools/kdiff3: do not use --auto when diffing · e2161bc3
      由 David Aguilar 提交于 
      The `kdiff3 --auto` help message is, "No GUI if all conflicts are auto-
solvable."  This flag was carried over from the original mergetool
commands.  diff_cmd() is for two-way comparisons only so remove the
superfluous flag.
Signed-off-by: NDavid Aguilar <davvid@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e2161bc3
    • F
      transport-helper: trivial style cleanup · b120ef3e
      由 Felipe Contreras 提交于 
      Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b120ef3e
  17. 09 5月, 2013 3 次提交
  19. 08 5月, 2013 4 次提交