summaryrefslogtreecommitdiff
path: root/config.mak.in
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2011-04-05 17:20:25 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2011-04-05 20:01:37 -0700
commit59d418fe10c207a510672d17a854697a8abc1e0b (patch)
treeb7749f32165822dc7b6a22f512e453130da0e277 /config.mak.in
parentGit 1.7.4 (diff)
downloadtgif-59d418fe10c207a510672d17a854697a8abc1e0b.tar.xz
stash: fix accidental apply of non-existent stashes
Once upon a time, "git rev-parse ref@{9999999}" did not generate an error. Therefore when we got an invalid stash reference in "stash apply", we could end up not noticing until quite late. Commit b0f0ecd (detached-stash: work around git rev-parse failure to detect bad log refs, 2010-08-21) handled this by checking for the "Log for stash has only %d entries" warning on stderr when we validated the ref. A few days later, e6eedc3 (rev-parse: exit with non-zero status if ref@{n} is not valid., 2010-08-24) fixed the original issue. That made the extra stderr test superfluous, but also introduced a new bug. Now the early call to: git rev-parse --symbolic "$@" fails, but we don't notice the exit code. Worse, its empty output means we think the user didn't provide us a ref, and we try to apply stash@{0}. This patch checks the rev-parse exit code and fails early in the revision parsing process. We can also get rid of the stderr test; as a bonus, this means that "stash apply" can now run under GIT_TRACE=1 properly. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'config.mak.in')
0 files changed, 0 insertions, 0 deletions