Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 02 10月, 2014 1 次提交
  3. 23 7月, 2014 2 次提交
  5. 17 7月, 2014 2 次提交
  7. 03 7月, 2014 2 次提交
  9. 31 5月, 2014 1 次提交
  11. 29 5月, 2014 2 次提交
    • J
      Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname' into maint · 12188a82
      由 Junio C Hamano 提交于 
      * rh/prompt-pcmode-avoid-eval-on-refname:
  git-prompt.sh: don't assume the shell expands the value of PS1
      12188a82
    • J
      Merge branch 'mw/symlinks' into maint · 64d8c31e
      由 Junio C Hamano 提交于 
      * mw/symlinks:
  setup: fix windows path buffer over-stepping
  setup: don't dereference in-tree symlinks for absolute paths
  setup: add abspath_part_inside_repo() function
  t0060: add tests for prefix_path when path begins with work tree
  t0060: add test for prefix_path when path == work tree
  t0060: add test for prefix_path on symlinks via absolute paths
  t3004: add test for ls-files on symlinks via absolute paths
      64d8c31e
  13. 20 5月, 2014 1 次提交
  15. 10 5月, 2014 1 次提交
  17. 09 5月, 2014 8 次提交
  19. 08 5月, 2014 1 次提交
  21. 25 4月, 2014 1 次提交
    • M
      setup: fix windows path buffer over-stepping · 6127ff63
      由 Martin Erik Werner 提交于 
      Fix a buffer over-stepping issue triggered by providing an absolute path
that is similar to the work tree path.

abspath_part_inside_repo() may currently increment the path pointer by
offset_1st_component() + wtlen, which is too much, since
offset_1st_component() is a subset of wtlen.

For the *nix-style prefix '/', this does (by luck) not cause any issues,
since offset_1st_component() is 1 and there will always be a '/' or '\0'
that can "absorb" this.

In the case of DOS-style prefixes though, the offset_1st_component() is
3 and this can potentially over-step the string buffer. For example if

    work_tree = "c:/r"
    path      = "c:/rl"

Then wtlen is 4, and incrementing the path pointer by (3 + 4) would
end up 2 bytes outside a string buffer of length 6.

Similarly if

    work_tree = "c:/r"
    path      = "c:/rl/d/a"

Then (since the loop starts by also incrementing the pointer one step),
this would mean that the function would miss checking if "c:/rl/d" could
be the work_tree, arguably this is unlikely though, since it would only
be possible with symlinks on windows.

Fix this by simply avoiding to increment by offset_1st_component() and
wtlen at the same time.
Signed-off-by: NMartin Erik Werner <martinerikwerner@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6127ff63
  23. 23 4月, 2014 1 次提交
  25. 18 4月, 2014 2 次提交
    • K
      Revert "rebase: fix run_specific_rebase's use of "return" on FreeBSD" · 8cd65967
      由 Kyle J. McKay 提交于 
      This reverts commit 99855ddf.

The workaround 99855ddf introduced to deal with problematic
"return" statements in scripts run by "dot" commands located
inside functions only handles one part of the problem.  The
issue has now been addressed by not using "return" statements
in this way in the git-rebase--*.sh scripts.

This workaround is therefore no longer necessary, so clean
up the code by reverting it.
Signed-off-by: NKyle J. McKay <mackyle@gmail.com>
Acked-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8cd65967
    • K
      rebase: avoid non-function use of "return" on FreeBSD · 9f50d32b
      由 Kyle J. McKay 提交于 
      Since a1549e10, 15d4bf2e and 01a1e646 (first appearing in v1.8.4)
the git-rebase--*.sh scripts have used a "return" to stop execution
of the dot-sourced file and return to the "dot" command that
dot-sourced it.  The /bin/sh utility on FreeBSD however behaves
poorly under some circumstances when such a "return" is executed.

In particular, if the "dot" command is contained within a function,
then when a "return" is executed by the script it runs (that is not
itself inside a function), control will return from the function
that contains the "dot" command skipping any statements that might
follow the dot command inside that function.  Commit 99855ddf (first
appearing in v1.8.4.1) addresses this by making the "dot" command
the last line in the function.

