{"thread":{"id":"4190","subject":"Remove old \"git-add.sh\" remnants","startedAt":"2006-05-18T04:21:04Z","lastAt":"2006-05-18T06:44:15Z","messageCount":3,"participants":["Linus Torvalds","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"20202","messageId":"Pine.LNX.4.64.0605172120160.10823@g5.osdl.org","threadId":"4190","inReplyTo":null,"subject":"Remove old \"git-add.sh\" remnants","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-18T04:21:04Z","receivedAt":"2006-05-18T04:21:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nRepeat after me: \"It's now a built-in\"\n\nSigned-off-by: Linus Torvalds <torvalds@osdl.org>\n---\n\ndiff --git a/Makefile b/Makefile\nindex a1d2e08..3a28580 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -113,7 +113,7 @@ SPARSE_FLAGS = -D__BIG_ENDIAN__ -D__powe\n ### --- END CONFIGURATION SECTION ---\n \n SCRIPT_SH = \\\n-\tgit-add.sh git-bisect.sh git-branch.sh git-checkout.sh \\\n+\tgit-bisect.sh git-branch.sh git-checkout.sh \\\n \tgit-cherry.sh git-clean.sh git-clone.sh git-commit.sh \\\n \tgit-fetch.sh \\\n \tgit-format-patch.sh git-ls-remote.sh \\\n@@ -170,7 +170,7 @@ PROGRAMS = \\\n \n BUILT_INS = git-log$X git-whatchanged$X git-show$X \\\n \tgit-count-objects$X git-diff$X git-push$X \\\n-\tgit-grep$X\n+\tgit-grep$X git-add$X\n \n # what 'all' will build and 'install' will install, in gitexecdir\n ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)\ndiff --git a/git-add.sh b/git-add.sh\ndeleted file mode 100755\nindex d6a4bc7..0000000\n--- a/git-add.sh\n+++ /dev/null\n@@ -1,56 +0,0 @@\n-#!/bin/sh\n-\n-USAGE='[-n] [-v] <file>...'\n-SUBDIRECTORY_OK='Yes'\n-. git-sh-setup\n-\n-show_only=\n-verbose=\n-while : ; do\n-  case \"$1\" in\n-    -n)\n-\tshow_only=true\n-\t;;\n-    -v)\n-\tverbose=--verbose\n-\t;;\n-    --)\n-\tshift\n-\tbreak\n-\t;;\n-    -*)\n-\tusage\n-\t;;\n-    *)\n-\tbreak\n-\t;;\n-  esac\n-  shift\n-done\n-\n-# Check misspelled pathspec\n-case \"$#\" in\n-0)\t;;\n-*)\n-\tgit-ls-files --error-unmatch --others --cached -- \"$@\" >/dev/null || {\n-\t\techo >&2 \"Maybe you misspelled it?\"\n-\t\texit 1\n-\t}\n-\t;;\n-esac\n-\n-if test -f \"$GIT_DIR/info/exclude\"\n-then\n-\tgit-ls-files -z \\\n-\t--exclude-from=\"$GIT_DIR/info/exclude\" \\\n-\t--others --exclude-per-directory=.gitignore -- \"$@\"\n-else\n-\tgit-ls-files -z \\\n-\t--others --exclude-per-directory=.gitignore -- \"$@\"\n-fi |\n-case \"$show_only\" in\n-true)\n-\txargs -0 echo ;;\n-*)\n-\tgit-update-index --add $verbose -z --stdin ;;\n-esac\n"},{"id":"20206","messageId":"7vy7wz6e8c.fsf@assigned-by-dhcp.cox.net","threadId":"4190","inReplyTo":"Pine.LNX.4.64.0605172120160.10823@g5.osdl.org","subject":"Necessity of \"evil\" merge and topic branches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-18T06:25:55Z","receivedAt":"2006-05-18T06:25:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When you are maintaining two codebases (one is slightly ahead of\nthe other, e.g. \"master\" and \"next\"), you would expect that a\ntopic branch based on \"master\" would apply well to \"next\".\n\nSo your \"make guts of ls-files accessible from others, and make\ngit-add a built-in\" is stored in \"lt/dirwalk\" topic branch,\nbased on a commit on \"master\".  By itself, it passes all tests.\n\nWhen it is merged into \"next\", which has other stuff, literal\nmerging did not really work (not your fault).  Many tests that\ninvolve writing trees (typically to create new commits) fail\nmiserably.\n\n   o---o---o---o---o---o---o---o master\n  .     \\\n  .      o---o---o lt/dirwalk -- contains builtin-add\n  \\               \\ \n   o---o---o---o---o next -- up to date with \"master\" but\n                             has many other stuff in it.\n\nThis is because the rule to manupulate the index is a bit\ndifferent on \"next\" branch, where it has jc/cache-tree topic.\n\nWith cache-tree, when you modify the index, you need to either\ninvalidate the path (and its parent directories up to root) in\nthe cached tree information, or discard the whole cache-tree,\nwhichever is easier [*1*].  So I have an \"evil merge\" that\nmerges the lt/dirwalk topic to next (it is ae12e59a).  It\nchanges the code like this:\n\n        $ git diff lt/dirwalk next -- builtin-add.c\n        diff --git a/builtin-add.c b/builtin-add.c\n        index 089c7a8..7083820 100644\n        --- a/builtin-add.c\n        +++ b/builtin-add.c\n        @@ -8,6 +8,7 @@ #include <fnmatch.h>\n         #include \"cache.h\"\n         #include \"builtin.h\"\n         #include \"dir.h\"\n        +#include \"cache-tree.h\"\n\n         static const char builtin_add_usage[] =\n         \"git-add [-n] [-v] <filepattern>...\";\n        @@ -197,6 +198,7 @@ static int add_file_to_index(const char \n                        die(\"unable to add %s to index\",path);\n                if (verbose)\n                        printf(\"add '%s'\\n\", path);\n        +\tcache_tree_invalidate_path(active_cache_tree, path);\n                return 0;\n         }\n\nObviously, this is a semantic adjustment, not a simple textual\nmerge, so no automated merge algorithm would help doing this for\nme.  I literally edited the automerged builtin-add.c (the merge\nis \"one adds a new file, the other does not do anything\" case,\nso it trivially automerges at the tree level) and amended the\ncommit when I made the merge.\n\nNow, unlike \"pu\", I never rewind \"next\", so once I did this\n\"evil merge\", I do not have to worry about this anymore while\nthe topic is still on \"next\".  However, when jc/cache-tree topic\nand lt/dirwalk topic both graduate to \"master\", I will somehow\nneed to remember to do this again.  That sounds somewhat painful\nand quite error prone.\n\nI am not going to rewind \"next\", so this evil merge will stay\nthere, but I am wondering if there was a better way I could have\nhandled this.\n\nIf I _know_ lt/dirwalk is going to graduate first (and I think\nthat is the case), I could have pulled lt/dirwalk into\njc/cache-tree topic, done an equivalent \"evil merge\" as the\nabove on jc/cache-tree topic, and pulled the result into \"next\".\nThat way, when lt/dirwalk alone graduates, I can just pull it\ninto \"master\".  Later, when the jc/cache-tree graduates, the\nnecessary \"evil merge\" will be pulled along with it, so I can\ntruly forget and not worry about it after I do the evil merge\nonce.\n\nBut in general, you would not know which one will graduate\nfirst, so pulling one topic into another is not always a good\nidea.  If I pull lt/dirwalk into jc/cache-tree, making\njc/cache-tree graduate alone becomes impossible.  Depending on\nthe readiness of these two topics, it may not be acceptable to\ncreate such a dependency between topics.\n\nOne possibility I can think of is that I could have created\nanother topic branch that merged jc/cache-tree and lt/dirwalk in\nthe evil way, and pulled that into \"next\".  Then either one of\nthe topics can independently graduate to \"master\" without\nwaiting for the other.  I still have to remember that I need to\nmerge the third topic with evil merge when I make both of them\ngraduate to \"master\", but at least I do not have to remember the\ndetails of how that evil merge should look like when I do so.  I\nonly need to remember that it needs to be done.\n\nIn practice, when I merge a topic branch into \"master\", I note\nthe paths that merge touches from \"master\", and run diff between\n\"master\" and \"next\" for them to see if the remaining changes on\nthem are reasonable.  I will hopefully remember the need for\n(and the details of) the evil merge that way when I pull these\ntwo branches to \"master\", so what I did would not cause trouble\ndown the road (with some luck ;-), but I feel there should be a\nbetter way to handle this situation.\n\nThoughts?\n\n\n[Footnotes]\n\n*1* In this message, let's not discuss if cache-tree is a good\n  idea to begin with, if we should rip it out and/or if we\n  should replace it with tree objects in the index.  I'd like to\n  discuss SCM issue to handle somewhat interrelated topic\n  branches here, not cache-tree.\n"},{"id":"20209","messageId":"7vu07n6dds.fsf@assigned-by-dhcp.cox.net","threadId":"4190","inReplyTo":"7vy7wz6e8c.fsf@assigned-by-dhcp.cox.net","subject":"Re: Necessity of \"evil\" merge and topic branches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-18T06:44:15Z","receivedAt":"2006-05-18T06:44:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Now, unlike \"pu\", I never rewind \"next\", so once I did this\n> \"evil merge\", I do not have to worry about this anymore while\n> the topic is still on \"next\".\n\nSide note.  If an evil merge or other hand resolution needs to\nbe done on a path that results in automerge conflicts, rerere\noften helps.  I really should start advertising it a bit more.\n\nUnfortunatly, rerere does not even kick in in this case.\n"}]}