path: root/t/
AgeCommit message (Collapse)Author
2022-05-12commit: fix "author_ident" leakJunio C Hamano
Since 4c28e4ada03 (commit: die before asking to edit the log message, 2010-12-20), we have been "leaking" the "author_ident" when prepare_to_commit() fails. Instead of returning from right there, introduce an exit status variable and jump to the clean-up label at the end. Instead of explicitly releasing the resource with strbuf_release(), mark the variable with UNLEAK() at the end, together with two other variables that are already marked as such. If this were in a utility function that is called number of times, but these are different, we should explicitly release resources that grow proportionally to the size of the problem being solved, but cmd_commit() is like main() and there is no point in spending extra cycles to release individual pieces of resource at the end, just before process exit will clean everything for us for free anyway. This fixes a leak demonstrated by e.g. "", but unfortunately we cannot mark it or other affected tests as passing now with "TEST_PASSES_SANITIZE_LEAK=true" as we'll need to fix many other memory leaks before doing so. Incidentally there are two tests that always passes the leak checker with or without this change. Mark them as such. This is based on an earlier patch by Ævar, but takes a different approach that is more maintainable. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2021-12-13t0000-t3999: detect and signal failure within loopEric Sunshine
Failures within `for` and `while` loops can go unnoticed if not detected and signaled manually since the loop itself does not abort when a contained command fails, nor will a failure necessarily be detected when the loop finishes since the loop returns the exit code of the last command it ran on the final iteration, which may not be the command which failed. Therefore, detect and signal failures manually within loops using the idiom `|| return 1` (or `|| exit 1` within subshells). Signed-off-by: Eric Sunshine <> Reviewed-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2020-07-01diff-files --raw: show correct post-image of intent-to-add filesJohannes Schindelin
The documented behavior of `git diff-files --raw` is to display [...] 0{40} if creation, unmerged or "look at work tree". on the right hand (i.e. postimage) side. This happens for files that have unstaged modifications, and for files that are unmodified but stat-dirty. For intent-to-add files, we used to show the empty blob's hash instead. In c26022ea8f5 (diff: convert diff_addremove to struct object_id, 2017-05-30), we made that worse by inadvertently changing that to the hash of the empty tree. Let's make the behavior consistent with files that have unstaged modifications (which applies to intent-to-add files, too) by showing all-zero values also for intent-to-add files. Accordingly, this patch adjusts the expectations set by the regression test introduced in feea6946a5b (diff-files: treat "i-t-a" files as "not-in-index", 2020-06-20). Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2020-06-22diff-files: treat "i-t-a" files as "not-in-index"Srinidhi Kaushik
The `diff-files' command and related commands which call the function `cmd_diff_files()', consider the "intent-to-add" files as a part of the index when comparing the work-tree against it. This was previously addressed in commits [1] and [2] by turning the option `--ita-invisible-in-index' (introduced in [3]) on by default. For `diff-files' (and `add -p' as a consequence) to show the i-t-a files as as new, `ita_invisible_in_index' will be enabled by default here as well. [1] 0231ae71d3 (diff: turn --ita-invisible-in-index on by default, 2018-05-26) [2] 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist in index", 2016-10-24) [3] b42b451919 (diff: add --ita-[in]visible-in-index, 2016-10-24) Signed-off-by: Srinidhi Kaushik <> Signed-off-by: Junio C Hamano <>
2019-07-01t2203: avoid hard-coded object ID valuesbrian m. carlson
In order to make this test work with multiple hash algorithms, compute the object ID used in this test instead of hard-coding it. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2018-08-21tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'SZEDER Gábor
Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in '', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in ''. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in ''. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in ''. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2018-06-25Merge branch 'nd/diff-apply-ita'Junio C Hamano
"git diff" compares the index and the working tree. For paths added with intent-to-add bit, the command shows the full contents of them as added, but the paths themselves were not marked as new files. They are now shown as new by default. "git apply" learned the "--intent-to-add" option so that an otherwise working-tree-only application of a patch will add new paths to the index marked with the "intent-to-add" bit. * nd/diff-apply-ita: apply: add --intent-to-add t2203: add a test about "diff HEAD" case diff: turn --ita-invisible-in-index on by default diff: ignore --ita-[in]visible-in-index when diffing worktree-to-tree
2018-05-29apply: add --intent-to-addNguyễn Thái Ngọc Duy
Similar to 'git reset -N', this option makes 'git apply' automatically mark new files as intent-to-add so they are visible in the following 'git diff' command and could also be committed with 'git commit -a'. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-05-29t2203: add a test about "diff HEAD" caseNguyễn Thái Ngọc Duy
Previous attempts to fix ita-related diffs breaks this case. To make sure that does not happen again, add a test to verify the behavior wrt. ita entries when we diff a worktree and a tree. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-05-29diff: turn --ita-invisible-in-index on by defaultNguyễn Thái Ngọc Duy
Due to the implementation detail of intent-to-add entries, the current "git diff" (i.e. no treeish or --cached argument) would show the changes in the i-t-a file, but it does not mark the file as new, while "diff --cached" would mark the file as new while showing its content as empty. $ git diff | $ diff --cached --------------------------------|------------------------------- diff --git a/new b/new | diff --git a/new b/new index e69de29..5ad28e2 100644 | new file mode 100644 --- a/new | index 0000000..e69de29 +++ b/new | @@ -0,0 +1 @@ | +haha | One evidence of the current output being wrong is that, the output from "git diff" (with ita entries) cannot be applied because it assumes empty files exist before applying. Turning on --ita-invisible-in-index [1] [2] would fix this. The result is "new file" line moving from "git diff --cached" to "git diff". $ git diff | $ diff --cached --------------------------------|------------------------------- diff --git a/new b/new | new file mode 100644 | index 0000000..5ad28e2 | --- /dev/null | +++ b/new | @@ -0,0 +1 @@ | +haha | This option is on by default in git-status [1] but we need more fixup in rename detection code [3]. Luckily we don't need to do anything else for the rename detection code in diff.c (wt-status.c uses a customized one). [1] 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist in index" - 2016-10-24) [2] b42b451919 (diff: add --ita-[in]visible-in-index - 2016-10-24) [3] bc3dca07f4 (Merge branch 'nd/ita-wt-renames-in-status' - 2018-01-23) Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-05-29diff: ignore --ita-[in]visible-in-index when diffing worktree-to-treeNguyễn Thái Ngọc Duy
This option is supposed to fix the diff of "diff-files" (not reporting ita entries as new files) and "diff-index --cached <tree>" (showing ita entries as present in the index with empty content) but not "diff-index <tree>". When --ita-invisible-in-index is set on "git diff-index <tree>", unpack_trees() will eventually call oneway_diff() on the ita entry with the same code flow as "diff-index --cached <tree>". We want to ignore the ita entry for "diff-index --cached <tree>" but not "diff-index <tree>" since the latter will examine and produce a diff based on worktree entry's (real) content, not ita index entry's (empty) content. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-05-14t2203: abstract away SHA-1-specific constantsbrian m. carlson
Adjust the test so that it computes variables for blobs instead of using hard-coded hashes. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2018-05-14t: switch $_z40 to $ZERO_OIDbrian m. carlson
Switch all uses of $_z40 to $ZERO_OID so that they work correctly with larger hashes. This commit was created by using the following sed command to modify all files in the t directory except t/ sed -i 's/\$_z40/$ZERO_OID/g' Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2018-01-23Merge branch 'nd/ita-wt-renames-in-status'Junio C Hamano
"git status" after moving a path in the working tree (hence making it appear "removed") and then adding with the -N option (hence making that appear "added") detected it as a rename, but did not report the old and new pathnames correctly. * nd/ita-wt-renames-in-status: wt-status.c: handle worktree renames wt-status.c: rename rename-related fields in wt_status_change_data wt-status.c: catch unhandled diff status codes wt-status.c: coding style fix Use DIFF_DETECT_RENAME for detect_rename assignments t2203: test status output with porcelain v2 format
2017-12-27wt-status.c: handle worktree renamesNguyễn Thái Ngọc Duy
Before 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist in index" - 2016-10-24) there are never "new files" in the index, which essentially disables rename detection because we only detect renames when a new file appears in a diff pair. After that commit, an i-t-a entry can appear as a new file in "git diff-files". But the diff callback function in wt-status.c does not handle this case and produces incorrect status output. PS. The reader may notice that this patch adds a new xstrdup() but not a free(). Yes we leak memory (the same for head_path). But wt_status so far has been short lived, this leak should not matter in practice. Noticed-by: Alex Vandiver <> Helped-by: Igor Djordjevic <> Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2017-12-27t2203: test status output with porcelain v2 formatNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2017-06-27Spelling fixesVille Skyttä
Signed-off-by: Ville Skyttä <> Signed-off-by: Junio C Hamano <>
2016-10-24commit: don't be fooled by ita entries when creating initial commitNguyễn Thái Ngọc Duy
ita entries are dropped at tree generation phase. If the entire index consists of just ita entries, the result would be a a commit with no entries, which should be caught unless --allow-empty is specified. The test "!!active_nr" is not sufficient to catch this. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2016-10-24commit: fix empty commit creation when there's no changes but ita entriesNguyễn Thái Ngọc Duy
If i-t-a entries are present and there is no change between the index and HEAD i-t-a entries, index_differs_from() still returns "dirty, new entries" (aka, the resulting commit is not empty), but cache-tree will skip i-t-a entries and produce the exact same tree of current commit. index_differs_from() is supposed to catch this so we can abort git-commit (unless --no-empty is specified). Update it to optionally ignore i-t-a entries when doing a diff between the index and HEAD so that it would return "no change" in this case and abort commit. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2016-10-24diff: add --ita-[in]visible-in-indexNguyễn Thái Ngọc Duy
The option --ita-invisible-in-index exposes the "ita_invisible_in_index" diff flag to outside to allow easier experimentation with this new mode. The "plan" is to make --ita-invisible-in-index default to keep consistent behavior with 'status' and 'commit', but a bunch other commands like 'apply', 'merge', 'reset'.... need to be taken into consideration as well. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2016-10-24diff-lib: allow ita entries treated as "not yet exist in index"Nguyễn Thái Ngọc Duy
When comparing the index and the working tree to show which paths are new, and comparing the tree recorded in the HEAD and the index to see if committing the contents recorded in the index would result in an empty commit, we would want the former comparison to say "these are new paths" and the latter to say "there is no change" for paths that are marked as intent-to-add. We made a similar attempt at d95d728a ("diff-lib.c: adjust position of i-t-a entries in diff", 2015-03-16), which redefined the semantics of these two comparison modes globally, which was a disaster and had to be reverted at 78cc1a54 ("Revert "diff-lib.c: adjust position of i-t-a entries in diff"", 2015-06-23). To make sure we do not repeat the same mistake, introduce a new internal diffopt option so that this different semantics can be asked for only by callers that ask it, while making sure other unaudited callers will get the same comparison result. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2016-07-18cache-tree: do not generate empty trees as a result of all i-t-a subentriesNguyễn Thái Ngọc Duy
If a subdirectory contains nothing but i-t-a entries, we generate an empty tree object and add it to its parent tree. Which is wrong. Such a subdirectory should not be added. Note that this has a cascading effect. If subdir 'a/b/c' contains nothing but i-t-a entries, we ignore it. But then if 'a/b' contains only (the non-existing) 'a/b/c', then we should ignore 'a/b' while building 'a' too. And it goes all the way up to top directory. Noticed-by: Junio C Hamano <> Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2016-07-18cache-tree.c: fix i-t-a entry skipping directory updates sometimesNguyễn Thái Ngọc Duy
Commit 3cf773e (cache-tree: fix writing cache-tree when CE_REMOVE is present - 2012-12-16) skips i-t-a entries when building trees objects from the index. Unfortunately it may skip too much. The code in question checks if an entry is an i-t-a one, then no tree entry will be written. But it does not take into account that directories can also be written with the same code. Suppose we have this in the index. a-file subdir/file1 subdir/file2 subdir/file3 the-last-file We write an entry for a-file as normal and move on to subdir/file1, where we realize the entry name for this level is simply just "subdir", write down an entry for "subdir" then jump three items ahead to the-last-file. That is what happens normally when the first file in subdir is not an i-t-a entry. If subdir/file1 is an i-t-a, because of the broken condition in this code, we still think "subdir" is an i-t-a file and not writing "subdir" down and jump to the-last-file. The result tree now only has two items: a-file and the-last-file. subdir should be there too (even though it only records two sub-entries, file2 and file3). If the i-t-a entry is subdir/file2 or subdir/file3, this is not a problem because we jump over them anyway. Which may explain why the bug is hidden for nearly four years. Fix it by making sure we only skip i-t-a entries when the entry in question is actual an index entry, not a directory. Reported-by: Yuri Kanivetsky <> Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2015-06-23Revert "diff-lib.c: adjust position of i-t-a entries in diff"Junio C Hamano
This reverts commit d95d728aba06a34394d15466045cbdabdada58a2. It turns out that many other commands that need to interact with the result of running diff-files and diff-index, e.g. "git apply", "git rm", etc., need to be adjusted to the new world order it brings in. For example, it would break this sequence to correct a whitespace breakage in the parts you changed: git add -N file git diff --cached file | git apply --cached --whitespace=fix git checkout file In the old world order, "diff" showed a patch to modify an existing empty file by adding its full contents, and "apply" updated the index by modifying the existing empty blob (which is what an Intent-to-Add entry records in the index) with that patch. In the new world order, "diff" shows a patch to create a new file with its full contents, but because "apply" thinks that the i-t-a entry already exists in the index, it refused to accept a creation. Adjusting "apply" to this new world order is easy, but we need to assess the extent of the damage to the rest of the system the new world order brought in before going forward and adjust them all, after which we can resurrect the commit being reverted here. Signed-off-by: Junio C Hamano <>
2015-03-23diff-lib.c: adjust position of i-t-a entries in diffNguyễn Thái Ngọc Duy
Entries added by "git add -N" are reminder for the user so that they don't forget to add them before committing. These entries appear in the index even though they are not real. Their presence in the index leads to a confusing "git status" like this: On branch master Changes to be committed: new file: foo Changes not staged for commit: modified: foo If you do a "git commit", "foo" will not be included even though "status" reports it as "to be committed". This patch changes the output to become On branch master Changes not staged for commit: new file: foo no changes added to commit The two hunks in diff-lib.c adjust "diff-index" and "diff-files" so that i-t-a entries appear as new files in diff-files and nothing in diff-index. Due to this change, diff-files may start to report "new files" for the first time. "add -u" needs to be told about this or it will die in denial, screaming "new files can't exist! Reality is wrong." Luckily, it's the only one among run_diff_files() callers that needs fixing. Now in the new world order, a hierarchy in the index that contain i-t-a paths is written out as a tree object as if these i-t-a entries do not exist, and comparing the index with such a tree object that would result from writing out the hierarchy will result in no difference. Update a test in t2203 that expected the i-t-a entries to appear as "added to the index" in the comparison to instead expect no output. An earlier change eec3e7e4 (cache-tree: invalidate i-t-a paths after generating trees, 2012-12-16) becomes an unnecessary pessimization in the new world order---a cache-tree in the index that corresponds to a hierarchy with i-t-a paths can now be marked as valid and record the object name of the tree that results from writing a tree object out of that hierarchy, as it will compare equal to that tree. Reverting the commit is left for the future, though, as it is purely a performance issue and no longer affects correctness. Helped-by: Michael J Gruber <> Helped-by: Junio C Hamano <> Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2012-12-16cache-tree: invalidate i-t-a paths after generating treesNguyễn Thái Ngọc Duy
Intent-to-add entries used to forbid writing trees so it was not a problem. After commit 3f6d56d (commit: ignore intent-to-add entries instead of refusing - 2012-02-07), we can generate trees from an index with i-t-a entries. However, the commit forgets to invalidate all paths leading to i-t-a entries. With fully valid cache-tree (e.g. after commit or write-tree), diff operations may prefer cache-tree to index and not see i-t-a entries in the index, because cache-tree does not have them. Reported-by: Jonathon Mah <> Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2012-02-07commit: ignore intent-to-add entries instead of refusingJunio C Hamano
Originally, "git add -N" was introduced to help users from forgetting to add new files to the index before they ran "git commit -a". As an attempt to help them further so that they do not forget to say "-a", "git commit" to commit the index as-is was taught to error out, reminding the user that they may have forgotten to add the final contents of the paths before running the command. This turned out to be a false "safety" that is useless. If the user made changes to already tracked paths and paths added with "git add -N", and then ran "git add" to register the final contents of the paths added with "git add -N", "git commit" will happily create a commit out of the index, without including the local changes made to the already tracked paths. It was not a useful "safety" measure to prevent "forgetful" mistakes from happening. It turns out that this behaviour is not just a useless false "safety", but actively hurts use cases of "git add -N" that were discovered later and have become popular, namely, to tell Git to be aware of these paths added by "git add -N", so that commands like "git status" and "git diff" would include them in their output, even though the user is not interested in including them in the next commit they are going to make. Fix this ancient UI mistake, and instead make a commit from the index ignoring the paths added by "git add -N" without adding real contents. Based on the work by Nguyễn Thái Ngọc Duy, and helped by injection of sanity from Jonathan Nieder and others on the Git mailing list. Signed-off-by: Junio C Hamano <>
2012-01-11t2203: fix wrong commit commandNguyễn Thái Ngọc Duy
Add commit message to avoid commit's aborting due to the lack of commit message, not because there are INTENT_TO_ADD entries in index. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2008-12-01git add --intent-to-add: do not let an empty blob be committed by accidentJunio C Hamano
Writing a tree out of an index with an "intent to add" entry is blocked. This implies that you cannot "git commit" from such a state; however you can still do "git commit -a" or "git commit $that_path". Signed-off-by: Junio C Hamano <>
2008-08-31git-add --intent-to-add (-N)Junio C Hamano
This adds "--intent-to-add" option to "git add". This is to let the system know that you will tell it the final contents to be staged later, iow, just be aware of the presense of the path with the type of the blob for now. It is implemented by staging an empty blob as the content. With this sequence: $ git reset --hard $ edit newfile $ git add -N newfile $ edit newfile oldfile $ git diff the diff will show all changes relative to the current commit. Then you can do: $ git commit -a ;# commit everything or $ git commit oldfile ;# only oldfile, newfile not yet added to pretend you are working with an index-free system like CVS. Signed-off-by: Junio C Hamano <>