kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Junio C Hamano	8a2f87332b	Fix "git-commit -C $tag" The scripted version might not have handled this correctly either, but the version rewritten in C definitely does not grok this and complains $tag is not a commit object. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	41ac414ea2	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>	17 years ago
Junio C Hamano	1eb1e9eea4	commit: allow --amend to reuse message from another commit After tentatively applying a patch from a contributor, you can get a replacement patch with corrected code and unusable commit log message. In such a case, this sequence ought to give you an editor based on the message in the earlier commit, to let you describe an incremental improvement: git reset --hard HEAD^ ;# discard the earlier one git am <corrected-patch git commit --amend -c HEAD@{1} Unfortunately, --amend insisted reusing the message from the commit being amended, ignoring the -c option. This corrects it. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Wincent Colaiuta	264474f29a	Add tests for pre-commit and commit-msg hooks As desired, these pass for git-commit.sh, fail for builtin-commit (prior to the fixes), and succeeded for builtin-commit (after the fixes). Signed-off-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	36863af16e	git-commit --allow-empty It does not usually make sense to record a commit that has the exact same tree as its sole parent commit and that is why git-commit prevents you from making such a mistake, but when data from foreign scm is involved, it is a different story. We are equipped to represent such an (perhaps insane, perhaps by mistake, or perhaps done on purpose) empty change, and it is better to represent it bypassing the safety valve for native use. This is primarily for use by foreign scm interface scripts. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Johannes Sixt	13aba1e514	git-commit: Allow to amend a merge commit that does not change the tree Normally, it should not be allowed to generate an empty commit. A merge commit generated with git 'merge -s ours' does not change the tree (along the first parent), but merges are not "empty" even if they do not change the tree. Hence, commit `8588452ceb` allowed to amend a merge commit that does not change the tree, but `4fb5fd5d30` disallowed it again in an attempt to avoid that an existing commit is amended such that it becomes empty. With this change, a commit can be edited (create a new one or amend an existing one) either if there are changes or if there are at least two parents. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Kristian Høgsberg	1200993a1e	t7501-commit: Add test for git commit <file> with dirty index. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Kristian Høgsberg	d63c2fd192	Add testcase for amending and fixing author in git commit. We used to clobber author time, but we shouldn't. Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	958e67c0a8	Make test scripts executable.	17 years ago
Johannes Sixt	41ec097aea	t7501-commit.sh: Not all seds understand option -i Use mv instead. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Björn Steinbrink	9d87442f03	git-commit: Add tests for invalid usage of -a/--interactive with paths git-commit was/is broken in that it accepts paths together with -a or --interactive, which it shouldn't. There tests check those usage errors. Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	5aa5cd460c	git-commit: a bit more tests Add tests for -s (sign-off) and multiple -m options Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	cba8d48961	git-commit: partial commit of paths only removed from the index Because a partial commit is meant to be a way to ignore what are staged in the index, "git rm --cached A && git commit A" should just record what is in A on the filesystem. The previous patch made the command sequence to barf, saying that A has not been added yet. This fixes it. Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	64586e75af	git-commit: Allow partial commit of file removal. When making a partial commit, git-commit uses git-ls-files with the --error-unmatch option to expand and sanity check the user supplied path patterns. When any path pattern does not match with the paths known to the index, it errors out, in order to catch a common mistake to say "git commit Makefiel cache.h" and end up with a commit that touches only cache.h (notice the misspelled "Makefile"). This detection however does not work well when the path has already been removed from the index. If you drop a path from the index and try to commit that partially, i.e. $ git rm COPYING $ git commit -m 'Remove COPYING' COPYING the command complains because git does not know anything about COPYING anymore. This introduces a new option --with-tree to git-ls-files and uses it in git-commit when we build a temporary index to write a tree object for the partial commit. When --with-tree=<tree-ish> option is specified, names from the given tree are added to the set of names the index knows about, so we can treat COPYING file in the example as known. Of course, there is no reason to use "git rm" and git-aware people have long time done: $ rm COPYING $ git commit -m 'Remove COPYING' COPYING which works just fine. But this caused a constant confusion. Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	db33af0a7f	git-commit: partial commit of paths only removed from the index Because a partial commit is meant to be a way to ignore what are staged in the index, "git rm --cached A && git commit A" should just record what is in A on the filesystem. The previous patch made the command sequence to barf, saying that A has not been added yet. This fixes it. Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	80bffaf7fb	git-commit: Allow partial commit of file removal. When making a partial commit, git-commit uses git-ls-files with the --error-unmatch option to expand and sanity check the user supplied path patterns. When any path pattern does not match with the paths known to the index, it errors out, in order to catch a common mistake to say "git commit Makefiel cache.h" and end up with a commit that touches only cache.h (notice the misspelled "Makefile"). This detection however does not work well when the path has already been removed from the index. If you drop a path from the index and try to commit that partially, i.e. $ git rm COPYING $ git commit -m 'Remove COPYING' COPYING the command complains because git does not know anything about COPYING anymore. This introduces a new option --with-tree to git-ls-files and uses it in git-commit when we build a temporary index to write a tree object for the partial commit. When --with-tree=<tree-ish> option is specified, names from the given tree are added to the set of names the index knows about, so we can treat COPYING file in the example as known. Of course, there is no reason to use "git rm" and git-aware people have long time done: $ rm COPYING $ git commit -m 'Remove COPYING' COPYING which works just fine. But this caused a constant confusion. Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	6d4bbebd35	git-commit.sh: Permit the --amend message to be given with -m/-c/-C/-F. [jc: adjusted t/t7501 as this makes -F and --amend compatible] Signed-off-by: David Kastrup <dak@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Kristian Høgsberg	12ace0b20d	Add test case for basic commit functionality. Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago

23 Commits (5d02294c776c46f0d454470c66c16fe9f08fad3d)