* Merge with local conflicts in new files
@ 2006-05-16 22:00 Santi
2006-05-16 22:12 ` Santi
2006-05-16 22:40 ` Junio C Hamano
0 siblings, 2 replies; 10+ messages in thread
From: Santi @ 2006-05-16 22:00 UTC (permalink / raw)
To: git, Junio C Hamano
Hi *,
In the case of:
- You merge from a branch with new files
- You have these files in the working directory
- You do not have these files in the HEAD.
The end result is that you lose the content of these files.
So an additional check for the merge is to check for these dirty
but not in HEAD files.
Here is a test that reproduce it. I expect the merge to fail and
with the content of foo being bar.
test_description='Test merge with local conflicts in new files'
. ./test-lib.sh
test_expect_success 'prepare repository' \
'echo "Hello" > init &&
git add init &&
git commit -m "Initial commit" &&
git branch B &&
echo "foo" > foo &&
git add foo &&
git commit -m "File: foo" &&
git checkout B &&
echo "bar" > foo '
test_expect_code 1 'Merge with local conflicts in new files' 'git
merge "merge msg" B master'
test_done
Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Merge with local conflicts in new files 2006-05-16 22:00 Merge with local conflicts in new files Santi @ 2006-05-16 22:12 ` Santi 2006-05-16 22:40 ` Junio C Hamano 1 sibling, 0 replies; 10+ messages in thread From: Santi @ 2006-05-16 22:12 UTC (permalink / raw) To: git, Junio C Hamano Sorry, the test is wrong. Use this: test_description='Test merge with local conflicts in new files' . ./test-lib.sh test_expect_success 'prepare repository' \ 'echo "Hello" > init && git add init && git commit -m "Initial commit" && git checkout -b B && echo "foo" > foo && git add foo && git commit -m "File: foo" && git checkout master && echo "bar" > foo && ' test_expect_code 1 'Merge with local conflicts in new files' 'git merge "merge msg" HEAD B' test_done ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Merge with local conflicts in new files 2006-05-16 22:00 Merge with local conflicts in new files Santi 2006-05-16 22:12 ` Santi @ 2006-05-16 22:40 ` Junio C Hamano 2006-05-16 23:11 ` Santi 1 sibling, 1 reply; 10+ messages in thread From: Junio C Hamano @ 2006-05-16 22:40 UTC (permalink / raw) To: Santi; +Cc: git Santi <sbejar@gmail.com> writes: > In the case of: > > - You merge from a branch with new files > - You have these files in the working directory > - You do not have these files in the HEAD. and - You have not told git that these files matter. >... > test_expect_success 'prepare repository' \ > 'echo "Hello" > init && > git add init && > git commit -m "Initial commit" && > git branch B && > echo "foo" > foo && > git add foo && > git commit -m "File: foo" && > git checkout B && > echo "bar" > foo ' At this point, you have not told git that foo is a file that is relevant on branch B, so git considers it a fair game to overwrite. At least, that was the original reasoning. It happens not just during the ordinary "git-merge", by the way. If you are on branch B that did not have 'foo', created 'foo' and switched to branch A (which has 'foo') before telling the index that you care about your version of 'foo' on branch B, 'foo' from branch A will overwrite your throwaway copy in the working tree: $ git branch * master $ git branch another $ echo 'New file' >afile $ git add afile $ git commit -m 'Add afile' $ git checkout another $ ls afile ls: afile: No such file or directory $ echo 'Lost file' >afile $ git checkout master $ cat afile New file We acquired "git apply" which does take notice when you have such an untracked file in the working tree that conflicts with what it does to the index, and I think its behaviour sometimes is more user friendly and safer than what the merge does currently (but it irritates people some other times). This is totally untested, but on top of "next" you could do something like this, perhaps. We _might_ want to do this conditionally, only when the user asks, though. I dunno. Being able to blow away irrelevant files is sometimes a good thing, so we _might_ want to have a reverse logic to "git apply" that makes it blow away untracked working tree files under "--index" option. -- >8 -- diff --git a/read-tree.c b/read-tree.c index aa6172b..185a73f 100644 --- a/read-tree.c +++ b/read-tree.c @@ -453,8 +453,18 @@ static int merged_entry(struct cache_ent invalidate_ce_path(old); } } - else + else { + /* + * Originally we did not have a cache entry here but + * are creating a new file as a result of the merge. + * Do we want to lose the untracked working tree files? + */ + struct stat st; + + if (!lstat(merge->name, &st)) + die("Untracked working tree file '%s' would be overwritten by merge.", merge->name); invalidate_ce_path(merge); + } merge->ce_flags &= ~htons(CE_STAGEMASK); add_cache_entry(merge, ADD_CACHE_OK_TO_ADD); return 1; @@ -701,7 +711,7 @@ static int bind_merge(struct cache_entry return error("Cannot do a bind merge of %d trees\n", merge_size); if (!a) - return merged_entry(old, NULL); + return merged_entry(old, old); if (old) die("Entry '%s' overlaps. Cannot bind.", a->name); @@ -736,7 +746,7 @@ static int oneway_merge(struct cache_ent } return keep_entry(old); } - return merged_entry(a, NULL); + return merged_entry(a, old); } static int read_cache_unmerged(void) ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: Merge with local conflicts in new files 2006-05-16 22:40 ` Junio C Hamano @ 2006-05-16 23:11 ` Santi 2006-05-16 23:28 ` Junio C Hamano 2006-05-17 8:17 ` [PATCH/RFC] read-tree -m -u: do not overwrite or remove untracked working tree files Junio C Hamano 0 siblings, 2 replies; 10+ messages in thread From: Santi @ 2006-05-16 23:11 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 2006/5/17, Junio C Hamano <junkio@cox.net>: > Santi <sbejar@gmail.com> writes: > > > In the case of: > > > > - You merge from a branch with new files > > - You have these files in the working directory > > - You do not have these files in the HEAD. > > and > > - You have not told git that these files matter. For me it is the other way, all my files matter but git can do whatever it wants with the ones it controls. > > This is totally untested, but on top of "next" you could do > something like this, perhaps. Thanks, it works here. Santi ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Merge with local conflicts in new files 2006-05-16 23:11 ` Santi @ 2006-05-16 23:28 ` Junio C Hamano 2006-05-17 7:47 ` Pavel Roskin 2006-05-17 8:17 ` [PATCH/RFC] read-tree -m -u: do not overwrite or remove untracked working tree files Junio C Hamano 1 sibling, 1 reply; 10+ messages in thread From: Junio C Hamano @ 2006-05-16 23:28 UTC (permalink / raw) To: Santi; +Cc: git Santi <sbejar@gmail.com> writes: > 2006/5/17, Junio C Hamano <junkio@cox.net>: >> Santi <sbejar@gmail.com> writes: >> >> > In the case of: >> > >> > - You merge from a branch with new files >> > - You have these files in the working directory >> > - You do not have these files in the HEAD. >> >> and >> >> - You have not told git that these files matter. > > For me it is the other way, all my files matter but git can do > whatever it wants with the ones it controls. You really do not mean that. If you told git a file matters, and have local modifications to the file in the working tree that you have not run update-index yet, merge and apply should be careful not to overwrite your changes that is not ready while doing whatever thing they have to do. And they are careful, because you have told git that they matter, and the way you tell git that they matter is to have entries for them in the index. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Merge with local conflicts in new files 2006-05-16 23:28 ` Junio C Hamano @ 2006-05-17 7:47 ` Pavel Roskin 2006-05-17 8:20 ` Junio C Hamano 2006-05-17 8:50 ` Martin Langhoff 0 siblings, 2 replies; 10+ messages in thread From: Pavel Roskin @ 2006-05-17 7:47 UTC (permalink / raw) To: Junio C Hamano; +Cc: Santi, git Hello, Junio! On Tue, 2006-05-16 at 16:28 -0700, Junio C Hamano wrote: > Santi <sbejar@gmail.com> writes: > > > 2006/5/17, Junio C Hamano <junkio@cox.net>: > >> - You have not told git that these files matter. > > > > For me it is the other way, all my files matter but git can do > > whatever it wants with the ones it controls. > > You really do not mean that. > > If you told git a file matters, and have local modifications to > the file in the working tree that you have not run update-index > yet, merge and apply should be careful not to overwrite your > changes that is not ready while doing whatever thing they have > to do. And they are careful, because you have told git that > they matter, and the way you tell git that they matter is to > have entries for them in the index. I'm afraid this approach, while understandable from the technical standpoint, could prevent git from ever becoming a version control system that "just works" without any porcelains. I know a person who refuses to use any version control. If he encountered this situation, he would never try any version control again. After all, we are talking about files in the _working_ directory. It's not merely a transient appendix to the repository. git is not the only player here. If a file doesn't "belong" to git, it belongs to its "supreme commander", i.e. the user, and should be approached with utmost care. Merging a branch should not cause an irreparable loss of user data. The same applies to other commands. Exceptions can be made for commands that are specifically meant to clean user data, for commands with special options (e.g. --force or --hard), and for the files explicitly marked as transient (e.g. in .gitignore). -- Regards, Pavel Roskin ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Merge with local conflicts in new files 2006-05-17 7:47 ` Pavel Roskin @ 2006-05-17 8:20 ` Junio C Hamano 2006-05-17 8:50 ` Martin Langhoff 1 sibling, 0 replies; 10+ messages in thread From: Junio C Hamano @ 2006-05-17 8:20 UTC (permalink / raw) To: Pavel Roskin; +Cc: git Pavel Roskin <proski@gnu.org> writes: > I'm afraid this approach, while understandable from the technical > standpoint, could prevent git from ever becoming a version control > system that "just works" without any porcelains. > > I know a person who refuses to use any version control. If he > encountered this situation, he would never try any version control > again. > > After all, we are talking about files in the _working_ directory. It's > not merely a transient appendix to the repository. git is not the only > player here. If a file doesn't "belong" to git, it belongs to its > "supreme commander", i.e. the user, and should be approached with utmost > care. I am biased ;-) and appreciate corrections like this. How does the updated patch I just sent out look? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Merge with local conflicts in new files 2006-05-17 7:47 ` Pavel Roskin 2006-05-17 8:20 ` Junio C Hamano @ 2006-05-17 8:50 ` Martin Langhoff 1 sibling, 0 replies; 10+ messages in thread From: Martin Langhoff @ 2006-05-17 8:50 UTC (permalink / raw) To: Pavel Roskin; +Cc: Junio C Hamano, Santi, git On 5/17/06, Pavel Roskin <proski@gnu.org> wrote: > If a file doesn't "belong" to git, it belongs to its > "supreme commander", i.e. the user, and should be approached with utmost > care. +1 here. Unknown files are precious (to take an Arch term) until git is told otherwise. > special options (e.g. --force or --hard), and for the files explicitly > marked as transient (e.g. in .gitignore). I think that if we turn into clobbering files listed in .gitignore users will probably be screaming bloody murder. No git op should clobber untracked files... Arch has this strange concept of allowing you to list 'junk' files. I could never figure out why it would want my authorization to remove files randomly. For all its faults, cvs does the right thing -- it will say 'checkout/update of foo.c blocked by foo.c in directory'. And if you force it with -C it will rename the local file to .#originalname-local or something like that. Even the files I think of as junk are actually useful and should not be messed up with. Editor temp files, for instance, are often listed in .gitignore, and if you ask me, they are junk. Except while I am working with my editor! ;-) Another case is .project files from IDEs like Eclipse. People list them in .cvsignore so that they are not committed, and yet preserved. The user probably has a lot of personal settings there. cheers, martin ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH/RFC] read-tree -m -u: do not overwrite or remove untracked working tree files. 2006-05-16 23:11 ` Santi 2006-05-16 23:28 ` Junio C Hamano @ 2006-05-17 8:17 ` Junio C Hamano 2006-05-17 8:24 ` Jakub Narebski 1 sibling, 1 reply; 10+ messages in thread From: Junio C Hamano @ 2006-05-17 8:17 UTC (permalink / raw) To: Santi; +Cc: git When a merge results in a creation of a path that did not exist in HEAD, and if you already have that path on the working tree, because the index has not been told about the working tree file, read-tree happily removes it. The issue was brought up by Santi Béjar on the list. Signed-off-by: Junio C Hamano <junkio@cox.net> --- >> This is totally untested, but on top of "next" you could do >> something like this, perhaps. > > Thanks, it works here. This is an updated version, applicable to the "master" branch. The earlier one only dealt with very limited cases, and I suspect it did not do the right thing when "--reset" is involved (it would probably had broken "git reset --hard"). This is an RFC patch that I consider of somewhat dubious value. Not the implementation quality, but the semantic change it implies. Before, we could freely work in a working tree, which is just a scratch area to build the index, littered with throw-away files, knowing they would not prevent merge between our HEAD and other branch from happenning even if a merge needs to blow them away. With this change, it is not a case anymore. Your merge will fail to proceed and you have to remove those throw-away files yourself and retry the merge. The extent of the damage can be seen by the change to t1002 test this commit contains. It arguably is making things much safer by refusing to proceed, so this might be a desirable change. I am still undecided. 435ac2bfd2ef29c584531cd4a29c1f018f9aea13 read-tree.c | 43 ++++++++++++++++++++++++--- t/t1002-read-tree-m-u-2way.sh | 66 +++++++++++++++++++++++++++-------------- t/t3500-cherry.sh | 1 + t/t4002-diff-basic.sh | 6 ++-- t/t6022-merge-rename.sh | 1 + 5 files changed, 87 insertions(+), 30 deletions(-) 435ac2bfd2ef29c584531cd4a29c1f018f9aea13 diff --git a/read-tree.c b/read-tree.c index e16e91b..6dc95a3 100644 --- a/read-tree.c +++ b/read-tree.c @@ -408,7 +408,7 @@ static void verify_uptodate(struct cache { struct stat st; - if (index_only) + if (index_only || reset) return; if (!lstat(ce->name, &st)) { @@ -426,6 +426,21 @@ static void verify_uptodate(struct cache die("Entry '%s' not uptodate. Cannot merge.", ce->name); } +/* + * We do not want to remove or overwrite a working tree file that + * is not tracked. + */ +static void verify_absent(const char *path, const char *action) +{ + struct stat st; + + if (index_only || reset || !update) + return; + if (!lstat(path, &st)) + die("Untracked working tree file '%s' " + "would be %s by merge.", path, action); +} + static int merged_entry(struct cache_entry *merge, struct cache_entry *old) { merge->ce_flags |= htons(CE_UPDATE); @@ -443,6 +458,9 @@ static int merged_entry(struct cache_ent verify_uptodate(old); } } + else + verify_absent(merge->name, "overwritten"); + merge->ce_flags &= ~htons(CE_STAGEMASK); add_cache_entry(merge, ADD_CACHE_OK_TO_ADD); return 1; @@ -452,6 +470,8 @@ static int deleted_entry(struct cache_en { if (old) verify_uptodate(old); + else + verify_absent(ce->name, "removed"); ce->ce_mode = 0; add_cache_entry(ce, ADD_CACHE_OK_TO_ADD); return 1; @@ -487,6 +507,7 @@ static int threeway_merge(struct cache_e int count; int head_match = 0; int remote_match = 0; + const char *path = NULL; int df_conflict_head = 0; int df_conflict_remote = 0; @@ -498,8 +519,11 @@ static int threeway_merge(struct cache_e for (i = 1; i < head_idx; i++) { if (!stages[i]) any_anc_missing = 1; - else + else { + if (!path) + path = stages[i]->name; no_anc_exists = 0; + } } index = stages[0]; @@ -515,6 +539,13 @@ static int threeway_merge(struct cache_e remote = NULL; } + if (!path && index) + path = index->name; + if (!path && head) + path = head->name; + if (!path && remote) + path = remote->name; + /* First, if there's a #16 situation, note that to prevent #13 * and #14. */ @@ -575,6 +606,8 @@ static int threeway_merge(struct cache_e (remote_deleted && head && head_match)) { if (index) return deleted_entry(index, index); + else if (path) + verify_absent(path, "removed"); return 0; } /* @@ -592,6 +625,8 @@ static int threeway_merge(struct cache_e if (index) { verify_uptodate(index); } + else if (path) + verify_absent(path, "overwritten"); nontrivial_merge = 1; @@ -689,7 +724,7 @@ static int oneway_merge(struct cache_ent merge_size); if (!a) - return deleted_entry(old, NULL); + return deleted_entry(old, old); if (old && same(old, a)) { if (reset) { struct stat st; @@ -699,7 +734,7 @@ static int oneway_merge(struct cache_ent } return keep_entry(old); } - return merged_entry(a, NULL); + return merged_entry(a, old); } static int read_cache_unmerged(void) diff --git a/t/t1002-read-tree-m-u-2way.sh b/t/t1002-read-tree-m-u-2way.sh index 4d175d8..8335a63 100755 --- a/t/t1002-read-tree-m-u-2way.sh +++ b/t/t1002-read-tree-m-u-2way.sh @@ -39,7 +39,6 @@ test_expect_success \ echo nitfol >nitfol && echo bozbar >bozbar && echo rezrov >rezrov && - echo yomin >yomin && git-update-index --add nitfol bozbar rezrov && treeH=`git-write-tree` && echo treeH $treeH && @@ -56,7 +55,8 @@ test_expect_success \ test_expect_success \ '1, 2, 3 - no carry forward' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && git-read-tree -m -u $treeH $treeM && git-ls-files --stage >1-3.out && cmp M.out 1-3.out && @@ -66,11 +66,12 @@ test_expect_success \ check_cache_at frotz clean && check_cache_at nitfol clean' -echo '+100644 X 0 yomin' >expected - test_expect_success \ '4 - carry forward local addition.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && + echo "+100644 X 0 yomin" >expected && + echo yomin >yomin && git-update-index --add yomin && git-read-tree -m -u $treeH $treeM && git-ls-files --stage >4.out || return 1 @@ -85,7 +86,9 @@ test_expect_success \ test_expect_success \ '5 - carry forward local addition.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && + git-read-tree -m -u $treeH && echo yomin >yomin && git-update-index --add yomin && echo yomin yomin >yomin && @@ -103,7 +106,9 @@ test_expect_success \ test_expect_success \ '6 - local addition already has the same.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && + echo frotz >frotz && git-update-index --add frotz && git-read-tree -m -u $treeH $treeM && git-ls-files --stage >6.out && @@ -117,7 +122,8 @@ test_expect_success \ test_expect_success \ '7 - local addition already has the same.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo frotz >frotz && git-update-index --add frotz && echo frotz frotz >frotz && @@ -134,14 +140,16 @@ test_expect_success \ test_expect_success \ '8 - conflicting addition.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo frotz frotz >frotz && git-update-index --add frotz && if git-read-tree -m -u $treeH $treeM; then false; else :; fi' test_expect_success \ '9 - conflicting addition.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo frotz frotz >frotz && git-update-index --add frotz && echo frotz >frotz && @@ -149,7 +157,8 @@ test_expect_success \ test_expect_success \ '10 - path removed.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo rezrov >rezrov && git-update-index --add rezrov && git-read-tree -m -u $treeH $treeM && @@ -160,7 +169,8 @@ test_expect_success \ test_expect_success \ '11 - dirty path removed.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo rezrov >rezrov && git-update-index --add rezrov && echo rezrov rezrov >rezrov && @@ -168,14 +178,16 @@ test_expect_success \ test_expect_success \ '12 - unmatching local changes being removed.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo rezrov rezrov >rezrov && git-update-index --add rezrov && if git-read-tree -m -u $treeH $treeM; then false; else :; fi' test_expect_success \ '13 - unmatching local changes being removed.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo rezrov rezrov >rezrov && git-update-index --add rezrov && echo rezrov >rezrov && @@ -188,7 +200,8 @@ EOF test_expect_success \ '14 - unchanged in two heads.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo nitfol nitfol >nitfol && git-update-index --add nitfol && git-read-tree -m -u $treeH $treeM && @@ -207,7 +220,8 @@ test_expect_success \ test_expect_success \ '15 - unchanged in two heads.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo nitfol nitfol >nitfol && git-update-index --add nitfol && echo nitfol nitfol nitfol >nitfol && @@ -227,14 +241,16 @@ test_expect_success \ test_expect_success \ '16 - conflicting local change.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo bozbar bozbar >bozbar && git-update-index --add bozbar && if git-read-tree -m -u $treeH $treeM; then false; else :; fi' test_expect_success \ '17 - conflicting local change.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo bozbar bozbar >bozbar && git-update-index --add bozbar && echo bozbar bozbar bozbar >bozbar && @@ -242,7 +258,8 @@ test_expect_success \ test_expect_success \ '18 - local change already having a good result.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo gnusto >bozbar && git-update-index --add bozbar && git-read-tree -m -u $treeH $treeM && @@ -254,7 +271,8 @@ test_expect_success \ test_expect_success \ '19 - local change already having a good result, further modified.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo gnusto >bozbar && git-update-index --add bozbar && echo gnusto gnusto >bozbar && @@ -273,7 +291,8 @@ test_expect_success \ test_expect_success \ '20 - no local change, use new tree.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo bozbar >bozbar && git-update-index --add bozbar && git-read-tree -m -u $treeH $treeM && @@ -285,7 +304,8 @@ test_expect_success \ test_expect_success \ '21 - no local change, dirty cache.' \ - 'rm -f .git/index && + 'rm -f .git/index nitfol bozbar rezrov frotz && + git-read-tree --reset -u $treeH && echo bozbar >bozbar && git-update-index --add bozbar && echo gnusto gnusto >bozbar && @@ -294,7 +314,7 @@ test_expect_success \ # Also make sure we did not break DF vs DF/DF case. test_expect_success \ 'DF vs DF/DF case setup.' \ - 'rm -f .git/index && + 'rm -f .git/index echo DF >DF && git-update-index --add DF && treeDF=`git-write-tree` && diff --git a/t/t3500-cherry.sh b/t/t3500-cherry.sh index b141f89..e83bbee 100755 --- a/t/t3500-cherry.sh +++ b/t/t3500-cherry.sh @@ -30,6 +30,7 @@ test_expect_success \ git-commit -m "Add C." && git-checkout -f master && + rm -f B C && echo Third >> A && git-update-index A && diff --git a/t/t4002-diff-basic.sh b/t/t4002-diff-basic.sh index 769274a..56eda63 100755 --- a/t/t4002-diff-basic.sh +++ b/t/t4002-diff-basic.sh @@ -191,7 +191,7 @@ test_expect_success \ 'rm -fr Z [A-Z][A-Z] && git-read-tree $tree_A && git-checkout-index -f -a && - git-read-tree -m $tree_O || return 1 + git-read-tree --reset $tree_O || return 1 git-update-index --refresh >/dev/null ;# this can exit non-zero git-diff-files >.test-a && cmp_diff_files_output .test-a .test-recursive-OA' @@ -201,7 +201,7 @@ test_expect_success \ 'rm -fr Z [A-Z][A-Z] && git-read-tree $tree_B && git-checkout-index -f -a && - git-read-tree -m $tree_O || return 1 + git-read-tree --reset $tree_O || return 1 git-update-index --refresh >/dev/null ;# this can exit non-zero git-diff-files >.test-a && cmp_diff_files_output .test-a .test-recursive-OB' @@ -211,7 +211,7 @@ test_expect_success \ 'rm -fr Z [A-Z][A-Z] && git-read-tree $tree_B && git-checkout-index -f -a && - git-read-tree -m $tree_A || return 1 + git-read-tree --reset $tree_A || return 1 git-update-index --refresh >/dev/null ;# this can exit non-zero git-diff-files >.test-a && cmp_diff_files_output .test-a .test-recursive-AB' diff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh index a2d24b5..5ac2564 100755 --- a/t/t6022-merge-rename.sh +++ b/t/t6022-merge-rename.sh @@ -111,6 +111,7 @@ test_expect_success 'pull renaming branc test_expect_success 'pull renaming branch into another renaming one' \ ' + rm -f B git reset --hard git checkout red git pull . white && { -- 1.3.3.g8a24 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH/RFC] read-tree -m -u: do not overwrite or remove untracked working tree files. 2006-05-17 8:17 ` [PATCH/RFC] read-tree -m -u: do not overwrite or remove untracked working tree files Junio C Hamano @ 2006-05-17 8:24 ` Jakub Narebski 0 siblings, 0 replies; 10+ messages in thread From: Jakub Narebski @ 2006-05-17 8:24 UTC (permalink / raw) To: git Junio C Hamano wrote: > This is an RFC patch that I consider of somewhat dubious value. > Not the implementation quality, but the semantic change it > implies. Before, we could freely work in a working tree, which > is just a scratch area to build the index, littered with > throw-away files, knowing they would not prevent merge between > our HEAD and other branch from happenning even if a merge needs > to blow them away. With this change, it is not a case anymore. > Your merge will fail to proceed and you have to remove those > throw-away files yourself and retry the merge. The extent of > the damage can be seen by the change to t1002 test this commit > contains. It arguably is making things much safer by refusing to > proceed, so this might be a desirable change. I am still > undecided. Perhaps the behavior should be decided by the config option, e.g. core.preserveWorkingTree; of course that leave us with the problem what value should be the default: the one preserving backward compatibility, or the more safe one. And of course --force to blow away changes anyway... -- Jakub Narebski Warsaw, Poland ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-05-17 8:50 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-05-16 22:00 Merge with local conflicts in new files Santi 2006-05-16 22:12 ` Santi 2006-05-16 22:40 ` Junio C Hamano 2006-05-16 23:11 ` Santi 2006-05-16 23:28 ` Junio C Hamano 2006-05-17 7:47 ` Pavel Roskin 2006-05-17 8:20 ` Junio C Hamano 2006-05-17 8:50 ` Martin Langhoff 2006-05-17 8:17 ` [PATCH/RFC] read-tree -m -u: do not overwrite or remove untracked working tree files Junio C Hamano 2006-05-17 8:24 ` Jakub Narebski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).