{"thread":{"id":"6345","subject":"What's in git.git and announcing GIT v1.5.0-rc1","startedAt":"2007-01-12T02:43:53Z","lastAt":"2007-01-16T15:14:46Z","messageCount":28,"participants":["Junio C Hamano","Shawn O. Pearce","Andy Parkins","koreth@midwinter.com","Steven Grimm","Josef Weidendorfer","lamikr","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"31536","messageId":"7v8xg9x8uu.fsf@assigned-by-dhcp.cox.net","threadId":"6345","inReplyTo":null,"subject":"What's in git.git and announcing GIT v1.5.0-rc1","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-12T02:43:53Z","receivedAt":"2007-01-12T02:43:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The tip of 'master' branch is tagged as v1.5.0-rc1; this means a\nfew things:\n\n - The focus is shifted to stabilize 'master'. Fixes to what\n are already there are very much appreciated.\n\n - I'll change my $PATH to use the 'master' version, not 'next',\n for my own use until v1.5.0 final. I ask people who usually\n follow 'next' to do the same so that we can catch breakages\n on 'master'.\n\n - No new features nor major changes, whether they have been\n cooking in 'next' or not, will be merged to 'master' until\n v1.5.0 final. I might drop patches on the floor that are not\n meant for 'master', although I intend to try hard to keep up\n with whatever the list comes up with.\n\nTonight's update merges a handful remaining topics from 'next',\nalong with fixes and updates directly applied to 'master'.\n\n\n* The 'master' branch has these since the last announcement.\n\n Alex Riesen (1):\n Speed-up recursive by flushing index only once for all entries\n\n Eric Wong (1):\n Avoid errors and warnings when attempting to do I/O on zero bytes\n\n Johannes Schindelin (2):\n Sanitize for_each_reflog_ent()\n Fix t1410 for core.filemode==false\n\n Junio C Hamano (20):\n Move initialization of log_all_ref_updates\n Introduce is_bare_repository() and core.bare configuration variable\n git-fetch: allow updating the current branch in a bare repository.\n git-status: show detached HEAD\n Detached HEAD (experimental)\n git-checkout: do not warn detaching HEAD when it is already detached.\n git-checkout: rewording comments regarding detached HEAD.\n git-checkout: safety when coming back from the detached HEAD state.\n git-checkout: fix branch name output from the command\n git-checkout: safety check for detached HEAD checks existing refs\n git-checkout: handle local changes sanely when detaching HEAD\n Makefile: remove $foo when $foo.exe is built/installed.\n merge-recursive: do not use on-file index when not needed.\n Document git-init\n index-pack: write-or-die instead of unchecked write-in-full.\n config-set: check write-in-full returns in set_multivar\n git-rm: do not fail on already removed file.\n git-status: wording update to deal with deleted files.\n plug a few leaks in revision walking used in describe.\n GIT v1.5.0-rc1\n\n Jürgen Rühle (2):\n send-email: work around double encoding of in-body From field.\n Provide better feedback for the untracked only case in status output\n\n Lars Hjemli (1):\n git-branch: show detached HEAD\n\n Linus Torvalds (3):\n write-cache: do not leak the serialized cache-tree data.\n write_in_full: really write in full or return error on disk full.\n Better error messages for corrupt databases\n\n Nicolas Pitre (1):\n Add git-init documentation.\n\n Shawn O. Pearce (4):\n Don't save the commit buffer in git-describe.\n Make git-describe a builtin.\n Disallow working directory commands in a bare repository.\n Chose better tag names in git-describe after merges.\n"},{"id":"31538","messageId":"7vzm8ox5dn.fsf@assigned-by-dhcp.cox.net","threadId":"6345","inReplyTo":"7v8xg9x8uu.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] reflog-expire: brown paper bag fix.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-12T03:59:00Z","receivedAt":"2007-01-12T03:59:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When --stale-fix is not passed, the code did not initialize the\ntwo commit objects properly.\n\nSigned-off-by: Junio C Hamano \n---\n\n * If you see Segfault from \"git gc\", it would have left two\n .lock files under .git/refs/ and .git/logs/refs; your\n repository has not be corrupted with this. Please remove the\n two leftover .lock files by hand, apply this patch and\n re-run.\n\n builtin-reflog.c | 18 ++++++++++++------\n 1 files changed, 12 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin-reflog.c b/builtin-reflog.c\nindex ca22452..7206b7a 100644\n--- a/builtin-reflog.c\n+++ b/builtin-reflog.c\n@@ -173,7 +173,6 @@ static int keep_entry(struct commit **it, unsigned char *sha1)\n {\n \tstruct commit *commit;\n \n-\t*it = NULL;\n \tif (is_null_sha1(sha1))\n \t\treturn 1;\n \tcommit = lookup_commit_reference_gently(sha1, 1);\n@@ -204,15 +203,22 @@ static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,\n \tif (timestamp < cb->cmd->expire_total)\n \t\tgoto prune;\n \n+\told = new = NULL;\n \tif (cb->cmd->stalefix &&\n \t (!keep_entry(&old, osha1) || !keep_entry(&new, nsha1)))\n \t\tgoto prune;\n \n-\tif ((timestamp < cb->cmd->expire_unreachable) &&\n-\t (!cb->ref_commit ||\n-\t (old && !in_merge_bases(old, cb->ref_commit)) ||\n-\t (new && !in_merge_bases(new, cb->ref_commit))))\n-\t\tgoto prune;\n+\tif (timestamp < cb->cmd->expire_unreachable) {\n+\t\tif (!cb->ref_commit)\n+\t\t\tgoto prune;\n+\t\tif (!old && !is_null_sha1(osha1))\n+\t\t\told = lookup_commit_reference_gently(osha1, 1);\n+\t\tif (!new && !is_null_sha1(nsha1))\n+\t\t\tnew = lookup_commit_reference_gently(nsha1, 1);\n+\t\tif ((old && !in_merge_bases(old, cb->ref_commit)) ||\n+\t\t (new && !in_merge_bases(new, cb->ref_commit)))\n+\t\t\tgoto prune;\n+\t}\n \n \tif (cb->newlog) {\n \t\tchar sign = (tz < 0) ? '-' : '+';\n-- \n1.5.0.rc1\n"},{"id":"31539","messageId":"20070112040200.GA24195@spearce.org","threadId":"6345","inReplyTo":"7vzm8ox5dn.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] reflog-expire: brown paper bag fix.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-12T04:02:01Z","receivedAt":"2007-01-12T04:02:01Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> When --stale-fix is not passed, the code did not initialize the\n> two commit objects properly.\n> \n> Signed-off-by: Junio C Hamano \n> ---\n> \n> * If you see Segfault from \"git gc\", it would have left two\n> .lock files under .git/refs/ and .git/logs/refs; your\n> repository has not be corrupted with this. Please remove the\n> two leftover .lock files by hand, apply this patch and\n> re-run.\n\nThanks for fixing this Junio. I noticed it myself today and meant\nto debug it, but haven't had a chance to do it yet.\n\n-- \nShawn.\n"},{"id":"31559","messageId":"200701121501.24642.andyparkins@gmail.com","threadId":"6345","inReplyTo":"7v8xg9x8uu.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git and announcing GIT v1.5.0-rc1","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-12T15:01:07Z","receivedAt":"2007-01-12T15:01:07Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007, January 12 02:43, Junio C Hamano wrote:\n\n> - I'll change my $PATH to use the 'master' version, not 'next',\n> for my own use until v1.5.0 final. I ask people who usually\n> follow 'next' to do the same so that we can catch breakages\n> on 'master'.\n\nMinor thing: git-rebase, git-cherry-pick and git-pull (and presumably \ngit-merge) all need to be the repository root to work. If that is \nintentional, a better message than \"fatal: Not a git repository: '.git'\" \nwould be appropriate.\n\nFor me, I'd prefer that they worked in subdirectories. I do all almost all \ndevelopment in \"src/\" and having to change up a directory just to run git \ncommands is inconvenient.\n\n\n\nAndy\n\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\nandyparkins@gmail.com\n"},{"id":"31572","messageId":"20070112183548.GA3940@midwinter.com","threadId":"6345","inReplyTo":"200701121501.24642.andyparkins@gmail.com","subject":"[PATCH] Friendlier error message for commands that can't be run from a subdirectory.","fromName":"","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-12T18:35:48Z","receivedAt":"2007-01-12T18:35:48Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Signed-off-by: Steven Grimm \n---\n\nThis doesn't fix the underlying problem (those commands ought to work\nfrom any directory) but it is at least less baffling for the common case.\nIt's pretty braindead -- if you for some reason have a .git directory\ninside one of your subdirectories, you'll get the old error message.\n\n git-sh-setup.sh | 3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/git-sh-setup.sh b/git-sh-setup.sh\nindex 4a02b38..803a3bc 100755\n--- a/git-sh-setup.sh\n+++ b/git-sh-setup.sh\n@@ -60,6 +60,9 @@ esac\n if [ -z \"$SUBDIRECTORY_OK\" ]\n then\n \t: ${GIT_DIR=.git}\n+\tif [ ! -d \"$GIT_DIR\" ]; then\n+\t\tdie \"This command must be run from the root directory of a git repository.\"\n+\tfi\n \tGIT_DIR=$(GIT_DIR=\"$GIT_DIR\" git-rev-parse --git-dir) || exit\n else\n \tGIT_DIR=$(git-rev-parse --git-dir) || exit\n-- \n1.5.0.rc0.g4083\n"},{"id":"31573","messageId":"45A7D5F6.9020606@midwinter.com","threadId":"6345","inReplyTo":"200701121501.24642.andyparkins@gmail.com","subject":"Re: What's in git.git and announcing GIT v1.5.0-rc1","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-12T18:39:50Z","receivedAt":"2007-01-12T18:39:50Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Andy Parkins wrote:\n> For me, I'd prefer that they worked in subdirectories. I do all almost all \n> development in \"src/\" and having to change up a directory just to run git \n> commands is inconvenient.\n> \n\nI agree; I find that inconvenient too. The only catch I can see is that \nthere might be an expectation that if you run, say, \"git-pull\" in the \nsrc directory, it will only update the files in src and will leave the \nones in the other top-level directories alone. For example, \"svn update\" \nworks that way.\n\nBut honestly I think touching files outside the current subdirectory is \nmuch less of an inconvenience (and it's something you only get surprised \nby once, if at all) than not working in subdirectories at all.\n\n-Steve\n"},{"id":"31575","messageId":"20070112191044.GA5113@midwinter.com","threadId":"6345","inReplyTo":"200701121501.24642.andyparkins@gmail.com","subject":"[PATCH] Change to the repository's root directory if needed.","fromName":"","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-12T19:10:44Z","receivedAt":"2007-01-12T19:10:44Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Signed-off-by: Steven Grimm \n---\n\nOr try this instead. It seems to work in my limited testing, but it's\npossible this breaks something somewhere. The only weird thing here\nis that if, e.g., you have a file foo.c in the top-level directory and\nyou run \"git pull\" from a subdirectory, you'll see a message indicating\nthat \"foo.c\" was updated, implying that it's updating that file in the\ncurrent directory. (Output about files in subdirectories, to my eye,\nfeels less ambiguous in that respect.) But after running with this for\njust a few minutes, I'm willing to put up with that in exchange for\nnot having to manually cd.\n\n git-sh-setup.sh | 9 +++++++--\n 1 files changed, 7 insertions(+), 2 deletions(-)\n\ndiff --git a/git-sh-setup.sh b/git-sh-setup.sh\nindex 4a02b38..d1c78c4 100755\n--- a/git-sh-setup.sh\n+++ b/git-sh-setup.sh\n@@ -59,8 +59,13 @@ esac\n # Make sure we are in a valid repository of a vintage we understand.\n if [ -z \"$SUBDIRECTORY_OK\" ]\n then\n-\t: ${GIT_DIR=.git}\n-\tGIT_DIR=$(GIT_DIR=\"$GIT_DIR\" git-rev-parse --git-dir) || exit\n+\tGIT_DIR=$(git-rev-parse --git-dir) || exit\n+\tif [ \"$GIT_DIR\" != \".git\" -a \"$(basename \\\"$GIT_DIR\\\")\" = \".git\" ]\n+\tthen\n+\t\t# In a subdirectory of a non-bare repository; move to root dir\n+\t\tcd \"`dirname \\\"$GIT_DIR\\\"`\" || \\\n+\t\t\tdie \"Can't change to repository root directory\"\n+\tfi\n else\n \tGIT_DIR=$(git-rev-parse --git-dir) || exit\n fi\n-- \n1.5.0.rc0.g4083\n"},{"id":"31585","messageId":"7vy7o8rnyw.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6345","inReplyTo":"200701121501.24642.andyparkins@gmail.com","subject":"[PATCH] Explain \"Not a git repository: '.git'\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-12T20:26:15Z","receivedAt":"2007-01-12T20:26:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins noticed that the error message some \"whole tree\"\noriented commands emit is stated misleadingly when they refused\nto run from a subdirectory.\n\nWe could probably allow some of them to work from a subdirectory\nbut that is a semantic change that could have unintended side\neffects, so let's start at first by rewording the error message\nto be easier to read without doing anything else to be safe.\n\nSigned-off-by: Junio C Hamano \n---\n\n Andy Parkins writes:\n\n > Minor thing: git-rebase, git-cherry-pick and git-pull (and\n > presumably git-merge) all need to be the repository root to\n > work. If that is intentional, a better message than \"fatal:\n > Not a git repository: '.git'\" would be appropriate.\n >\n > For me, I'd prefer that they worked in subdirectories. I do\n > all almost all development in \"src/\" and having to change up a\n > directory just to run git commands is inconvenient.\n\n Thanks; let's do this for now.\n\n git-sh-setup.sh | 6 +++++-\n 1 files changed, 5 insertions(+), 1 deletions(-)\n\ndiff --git a/git-sh-setup.sh b/git-sh-setup.sh\nindex 4a02b38..57f7f77 100755\n--- a/git-sh-setup.sh\n+++ b/git-sh-setup.sh\n@@ -60,7 +60,11 @@ esac\n if [ -z \"$SUBDIRECTORY_OK\" ]\n then\n \t: ${GIT_DIR=.git}\n-\tGIT_DIR=$(GIT_DIR=\"$GIT_DIR\" git-rev-parse --git-dir) || exit\n+\tGIT_DIR=$(GIT_DIR=\"$GIT_DIR\" git-rev-parse --git-dir) || {\n+\t\texit=$?\n+\t\techo >&2 \"You need to run this command from the toplevel of the working tree.\"\n+\t\texit $exit\n+\t}\n else\n \tGIT_DIR=$(git-rev-parse --git-dir) || exit\n fi\n-- \n1.5.0.rc1.g397d\n"},{"id":"31587","messageId":"7vtzywrmmz.fsf@assigned-by-dhcp.cox.net","threadId":"6345","inReplyTo":"7vy7o8rnyw.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Explain \"Not a git repository: '.git'\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-12T20:55:00Z","receivedAt":"2007-01-12T20:55:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I have three follow-up patches, two are probably Ok (but I'd\nrather not apply them to 'master' now -rc1 cycle is on), and the\nlast one debatable.\n\n [PATCH 1/3] Define cd_to_toplevel shell function in git-sh-setup\n [PATCH 2/3] Use cd_to_toplevel in scripts that implement it by hand.\n [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory\n"},{"id":"31588","messageId":"7vmz4ormmc.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6345","inReplyTo":"7vy7o8rnyw.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH 1/3] Define cd_to_toplevel shell function in git-sh-setup","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-12T20:55:23Z","receivedAt":"2007-01-12T20:55:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\nSigned-off-by: Junio C Hamano \n---\n git-sh-setup.sh | 11 +++++++++++\n 1 files changed, 11 insertions(+), 0 deletions(-)\n\ndiff --git a/git-sh-setup.sh b/git-sh-setup.sh\nindex 57f7f77..6b1c142 100755\n--- a/git-sh-setup.sh\n+++ b/git-sh-setup.sh\n@@ -36,6 +36,17 @@ is_bare_repository () {\n \tesac\n }\n \n+cd_to_toplevel () {\n+\tcdup=$(git-rev-parse --show-cdup)\n+\tif test ! -z \"$cdup\"\n+\tthen\n+\t\tcd \"$cdup\" || {\n+\t\t\techo >&2 \"Cannot chdir to $cdup, the toplevel of the working tree\"\n+\t\t\texit 1\n+\t\t}\n+\tfi\n+}\n+\n require_work_tree () {\n \ttest $(is_bare_repository) = false ||\n \tdie \"fatal: $0 cannot be used without a working tree.\"\n-- \n1.5.0.rc1.g397d\n"},{"id":"31589","messageId":"7vfyagrmlu.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6345","inReplyTo":"7vy7o8rnyw.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH 2/3] Use cd_to_toplevel in scripts that implement it by hand.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-12T20:55:41Z","receivedAt":"2007-01-12T20:55:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This converts scripts that do \"cd $(rev-parse --show-cdup)\" by\nhand to use cd_to_toplevel.\n\nI think git-fetch does not have to go to the toplevel, but that\nshould be dealt with in a separate patch.\n\nSigned-off-by: Junio C Hamano \n---\n git-checkout.sh | 6 +-----\n git-commit.sh | 22 ++++++++--------------\n git-fetch.sh | 6 +-----\n git-reset.sh | 6 +-----\n 4 files changed, 11 insertions(+), 29 deletions(-)\n\ndiff --git a/git-checkout.sh b/git-checkout.sh\nindex a2b8e4f..66e40b9 100755\n--- a/git-checkout.sh\n+++ b/git-checkout.sh\n@@ -135,11 +135,7 @@ fi\n \n # We are switching branches and checking out trees, so\n # we *NEED* to be at the toplevel.\n-cdup=$(git-rev-parse --show-cdup)\n-if test ! -z \"$cdup\"\n-then\n-\tcd \"$cdup\"\n-fi\n+cd_to_toplevel\n \n [ -z \"$new\" ] && new=$old && new_name=\"$old_name\"\n \ndiff --git a/git-commit.sh b/git-commit.sh\nindex eddd863..9fdf234 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -316,22 +316,16 @@ esac\n ################################################################\n # Prepare index to have a tree to be committed\n \n-TOP=`git-rev-parse --show-cdup`\n-if test -z \"$TOP\"\n-then\n-\tTOP=./\n-fi\n-\n case \"$all,$also\" in\n t,)\n \tsave_index &&\n \t(\n-\t\tcd \"$TOP\"\n-\t\tGIT_INDEX_FILE=\"$NEXT_INDEX\"\n-\t\texport GIT_INDEX_FILE\n+\t\tcd_to_toplevel &&\n+\t\tGIT_INDEX_FILE=\"$NEXT_INDEX\" &&\n+\t\texport GIT_INDEX_FILE &&\n \t\tgit-diff-files --name-only -z |\n \t\tgit-update-index --remove -z --stdin\n-\t)\n+\t) || exit\n \t;;\n ,t)\n \tsave_index &&\n@@ -339,11 +333,11 @@ t,)\n \n \tgit-diff-files --name-only -z -- \"$@\" |\n \t(\n-\t\tcd \"$TOP\"\n-\t\tGIT_INDEX_FILE=\"$NEXT_INDEX\"\n-\t\texport GIT_INDEX_FILE\n+\t\tcd_to_toplevel &&\n+\t\tGIT_INDEX_FILE=\"$NEXT_INDEX\" &&\n+\t\texport GIT_INDEX_FILE &&\n \t\tgit-update-index --remove -z --stdin\n-\t)\n+\t) || exit\n \t;;\n ,)\n \tcase \"$#\" in\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex c58704d..87b940b 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -5,12 +5,8 @@ USAGE=' ...'\n SUBDIRECTORY_OK=Yes\n . git-sh-setup\n set_reflog_action \"fetch $*\"\n+cd_to_toplevel ;# probably unnecessary...\n \n-TOP=$(git-rev-parse --show-cdup)\n-if test ! -z \"$TOP\"\n-then\n-\tcd \"$TOP\"\n-fi\n . git-parse-remote\n _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'\n _x40=\"$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40\"\ndiff --git a/git-reset.sh b/git-reset.sh\nindex b9045bc..91c7e6e 100755\n--- a/git-reset.sh\n+++ b/git-reset.sh\n@@ -53,11 +53,7 @@ then\n \texit\n fi\n \n-TOP=$(git-rev-parse --show-cdup)\n-if test ! -z \"$TOP\"\n-then\n-\tcd \"$TOP\"\n-fi\n+cd_to_toplevel\n \n if test \"$reset_type\" = \"--hard\"\n then\n-- \n1.5.0.rc1.g397d\n"},{"id":"31590","messageId":"7vac0orml9.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6345","inReplyTo":"7vy7o8rnyw.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH 3/3] Allow whole-tree operations to be started from a subdirectory","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-12T20:56:02Z","receivedAt":"2007-01-12T20:56:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This updates five commands (merge, pull, rebase, revert and cherry-pick)\nso that they can be started from a subdirectory.\n\nThis may not actually be what we want to do. These commands are\ninherently whole-tree operations, and an inexperienced user may\nmistakenly expect a \"git pull\" from a subdirectory would merge\nonly the subdirectory the command started from.\n\nSigned-off-by: Junio C Hamano \n---\n git-merge.sh | 4 +++-\n git-pull.sh | 4 +++-\n git-rebase.sh | 3 +++\n git-revert.sh | 3 +++\n 4 files changed, 12 insertions(+), 2 deletions(-)\n\ndiff --git a/git-merge.sh b/git-merge.sh\nindex 3eef048..7de83dc 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -5,12 +5,14 @@\n \n USAGE='[-n] [--no-commit] [--squash] [-s ] [-m=] +'\n \n+SUBDIRECTORY_OK=Yes\n . git-sh-setup\n set_reflog_action \"merge $*\"\n require_work_tree\n+cd_to_toplevel\n \n test -z \"$(git ls-files -u)\" ||\n-\tdie \"You are in a middle of conflicted merge.\"\n+\tdie \"You are in the middle of a conflicted merge.\"\n \n LF='\n '\ndiff --git a/git-pull.sh b/git-pull.sh\nindex e9826fc..9592617 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -6,12 +6,14 @@\n \n USAGE='[-n | --no-summary] [--no-commit] [-s strategy]... [] ...'\n LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'\n+SUBDIRECTORY_OK=Yes\n . git-sh-setup\n set_reflog_action \"pull $*\"\n require_work_tree\n+cd_to_toplevel\n \n test -z \"$(git ls-files -u)\" ||\n-\tdie \"You are in a middle of conflicted merge.\"\n+\tdie \"You are in the middle of a conflicted merge.\"\n \n strategy_args= no_summary= no_commit= squash=\n while case \"$#,$1\" in 0) break ;; *,-*) ;; *) break ;; esac\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 98f9558..c8bd0f9 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -27,9 +27,12 @@ Example: git-rebase master~1 topic\n / --> /\n D---E---F---G master D---E---F---G master\n '\n+\n+SUBDIRECTORY_OK=Yes\n . git-sh-setup\n set_reflog_action rebase\n require_work_tree\n+cd_to_toplevel\n \n RESOLVEMSG=\"\n When you have resolved this problem run \\\"git rebase --continue\\\".\ndiff --git a/git-revert.sh b/git-revert.sh\nindex fcca3eb..224e654 100755\n--- a/git-revert.sh\n+++ b/git-revert.sh\n@@ -19,8 +19,11 @@ case \"$0\" in\n \techo >&2 \"What are you talking about?\"\n \texit 1 ;;\n esac\n+\n+SUBDIRECTORY_OK=Yes ;# we will cd up\n . git-sh-setup\n require_work_tree\n+cd_to_toplevel\n \n no_commit=\n while case \"$#\" in 0) break ;; esac\n-- \n1.5.0.rc1.g397d\n"},{"id":"31595","messageId":"7vtzywq703.fsf@assigned-by-dhcp.cox.net","threadId":"6345","inReplyTo":"20070112191044.GA5113@midwinter.com","subject":"Re: [PATCH] Change to the repository's root directory if needed.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-12T21:18:04Z","receivedAt":"2007-01-12T21:18:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"koreth@midwinter.com writes:\n\n> Signed-off-by: Steven Grimm \n> ---\n>\n> Or try this instead. It seems to work in my limited testing, but it's\n> possible this breaks something somewhere.\n\nPorcelains that define SUBDIRECTORY_OK but do not do cdup are\nvery valid, and they should not be cd'ed up automatically.\nThey set SUBDIRECTORY_OK for three different reasons:\n\n (1) some of them always cdup themselves. git-fetch is the sole\n example I can think of and I do not think it even needs to.\n\n (2) some of them stay in the subdirectory, and rely on the\n plumbing level to limit the scope of operation with the\n current directory. The most notable example used to be\n \"git-diff\" but that is now a built-in.\n\n Also they take filename that could be relative to the\n current directory. git-commit is an example.\n\n (3) some of them are complex mixture of (1) and (2) -- most\n notable is git-checkout\n\n (4) some of them do not care. git-verify-tag is an example.\n\nYour patch assumes everybody is either (1) or (4). I would not\nbe surprised if you see breakage everywhere. For example, I\nthink you just broke \"git-tag -F \". Also I think you\nsurprised users of git-clean (which I do not use personally);\nit would start removing stuff outside of the current directory.\n"},{"id":"31599","messageId":"45A807A9.3090402@midwinter.com","threadId":"6345","inReplyTo":"7vtzywq703.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Change to the repository's root directory if needed.","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-12T22:11:53Z","receivedAt":"2007-01-12T22:11:53Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Porcelains that define SUBDIRECTORY_OK but do not do cdup are\n> very valid, and they should not be cd'ed up automatically.\n> \n\nMy patch doesn't do the cd if SUBDIRECTORY_OK is defined, for exactly \nthat reason.\n\n-Steve\n"},{"id":"31609","messageId":"7vvejbq1gt.fsf@assigned-by-dhcp.cox.net","threadId":"6345","inReplyTo":"45A807A9.3090402@midwinter.com","subject":"Re: [PATCH] Change to the repository's root directory if needed.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-12T23:17:38Z","receivedAt":"2007-01-12T23:17:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> Junio C Hamano wrote:\n>> Porcelains that define SUBDIRECTORY_OK but do not do cdup are\n>> very valid, and they should not be cd'ed up automatically.\n>>\n>\n> My patch doesn't do the cd if SUBDIRECTORY_OK is defined, for exactly\n> that reason.\n\nAh, I misread the patch. Sorry.\n\nBut the point is that the scripts that do not currently say\nSUBDIRECTORY_OK have not even been audited to see if it makes\nsense to always cd to the top. Isn't your patch making as if\nthey are saying SUBDIRECTORY_OK=Yes and cd to the top upfront is\nthe right thing to do?\n"},{"id":"31640","messageId":"200701131642.16824.andyparkins@gmail.com","threadId":"6345","inReplyTo":"7vac0orml9.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-13T16:42:15Z","receivedAt":"2007-01-13T16:42:15Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007, January 12 20:56, Junio C Hamano wrote:\n\n> This may not actually be what we want to do. These commands are\n> inherently whole-tree operations, and an inexperienced user may\n> mistakenly expect a \"git pull\" from a subdirectory would merge\n> only the subdirectory the command started from.\n\nYou're right it might be confusing at first, however, I still think it's the \nright thing to do.\n\nHere's my reasoning: for a while, with subversion as a user you feel all warm \ninside that commands only work on the current subdirectory, so \"svn update\" \nwould only update the current subdirectory to the latest revision. Of course \nas git users we all see the horrendous potential errors that behaviour can \ninduce. It creates subdirectories with mixed versions from the repository - \nabsolute disaster pends.\n\nGit is of course far more sensible, if you checkout in a subdirectory the \nwhole working directory changes, meaning everything is always nicely in sync \nand really does represent a snapshot at any time.\n\nNow; once you (as a new user) accept that git checkout should (and does) \ncheckout the whole working directory regardless of where you are, then by \nextension every other working-directory-wide command should do the same.\n\nPhew. I'm too noisy. What a verbose way of saying\n fromAOL(\"me too\");\n\n\nAndy\n\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\nandyparkins@gmail.com\n"},{"id":"31664","messageId":"200701140111.20671.Josef.Weidendorfer@gmx.de","threadId":"6345","inReplyTo":"7vac0orml9.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-01-14T00:11:20Z","receivedAt":"2007-01-14T00:11:20Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 12 January 2007 21:56, Junio C Hamano wrote:\n> This updates five commands (merge, pull, rebase, revert and cherry-pick)\n> so that they can be started from a subdirectory.\n> \n> This may not actually be what we want to do. These commands are\n> inherently whole-tree operations, and an inexperienced user may\n> mistakenly expect a \"git pull\" from a subdirectory would merge\n> only the subdirectory the command started from.\n\nYes, this IMHO is a problem.\n\nWhy not add a general \"--top\" option to the \"git\" wrapper,\nto temporarily let git change to the toplevel while running\nthe command?\n\nThe wish to allow git-fetch from subdirectories is the\ninconvenience to have to cd up, and later down. This is\navoided by running \"git --top fetch\", and theses people\nshould be happy.\n\nYet, if the command outputs some relative paths, the\nuser is very well aware that these paths are from the\ntoplevel, as he explicitly specified \"--top\".\n\nAside from this, the \"--top\" options sometimes could\nbe handy even for other git commands.\n\nAnd when e.g. git fetch is run from a subdirectory, we\ncould add to the (now better) error message:\n\nYou need to run this command from the toplevel of the working tree.\nAlternatively, run \"git --top ...\" to temporary switch to the\ntoplevel while running the git command.\n\nJosef\n"},{"id":"31665","messageId":"20070114002152.GA18277@spearce.org","threadId":"6345","inReplyTo":"200701140111.20671.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-14T00:21:52Z","receivedAt":"2007-01-14T00:21:52Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Josef Weidendorfer wrote:\n> The wish to allow git-fetch from subdirectories is the\n> inconvenience to have to cd up, and later down. This is\n> avoided by running \"git --top fetch\", and theses people\n> should be happy.\n\nBut not only that, git-fetch *never* alters the working directory.\nSo it doesn't matter where git-fetch is invoked from, just that\nit can find the correct .git directory to run against. And --top\nisn't necessary to do that, the command will find the implied .git\ndirectory own its own.\n \n-- \nShawn.\n"},{"id":"31666","messageId":"200701140139.26120.Josef.Weidendorfer@gmx.de","threadId":"6345","inReplyTo":"20070114002152.GA18277@spearce.org","subject":"Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-01-14T00:39:25Z","receivedAt":"2007-01-14T00:39:25Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Sunday 14 January 2007 01:21, Shawn O. Pearce wrote:\n> Josef Weidendorfer wrote:\n> > The wish to allow git-fetch from subdirectories is the\n> > inconvenience to have to cd up, and later down. This is\n> > avoided by running \"git --top fetch\", and theses people\n> > should be happy.\n> \n> But not only that, git-fetch *never* alters the working directory.\n\nAh, typo.\ns/fetch/merge/ (or pull, rebase, ...)\n\nJosef\n"},{"id":"31668","messageId":"7vps9iig83.fsf@assigned-by-dhcp.cox.net","threadId":"6345","inReplyTo":"200701140111.20671.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-14T00:50:36Z","receivedAt":"2007-01-14T00:50:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer writes:\n\n> On Friday 12 January 2007 21:56, Junio C Hamano wrote:\n>> This updates five commands (merge, pull, rebase, revert and cherry-pick)\n>> so that they can be started from a subdirectory.\n>> \n>> This may not actually be what we want to do. These commands are\n>> inherently whole-tree operations,...\n>\n> Why not add a general \"--top\" option to the \"git\" wrapper,\n> to temporarily let git change to the toplevel while running\n> the command?\n>\n> The wish to allow git-fetch from subdirectories is the\n> inconvenience to have to cd up, and later down. This is\n> avoided by running \"git --top fetch\", and theses people\n> should be happy.\n\nWell, git-fetch does not have anything to do with the working\ntree, so it does not matter if you run from a subdirectory. You\ndo not even need --top for it (and you don't with v1.5.0-rc1).\n\nIf we replace \"git-fetch\" in what you said with one of the\ncommands I listed in the message you quoted, what you said\nbecomes at least internally consistent. But I do not\nnecessarily agree with it.\n\nAdding --top and refusing to work without the option gives a\nfalse impression that it is a bug that they do not work from the\ntop in the current implementation, and someday we might do these\ncommands limited to the current directory when the user is in a\nsubdirectory. But for the above commands, it is definitely not\nthe case. They are inherently whole-tree operations and it\nould actually be a bug to limit their operation to a single\nsubdirectory.\n\nFor example, what would a \"merge\" limited to the current\ndirectory do? It would probably do the usual 3-way merge for\nthe current directory and apply the 'ours' strategy for the rest\nof the tree.\n\nBut that is obviously wrong. The new commit claims that \"I\nconsidered the whole tree states these two commits record, and\ncame up with this another whole tree this commit records -- it\nsuits my purpose better than either of these other two trees\".\nFuture merges that involve the resulting commit will take this\nstatement into account, and will revert the changes the other\nbranch would have brought in outside the current directory if\nyour merge result is later merged into somebody else's tree.\n\nRebasing a series of commits on top of some other branch, but\nlimiting only to the current directory does not make much sense,\neither; it would lose the changes to the other parts of the\ntree. Losing the changes to the other parts of the tree might\nsometimes be what the user would want, but for the most cases\nthat would not be true. Also what the original log messages say\nwould not match the set of partial changes limited to the\ncurrent directory you are porting forward, so you would need to\nreword the logs as well if you are limiting its operation to the\ncurrent directory. In other words, it might be sometimes useful\nbut that is not a \"rebase\" anymore -- it is something else. The\nsame discussion applies to the last two commands in the list\n(revert and cherry-pick).\n\nSo for that reason, I think there are only two valid choices.\nEither we insist these commands to be run from the top, or we\nalways automatically run these commands by cd'ing to the top\nourselves.\n"},{"id":"31669","messageId":"45A97EC5.10401@midwinter.com","threadId":"6345","inReplyTo":"200701140111.20671.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-14T00:52:21Z","receivedAt":"2007-01-14T00:52:21Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Josef Weidendorfer wrote:\n> Why not add a general \"--top\" option to the \"git\" wrapper,\n> to temporarily let git change to the toplevel while running\n> the command?\n> \n\nIf I can add a config entry so --top is the default, then that's \nacceptable, but IMO it should be the default and we should, at most, \nspit out a warning if a command is run in a subdirectory and there's a \nchance of confusion.\n\nWhen I run one of the commands that currently can't run in a \nsubdirectory and it spits out its error message, I NEVER react to that \nby saying, \"Oops, forgot I was in a subdirectory, guess I didn't want to \nrun that after all.\" (Have any of you said that, even once?) I react by \ngrimacing and typing \"cd\" so the command will do what I told it to do. I \nhave done that every single time I've gotten the in-a-subdirectory \nerror. And muttering under my breath something along the lines of, \"The \ncode knows everything it needs to know to do what I just told it to, but \nit's making me take seconds to do by hand what it could have done on its \nown in nanoseconds.\"\n\nWhich is why I think the commands should just cd to the top directory as \nneeded. Doing otherwise is just making the user do pointless busywork. \nIMO any command that, if run in a subdirectory, currently does nothing \nbut spit out a \"hey, you can't run me in a subdirectory!\" error is not \ndoing what the user wanted. The user never runs one of those commands \nhoping to see an error message or to test whether he's in the top-level \ndirectory. I can't think of any situation in which I'd want to see that \nerror instead of the --top behavior.\n\nIt is entirely possible that automatically changing to the top directory \nwill also do something other than what the user wanted some percentage \nof the time, but that percentage will be far, far lower than 100, which \nis what it is now. And I posit that the number of users confused or \nfrustrated by the whole-tree operations after the first time they see it \nhappen (after which it won't be unexpected) will be far smaller than the \nnumber frustrated by the current pointless error message on a regular basis.\n\n> The wish to allow git-fetch from subdirectories is the\n> inconvenience to have to cd up, and later down. This is\n> avoided by running \"git --top fetch\", and theses people\n> should be happy.\n>\n> Yet, if the command outputs some relative paths, the\n> user is very well aware that these paths are from the\n> toplevel, as he explicitly specified \"--top\".\n> \n\nThat would be covered just as well by outputting a status message before \nany relative paths, e.g.\n\nUpdating /home/john/git-repo ...\nConflict: src/foo.c\n\n(Not that that's real git output, but you get the idea.) It could be \nsuppressed when the command is run from the top-level directory, though \nI think it'd be better to just always output it for consistency's sake.\n\n-Steve\n"},{"id":"31670","messageId":"7virfaie1m.fsf@assigned-by-dhcp.cox.net","threadId":"6345","inReplyTo":"45A97EC5.10401@midwinter.com","subject":"Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-14T01:37:41Z","receivedAt":"2007-01-14T01:37:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> Josef Weidendorfer wrote:\n>> Why not add a general \"--top\" option to the \"git\" wrapper,\n>> to temporarily let git change to the toplevel while running\n>> the command?\n>>\n>\n> If I can add a config entry so --top is the default, then that's\n> acceptable, but IMO it should be the default and we should, at most,\n> spit out a warning if a command is run in a subdirectory and there's a\n> chance of confusion.\n>\n> When I run one of the commands that currently can't run in a\n> subdirectory and it spits out its error message, I NEVER react to that\n> by saying, \"Oops, forgot I was in a subdirectory, guess I didn't want\n> to run that after all.\" (Have any of you said that, even once?)\n\nI agree with you 90% -- the other 10% are:\n\n - when these whole-tree operations fail in conflicts, I need to\n cd to the top to deal with \"the other parts\" of the tree\n anyway.\n\n - the result of merging other tree may make the current\n directory disappear (say, I haven't changed anything in the\n current directory and the other branch moved it to somewhere\n else, so it cleanly merged but now the current directory\n should not be there).\n\nThese worries are only small percentage because most of the\nmerges (or merge-like operations) are clean and directory\nremoval is rare.\n\nI would understand why somebody might want to fetch from others\nwhile working in subdirectory -- to see what other people might\nbe doing in the same area as you are currently working on.\n\nI consider that being in a subdirectory means the user is in the\nmiddle of actively working on something in that area. Honestly\nI do not understand why anybody would want to run the five\nwhole-tree commands under discussion (merge, pull, rebase,\nrevert and cherry-pick) in the middle of doing something, so\nfrom the theoretical point of view I would agree that it makes\nsense for the commands to internally cd-up to do their work, I\nam not sure how much practical value it would add.\n\n> ... I\n> react by grimacing and typing \"cd\" so the command will do what I told\n> it to do. I have done that every single time I've gotten the\n> in-a-subdirectory error. And muttering under my breath something along\n> the lines of, \"The code knows everything it needs to know to do what I\n> just told it to, but it's making me take seconds to do by hand what it\n> could have done on its own in nanoseconds.\"\n\nI do understand that you would want to cuss --- I probably would\nif that happened to me, too.\n\nHowever, I am somewhat doubtful to put me in that situation in\nthe first place, because running these five commands would be\nsomething I would do when my work-in-progress is somewhat in a\nstable state (perhaps after creating a temporary commit with\n\"git-commit -a -m WIP\" on the current topic branch), and am\nswitching my attention to do something else. Doing one of these\nfive commands (say \"rebase\") would be the first action of the\nnext stage of my work, but that would most likely be preceded by\ncd'ing to the top; I am unlikely to stay in the \"current\nsubdirectory\" when running the \"rebase\".\n\nI most likely am missing something, some obvious thing in your\nworkflow that is not mine.\n"},{"id":"31671","messageId":"7vejpyidgl.fsf@assigned-by-dhcp.cox.net","threadId":"6345","inReplyTo":"45A97EC5.10401@midwinter.com","subject":"Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-14T01:50:18Z","receivedAt":"2007-01-14T01:50:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> Which is why I think the commands should just cd to the top directory\n> as needed. Doing otherwise is just making the user do pointless\n> busywork. IMO any command that, if run in a subdirectory, currently\n> does nothing but spit out a \"hey, you can't run me in a subdirectory!\"\n> error is not doing what the user wanted. The user never runs one of\n> those commands hoping to see an error message or to test whether he's\n> in the top-level directory. I can't think of any situation in which\n> I'd want to see that error instead of the --top behavior.\n\nHaving said what I said in the other message, I 120% agree with\nthis.\n\nThe 20% you did not say but I am adding because I really want it\nto happen is this. I want to make running \"git merge\" from a\nsubdirectory first cd-up the interactive shell I am typing \"git\nmerge\" into and then run the command. This is because the\nreason why I am running one of these \"whole tree\" operations is\nbecause I am done with what I have been doing in the\nsubdirectory I was in, and I am moving onto something different.\n\nOf course this cannot be done from within \"git merge\" command,\nbut perhaps with clever use of shell aliases it might be\npossible.\n"},{"id":"31705","messageId":"45AA72E1.6060701@midwinter.com","threadId":"6345","inReplyTo":"7virfaie1m.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-14T18:13:53Z","receivedAt":"2007-01-14T18:13:53Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> I consider that being in a subdirectory means the user is in the\n> middle of actively working on something in that area. Honestly\n> I do not understand why anybody would want to run the five\n> whole-tree commands under discussion (merge, pull, rebase,\n> revert and cherry-pick) in the middle of doing something, so\n> from the theoretical point of view I would agree that it makes\n> sense for the commands to internally cd-up to do their work, I\n> am not sure how much practical value it would add.\n> \n\nHere's one use case for merge/pull/rebase that is, if not an everyday \nthing, then at least fairly common in my group: Person B fixes a bug in \nsome code that's causing problems for the code person A is working on. \nPerson A is not at a stopping point in his own work yet, but wants to \nget the fix.\n\nRevert and cherry-pick are less common here but consider this: some \npeople want submodule support because they're working on a specific part \nof the tree. They only cd into a subdirectory because there's no way for \nthem to make that subdirectory the top level of their local repository. \nThe fact that there are siblings of their current directory is just an \nartifact of the project layout and has nothing to do with what they're \ndoing at the moment.\n\nFor example, on a simple Web project, the UI designers will always cd to \nthe \"html\" directory. They get \"src\" and \"lib\" too, but if they had a \nchoice they wouldn't. When they cherry-pick, it'll always be a \ncherry-pick of their own stuff (in the html directory) and likewise with \na revert, so they have no reason to cd-up for any of those operations if \nthe tool doesn't demand it. And perhaps less obvious: in a typical \nshared integration area setup, they will never have any conflicts \nanywhere but their subdirectory since the other directories will always \nbe able to fast-forward merge. So cd-up isn't useful for them even in \nthe case of merge conflicts.\n\n-Steve\n"},{"id":"31697","messageId":"45AA7695.7040700@midwinter.com","threadId":"6345","inReplyTo":"45AA72E1.6060701@midwinter.com","subject":"Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-01-14T18:29:41Z","receivedAt":"2007-01-14T18:29:41Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Steven Grimm wrote:\n> Here's one use case for merge/pull/rebase that is, if not an everyday \n> thing, then at least fairly common in my group: Person B fixes a bug \n> in some code that's causing problems for the code person A is working \n> on. Person A is not at a stopping point in his own work yet, but wants \n> to get the fix.\n\nI'll add that that's also the use case where I want git-pull and \ngit-rebase to merge changes into my uncommitted working copy. It's \nprobably less common in big distributed open-source projects where \neveryone is working on a logically separate, non-overlapping change to \nan otherwise stable code base, but in highly collaborative workgroup \nsettings where 5 people are working on the same brand-new feature, it's \nnot at all rare, and in those cases, where people are typically editing \nthe same small set of files, you really do want to update early and \noften so as to minimize the scope of your merge conflicts and catch any \nintegration problems as early as possible.\n\nIn that setting, I'd rather not have to commit before each update since \nI'd end up with a change history like \"update\" \"update\" \"update\" \n\"implement function foo()\" \"update\" \"update\" \"fix a bug in bar()\" etc., \neven if I use rebase.\n\nCogito handles this case reasonably well, though it has to play tricks \nto do it.\n\n-Steve\n"},{"id":"31732","messageId":"7vhcutflj9.fsf@assigned-by-dhcp.cox.net","threadId":"6345","inReplyTo":"45AA72E1.6060701@midwinter.com","subject":"Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-14T19:36:26Z","receivedAt":"2007-01-14T19:36:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> For example, on a simple Web project, the UI designers will always cd\n> to the \"html\" directory. They get \"src\" and \"lib\" too, but if they had\n> a choice they wouldn't. When they cherry-pick, it'll always be a\n> cherry-pick of their own stuff (in the html directory) and likewise\n> with a revert, so they have no reason to cd-up for any of those\n> operations if the tool doesn't demand it. And perhaps less obvious: in\n> a typical shared integration area setup, they will never have any\n> conflicts anywhere but their subdirectory since the other directories\n> will always be able to fast-forward merge. So cd-up isn't useful for\n> them even in the case of merge conflicts.\n\nBoth good points. Especially the latter one, I did not think of\nmyself.\n\nThanks.\n"},{"id":"31703","messageId":"45AABE69.1070505@cc.jyu.fi","threadId":"6345","inReplyTo":"7v8xg9x8uu.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git and announcing GIT v1.5.0-rc1","fromName":"lamikr","fromEmail":"lamikr@cc.jyu.fi","sentAt":"2007-01-14T23:36:09Z","receivedAt":"2007-01-14T23:36:09Z","isPatch":false,"sender":{"key":"lamikr@cc.jyu.fi","avatar":null},"body":"Junio C Hamano wrote:\n> The tip of 'master' branch is tagged as v1.5.0-rc1; this means a\n> few things:\n> \nHi\n\nWould it make sense to add something like this to the announcements as\nit is not very easy to find references to the git-repository itself from\nthe net.\n\n You can get the git repository-itself by using a following commands\n\n git-clone git://git.kernel.org/pub/scm/git/git.git git_repo\n\n After that you can switch to tagged version or sources\nfrom the repository by using command\n\n git-checkout -f v1.5.0-rc1 master\n\n Alternatively you can download the tar packed version of sources from\n \n http://www.kernel.org/pub/software/scm/git/\n\nMika\n"},{"id":"31825","messageId":"45ACEBE6.40506@op5.se","threadId":"6345","inReplyTo":"200701140111.20671.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-01-16T15:14:46Z","receivedAt":"2007-01-16T15:14:46Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Josef Weidendorfer wrote:\n> On Friday 12 January 2007 21:56, Junio C Hamano wrote:\n>> This updates five commands (merge, pull, rebase, revert and cherry-pick)\n>> so that they can be started from a subdirectory.\n>>\n>> This may not actually be what we want to do. These commands are\n>> inherently whole-tree operations, and an inexperienced user may\n>> mistakenly expect a \"git pull\" from a subdirectory would merge\n>> only the subdirectory the command started from.\n> \n> Yes, this IMHO is a problem.\n> \n> Why not add a general \"--top\" option to the \"git\" wrapper,\n> to temporarily let git change to the toplevel while running\n> the command?\n> \n> The wish to allow git-fetch from subdirectories is the\n> inconvenience to have to cd up, and later down. This is\n> avoided by running \"git --top fetch\", and theses people\n> should be happy.\n> \n\nIt has the feel of forcing me to tell git to do the right thing when \nit's perfectly capable of figuring out what the right thing is on its own.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"}]}