kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
René Scharfe	baf0a3e47d	wt-status: avoid building bogus branch name with detached HEAD If we're on a detached HEAD then wt_shortstatus_print_tracking() takes the string "HEAD (no branch)", translates it, skips the first eleven characters and passes the result to branch_get(), which returns a bogus result and accesses memory out of bounds in order to produce it. Somehow stat_tracking_info(), which is passed that result, does the right thing anyway, i.e. it finds that there is no base. Avoid the bogus results and memory accesses by checking for HEAD first and exiting early in that case. This fixes t7060 with --valgrind. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
René Scharfe	7ca8c18950	t7060: add test for status --branch on a detached HEAD This test fails when run under Valgrind because branch_get() gets passed a bogus branch name pointer: ==62831== Invalid read of size 1 ==62831== at 0x4F76AE: branch_get (remote.c:1650) ==62831== by 0x53499E: wt_shortstatus_print_tracking (wt-status.c:1654) ==62831== by 0x53499E: wt_shortstatus_print (wt-status.c:1706) ==62831== by 0x428D29: cmd_status (commit.c:1384) ==62831== by 0x405D6D: run_builtin (git.c:350) ==62831== by 0x405D6D: handle_builtin (git.c:536) ==62831== by 0x404F10: run_argv (git.c:582) ==62831== by 0x404F10: main (git.c:690) ==62831== Address 0x5e89b0b is 6 bytes after a block of size 5 alloc'd ==62831== at 0x4C28C4F: malloc (vg_replace_malloc.c:299) ==62831== by 0x59579E9: strdup (strdup.c:42) ==62831== by 0x52E108: xstrdup (wrapper.c:43) ==62831== by 0x5322A6: wt_status_prepare (wt-status.c:130) ==62831== by 0x4276E0: status_init_config (commit.c:184) ==62831== by 0x428BB8: cmd_status (commit.c:1350) ==62831== by 0x405D6D: run_builtin (git.c:350) ==62831== by 0x405D6D: handle_builtin (git.c:536) ==62831== by 0x404F10: run_argv (git.c:582) ==62831== by 0x404F10: main (git.c:690) Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Matthieu Prat	b894d3e788	t7060: actually test "git diff-index --cached -M" A test was designed for "git diff-index --cached -M" but the command is run without the "-M" option (which makes the test essentially identical to its preceding counterpart). Signed-off-by: Matthieu Prat <matthieuprat@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Junio C Hamano	c7cb333f60	wt-status: lift the artificual "at least 20 columns" floor When we show unmerged paths, we had an artificial 20 columns floor for the width of labels (e.g. "both deleted:") shown next to the pathnames. Depending on the locale, this may result in a label that is too wide when all the label strings are way shorter than 20 columns, or no-op when a label string is longer than 20 columns. Just drop the artificial floor. The screen real estate is better utilized this way when all the strings are shorter. Adjust the tests to this change. Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
Matthieu Moy	2556b9962e	status: disable display of '#' comment prefix by default Historically, "git status" needed to prefix each output line with '#' so that the output could be added as comment to the commit message. This prefix comment has no real purpose when "git status" is ran from the command-line, and this may distract users from the real content. Disable this prefix comment by default, and make it re-activable for users needing backward compatibility with status.displayCommentPrefix. Obviously, "git commit" ignores status.displayCommentPrefix and keeps the comment unconditionnaly when writing to COMMIT_EDITMSG (but not when writing to stdout for an error message or with --dry-run). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Matthieu Moy	1c7969c933	tests: don't set status.displayCommentPrefix file-wide The previous commit set status.displayCommentPrefix file-wide in t7060-wtstatus.sh, t7508-status.sh and t/t7512-status-help.sh to make the patch small. However, now that status.displayCommentPrefix is not the default, it is better to disable it in tests so that the most common situation is also the most tested. While we're there, move the "cat > expect << EOF" blocks inside the tests. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Nguyễn Thái Ngọc Duy	6a38ef2ced	status: advise to consider use of -u when read_directory takes too long Introduce advice.statusUoption to suggest considering use of -u to strike different trade-off when it took more than 2 seconds to enumerate untracked/ignored files. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Lucien Kong	96b0ec1a4c	status: don't suggest "git rm" or "git add" if not appropriate The display of the advice '(use git add/rm [...])' (when there are unmerged files) after running 'git status' is now depending of the mark, whether it's 'both deleted', 'deleted by us/them' or others. For instance, when there is just one file that's marked as 'both deleted', 'git status' shows '(use git rm [...])' and if there are two files, one as 'both deleted' and the other as 'added by them', the advice is '(use git add/rm [...])'. The previous tests in t7512-status-help.sh are updated. Test about the case of only 'both deleted' is added in t7060-wtstatus.sh Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Lucien Kong	83c750acde	wt-status.*: better advices for git status added This patch provides new informative help messages in the display of 'git status' (at the top) during conflicts, rebase, am, bisect or cherry-pick process. The new messages are not shown when using options such as -s or --porcelain. The messages about the current situation of the user are always displayed but the advices on what the user needs to do in order to resume a rebase/bisect/am/commit after resolving conflicts can be hidden by setting advice.statushints to 'false' in the config file. Thus, information about the updated advice.statushints key are added in Documentation/config.txt. Also, the test t7060-wt-status.sh is now working with the new help messages. Tests about suggestions of "git rm" are also added. Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	b3e1900a74	i18n: use test_i18ncmp and test_i18ngrep in t5541, t6040, t6120, t7004, t7012 and t7060 Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Martin von Zweigbergk	d7c9bf2235	diffcore-rename: don't consider unmerged path as source Since `e9c8409` (diff-index --cached --raw: show tree entry on the LHS for unmerged entries., 2007-01-05), an unmerged entry should be detected by using DIFF_PAIR_UNMERGED(p), not by noticing both one and two sides of the filepair records mode=0 entries. However, it forgot to update some parts of the rename detection logic. This only makes difference in the "diff --cached" codepath where an unmerged filepair carries information on the entries that came from the tree. It probably hasn't been noticed for a long time because nobody would run "diff -M" during a conflict resolution, but "git status" uses rename detection when it internally runs "diff-index" and "diff-files" and gives nonsense results. In an unmerged pair, "one" side can have a valid filespec to record the tree entry (e.g. what's in HEAD) when running "diff --cached". This can be used as a rename source to other paths in the index that are not unmerged. The path that is unmerged by definition does not have the final content yet (i.e. "two" side cannot have a valid filespec), so it can never be a rename destination. Use the DIFF_PAIR_UNMERGED() to detect unmerged filepair correctly, and allow the valid "one" side of an unmerged filepair to be considered a potential rename source, but never to be considered a rename destination. Commit message and first two test cases by Junio, the rest by Martin. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Ævar Arnfjörð Bjarmason	355ec7a130	i18n: git-status basic messages Gettextize the most common git-status messages. Many tests checked for these explicitly. Change them to skip under GETTEXT_POISON=YesPlease. Some of the tests in t7508-status.sh needed to be split up when I added C_LOCALE_OUTPUT to them, since parts of them affected later tests (some of which aren't being skipped) indirectly. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Junio C Hamano	3c58845365	status/commit: do not suggest "reset HEAD <path>" while merging Suggesting "'reset HEAD <path>' to unstage" is dead wrong if we are about to record a merge commit. For either an unmerged path (i.e. with unresolved conflicts), or an updated path, it would result in discarding what the other branch did. Note that we do not do anything special in a case where we are amending a merge. The user is making an evil merge starting from an already committed merge, and running "reset HEAD <path>" is the right way to get rid of the local edit that has been added to the index. Once "reset --unresolve <path>" becomes available, we might want to suggest it for a merged path that has unresolve information, but until then, just remove the incorrect advice. We might also want to suggest "checkout --conflict <path>" to revert the file in the work tree to the state of failed automerge for an unmerged path, but we never did that, and this commit does not change that. Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Junio C Hamano	dd20f8af1a	commit/status: "git add <path>" is not necessarily how to resolve When the desired resolution is to remove the path, "git rm <path>" is the command the user needs to use. Just like in "Changed but not updated" section, suggest to use "git add/rm" as appropriate. Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Junio C Hamano	9e4b7ab652	git status: not "commit --dry-run" anymore This removes tentative "git stat" and make it take over "git status". There are some tests that expect "git status" to exit with non-zero status when there is something staged. Some tests expect "git status path..." to show the status for a partial commit. For these, replace "git status" with "git commit --dry-run". For the ones that do not attempt a dry-run of a partial commit that check the output from the command, check the output from "git status" as well, as they should be identical. Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Junio C Hamano	4d4d5726ae	status: show worktree status of conflicted paths separately When a path is unmerged in the index, we used to always say "unmerged" in the "Changed but not updated" section, even when the path was deleted in the work tree. Remove unmerged entries from the "Updated" section, and create a new section "Unmerged paths". Describe how the different stages conflict in more detail in this new section. Note that with the current 3-way merge policy (with or without recursive), certain combinations of index stages should never happen. For example, having only stage #2 means that a path that did not exist in the common ancestor was added by us while the other branch did not do anything to it, which would have autoresolved to take our addition. The code nevertheless prepares for the possibility that future merge policies may leave a path in such a state. Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Junio C Hamano	29796c6ccf	diff-index: report unmerged new entries Since an earlier change to diff-index by `d1f2d7e` (Make run_diff_index() use unpack_trees(), not read_tree(), 2008-01-19), we stopped reporting an unmerged path that does not exist in the tree, but we should. Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago

21 Commits (70af7662d47ac9f450c248720a379a8db817163b)