kernel/git - git - PowerEL Git System

Tree: 980419b993

Author	SHA1	Message	Date
Junio C Hamano	9aeaab6811	blame: allow "blame file" in the middle of a conflicted merge "git blame file" has always meant "find the origin of each line of the file in the history leading to HEAD, oh by the way, blame the lines that are modified locally to the working tree". This teaches "git blame" that during a conflicted merge, some uncommitted changes may have come from the other history that is being merged. The verify_working_tree_path() function introduced in the previous patch to notice a typo in the filename (primarily on case insensitive filesystems) has been updated to allow a filename that does not exist in HEAD (i.e. the tip of our history) as long as it exists one of the commits being merged, so that a "we deleted, the other side modified" case tracks the history of the file in the history of the other side. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	ffcabccf5d	blame $path: avoid getting fooled by case insensitive filesystems "git blame MAKEFILE" run in a history that has "Makefile" but not MAKEFILE can get confused on a case insensitive filesystem, because the check we run to see if there is a corresponding file in the working tree with lstat("MAKEFILE") succeeds. In addition to that check, we have to make sure that the given path also exists in the commit we start digging history from (i.e. "HEAD"). Note that this reveals the breakage in a test added in `cd8ae20` (git-blame shouldn't crash if run in an unmerged tree, 2007-10-18), which expects the entire merge-in-progress path to be blamed to the working tree when it did not exist in our tree. As it is clear in the log message of that commit, the old breakage was that it was causing an internal error and the fix was about avoiding it. Just check that the command does not die an uncontrolled death. For this particular case, the blame should fail, as the history for the file in that contents has not been committed yet at the point in the test. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Michael J Gruber	0137ef7dae	t800?-blame.sh: retitle uniquely Currently we have three test files matching t800?-blame.sh. Rename the latter two to make it easier to spot where additions would go. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Linus Torvalds	cd8ae20195	git-blame shouldn't crash if run in an unmerged tree If we are in the middle of resolving a merge conflict there may be one or more files whose entries in the index represent an unmerged state (index entries in the higher-order stages). Attempting to run git-blame on any file in such a working directory resulted in "fatal: internal error: ce_mode is 0" as we use the magic marker for an unmerged entry is 0 (set up by things like diff-lib.c's do_diff_cache() and builtin-read-tree.c's read_tree_unmerged()) and the ce_match_stat_basic() function gets upset about this. I'm not entirely sure that the whole "ce_mode = 0" case is a good idea to begin with, and maybe the right thing to do is to remove that horrid freakish special case, but removing the internal error seems to be the simplest fix for now. Linus [sp: Thanks to Björn Steinbrink for the test case] Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago