Carlos Rica <jasampler@xxxxxxxxx> writes:
> This adds the new file t/t7102-reset.sh following the text
> and examples in "Documentation/git-reset.txt" in order to
> check the behaviour of the upcoming "builtin-reset.c",
> and be able to compare it with the original "git-reset.sh".
I think what the tests try to catch are sensible, but I wonder
if this cannot be done without hardcoding too many object
names. For example,
> +check_changes () {
> + test "$(git rev-parse HEAD)" = "$1" &&
> + git diff | git diff .diff_expect - &&
> + git diff --cached | git diff .cached_expect - &&
> + for FILE in *
> + do
> + echo $FILE':'
> + cat $FILE || return
> + done | git diff .cat_expect -
> +}
this can be done without hardcoding the exact commit object name
if you tag the commits while you build the test repository and
give tag relative name in "$1" (you have to do "git rev-parse"
it). Then you do not have to say ...
> +test_expect_success 'giving a non existing revision should fail' '
> + ! git reset aaaaaa &&
> + ! git reset --mixed aaaaaa &&
> + ! git reset --soft aaaaaa &&
> + ! git reset --hard aaaaaa &&
> + check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
> +'
... 3ec3965 here.
I'd like to keep the very low level details of how exactly
object names are computed isolated to t0000 as much as
possible.
I also suspect this would not pass on CRLF boxes.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
