{"thread":{"id":"2371","subject":"Expected Behavior?","startedAt":"2005-11-06T22:16:02Z","lastAt":"2005-11-07T02:01:28Z","messageCount":3,"participants":["Jon Loeliger","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"11222","messageId":"E1EYsny-0004hq-IW@jdl.com","threadId":"2371","inReplyTo":null,"subject":"Expected Behavior?","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2005-11-06T22:16:02Z","receivedAt":"2005-11-06T22:16:02Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"\nI was working through some examples and found some\nrather curious behavior.  I'm wondering if it is\nexpected or not.  This isn't quite minimal, but\nit is still small and shows the weirdness:\n\n    git-init-db\n    echo \"Stuff for file1\" > file1\n    echo \"Stuff for file2\" > file2\n\n    git add file1 file2\n    git commit -m \"Initial file1 and file2\"\n\n    git checkout -b dev\n\n    echo \"More for file1\" >> file1\n    rm -f file2\n    echo \"Another file!\" > file3\n\n    git update-index file1\n    git update-index --force-remove file2\n    git add file3\n\n    git commit -m \"Updated some stuff.\"\n\n    git checkout master\n    echo \"Stuff for a conflict.\" >> file3\n    git add file3\n    git commit -m \"Master update of file3\"\n\n    git merge \"Grab dev stuff\" master dev\n\nThen, the part that I think is odd is demonstrated by \"git status\":\n\n    $ git status\n    #\n    # Updated but not checked in:\n    #   (will commit)\n    #\n    #       modified: file1\n    #       deleted:  file2\n    #       unmerged: file3\n    #\n    #\n    # Changed but not updated:\n    #   (use git-update-index to mark for commit)\n    #\n    #       unmerged: file3\n    #\n    #\n    # Untracked files:\n    #   (use \"git add\" to add to commit)\n    #\n    #       file3\n\nWhy is file3 considered untracked and needing to be added?\nIt was present in both \"dev\" and \"master\" branches before\nthe merge.  It doesn't end up with \"<<< one === other >>>\"\nstyle diffs either.\n\nMy guess is that the file is small, one line, in each branch.\nWhen the diff happens, it sees the file as empty in the other\nbranch and considers that \"new\" directly, rather than asking\nthe index if it knows about it to determine \"newness\" status.\n\nOr perhaps it is that the file  became new in each branch\nindependently and never really had a true common ancestor.\n\nThanks,\njdl\n"},{"id":"11236","messageId":"7vy841utif.fsf@assigned-by-dhcp.cox.net","threadId":"2371","inReplyTo":"E1EYsny-0004hq-IW@jdl.com","subject":"Re: Expected Behavior?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-07T01:38:32Z","receivedAt":"2005-11-07T01:38:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger <jdl@freescale.com> writes:\n\n>     # Untracked files:\n>     #   (use \"git add\" to add to commit)\n>     #\n>     #       file3\n>\n> Why is file3 considered untracked and needing to be added?\n> It was present in both \"dev\" and \"master\" branches before\n> the merge.  It doesn't end up with \"<<< one === other >>>\"\n> style diffs either.\n\nIt is because Untracked uses different program than git-diff-*\nand, it mishandles unmerged paths.  Let me see...\n\nYup, it uses \"git-ls-files --others\", which considers that\nunmerged paths do not \"exist\" in the index.  This is wrong.\n\nThe attached is a patch to fix ls-files.\n\nI also think that file3 should not appear in \"Updated but not\nchecked in (will commit)\" list -- we are _not_ going to commit\nunmerged paths until you tell git what you want to do with\nthem.  The patch in the next message fixes it.\n\n-- >8 -- cut here -- >8 --\nSubject: ls-files: --others should not say unmerged paths are unknown.\n\nJon Loeliger noticed that an unmerged path appears as\n\"Untracked\" in git-status output, even though we show the same\npath as updated/changed.  Since --others means \"we have not told\ngit about that path\", we should not show unmerged paths --\nobviously, git knows about them; it just does not know what we\nwant to do about them yet.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n ls-files.c |   26 ++++++++++++++++++++++++--\n 1 files changed, 24 insertions(+), 2 deletions(-)\n\napplies-to: f571975209b0bc38ca099684f9731efe4163b396\nfcbc3083e37f3c025d85d7b2c8a1c53d07a81fac\ndiff --git a/ls-files.c b/ls-files.c\nindex d9c8b21..f7653e7 100644\n--- a/ls-files.c\n+++ b/ls-files.c\n@@ -348,6 +348,29 @@ static void show_dir_entry(const char *t\n \tputchar(line_terminator);\n }\n \n+static void show_other_files(void)\n+{\n+\tint i;\n+\tfor (i = 0; i < nr_dir; i++) {\n+\t\t/* We should not have a matching entry, but we\n+\t\t * may have an unmerged entry for this path.\n+\t\t */\n+\t\tstruct nond_on_fs *ent = dir[i];\n+\t\tint pos = cache_name_pos(ent->name, ent->len);\n+\t\tstruct cache_entry *ce;\n+\t\tif (0 <= pos)\n+\t\t\tdie(\"bug in show-other-files\");\n+\t\tpos = -pos - 1;\n+\t\tif (pos < active_nr) { \n+\t\t\tce = active_cache[pos];\n+\t\t\tif (ce_namelen(ce) == ent->len &&\n+\t\t\t    !memcmp(ce->name, ent->name, ent->len))\n+\t\t\t\tcontinue; /* Yup, this one exists unmerged */\n+\t\t}\n+\t\tshow_dir_entry(tag_other, ent);\n+\t}\n+}\n+\n static void show_killed_files(void)\n {\n \tint i;\n@@ -438,8 +461,7 @@ static void show_files(void)\n \t\tread_directory(path, base, baselen);\n \t\tqsort(dir, nr_dir, sizeof(struct nond_on_fs *), cmp_name);\n \t\tif (show_others)\n-\t\t\tfor (i = 0; i < nr_dir; i++)\n-\t\t\t\tshow_dir_entry(tag_other, dir[i]);\n+\t\t\tshow_other_files();\n \t\tif (show_killed)\n \t\t\tshow_killed_files();\n \t}\n---\n0.99.9.GIT\n"},{"id":"11238","messageId":"7vd5ldusg7.fsf@assigned-by-dhcp.cox.net","threadId":"2371","inReplyTo":"E1EYsny-0004hq-IW@jdl.com","subject":"Re: Expected Behavior?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-07T02:01:28Z","receivedAt":"2005-11-07T02:01:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger <jdl@freescale.com> writes:\n\n>     git checkout -b dev\n>\n>     echo \"More for file1\" >> file1\n>     rm -f file2\n>     echo \"Another file!\" > file3\n>\n>     git update-index file1\n>     git update-index --force-remove file2\n>     git add file3\n\nYou do not have file2 in the working tree, so regular --remove\nwould do.\n\n\tgit-update-index --add --remove file1 file2 file3\n\n>     git merge \"Grab dev stuff\" master dev\n\nThis is good.  We used to use (and the tutorial only talks\nabout) git-resolve to do this step, like this:\n\n\tgit-resolve master dev 'Merge dev branch'\n\nAnd I've kept using git-resolve myself; not that I do not trust\ngit-merge but purely from inertia, although I was the one who\ndid 'git merge' ;-).  Maybe I should first update the tutorial\nto use git-merge instead of git-resolve.\n\nIt appears that as the everyday workhorse, using Daniel's\ngit-merge-resolve is stable through git-merge have proven stable\nenough.  So here is a question.  Do people mind if 'git-resolve'\nand 'git-octopus' are dropped before 1.0?  This means 2 less\nprograms in your /usr/bin ;-).\n"}]}