kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
René Scharfe	f670adb49b	t3501: don't create unused file The file "out" became unused with `fd53b7ffd1` (merge-recursive: improve add_cacheinfo error handling, 2018-04-19); get rid of it. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Denton Liu	2c9e125b27	t: teach test_cmp_rev to accept ! for not-equals In the case where we are using test_cmp_rev() to report not-equals, we write `! test_cmp_rev`. However, since test_cmp_rev() contains r1=$(git rev-parse --verify "$1") && r2=$(git rev-parse --verify "$2") && `! test_cmp_rev` will succeed if any of the rev-parses fail. This behavior is not desired. We want the rev-parses to _always_ be successful. Rewrite test_cmp_rev() to optionally accept "!" as the first argument to do a not-equals comparison. Rewrite `! test_cmp_rev` to `test_cmp_rev !` in all tests to take advantage of this new functionality. Also, rewrite the rev-parse logic to end with a `\|\| return 1` instead of &&-chaining into the rev-comparison logic. This makes it obvious to future readers that we explicitly intend on returning early if either of the rev-parses fail. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Elijah Newren	2f682e21a6	merge-recursive: avoid triggering add_cacheinfo error with dirty mod If a cherry-pick or merge with a rename results in a skippable update (due to the merged content matching what HEAD already had), but the working directory is dirty, avoid trying to refresh the index as that will fail. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Elijah Newren	fd53b7ffd1	merge-recursive: improve add_cacheinfo error handling Four closely related changes all with the purpose of fixing error handling in this function: - fix reported function name in add_cacheinfo error messages - differentiate between the two error messages - abort early when we hit the error (stop ignoring return code) - mark a test which was hitting this error as failing until we get the right fix In more detail... In commit `0424138d57` ("Fix bogus error message from merge-recursive error path", 2007-04-01), it was noted that the name of the function which the error message claimed it was reported from did not match the actual function name. This was changed to something closer to the real function name, but it still didn't match the actual function name. Fix the reported name to match. Second, the two errors in this function had identical messages, preventing us from knowing which error had been triggered. Add a couple words to the second error message to differentiate the two. Next, make sure callers do not ignore the return code so that it will stop processing further entries (processing further entries could result in more output which could cause the error to scroll off the screen, or at least be missed by the user) and make it clear the error is the cause of the early abort. These errors should never be triggered in production; if either one is, it represents a bug in the calling path somewhere and is likely to have resulted in mis-merged content. The combination of ignoring of the return code and continuing to print other standard messages after hitting the error resulted in the following bug report from Junio: "...the command pretends that everything went well and merged cleanly in that path...[Behaving] in a buggy and unexplainable way is bad enough, doing so silently is unexcusable." Fix this. Finally, there was one test in the testsuite that did hit this error path, but was passing anyway. This would have been easy to miss since it had a test_must_fail and thus could have failed for the wrong reason, but in a separate testing step I added an intentional NULL-dereference to the codepath where these error messages are printed in order to flush out such cases. I could modify that test to explicitly check for this error and fail the test if it is hit, but since this test operates in a bit of a gray area and needed other changes, I went for a different fix. The gray area this test operates in is the following: If the merge of a certain file results in the same version of the file that existed in HEAD, but there are dirty modifications to the file, is that an error with a "Refusing to overwrite existing file" expected, or a case where the merge should succeed since we shouldn't have to touch the dirty file anyway? Recent discussion on the list leaned towards saying it should be a success. Therefore, change the expected behavior of this test to match. As a side effect, this makes the failed-due-to-hitting-add_cacheinfo-error very clear, and we can mark the test as test_expect_failure. A subsequent commit will implement the necessary changes to get this test to pass again. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Elijah Newren	64b1abe962	merge-recursive: fix overwriting dirty files involved in renames This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of dirty files that are involved in directory rename detection will be added in a subsequent commit. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Junio C Hamano	8b026edac3	Revert "Merge branch 'en/rename-directory-detection'" This reverts commit `e4bb62fa1e`, reversing changes made to `468165c1d8`. The topic appears to inflict severe regression in renaming merges, even though the promise of it was that it would improve them. We do not yet know which exact change in the topic was wrong, but in the meantime, let's play it safe and revert it out of 'master' before real Git-using projects are harmed. Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Nguyễn Thái Ngọc Duy	0e496492d2	t/helper: merge test-chmtime into test-tool Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Elijah Newren	e0052f4613	merge-recursive: fix overwriting dirty files involved in renames This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of dirty files that are involved in directory rename detection will be added in a subsequent commit. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Elijah Newren	7c5585ff48	Tighten and correct a few testcases for merging and cherry-picking t3501 had a testcase originally added in `05f2dfb965` (cherry-pick: demonstrate a segmentation fault, 2016-11-26) to ensure cherry-pick wouldn't segfault when working with a dirty file involved in a rename. While the segfault was fixed, there was another problem this test demonstrated: namely, that git would overwrite a dirty file involved in a rename. Further, the test encoded a "successful merge" and overwriting of this file as correct behavior. Modify the test so that it would still catch the segfault, but to require the correct behavior. Mark it as test_expect_failure for now too, since this second bug is not yet fixed. t7607 had a test added in `30fd3a5425` (merge overwrites unstaged changes in renamed file, 2012-04-15) specific to looking for a merge overwriting a dirty file involved in a rename, but it too actually encoded what I would term incorrect behavior: it expected the merge to succeed. Fix that, and add a few more checks to make sure that the merge really does produce the expected results. Reviewed-By: Stefan Beller <sbeller@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Johannes Schindelin	55e9f0e5c9	merge-recursive: handle NULL in add_cacheinfo() correctly `1335d76e45` ("merge: avoid "safer crlf" during recording of merge results", 2016-07-08) tried to split make_cache_entry() call made with CE_MATCH_REFRESH into a call to make_cache_entry() without one, followed by a call to add_cache_entry(), refresh_cache() and another add_cache_entry() as needed. However the conversion was botched in that it forgot that refresh_cache() can return NULL, which was handled correctly in make_cache_entry() but in the updated code. This fixes https://github.com/git-for-windows/git/issues/952 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Johannes Schindelin	05f2dfb965	cherry-pick: demonstrate a segmentation fault In https://github.com/git-for-windows/git/issues/952, a complicated scenario was described that leads to a segmentation fault in cherry-pick. It boils down to a certain code path involving a renamed file that is dirty, for which `refresh_cache_entry()` returns `NULL`, and that `NULL` not being handled properly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Johannes Schindelin	93b3df6f14	sequencer: start error messages consistently with lower case Quite a few error messages touched by this developer during the work to speed up rebase -i started with an upper case letter, violating our current conventions. Instead of sneaking in this fix (and forgetting quite a few error messages), let's just have one wholesale patch fixing all of the error messages in the sequencer. While at it, the funny "error: Error wrapping up..." was changed to a less funny, but more helpful, "error: failed to finalize...". Pointed out by Junio Hamano. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Jeff King	d644c5502f	cherry-pick: handle "-" after parsing options Currently, we only try converting argv[1] from "-" into "@{-1}". This means we do not notice "-" when used together with an option. Worse, when "git cherry-pick" is run with no options, we segfault. Fix this by doing the substitution after we have checked that there is something in argv to cherry-pick and know any remaining options are meant for the revision-listing machinery. This still does not handle "-" after the first non-cherry-pick option. For example, git cherry-pick foo~2 - bar~5 and git cherry-pick --no-merges - will still dump usage. Reported-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>	12 years ago
Hiroshige Umino	182d7dc46b	cherry-pick: allow "-" as abbreviation of '@{-1}' "-" abbreviation is handy for "cherry-pick" like "checkout" and "merge". It's also good for uniformity that a "-" stands as the name of the previous branch where a branch name is accepted and it could not mean any other things like stdin. Signed-off-by: Hiroshige Umino <hiroshige88@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Junio C Hamano	7a96c3864e	typofix: cherry is spelled with two ars Do not say chery; it is spelled cherry. Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Martin von Zweigbergk	334ae39745	learn to pick/revert into unborn branch cherry-picking into an unborn branch should work, so make it work, with or without --ff. Cherry-picking anything other than a commit that only adds files, will naturally result in conflicts. Similarly, revert also works, but will result in conflicts unless the specified revision only deletes files. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Jiang Xin	9a0013819e	Fix tests under GETTEXT_POISON on parseopt Use the i18n-specific test functions in test scripts for parseopt tests. This issue was was introduced in v1.7.10.1-488-g54e6d: 54e6d i18n: parseopt: lookup help and argument translations when showing usage and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	fff1bb3a34	i18n: use test_i18ncmp and test_i18ngrep in t3203, t3501 and t3507 Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Ævar Arnfjörð Bjarmason	d3ee177e50	i18n: git-revert "Your local changes" message Translate the "Your local changes [...]" message without using the `me' variable, instead split up the two messages so translators can translate the whole messages as-is. Reported-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Jonathan Nieder	f6ce1f2588	cherry-pick/revert: transparently refresh index A stat-dirty index is not a detail that ought to concern the operator of porcelain such as "git cherry-pick". Without this change, a cherry-pick after copying a worktree with rsync errors out with a misleading message. $ git cherry-pick build/top error: Your local changes to 'file.h' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Noticed-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jonathan Nieder	e0ef8495e9	revert: do not rebuild argv on heap Set options in struct rev_info directly so we can reuse the arguments collected from parse_options without modification. This is just a cleanup; no noticeable change is intended. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Christian Couder	643cb5f7c9	commit: use value of GIT_REFLOG_ACTION env variable as reflog message The environment variable GIT_REFLOG_ACTION was used by git-commit.sh, but when it was converted to a builtin (`f5bbc3225c`, Port git commit to C, Nov 8 2007) this was lost. Let's use it again as it is more user friendly when reverting or cherry-picking to see "revert" or "cherry-pick" in the reflog rather than to just see "commit". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Matthieu Moy	d38a30df7d	Be more user-friendly when refusing to do something because of conflict. Various commands refuse to run in the presence of conflicts (commit, merge, pull, cherry-pick/revert). They all used to provide rough, and inconsistant error messages. A new variable advice.resolveconflict is introduced, and allows more verbose messages, pointing the user to the appropriate solution. For commit, the error message used to look like this: $ git commit foo.txt: needs merge foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169) foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030) foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4) error: Error building trees The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN option to make the output more consistant with the other porcelain commands, and catch the error in return, to stop with a clean error message. The next lines were displayed by a call to cache_tree_update(), which is not reached anymore if we noticed the conflict. The new output looks like: U foo.txt fatal: 'commit' is not possible because you have unmerged files. Please, fix them up in the work tree, and then use 'git add/rm <file>' as appropriate to mark resolution and make a commit, or use 'git commit -a'. Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD exists instead of waiting for merge to complain. The behavior of merge and the test-case are slightly modified to reflect the usual flow: start with conflicts, fix them, and afterwards get rid of MERGE_HEAD, with different error messages at each stage. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Stephan Beyer	944019c8b3	t3501: check that commits are actually done The basic idea of t3501 is to check whether revert and cherry-pick works on renamed files. But as there is no pure cherry-pick/revert test, it is good to also check if commits are actually done in that scenario. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Jeff King	0f2d4476c1	revert: actually check for a dirty index The previous code mistakenly used wt_status_prepare to check whether the index had anything commitable in it; however, that function is just an init function, and will never report a dirty index. The correct way with wt_status_* would be to call wt_status_print with the output pointing to /dev/null or similar. However, that does extra work by both examining the working tree and spewing status information to nowhere. Instead, let's just implement the useful subset of wt_status_print as an "is_index_dirty" function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Kristian Høgsberg	9e54dc6c12	Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test suites. They are already set and exoprted by sourcing ./test-lib.sh in all test scripts. Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	acb4441e0d	Use merge-recursive in git-revert/git-cherry-pick This makes revert and cherry-pick to use merge-recursive, to allow them to notice renames. A pair of test scripts demonstrate that an old change before a rename happened can be applied (reverted) after a rename with cherry-pick (with revert). Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago

33 Commits (1ac83f42da6437d74098f162fcfa37474c94e223)