Unfortunately the FreeBSD /bin/sh may also execute some statements
in the script run by the "dot" command that appear after the
troublesome "return".  The fix in 99855ddf does not address this
problem.

For example, if you have script1.sh with these contents:

run_script2() {
        . "$(dirname -- "$0")/script2.sh"
        _e=$?
        echo only this line should show
        [ $_e -eq 5 ] || echo expected status 5 got $_e
        return 3
}
run_script2
e=$?
[ $e -eq 3 ] || { echo expected status 3 got $e; exit 1; }

And script2.sh with these contents:

if [ 5 -gt 3 ]; then
        return 5
fi
case bad in *)
        echo always shows
esac
echo should not get here
! :

When running script1.sh (e.g. '/bin/sh script1.sh' or './script1.sh'
after making it executable), the expected output from a POSIX shell
is simply the single line:

only this line should show

However, when run using FreeBSD's /bin/sh, the following output
appears instead:

should not get here
expected status 3 got 1

Not only did the lines following the "dot" command in the run_script2
function in script1.sh get skipped, but additional lines in script2.sh
following the "return" got executed -- but not all of them (e.g. the
"echo always shows" line did not run).

These issues can be avoided by not using a top-level "return" in
script2.sh.  If script2.sh is changed to this:

main() {
        if [ 5 -gt 3 ]; then
                return 5
        fi
        case bad in *)
                echo always shows
        esac
        echo should not get here
        ! :
}
main

Then it behaves the same when using FreeBSD's /bin/sh as when using
other more POSIX compliant /bin/sh implementations.

We fix the git-rebase--*.sh scripts in a similar fashion by moving
the top-level code that contains "return" statements into its own
function and then calling that as the last line in the script.
Signed-off-by: NKyle J. McKay <mackyle@gmail.com>
Acked-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9f50d32b
  27. 12 4月, 2014 2 次提交
    • K
      test: fix t5560 on FreeBSD · ff7a1c67
      由 Kyle J. McKay 提交于 
      Since fd0a8c2e (first appearing in v1.7.0), the
t/t5560-http-backend-noserver.sh test has used a backslash escape
inside a ${} expansion in order to specify a literal '?' character.

Unfortunately the FreeBSD /bin/sh does not interpret this correctly.

In a POSIX compliant shell, the following:

x='one?two?three'
echo "${x#*\?}"

Would be expected to produce this:

two?three

When using the FreeBSD /bin/sh instead you get this:

one?two?three

In fact the FreeBSD /bin/sh treats the backslash as a literal
character to match so that this:

y='one\two\three'
echo "${y#*\?}"

Produces this unexpected value:

wo\three

In this case the backslash is not only treated literally, it also
fails to defeat the special meaning of the '?' character.

Instead, we can use the [...] construct to defeat the special meaning
of the '?' character and match it exactly in a way that works for the
FreeBSD /bin/sh as well as other POSIX /bin/sh implementations.

Changing the example like so:

x='one?two?three'
echo "${x#*[?]}"

Produces the expected output using the FreeBSD /bin/sh.

Therefore, change the use of \? to [?] in order to be compatible with
the FreeBSD /bin/sh which allows t/t5560-http-backend-noserver.sh to
pass on FreeBSD again.
Signed-off-by: NKyle J. McKay <mackyle@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ff7a1c67
    • K
      test: fix t7001 cp to use POSIX options · 00764ca1
      由 Kyle J. McKay 提交于 
      Since 11502468 and 04c1ee57 (both first appearing in v1.8.5), the
t7001-mv test has used "cp -a" to perform a copy in several of the
tests.

However, the "-a" option is not required for a POSIX cp utility and
some platforms' cp utilities do not support it.

The POSIX equivalent of -a is -R -P -p.

Change "cp -a" to "cp -R -P -p" so that the t7001-mv test works
on systems with a cp utility that only implements the POSIX
required set of options and not the "-a" option.
Signed-off-by: NKyle J. McKay <mackyle@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      00764ca1
  29. 10 4月, 2014 9 次提交
  31. 09 4月, 2014 3 次提交
  33. 04 4月, 2014 1 次提交