{"thread":{"id":"6138","subject":"[PATCH 2/11] Honor GIT_REFLOG_ACTION in git-rebase.","startedAt":"2006-12-28T07:34:52Z","lastAt":"2006-12-29T17:44:59Z","messageCount":17,"participants":["Shawn O. Pearce","Junio C Hamano","Shawn Pearce","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":11},"messages":[{"id":"30404","messageId":"20061228073452.GB17867@spearce.org","threadId":"6138","inReplyTo":"9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org","subject":"[PATCH 2/11] Honor GIT_REFLOG_ACTION in git-rebase.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T07:34:52Z","receivedAt":"2006-12-28T07:34:52Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"To help correctly log actions caused by porcelain which invoke\ngit-reset directly we should honor the setting of GIT_REFLOG_ACTION\nwhich we inherited from our caller.\n\nSigned-off-by: Shawn O. Pearce \n---\n git-reset.sh | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/git-reset.sh b/git-reset.sh\nindex 2379db0..a969370 100755\n--- a/git-reset.sh\n+++ b/git-reset.sh\n@@ -5,6 +5,7 @@\n USAGE='[--mixed | --soft | --hard] [] [ [--] ...]'\n SUBDIRECTORY_OK=Yes\n . git-sh-setup\n+set_reflog_action \"reset $*\"\n \n update= reset_type=--mixed\n unset rev\n@@ -81,7 +82,7 @@ then\n else\n \trm -f \"$GIT_DIR/ORIG_HEAD\"\n fi\n-git-update-ref -m \"reset $reset_type $*\" HEAD \"$rev\"\n+git-update-ref -m \"$GIT_REFLOG_ACTION\" HEAD \"$rev\"\n update_ref_status=$?\n \n case \"$reset_type\" in\n-- \n1.4.4.3.gd2e4\n"},{"id":"30407","messageId":"20061228073456.GC17867@spearce.org","threadId":"6138","inReplyTo":"9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org","subject":"[PATCH 3/11] Use branch names in 'git-rebase -m' conflict hunks.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T07:34:56Z","receivedAt":"2006-12-28T07:34:56Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"If a three-way merge in git-rebase generates a conflict then we\nshould take advantage of git-merge-recursive's ability to include\nthe branch name of each side of the conflict hunk by setting the\nGITHEAD_* environment variables.\n\nIn the case of rebase there aren't really two clear branches; we\nhave the branch we are rebasing onto, and we have the branch we are\ncurrently rebasing. Since most conflicts will be arising between\nthe user's current branch and the branch they are rebasing onto\nwe assume the stuff that isn't in the current commit is the \"onto\"\nbranch and the stuff in the current commit is the \"current\" branch.\n\nThis assumption may however come up wrong if the user resolves one\nconflict in such a way that it conflicts again on a future commit\nalso being rebased. In this case the user's prior resolution will\nappear to be in the \"onto\" part of the hunk.\n\nSigned-off-by: Shawn O. Pearce \n---\n git-rebase.sh | 11 ++++++++++-\n 1 files changed, 10 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 5c7c4a6..828c59c 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -81,10 +81,18 @@ continue_merge () {\n call_merge () {\n \tcmt=\"$(cat $dotest/cmt.$1)\"\n \techo \"$cmt\" > \"$dotest/current\"\n-\tgit-merge-$strategy \"$cmt^\" -- HEAD \"$cmt\"\n+\thd=$(git-rev-parse --verify HEAD)\n+\tcmt_name=$(git-symbolic-ref HEAD)\n+\tmsgnum=$(cat $dotest/msgnum)\n+\tend=$(cat $dotest/end)\n+\teval GITHEAD_$cmt='\"${cmt_name##refs/heads/}~$(($end - $msgnum))\"'\n+\teval GITHEAD_$hd='\"$(cat $dotest/onto_name)\"'\n+\texport GITHEAD_$cmt GITHEAD_$hd\n+\tgit-merge-$strategy \"$cmt^\" -- \"$hd\" \"$cmt\"\n \trv=$?\n \tcase \"$rv\" in\n \t0)\n+\t\tunset GITHEAD_$cmt GITHEAD_$hd\n \t\treturn\n \t\t;;\n \t1)\n@@ -314,6 +322,7 @@ fi\n \n mkdir -p \"$dotest\"\n echo \"$onto\" > \"$dotest/onto\"\n+echo \"$onto_name\" > \"$dotest/onto_name\"\n prev_head=`git-rev-parse HEAD^0`\n echo \"$prev_head\" > \"$dotest/prev_head\"\n \n-- \n1.4.4.3.gd2e4\n"},{"id":"30408","messageId":"20061228073501.GD17867@spearce.org","threadId":"6138","inReplyTo":"9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org","subject":"[PATCH 4/11] Ensure `git-pull` fails if `git-merge` fails.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T07:35:01Z","receivedAt":"2006-12-28T07:35:01Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"If git-merge exits with a non-zero exit status so should git-pull.\nThis way the caller of git-pull knows the task did not complete\nsuccessfully simply by checking the process exit status.\n\nSigned-off-by: Shawn O. Pearce \n---\n git-pull.sh | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex fd4ffb8..2725946 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -119,5 +119,5 @@ case \"$strategy_args\" in\n esac\n \n merge_name=$(git-fmt-merge-msg <\"$GIT_DIR/FETCH_HEAD\") || exit\n-git-merge $no_summary $no_commit $squash $strategy_args \\\n+exec git-merge $no_summary $no_commit $squash $strategy_args \\\n \t\"$merge_name\" HEAD $merge_head\n-- \n1.4.4.3.gd2e4\n"},{"id":"30409","messageId":"20061228073505.GE17867@spearce.org","threadId":"6138","inReplyTo":"9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org","subject":"[PATCH 5/11] Honor pull.{twohead,octopus} in git-merge.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T07:35:05Z","receivedAt":"2006-12-28T07:35:05Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"If git-merge is invoked without a strategy argument it is probably\nbeing run as a porcelain-ish command directly and is not being run\nfrom within git-pull. However we still should honor whatever merge\nstrategy the user may have selected in their configuration, just as\n`git-pull .` would have.\n\nSigned-off-by: Shawn O. Pearce \n---\n git-merge.sh | 16 ++++++++++++++--\n 1 files changed, 14 insertions(+), 2 deletions(-)\n\ndiff --git a/git-merge.sh b/git-merge.sh\nindex c7e033c..a8f673e 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -272,9 +272,21 @@ case \"$use_strategies\" in\n '')\n \tcase \"$#\" in\n \t1)\n-\t\tuse_strategies=\"$default_twohead_strategies\" ;;\n+\t\tvar=\"`git-repo-config --get pull.twohead`\"\n+\t\tif test -n \"$var\"\n+\t\tthen\n+\t\t\tuse_strategies=\"$var\"\n+\t\telse\n+\t\t\tuse_strategies=\"$default_twohead_strategies\"\n+\t\tfi ;;\n \t*)\n-\t\tuse_strategies=\"$default_octopus_strategies\" ;;\n+\t\tvar=\"`git-repo-config --get pull.octopus`\"\n+\t\tif test -n \"$var\"\n+\t\tthen\n+\t\t\tuse_strategies=\"$var\"\n+\t\telse\n+\t\t\tuse_strategies=\"$default_octopus_strategies\"\n+\t\tfi ;;\n \tesac\n \t;;\n esac\n-- \n1.4.4.3.gd2e4\n"},{"id":"30410","messageId":"20061228073511.GF17867@spearce.org","threadId":"6138","inReplyTo":"9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org","subject":"[PATCH 6/11] Allow git-merge to select the default strategy.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T07:35:11Z","receivedAt":"2006-12-28T07:35:11Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Now that git-merge knows how to use the pull.{twohead,octopus}\nconfiguration options to select the default merge strategy there\nis no reason for git-pull to do the same immediately prior to\ninvoking git-merge.\n\nSigned-off-by: Shawn O. Pearce \n---\n git-pull.sh | 18 ------------------\n 1 files changed, 0 insertions(+), 18 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 2725946..28d0819 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -90,18 +90,6 @@ case \"$merge_head\" in\n \t\techo >&2 \"Cannot merge multiple branches into empty head\"\n \t\texit 1\n \tfi\n-\tvar=`git-repo-config --get pull.octopus`\n-\tif test -n \"$var\"\n-\tthen\n-\t\tstrategy_default_args=\"-s $var\"\n-\tfi\n-\t;;\n-*)\n-\tvar=`git-repo-config --get pull.twohead`\n-\tif test -n \"$var\"\n- then\n-\t\tstrategy_default_args=\"-s $var\"\n-\tfi\n \t;;\n esac\n \n@@ -112,12 +100,6 @@ then\n \texit\n fi\n \n-case \"$strategy_args\" in\n-'')\n-\tstrategy_args=$strategy_default_args\n-\t;;\n-esac\n-\n merge_name=$(git-fmt-merge-msg <\"$GIT_DIR/FETCH_HEAD\") || exit\n exec git-merge $no_summary $no_commit $squash $strategy_args \\\n \t\"$merge_name\" HEAD $merge_head\n-- \n1.4.4.3.gd2e4\n"},{"id":"30411","messageId":"20061228073517.GG17867@spearce.org","threadId":"6138","inReplyTo":"9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org","subject":"[PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T07:35:17Z","receivedAt":"2006-12-28T07:35:17Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Users who merge frequently from remote repositories tend to prefer\n`git-pull .` over `git-merge` for local merges, as the pull interface\nis then consistent with how the user performs merges from remote\nrepositories.\n\nUnfortunately `git-pull .` has a (small) amount of overhead on top of\n`git-merge` as it needs to first invoke git-fetch to prepare the\nFETCH_HEAD file. However we can easily detect this special case\nof a local merge and jump directly into git-merge, bypassing that\noverhead.\n\nThis change also allows users of `git-pull .` to take advantage of\nthe change made in commit e0ec1819, where git-merge uses the local\nbranch name in conflict hunks if it is invoked as a porcelain,\nrather than as a plumbing.\n\nUsers may also now use `git-pull . foo~3` to merge the early part\nof branch foo. This was not previously possible as git-fetch does\nnot know how to fetch foo~3 from a repository.\n\nUnfortunately we cannot use this git-fetch bypass if the user is\nalso updating some sort of tracking branch in the local repository\nas part of the pull from the local repository. This however is a\nrather crazy usage of `git-pull .`, but we used to support it, so\nwe issue a silly warning message and use the older-style git-fetch\npath to continue supporting it.\n\nSigned-off-by: Shawn O. Pearce \n---\n git-pull.sh | 27 +++++++++++++++++++++++++++\n 1 files changed, 27 insertions(+), 0 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 28d0819..8c94fef 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -45,6 +45,33 @@ do\n \tshift\n done\n \n+if test \"X$1\" = X.\n+then\n+\t# We are merging from this repository. We can avoid fetch\n+\t# and go right into merge if the user isn't doing something\n+\t# odd like asking us to also update tracking branches in\n+\t# this repository as part of the pull. Yeah, they probably\n+\t# shouldn't do that - but we allowed it in the past...\n+\t#\n+\tdirect_merge=1\n+\tfor remote\n+\tdo\n+\t\tcase \"$remote\" in\n+\t\t*:*) direct_merge=0; break;;\n+\t\tesac\n+\tdone\n+\tif test $direct_merge = 1\n+\tthen\n+\t\tshift\n+\t\texec git-merge \\\n+\t\t\t$no_summary $no_commit $squash $strategy_args \\\n+\t\t\t\"$@\"\n+\telse\n+\t\techo >&2 \"Clever... Updating tracking branch while pulling from yourself.\"\n+\t\techo >&2\n+\tfi\n+fi\n+\n orig_head=$(git-rev-parse --verify HEAD 2>/dev/null)\n git-fetch --update-head-ok \"$@\" || exit 1\n \n-- \n1.4.4.3.gd2e4\n"},{"id":"30412","messageId":"20061228073520.GH17867@spearce.org","threadId":"6138","inReplyTo":"9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org","subject":"[PATCH 8/11] Move better_branch_name above get_ref in merge-recursive.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T07:35:20Z","receivedAt":"2006-12-28T07:35:20Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"To permit the get_ref function to use the static better_branch_name\nfunction to generate a string on demand I'm moving it up earlier.\nThe actual logic was not affected in this change.\n\nSigned-off-by: Shawn O. Pearce \n---\n merge-recursive.c | 24 ++++++++++++------------\n 1 files changed, 12 insertions(+), 12 deletions(-)\n\ndiff --git a/merge-recursive.c b/merge-recursive.c\nindex ca4f19e..1c84ed7 100644\n--- a/merge-recursive.c\n+++ b/merge-recursive.c\n@@ -1248,6 +1248,18 @@ static int merge(struct commit *h1,\n \treturn clean;\n }\n \n+static const char *better_branch_name(const char *branch)\n+{\n+\tstatic char githead_env[8 + 40 + 1];\n+\tchar *name;\n+\n+\tif (strlen(branch) != 40)\n+\t\treturn branch;\n+\tsprintf(githead_env, \"GITHEAD_%s\", branch);\n+\tname = getenv(githead_env);\n+\treturn name ? name : branch;\n+}\n+\n static struct commit *get_ref(const char *ref)\n {\n \tunsigned char sha1[20];\n@@ -1263,18 +1275,6 @@ static struct commit *get_ref(const char *ref)\n \treturn (struct commit *)object;\n }\n \n-static const char *better_branch_name(const char *branch)\n-{\n-\tstatic char githead_env[8 + 40 + 1];\n-\tchar *name;\n-\n-\tif (strlen(branch) != 40)\n-\t\treturn branch;\n-\tsprintf(githead_env, \"GITHEAD_%s\", branch);\n-\tname = getenv(githead_env);\n-\treturn name ? name : branch;\n-}\n-\n int main(int argc, char *argv[])\n {\n \tstatic const char *bases[2];\n-- \n1.4.4.3.gd2e4\n"},{"id":"30415","messageId":"20061228073523.GI17867@spearce.org","threadId":"6138","inReplyTo":"9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org","subject":"[PATCH 9/11] Allow merging bare trees in merge-recursive.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T07:35:24Z","receivedAt":"2006-12-28T07:35:24Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"To support wider use cases, such as from within `git am -3`, the\nmerge-recursive utility needs to accept not just commit-ish but\nalso tree-ish as arguments on its command line.\n\nIf given a tree-ish then merge-recursive will create a virtual commit\nwrapping it, with the subject of the commit set to the best name we\ncan derive for that tree, which is either the command line string\n(probably the SHA1), or whatever string appears in GITHEAD_*.\n\nSigned-off-by: Shawn O. Pearce \n---\n merge-recursive.c | 3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/merge-recursive.c b/merge-recursive.c\nindex 1c84ed7..bac16f5 100644\n--- a/merge-recursive.c\n+++ b/merge-recursive.c\n@@ -1268,6 +1268,9 @@ static struct commit *get_ref(const char *ref)\n \tif (get_sha1(ref, sha1))\n \t\tdie(\"Could not resolve ref '%s'\", ref);\n \tobject = deref_tag(parse_object(sha1), ref, strlen(ref));\n+\tif (object->type == OBJ_TREE)\n+\t\treturn make_virtual_commit((struct tree*)object,\n+\t\t\tbetter_branch_name(ref));\n \tif (object->type != OBJ_COMMIT)\n \t\treturn NULL;\n \tif (parse_commit((struct commit *)object))\n-- \n1.4.4.3.gd2e4\n"},{"id":"30414","messageId":"20061228073527.GJ17867@spearce.org","threadId":"6138","inReplyTo":"9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org","subject":"[PATCH 10/11] Use merge-recursive in git-am -3.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T07:35:27Z","receivedAt":"2006-12-28T07:35:27Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"By switching from merge-resolve to merge-recursive in the 3-way\nfallback behavior of git-am we gain a few benefits:\n\n * renames are automatically handled, like in rebase -m;\n * conflict hunks can reference the patch name;\n * its faster on Cygwin (less forks).\n\nSigned-off-by: Shawn O. Pearce \n---\n git-am.sh | 7 +++++--\n 1 files changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/git-am.sh b/git-am.sh\nindex c3bbd78..7c0bb60 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -88,10 +88,12 @@ It does not apply to blobs recorded in its index.\"\n # This is not so wrong. Depending on which base we picked,\n # orig_tree may be wildly different from ours, but his_tree\n # has the same set of wildly different changes in parts the\n- # patch did not touch, so resolve ends up canceling them,\n+ # patch did not touch, so recursive ends up canceling them,\n # saying that we reverted all those changes.\n \n- git-merge-resolve $orig_tree -- HEAD $his_tree || {\n+ eval GITHEAD_$his_tree='\"$SUBJECT\"'\n+ export GITHEAD_$his_tree\n+ git-merge-recursive $orig_tree -- HEAD $his_tree || {\n \t if test -d \"$GIT_DIR/rr-cache\"\n \t then\n \t\tgit-rerere\n@@ -99,6 +101,7 @@ It does not apply to blobs recorded in its index.\"\n \t echo Failed to merge in the changes.\n \t exit 1\n }\n+ unset GITHEAD_$his_tree\n }\n \n prec=4\n-- \n1.4.4.3.gd2e4\n"},{"id":"30413","messageId":"20061228073534.GK17867@spearce.org","threadId":"6138","inReplyTo":"9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org","subject":"[PATCH 11/11] Improve merge performance by avoiding in-index merges.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T07:35:34Z","receivedAt":"2006-12-28T07:35:34Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"In the early days of Git we performed a 3-way read-tree based merge\nbefore attempting any specific merge strategy, as our core merge\nstrategies of merge-one-file and merge-recursive were slower script\nbased programs which took far longer to execute. This was a good\nperformance optimization in the past, as most merges were able to\nbe handled strictly by `read-tree -m -u`.\n\nHowever now that merge-recursive is a C based program which performs\na full 3-way read-tree before it starts running we need to pay the\ncost of the 3-way read-tree twice if we have to do any sort of file\nlevel merging. This slows down some classes of simple merges which\n`read-tree -m -u` could not handle but which merge-recursive does\nautomatically.\n\nFor a really trivial merge which can be handled entirely by\n`read-tree -m -u`, skipping the read-tree and just going directly\ninto merge-recursive saves on average 50 ms on my PowerPC G4 system.\nMay sound odd, but it does appear to be true.\n\nIn a really simple merge which needs to use merge-recursive to handle\na file that was modified on both branches, skipping the read-tree\nin git-merge saves on average almost 100 ms (on the same PowerPC G4)\nas we avoid doing some work twice.\n\nWe only avoid `read-tree -m -u` if the only strategy to use is\nmerge-recursive, as not all merge strategies perform as well as\nmerge-recursive does.\n\nSigned-off-by: Shawn O. Pearce \n---\n git-merge.sh | 39 ++++++++++++++++++++++-----------------\n 1 files changed, 22 insertions(+), 17 deletions(-)\n\ndiff --git a/git-merge.sh b/git-merge.sh\nindex a8f673e..74d4fb0 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -341,23 +341,28 @@ f,*)\n ?,1,*,)\n \t# We are not doing octopus, not fast forward, and have only\n \t# one common. See if it is really trivial.\n-\tgit var GIT_COMMITTER_IDENT >/dev/null || exit\n-\n-\techo \"Trying really trivial in-index merge...\"\n-\tgit-update-index --refresh 2>/dev/null\n-\tif git-read-tree --trivial -m -u -v $common $head \"$1\" &&\n-\t result_tree=$(git-write-tree)\n-\tthen\n-\t echo \"Wonderful.\"\n-\t result_commit=$(\n-\t echo \"$merge_msg\" |\n-\t git-commit-tree $result_tree -p HEAD -p \"$1\"\n-\t ) || exit\n-\t finish \"$result_commit\" \"In-index merge\"\n-\t dropsave\n-\t exit 0\n-\tfi\n-\techo \"Nope.\"\n+\tcase \"$use_strategies\" in\n+\trecursive|'recursive '|recur|'recur ')\n+\t\t: run merge later\n+\t\t;;\n+\t*)\n+\t\tgit var GIT_COMMITTER_IDENT >/dev/null || exit\n+\t\techo \"Trying really trivial in-index merge...\"\n+\t\tgit-update-index --refresh 2>/dev/null\n+\t\tif git-read-tree --trivial -m -u -v $common $head \"$1\" &&\n+\t\t result_tree=$(git-write-tree)\n+\t\tthen\n+\t\t\techo \"Wonderful.\"\n+\t\t\tresult_commit=$(\n+\t\t\t\techo \"$merge_msg\" |\n+\t\t\t\tgit-commit-tree $result_tree -p HEAD -p \"$1\"\n+\t\t\t) || exit\n+\t\t\tfinish \"$result_commit\" \"In-index merge\"\n+\t\t\tdropsave\n+\t\t\texit 0\n+\t\tfi\n+\t\techo \"Nope.\"\n+\tesac\n \t;;\n *)\n \t# An octopus. If we can reach all the remote we are up to date.\n-- \n1.4.4.3.gd2e4\n"},{"id":"30418","messageId":"7vk60cxx1t.fsf@assigned-by-dhcp.cox.net","threadId":"6138","inReplyTo":"20061228073523.GI17867@spearce.org","subject":"Re: [PATCH 9/11] Allow merging bare trees in merge-recursive.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-28T08:08:14Z","receivedAt":"2006-12-28T08:08:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> To support wider use cases, such as from within `git am -3`, the\n> merge-recursive utility needs to accept not just commit-ish but\n> also tree-ish as arguments on its command line.\n\nYes, this was one of the things I did not like about\nmerge-recursive (I think the original Python one may have\naccepted three trees but I am not sure --- it's so looong ago).\n"},{"id":"30419","messageId":"7vejqkxx1s.fsf@assigned-by-dhcp.cox.net","threadId":"6138","inReplyTo":"20061228073534.GK17867@spearce.org","subject":"Re: [PATCH 11/11] Improve merge performance by avoiding in-index merges.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-28T08:08:15Z","receivedAt":"2006-12-28T08:08:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> For a really trivial merge which can be handled entirely by\n> `read-tree -m -u`, skipping the read-tree and just going directly\n> into merge-recursive saves on average 50 ms on my PowerPC G4 system.\n> May sound odd, but it does appear to be true.\n\nThis sounds awfully attractive yet disruptive. Should be cooked\nin 'next' for at least two weeks, maybe even longer to verify\nthat performance figure holds for everybody.\n\nAlso I think you need to make sure running merge-recursive\nupfront offers the same safety as the code you are removing then\nrunning it, as I vaguely recall its checking for local changes\nwere slightly looser.\n"},{"id":"30417","messageId":"7v8xgsxx1r.fsf@assigned-by-dhcp.cox.net","threadId":"6138","inReplyTo":"20061228073517.GG17867@spearce.org","subject":"Re: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-28T08:08:16Z","receivedAt":"2006-12-28T08:08:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Users may also now use `git-pull . foo~3` to merge the early part\n> of branch foo. This was not previously possible as git-fetch does\n> not know how to fetch foo~3 from a repository.\n\nI personally think this is not an improvement, but rather a new\nsource of confusion. If the user wants a local merge, there is\n'git-merge'. And the distinction between the commands makes it\nclear that local merge can merge any commits exactly because\nthey are available locally, while remote fetch+merge needs to\nchoose from what the remote side offers so not arbitrary commits\nlike foo@{3.days.ago} cannot be pulled.\n\nAlso I thought there was a configuration variable that talks\nabout \"remote = .\" (didn't I merge that patch -- I do not\nremember offhand) and I wonder how that interacts with this\nchange.\n\nHow much performance gain are we talking about here?\n"},{"id":"30420","messageId":"20061228081701.GA18029@spearce.org","threadId":"6138","inReplyTo":"7v8xgsxx1r.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T08:17:01Z","receivedAt":"2006-12-28T08:17:01Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > Users may also now use `git-pull . foo~3` to merge the early part\n> > of branch foo. This was not previously possible as git-fetch does\n> > not know how to fetch foo~3 from a repository.\n> \n> I personally think this is not an improvement, but rather a new\n> source of confusion. If the user wants a local merge, there is\n> 'git-merge'. And the distinction between the commands makes it\n> clear that local merge can merge any commits exactly because\n> they are available locally, while remote fetch+merge needs to\n> choose from what the remote side offers so not arbitrary commits\n> like foo@{3.days.ago} cannot be pulled.\n\nTrue. But you know you are doing a local merge with `git pull .`.\nSo why should you be restricted from using the capabilities of a\nlocal merge just because the frontend you prefer to use is limited\nwhen its doing remote merges?\n\nI didn't really do this change for this feature, I did for the\nperformance (see below).\n \n> Also I thought there was a configuration variable that talks\n> about \"remote = .\" (didn't I merge that patch -- I do not\n> remember offhand) and I wonder how that interacts with this\n> change.\n\nI must have missed that discussion on the list. Not sure how as\nI read everything. Oh, its that grey stuff upstairs not recalling\nhistory as well as Git does... ;-)\n \n> How much performance gain are we talking about here?\n\nIt halves my 'git pull . foo' times on my Mac OS X PowerPC 64 system:\n\n Without: ~900 ms\n With: ~440 ms\n\n-- \nShawn.\n"},{"id":"30421","messageId":"20061228082441.GB18029@spearce.org","threadId":"6138","inReplyTo":"7vejqkxx1s.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 11/11] Improve merge performance by avoiding in-index merges.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T08:24:41Z","receivedAt":"2006-12-28T08:24:41Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > For a really trivial merge which can be handled entirely by\n> > `read-tree -m -u`, skipping the read-tree and just going directly\n> > into merge-recursive saves on average 50 ms on my PowerPC G4 system.\n> > May sound odd, but it does appear to be true.\n> \n> This sounds awfully attractive yet disruptive. Should be cooked\n> in 'next' for at least two weeks, maybe even longer to verify\n> that performance figure holds for everybody.\n\nI agree. I have been thinking about doing this for a while but\njust never sat down and did it until night. To get it in 1.5.0 I\nprobably should have done this back in early Decmember. Whoops,\nbad timing on my part. ;-)\n \n> Also I think you need to make sure running merge-recursive\n> upfront offers the same safety as the code you are removing then\n> running it, as I vaguely recall its checking for local changes\n> were slightly looser.\n\n>From what I can tell, merge-recursive and read-tree -m are running\nexactly the same code. So aside from the fact that I bypassed the\nupdate-index --refresh by accident, I don't think they will have\ndifferent outcomes.\n\n-- \nShawn.\n"},{"id":"30434","messageId":"7vac18wego.fsf@assigned-by-dhcp.cox.net","threadId":"6138","inReplyTo":"20061228081701.GA18029@spearce.org","subject":"Re: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-28T09:35:03Z","receivedAt":"2006-12-28T09:35:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n>> I personally think this is not an improvement, but rather a new\n>> source of confusion. If the user wants a local merge, there is\n>> 'git-merge'. And the distinction between the commands makes it\n>> clear that local merge can merge any commits exactly because\n>> they are available locally, while remote fetch+merge needs to\n>> choose from what the remote side offers so not arbitrary commits\n>> like foo@{3.days.ago} cannot be pulled.\n>\n> True. But you know you are doing a local merge with `git pull .`.\n> So why should you be restricted from using the capabilities of a\n> local merge just because the frontend you prefer to use is limited\n> when its doing remote merges?\n\nPersonally I do not mind much about it because I happen to\nunderstand what \"git pull\" is doing.\n\nBut I do mind having to spend time defending why we special case\nonly the dot form, when people with twisted minds start\ncomplaining about inconsistencies among \"git pull .git\", \"git\npull .\" and \"git pull $(pwd)\". And no, I do not want to\nintroduce likes of \"test `cd .git && pwd` == `cd $1 && pwd`\" in\nthe code to make them behave consistently.\n"},{"id":"30477","messageId":"Pine.LNX.4.63.0612291840450.19693@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6138","inReplyTo":"20061228082441.GB18029@spearce.org","subject":"Re: [PATCH 11/11] Improve merge performance by avoiding in-index merges.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-29T17:44:59Z","receivedAt":"2006-12-29T17:44:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 28 Dec 2006, Shawn Pearce wrote:\n\n> From what I can tell, merge-recursive and read-tree -m are running\n> exactly the same code.\n\nThat was the idea of tags/v1.4.3~333^2 \"read-tree: move merge functions \nto the library\" and v1.4.3~236^2~10 \"merge-recur: use the unpack_trees() \ninterface instead of exec()ing read-tree\".\n\nCiao,\nDscho\n"}]}