summaryrefslogtreecommitdiff
path: root/t/t1004-read-tree-m-u-wf.sh
AgeCommit message (Collapse)AuthorFilesLines
2008-03-18Fix read-tree not to discard errorsLibravatar Junio C Hamano1-1/+1
This fixes the issue identified with recently added tests to t1004 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-18Add tests to catch problems with un-unlinkable symlinksLibravatar Junio C Hamano1-0/+35
This currently fails not because we refuse to check out, but because we detect error but incorrectly discard it in the callchain. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-18git-merge-one-file: fix longstanding stupid thinkoLibravatar Junio C Hamano1-0/+46
When a merge result creates a new file, and when our side already has a file in the path, taking the merge result may clobber the untracked file. However, the logic to detect this situation was totally the wrong way. We should complain when the file exists, not when the file does not exist. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-16Don't update unchanged merge entriesLibravatar Linus Torvalds1-0/+41
In commit 34110cd4e394e3f92c01a4709689b384c34645d8 ("Make 'unpack_trees()' have a separate source and destination index") I introduced a really stupid bug in that it would always add merged entries with the CE_UPDATE flag set. That caused us to always re-write the file, even when it was already up-to-date in the source index. Not only is that really stupid from a performance angle, but more importantly it's actively wrong: if we have dirty state in the tree when we merge, overwriting it with the result of the merge will incorrectly overwrite that dirty state. This trivially fixes the problem - simply don't set the CE_UPDATE flag when the merge result matches the old state. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-1/+1
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-02-03Assorted typo fixesLibravatar Pavel Roskin1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-05read-tree: further loosen "working file will be lost" check.Libravatar Junio C Hamano1-8/+74
This follows up commit ed93b449 where we removed overcautious "working file will be lost" check. A new option "--exclude-per-directory=.gitignore" can be used to tell the "git-read-tree" command that the user does not mind losing contents in untracked files in the working tree, if they need to be overwritten by a merge (either a two-way "switch branches" merge, or a three-way merge). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-27merge: loosen overcautious "working file will be lost" check.Libravatar Junio C Hamano1-0/+53
The three-way merge complained unconditionally when a path that does not exist in the index is involved in a merge when it existed in the working tree. If we are merging an old version that had that path tracked, but the path is not tracked anymore, and if we are merging that old version in, the result will be that the path is not tracked. In that case we should not complain. Signed-off-by: Junio C Hamano <junkio@cox.net>