summaryrefslogtreecommitdiff
path: root/t/t6050-replace.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-01-05t6050-replace: make failing editor test more robustLibravatar SZEDER Gábor1-3/+7
'git replace --edit' should error out when the invoked editor fails, but the test checking this behavior would not notice if this weren't the case. The test in question, ever since it was added in 85f98fc037ae (replace: add tests for --edit, 2014-05-17), has simulated a failing editor in an unconventional way: test_must_fail env GIT_EDITOR='./fakeeditor;false' git replace --edit I presume the reason for this unconventional editor was the fact that 'git replace --edit' requires the edited object to be different from the original, but a mere 'false' as editor would leave the object unchanged and 'git replace --edit' would error out anyway complaining about the new and the original object files being the same. Running 'fakeeditor' before 'false' was supposed to ensure that the object file is modified and thus 'git replace --edit' errors out because of the failed editor. However, this editor doesn't actually modify the edited object, because start_command() turns this editor into: /bin/sh -c './fakeeditor;false "$@"' './fakeeditor;false' \ '.../.git/REPLACE_EDITOBJ' This means that the test's fakeeditor script doesn't even get the path of the object to be edited as argument, triggering error messages from the commands executed inside the script ('sed' and 'mv'), and ultimately leaving the object file unchanged. If a patch were to remove the die() from the error path after launch_editor(), the test would not catch it, because 'git replace' would continue execution past launch_editor() and would error out a bit later due to the unchanged edited object. Though 'git replace' would error out for the wrong reason, this would satisfy 'test_must_fail' just as well, and the test would succeed leaving the undesired change unnoticed. Create a proper failing fake editor script for this test to ensure that the edited object is in fact modified and 'git replace --edit' won't error out because the new and original object files are the same. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-21replace: add test for --graft with a mergetagLibravatar Christian Couder1-0/+22
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-21replace: add test for --graft with signed commitLibravatar Christian Couder1-0/+24
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-21replace: add test for --graftLibravatar Christian Couder1-1/+44
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-07replace: cleanup redirection style in testsLibravatar Christian Couder1-24/+24
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19replace: add tests for --editLibravatar Christian Couder1-0/+27
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-30replace info: rename 'full' to 'long' and clarify in-code symbolsLibravatar Christian Couder1-2/+2
Enum names SHORT/MEDIUM/FULL were too broad to be descriptive. And they clashed with built-in symbols on platforms like Windows. Clarify by giving them REPLACE_FORMAT_ prefix. Rename 'full' format in "git replace --format=<name>" to 'long', to match others (i.e. 'short' and 'medium'). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12builtin/replace: unset read_replace_refsLibravatar Christian Couder1-1/+1
When checking to see if some objects are of the same type and when displaying the type of objects, git replace uses the sha1_object_info() function. Unfortunately this function by default respects replace refs, so instead of the type of a replaced object, it gives the type of the replacement object which might be different. To fix this bug, and because git replace should work at a level before replacement takes place, let's unset the read_replace_refs global variable at the beginning of cmd_replace(). Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12t6050: add tests for listing with --formatLibravatar Christian Couder1-0/+37
This patch adds tests for "git replace -l --format=<fmt>". 'short', 'medium' and 'full' are the only allowed values for <fmt>. 'short' is the same as with no --format option. Tests for 'medium' and 'full' are the most needed. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12sha1_file: perform object replacement in sha1_object_info_extended()Libravatar Christian Couder1-1/+1
sha1_object_info_extended() should perform object replacement if it is needed. The simplest way to do that is to make it call lookup_replace_object_extended(). And now its "unsigned flags" parameter is used as it is passed to lookup_replace_object_extended(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12t6050: show that git cat-file --batch fails with replace objectsLibravatar Christian Couder1-0/+5
When --batch is passed to git cat-file, the sha1_object_info_extended() function is used to get information about the objects passed to git cat-file. Unfortunately sha1_object_info_extended() doesn't take care of object replacement properly, so it will often fail with a message like this: $ echo a3fb2e1845a1aaf129b7975048973414dc172173 | git cat-file --batch a3fb2e1845a1aaf129b7975048973414dc172173 commit 231 fatal: object a3fb2e1845a1aaf129b7975048973414dc172173 change size!? The goal of this patch is to show this breakage. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-06t6050-replace: use some long option namesLibravatar Christian Couder1-4/+4
So that they are tested a little bit too. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-06t6050-replace: add test to clean up all the replace refsLibravatar Christian Couder1-0/+6
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-06t6050-replace: test that objects are of the same typeLibravatar Christian Couder1-0/+13
and that the -f option bypasses the type check Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-13replace: parse revision argument for -dLibravatar Michael J Gruber1-0/+11
'git replace' parses the revision arguments when it creates replacements (so that a sha1 can be abbreviated, e.g.) but not when deleting replacements. Make it parse the argument to 'replace -d' in the same way. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jeff King <peff@peff.net>
2011-05-15t6050: make sure we test not just commit replacementLibravatar Junio C Hamano1-2/+16
The replacement mechanism should affect all types of objects not just commits, so make sure it deals with at least a blob. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-09tests: add missing &&Libravatar Jonathan Nieder1-1/+1
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-27t6050 (replace): fix bogus "fetch branch with replacement" testLibravatar Christian Couder1-3/+10
The test was missing some "&&" at the end of some lines and it was wrong because, as the replacement refs were not fetched, the commits from the parallel branch should not show up. This was found by Elijah Newren. This is fixed by checking that after the branch from HASH6 is fetched, the commits from the parallel branch don't show up, and then by fetching the replacement refs and checking that they do show up afterwards. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-09tests: subshell indentation stylefixLibravatar Jonathan Nieder1-21/+25
Format the subshells introduced by the previous patch (Several tests: cd inside subshell instead of around, 2010-09-06) like so: ( cd subdir && ... ) && This is generally easier to read and has the nice side-effect that this patch will show what commands are used in the subshell, making it easier to check for lost environment variables and similar behavior changes. Cc: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-06Merge branch 'jl/maint-fix-test'Libravatar Junio C Hamano1-11/+11
* jl/maint-fix-test: Several tests: cd inside subshell instead of around Conflicts: t/t9600-cvsimport.sh
2010-09-06Several tests: cd inside subshell instead of aroundLibravatar Jens Lehmann1-11/+11
Fixed all places where it was a straightforward change from cd'ing into a directory and back via "cd .." to a cd inside a subshell. Found these places with "git grep -w "cd \.\.". Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-03Merge branch 'nd/maint-fix-replace'Libravatar Junio C Hamano1-1/+1
* nd/maint-fix-replace: parse_object: pass on the original sha1, not the replaced one
2010-09-03parse_object: pass on the original sha1, not the replaced oneLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Commit 0e87c36 (object: call "check_sha1_signature" with the replacement sha1) changed the first argument passed to parse_object_buffer() from "sha1" to "repl". With that change, the returned obj pointer has the replacement SHA1 in obj->sha1, not the original one. But when using lookup_commit() and then parse_commit() on a commit, we get an object pointer with the original sha1, but the commit content comes from the replacement commit. So the result we get from using parse_object() is different from the we get from using lookup_commit() followed by parse_commit(). It looks much simpler and safer to fix this inconsistency by passing "sha1" to parse_object_bufer() instead of "repl". The commit comment should be used to tell the the replacement commit is replacing another commit and why. So it should be easy to see that we have a replacement commit instead of an original one. And it is not a problem if the content of the commit is not consistent with the sha1 as cat-file piped to hash-object can be used to see the difference. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-12index-pack: Don't follow replace refs.Libravatar Nelson Elhage1-0/+6
Without this, attempting to index a pack containing objects that have been replaced results in a fatal error that looks like: fatal: SHA1 COLLISION FOUND WITH <replaced-object> ! Signed-off-by: Nelson Elhage <nelhage@ksplice.com> Acked-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20replace: use a GIT_NO_REPLACE_OBJECTS env variableLibravatar Christian Couder1-0/+17
This has the same effect as --no-replace-objects option; git ignores the replace refs. When --no-replace-objects option is passed to git, this environment variable is set to "1" and exported to subprocesses in order to propagate the same setting. It is useful for example for scripts, as the git commands used in them can now be aware that they must not read replace refs. Tested-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-13git: add --no-replace-objects option to disable replacingLibravatar Christian Couder1-0/+7
Commit dae556b (environment: add global variable to disable replacement) adds a variable to enable/disable replacement, and it is enabled by default for most commands. So there is no way to disable it for some commands, which is annoying when we want to get information about a commit that has been replaced. For example: $ git cat-file -p N would output information about the replacement commit if commit N is replaced. With the "--no-replace-objects" option that this patch adds it is possible to get information about the original commit using: $ git --no-replace-objects cat-file -p N While at it, let's add some documentation about this new option in the "git replace" man page too. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-31t6050: check pushing something based on a replaced commitLibravatar Christian Couder1-0/+68
When using something like: $ git push $there 04a8c^2:master we need to parse 04a8c to find its second parent and then start discussing what object to send with the other end. "04a8c^2" is a direct user input and should mean the same commit as git show "04a8c^2" would give the user, so it obviously needs to obey the replace rules (making 04a8c parsed), but the object transfer should not look at replace at all. This patch adds some tests to check that the above is working well. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-31builtin-replace: teach "git replace" to actually replaceLibravatar Christian Couder1-0/+10
Teach the syntax: "git replace <object> <replacement>", so that "git replace" can now create replace refs. These replace refs will be used by read_sha1_file to substitute <object> with <replacement> for most of the commands. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-31Add new "git replace" commandLibravatar Christian Couder1-0/+12
This command can only be used now to list replace refs in "refs/replace/" and to delete them. The option to list replace refs is "-l". The option to delete replace refs is "-d". The behavior should be consistent with how "git tag" and "git branch" are working. The code has been copied from "builtin-tag.c" by Kristian Høgsberg <krh@redhat.com> and Carlos Rica <jasampler@gmail.com> that was itself based on git-tag.sh and mktag.c by Linus Torvalds. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-31environment: add global variable to disable replacementLibravatar Christian Couder1-0/+23
This new "read_replace_refs" global variable is set to 1 by default, so that replace refs are used by default. But reachability traversal and packing commands ("cmd_fsck", "cmd_prune", "cmd_pack_objects", "upload_pack", "cmd_unpack_objects") set it to 0, as they must work with the original DAG. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-31mktag: call "check_sha1_signature" with the replacement sha1Libravatar Christian Couder1-0/+12
Otherwise we get a "sha1 mismatch" error for replaced objects. Note that I am not sure at all that this is a good change. It may be that we should just refuse to tag a replaced object. But in this case we should probably give a meaningfull error message instead of "sha1 mismatch". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-31replace_object: add a test caseLibravatar Christian Couder1-0/+75
In this patch the setup code is very big, but this will be used in test cases that will be added later. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>