summaryrefslogtreecommitdiff
path: root/t/t6050-replace.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-11-19t6[0-3]*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-6/+6
Carefully excluding t6300, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t6[0-3]*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t6[0-3]*.sh && git checkout HEAD -- t6300\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Libravatar Johannes Schindelin1-0/+3
In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-20t: use update-ref and show-ref to reading/writing refsLibravatar Han-Wen Nienhuys1-1/+1
Reading and writing .git/refs/* assumes that refs are stored in the 'files' ref backend. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-15replace: peel tag when passing a tag first to --graftLibravatar Christian Couder1-0/+11
When passing a tag as the first argument to `git replace --graft`, it can be useful to accept it and use the underlying commit as a the commit that will be replaced. This already works for lightweight tags, but unfortunately for annotated tags we have been using the hash of the tag object instead of the hash of the underlying commit. Especially we would pass the hash of the tag object to replace_object_oid() where we would likely fail with an error like: "error: Objects must be of the same type. 'annotated_replaced_object' points to a replaced object of type 'tag' while 'replacement' points to a replacement object of type 'commit'." This patch fixes that by using the hash of the underlying commit when an annotated tag is passed. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-15replace: peel tag when passing a tag as parent to --graftLibravatar Christian Couder1-0/+11
When passing a tag as a parent argument to `git replace --graft`, it can be useful to accept it and use the underlying commit as a parent. This already works for lightweight tags, but unfortunately for annotated tags we have been using the hash of the tag object instead of the hash of the underlying commit as a parent in the replacement object we create. This created invalid objects, but the replace succeeded even if it showed an error like: error: object A is a tag, not a commit This patch fixes that by using the hash of the underlying commit when an annotated tag is passed. While at it, let's also update an error message to make it clearer. Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-01t6050: redirect expected error output to a fileLibravatar Christian Couder1-1/+2
Otherwise the error from `git rev-parse` is uselessly polluting the debug output. Redirecting to a file, instead of /dev/null, makes it possible to check that we got the error we expected, so let's check that too. Reviewed-by: Taylor Blau <me@ttaylorr.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-01t6050: use test_line_count instead of wc -lLibravatar Christian Couder1-2/+4
This modernizes a test and makes it more portable. Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-04Merge branch 'nd/i18n'Libravatar Junio C Hamano1-2/+2
More _("i18n") markings. * nd/i18n: fsck: mark strings for translation fsck: reduce word legos to help i18n parse-options.c: mark more strings for translation parse-options.c: turn some die() to BUG() parse-options: replace opterror() with optname() repack: mark more strings for translation remote.c: mark messages for translation remote.c: turn some error() or die() to BUG() reflog: mark strings for translation read-cache.c: add missing colon separators read-cache.c: mark more strings for translation read-cache.c: turn die("internal error") to BUG() attr.c: mark more string for translation archive.c: mark more strings for translation alias.c: mark split_cmdline_strerror() strings for translation git.c: mark more strings for translation
2018-11-29advice: don't pointlessly suggest --convert-graft-fileLibravatar Ævar Arnfjörð Bjarmason1-1/+4
The advice to run 'git replace --convert-graft-file' added in f9f99b3f7d ("Deprecate support for .git/info/grafts", 2018-04-29) didn't add an exception for the 'git replace --convert-graft-file' codepath itself. As a result we'd suggest running --convert-graft-file while the user was running --convert-graft-file, which makes no sense. Before: $ git replace --convert-graft-file hint: Support for <GIT_DIR>/info/grafts is deprecated hint: and will be removed in a future Git version. hint: hint: Please use "git replace --convert-graft-file" hint: to convert the grafts into replace refs. hint: hint: Turn this message off by running hint: "git config advice.graftFileDeprecated false" Add a check for that case and skip printing the advice while the user is busy following our advice. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-12fsck: mark strings for translationLibravatar Nguyễn Thái Ngọc Duy1-2/+2
Two die() are updated to start with lowercase to be consistent with the rest. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-18add core.usereplacerefs config optionLibravatar Jeff King1-0/+6
We can already disable replace refs using a command line option or environment variable, but those are awkward to apply universally. Let's add a config option to do the same thing. That raises the question of why one might want to do so universally. The answer is that replace refs violate the immutability of objects. For instance, if you wanted to cache the diff between commit XYZ and its parent, then in theory that never changes; the hash XYZ represents the total state. But replace refs violate that; pushing up a new ref may create a completely new diff. The obvious "if it hurts, don't do it" answer is not to create replace refs if you're doing this kind of caching. But for a site hosting arbitrary repositories, they may want to allow users to share replace refs with each other, but not actually respect them on the site (because the caching is more important than the replace feature). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-30Merge branch 'sg/t6500-no-redirect-of-stdin'Libravatar Junio C Hamano1-2/+0
Test cleanup. * sg/t6500-no-redirect-of-stdin: t6050-replace: don't disable stdin for the whole test script
2018-05-09t6050-replace: don't disable stdin for the whole test scriptLibravatar SZEDER Gábor1-2/+0
The test script 't6050-replace.sh' starts off with redirecting the whole test script's stdin from /dev/null. This redirection has been there since the test script was introduced in a3e8267225 (replace_object: add a test case, 2009-01-23), but the commit message doesn't explain why it was deemed necessary. AFAICT, it has never been necessary, and t6050 runs just fine and succeeds even without it, not only the current version but past versions as well. Besides being unnecessary, this redirection is also harmful, as it prevents the test helper functions 'test_pause' and 'debug' from working properly in t6050, because we can't enter any commands to the shell and the debugger, respectively. So let's remove that redirection. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-30Add a test for `git replace --convert-graft-file`Libravatar Johannes Schindelin1-0/+28
The proof, as the saying goes, lies in the pudding. So here is a regression test that not only demonstrates what the option is supposed to accomplish, but also demonstrates that it does accomplish it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>