1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-30 13:57:54 +01:00
git/t/t1200-tutorial.sh

182 lines
4 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 &&
cmp diff.expect diff.output
'
test_expect_success 'git diff' '
git diff > diff.output &&
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' '
echo "Initial commit" | \
git commit-tree $(git write-tree) 2>&1 > .git/refs/heads/master &&
git diff-index -p HEAD > diff.output &&
cmp diff.expect diff.output
'
test_expect_success 'git diff HEAD' '
git diff HEAD > diff.output &&
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 20:59:32 +02: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 &&
cmp whatchanged.expect whatchanged.output
'
test_expect_success 'git tag my-first-tag' '
git tag my-first-tag &&
cmp .git/refs/heads/master .git/refs/tags/my-first-tag
'
test_expect_success 'git checkout -b mybranch' '
git checkout -b mybranch &&
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 &&
cmp branch.expect branch.output
'
test_expect_success 'git resolve now fails' '
git checkout mybranch &&
echo "Work, work, work" >>hello &&
git commit -m "Some work." -i hello &&
git checkout master &&
echo "Play, play, play" >>hello &&
echo "Lots of fun" >>example &&
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] Merged "mybranch" changes.
! [mybranch] Some work.
--
- [master] Merged "mybranch" changes.
*+ [mybranch] Some work.
EOF
test_expect_success 'git show-branch' '
git commit -m "Merged \"mybranch\" changes." -i hello &&
git show-branch --topo-order master mybranch > show-branch.output &&
cmp show-branch.expect show-branch.output
'
cat > resolve.expect << EOF
Updating VARIABLE..VARIABLE
Fast forward (no commit created; -m option ignored)
example | 1 +
hello | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
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" >resolve.output &&
cmp resolve.expect resolve.output
'
cat > show-branch2.expect << EOF
! [master] Merged "mybranch" changes.
* [mybranch] Merged "mybranch" changes.
--
-- [master] Merged "mybranch" changes.
EOF
test_expect_success 'git show-branch (part 2)' '
git show-branch --topo-order master mybranch > show-branch2.output &&
cmp show-branch2.expect show-branch2.output
'
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 10:50:53 +01:00
test_expect_success '-> only packed objects' '
git prune && # Remove conflict marked blobs
! find .git/objects/[0-9a-f][0-9a-f] -type f
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 10:50:53 +01:00
'
test_done