git/t/t1200-tutorial.sh

269 lines
6.3 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2005 Johannes Schindelin
#
test_description='A simple turial in the form of a test case'
. ./test-lib.sh
test_expect_success 'blob' '
echo "Hello World" > hello &&
echo "Silly example" > example &&
git update-index --add hello example &&
test blob = "$(git cat-file -t 557db03)"
'
test_expect_success 'blob 557db03' '
test "Hello World" = "$(git cat-file blob 557db03)"
'
echo "It's a new day for git" >>hello
cat > diff.expect << EOF
diff --git a/hello b/hello
index 557db03..263414f 100644
--- a/hello
+++ b/hello
@@ -1 +1,2 @@
Hello World
+It's a new day for git
EOF
test_expect_success 'git diff-files -p' '
git diff-files -p > diff.output &&
test_cmp diff.expect diff.output
'
test_expect_success 'git diff' '
git diff > diff.output &&
test_cmp diff.expect diff.output
'
test_expect_success 'tree' '
tree=$(git write-tree 2>/dev/null) &&
test 8988da15d077d4829fc51d8544c097def6644dbb = $tree
'
test_expect_success 'git diff-index -p HEAD' '
test_tick &&
tree=$(git write-tree) &&
commit=$(echo "Initial commit" | git commit-tree $tree) &&
git update-ref HEAD $commit &&
git diff-index -p HEAD > diff.output &&
test_cmp diff.expect diff.output
'
test_expect_success 'git diff HEAD' '
git diff HEAD > diff.output &&
test_cmp diff.expect diff.output
'
cat > whatchanged.expect << EOF
Log message printout cleanups On Sun, 16 Apr 2006, Junio C Hamano wrote: > > In the mid-term, I am hoping we can drop the generate_header() > callchain _and_ the custom code that formats commit log in-core, > found in cmd_log_wc(). Ok, this was nastier than expected, just because the dependencies between the different log-printing stuff were absolutely _everywhere_, but here's a patch that does exactly that. The patch is not very easy to read, and the "--patch-with-stat" thing is still broken (it does not call the "show_log()" thing properly for merges). That's not a new bug. In the new world order it _should_ do something like if (rev->logopt) show_log(rev, rev->logopt, "---\n"); but it doesn't. I haven't looked at the --with-stat logic, so I left it alone. That said, this patch removes more lines than it adds, and in particular, the "cmd_log_wc()" loop is now a very clean: while ((commit = get_revision(rev)) != NULL) { log_tree_commit(rev, commit); free(commit->buffer); commit->buffer = NULL; } so it doesn't get much prettier than this. All the complexity is entirely hidden in log-tree.c, and any code that needs to flush the log literally just needs to do the "if (rev->logopt) show_log(...)" incantation. I had to make the combined_diff() logic take a "struct rev_info" instead of just a "struct diff_options", but that part is pretty clean. This does change "git whatchanged" from using "diff-tree" as the commit descriptor to "commit", and I changed one of the tests to reflect that new reality. Otherwise everything still passes, and my other tests look fine too. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-17 18:59:32 +00:00
commit VARIABLE
Author: VARIABLE
Date: VARIABLE
Initial commit
diff --git a/example b/example
new file mode 100644
index 0000000..f24c74a
--- /dev/null
+++ b/example
@@ -0,0 +1 @@
+Silly example
diff --git a/hello b/hello
new file mode 100644
index 0000000..557db03
--- /dev/null
+++ b/hello
@@ -0,0 +1 @@
+Hello World
EOF
test_expect_success 'git whatchanged -p --root' '
git whatchanged -p --root |
sed -e "1s/^\(.\{7\}\).\{40\}/\1VARIABLE/" \
-e "2,3s/^\(.\{8\}\).*$/\1VARIABLE/" \
> whatchanged.output &&
test_cmp whatchanged.expect whatchanged.output
'
test_expect_success 'git tag my-first-tag' '
git tag my-first-tag &&
test_cmp .git/refs/heads/master .git/refs/tags/my-first-tag
'
test_expect_success 'git checkout -b mybranch' '
git checkout -b mybranch &&
test_cmp .git/refs/heads/master .git/refs/heads/mybranch
'
cat > branch.expect <<EOF
master
* mybranch
EOF
test_expect_success 'git branch' '
git branch > branch.output &&
test_cmp branch.expect branch.output
'
test_expect_success 'git resolve now fails' '
git checkout mybranch &&
echo "Work, work, work" >>hello &&
test_tick &&
git commit -m "Some work." -i hello &&
git checkout master &&
echo "Play, play, play" >>hello &&
echo "Lots of fun" >>example &&
test_tick &&
git commit -m "Some fun." -i hello example &&
test_must_fail git merge -m "Merge work in mybranch" mybranch
'
cat > hello << EOF
Hello World
It's a new day for git
Play, play, play
Work, work, work
EOF
cat > show-branch.expect << EOF
* [master] Merge work in mybranch
! [mybranch] Some work.
--
- [master] Merge work in mybranch
*+ [mybranch] Some work.
* [master^] Some fun.
EOF
test_expect_success 'git show-branch' '
test_tick &&
git commit -m "Merge work in mybranch" -i hello &&
git show-branch --topo-order --more=1 master mybranch \
> show-branch.output &&
test_cmp show-branch.expect show-branch.output
'
cat > resolve.expect << EOF
Updating VARIABLE..VARIABLE
FASTFORWARD (no commit created; -m option ignored)
example | 1 +
hello | 1 +
2 files changed, 2 insertions(+)
EOF
test_expect_success 'git resolve' '
git checkout mybranch &&
git merge -m "Merge upstream changes." master |
sed -e "1s/[0-9a-f]\{7\}/VARIABLE/g" \
-e "s/^Fast[- ]forward /FASTFORWARD /" >resolve.output
'
test_expect_success 'git resolve output' '
test_i18ncmp resolve.expect resolve.output
'
cat > show-branch2.expect << EOF
! [master] Merge work in mybranch
* [mybranch] Merge work in mybranch
--
-- [master] Merge work in mybranch
EOF
test_expect_success 'git show-branch (part 2)' '
git show-branch --topo-order master mybranch > show-branch2.output &&
test_cmp show-branch2.expect show-branch2.output
'
cat > show-branch3.expect << EOF
! [master] Merge work in mybranch
* [mybranch] Merge work in mybranch
--
-- [master] Merge work in mybranch
+* [master^2] Some work.
+* [master^] Some fun.
EOF
test_expect_success 'git show-branch (part 3)' '
git show-branch --topo-order --more=2 master mybranch \
> show-branch3.output &&
test_cmp show-branch3.expect show-branch3.output
'
test_expect_success 'rewind to "Some fun." and "Some work."' '
git checkout mybranch &&
git reset --hard master^2 &&
git checkout master &&
git reset --hard master^
'
cat > show-branch4.expect << EOF
* [master] Some fun.
! [mybranch] Some work.
--
* [master] Some fun.
+ [mybranch] Some work.
*+ [master^] Initial commit
EOF
test_expect_success 'git show-branch (part 4)' '
git show-branch --topo-order > show-branch4.output &&
test_cmp show-branch4.expect show-branch4.output
'
test_expect_success 'manual merge' '
mb=$(git merge-base HEAD mybranch) &&
git name-rev --name-only --tags $mb > name-rev.output &&
test "my-first-tag" = $(cat name-rev.output) &&
git read-tree -m -u $mb HEAD mybranch
'
cat > ls-files.expect << EOF
100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello
100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
EOF
test_expect_success 'git ls-files --stage' '
git ls-files --stage > ls-files.output &&
test_cmp ls-files.expect ls-files.output
'
cat > ls-files-unmerged.expect << EOF
100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello
100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
EOF
test_expect_success 'git ls-files --unmerged' '
git ls-files --unmerged > ls-files-unmerged.output &&
test_cmp ls-files-unmerged.expect ls-files-unmerged.output
'
test_expect_success 'git-merge-index' '
test_must_fail git merge-index git-merge-one-file hello
'
test_expect_success 'git ls-files --stage (part 2)' '
git ls-files --stage > ls-files.output2 &&
test_cmp ls-files.expect ls-files.output2
'
test_expect_success 'git repack' 'git repack'
test_expect_success 'git prune-packed' 'git prune-packed'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 09:50:53 +00:00
test_expect_success '-> only packed objects' '
git prune && # Remove conflict marked blobs
test $(find .git/objects/[0-9a-f][0-9a-f] -type f -print 2>/dev/null | wc -l) = 0
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 09:50:53 +00:00
'
test_done