{"thread":{"id":"18444","subject":"What's cooking in git.git (Mar 2009, #06; Sat, 21)","startedAt":"2009-03-21T07:58:33Z","lastAt":"2009-03-25T18:06:19Z","messageCount":13,"participants":["Junio C Hamano","Wincent Colaiuta","David Aguilar","Johannes Sixt","Finn Arne Gangstad"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"108786","messageId":"7vk56jfgt2.fsf@gitster.siamese.dyndns.org","threadId":"18444","inReplyTo":null,"subject":"What's cooking in git.git (Mar 2009, #06; Sat, 21)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-21T07:58:33Z","receivedAt":"2009-03-21T07:58:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed with '-' are\nonly in 'pu' while commits prefixed with '+' are in 'next'.  The ones\nmarked with '.' do not appear in any of the branches, but I am still\nholding onto them.\n\nThe topics list the commits in reverse chronological order.  The topics\nmeant to be merged to the maintenance series have \"maint-\" in their names.\n\n----------------------------------------------------------------\n[New Topics]\n\n* jk/reflog-date (Fri Mar 20 02:00:43 2009 -0400) 1 commit\n - make oneline reflog dates more consistent with multiline format\n\n* js/maint-1.6.0-exec-path-env (Wed Mar 18 08:42:53 2009 +0100) 1 commit\n - export GIT_EXEC_PATH when git is run with --exec-path\n\n* da/difftool (Thu Mar 19 01:25:25 2009 -0700) 1 commit\n - difftool: move 'git-difftool' out of contrib\n\n* jc/maint-1.6.0-keep-pack (Thu Mar 19 22:47:54 2009 -0500) 4 commits\n - Remove --kept-pack-only option and associated infrastructure\n - pack-objects: only repack or loosen objects residing in \"local\"\n   packs\n - git-repack.sh: don't use --kept-pack-only option to pack-objects\n - t7700-repack: add two new tests demonstrating repacking flaws\n\nBrandon Casey fixed the regression previous patches introduced; thanks.\n\n* jc/maint-1.6.0-blame-s (Wed Mar 18 00:13:03 2009 -0700) 1 commit\n - blame: read custom grafts given by -S before calling\n   setup_revisions()\n\nThe above are all ready for 'next'.\n\n* hv/cvsps-tests (Wed Mar 18 18:33:41 2009 +0100) 7 commits\n - cvsimport: extend testcase about patchset order to contain\n   branches\n - cvsimport: add test illustrating a bug in cvsps\n - Add a test of \"git cvsimport\"'s handling of tags and branches\n - Add some tests of git-cvsimport's handling of vendor branches\n - Test contents of entire cvsimported \"master\" tree contents\n - Use CVS's -f option if available (ignore user's ~/.cvsrc file)\n - Start a library for cvsimport-related tests\n\nTwo cvsimport test topics were rewound from 'next' and merged into this\none.  I'll keep this in 'pu' so that people can polish their cvsps skilz\nto resolve issues these tests identify.\n\n----------------------------------------------------------------\n[Graduated to \"master\"]\n\n* fc/parseopt-config (Tue Mar 17 10:46:37 2009 +0100) 10 commits\n + config: test for --replace-all with one argument and fix\n   documentation.\n + config: set help text for --bool-or-int\n + git config: don't allow --get-color* and variable type\n + git config: don't allow extra arguments for -e or -l.\n + git config: don't allow multiple variable types\n + git config: don't allow multiple config file locations\n + git config: reorganize to use parseopt\n + git config: reorganize get_color*\n + git config: trivial rename in preparation for parseopt\n + git_config(): not having a per-repo config file is not an error\n\n* js/rebase-i-opt (Tue Mar 3 10:55:31 2009 +0100) 1 commit\n + rebase -i: avoid 'git reset' when possible\n\n* jc/clone-branch-rebase (Tue Mar 10 01:20:42 2009 -0700) 2 commits\n + Improve \"git branch --tracking\" output\n + Make git-clone respect branch.autosetuprebase\n\nThis is a rewrite of a patch from Pat Notz.\n\n* xx/db-refspec-vs-js-remote (Sun Mar 8 00:12:33 2009 -0800) 1 commit\n + Adjust js/remote-improvements and db/refspec-wildcard-in-the-\n   middle\n\n* db/refspec-wildcard-in-the-middle (Sat Mar 7 01:11:39 2009 -0500) 5 commits\n + Support '*' in the middle of a refspec\n + Keep '*' in pattern refspecs\n + Use the matching function to generate the match results\n + Use a single function to match names against patterns\n + Make clone parse the default refspec with the normal code\n\n* bw/autoconf (Thu Mar 12 15:20:12 2009 -0400) 7 commits\n + configure: rework pthread handling to allow for user defined flags\n + configure: make iconv tests aware of user arguments\n + configure: asciidoc version test cleanup\n + configure: wrap some library tests with GIT_STASH_FLAGS\n + configure: add macros to stash FLAG variables\n + configure: reorganize flow of argument checks\n + configure: ensure settings from user are also usable in the script\n\n* mv/parseopt-ls-files (Sat Mar 7 20:27:22 2009 -0500) 4 commits\n + ls-files: fix broken --no-empty-directory\n + t3000: use test_cmp instead of diff\n + parse-opt: migrate builtin-ls-files.\n + Turn the flags in struct dir_struct into a single variable\n\nThe tip one was a subject for further discussion, but nothing is queued\nyet.\n\n----------------------------------------------------------------\n[Will merge to 'master' soon]\n\n* dm/maint-docco (Thu Mar 19 20:35:34 2009 -0700) 6 commits\n + Documentation: reword example text in git-bisect.txt.\n + Documentation: reworded the \"Description\" section of git-\n   bisect.txt.\n + Documentation: minor grammatical fixes in git-branch.txt.\n + Documentation: minor grammatical fixes in git-blame.txt.\n + Documentation: reword the \"Description\" section of git-bisect.txt.\n + Documentation: minor grammatical fixes in git-archive.txt.\n\n* mg/test-installed (Mon Mar 16 18:03:12 2009 +0100) 2 commits\n + test-lib.sh: Allow running the test suite against installed git\n + test-lib.sh: Test for presence of git-init in the right path.\n\n----------------------------------------------------------------\n[Discarded]\n\n* hv/cvsimport-tests (Mon Mar 2 18:59:36 2009 +0100) 1 commit\n ? cvsimport: add test illustrating a bug in cvsps\n\n* mh/cvsimport-tests (Mon Feb 23 06:08:14 2009 +0100) 5 commits\n ? Add a test of \"git cvsimport\"'s handling of tags and branches\n ? Add some tests of git-cvsimport's handling of vendor branches\n ? Test contents of entire cvsimported \"master\" tree contents\n ? Use CVS's -f option if available (ignore user's ~/.cvsrc file)\n ? Start a library for cvsimport-related tests\n\n----------------------------------------------------------------\n[Stalled and may need help and prodding to go forward]\n\n* ps/blame (Thu Mar 12 21:30:03 2009 +1100) 1 commit\n - blame.c: start libifying the blame infrastructure\n\nA few minor point remains in this initial one.\n\n* jc/log-tz (Tue Mar 3 00:45:37 2009 -0800) 1 commit\n - Allow --date=local --date=other-format to work as expected\n\nThe one I posted had a few corner-case bugs that was caught with the test\nsuite; this one has them fixed.  People did not like the UI so it is kept\nout of 'next'\n\n* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 1 commit\n - archive.c: add support for --submodules[=(all|checkedout)]\n\nDiscussion stalled on the submodule selection criteria.\nProbably I should discard it and wait for a reroll if needed.\n\n* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit\n - git-merge-file: allow converting the results for the work tree\n\nThis is a feature waiting for a user.\n\nWe did not give scripted Porcelains a way to say \"this temporary file I am\nusing for merging is for this path, so use the core.autocrlf and attributes\nrules for that final path\".  Instead, merge-file simply wrote out the\ndata in the canonical repository representation.\n\nrerere has the same issue, but it is a lot worse.  It reads the three\nfiles (preimage, postimage and thisimage) from the work tree in the work\ntree representation, merges them without converting them to the canonical\nrepresentation first but inserts the conflict markers with the canonical\nrepresentation and writes the resulting mess out.  It needs to be fixed to\nread with convert_to_git(), merge them while they are still in the\ncanonical representation and possibly add conflict markers, and then write\nthe results out after convert_to_working_tree().  It also needs to write\nin binary mode as well.\n\n* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits\n - Support fetching from foreign VCSes\n - Add specification of git-vcs helpers\n - Add \"vcs\" config option in remotes\n\nDaniel seems to have a plan for going forward with this series.\n\n* cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits\n - builtin-replace: use \"usage_msg_opt\" to give better error messages\n - parse-options: add new function \"usage_msg_opt\"\n - builtin-replace: teach \"git replace\" to actually replace\n - Add new \"git replace\" command\n - environment: add global variable to disable replacement\n - mktag: call \"check_sha1_signature\" with the replacement sha1\n - replace_object: add a test case\n - object: call \"check_sha1_signature\" with the replacement sha1\n - sha1_file: add a \"read_sha1_file_repl\" function\n - replace_object: add mechanism to replace objects found in\n   \"refs/replace/\"\n - refs: add a \"for_each_replace_ref\" function\n\nI know, I really have to drop everything else and re-read these, but I\nhaven't managed to.\n\n* js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits\n - tests: fix \"export var=val\"\n - notes: refuse to edit notes outside refs/notes/\n - t3301: use test_must_fail instead of !\n - t3301: fix confusing quoting in test for valid notes ref\n - notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR\n - notes: only clean up message file when editing\n - handle empty notes gracefully\n - git notes show: test empty notes\n - git-notes: fix printing of multi-line notes\n - notes: fix core.notesRef documentation\n - Add an expensive test for git-notes\n - Speed up git notes lookup\n - Add a script to edit/inspect notes\n - Introduce commit notes\n\n----------------------------------------------------------------\n[Actively cooking]\n\n* jc/attributes-checkout (Fri Mar 20 10:32:09 2009 +0100) 2 commits\n - Add a test for checking whether gitattributes is honored by\n   checkout.\n - Read attributes from the index that is being checked out\n\nOriginal issue identified, and test provided by Kristian Amlie.\n\n* fg/push-default (Mon Mar 16 16:42:52 2009 +0100) 2 commits\n - Display warning for default git push with no push.default config\n + New config push.default to decide default behavior for push\n\nReplaced the old series with the first step to allow a smooth transition.\nSome might argue that this should not give any warning but just give users\nthis new configuration to play with first, and after we know we are going\nto switch default some day, start the warning.\n\n* mg/http-auth (Wed Mar 18 18:46:41 2009 -0500) 6 commits\n + http-push.c: use a faux remote to pass to http_init\n + Do not name \"repo\" struct \"remote\" in push_http.c\n + http.c: CURLOPT_NETRC_OPTIONAL is not available in ancient\n   versions of cURL\n + http authentication via prompts\n + http_init(): Fix config file parsing\n + http.c: style cleanups\n\nAmos King added push side support on top of my fetch side support.\n\nWe may want to also pass --remote parameter from git-push to this backend\nas Daniel did as an interim solution for the fetch side, so that we can\nhandle the configuration better.\n\n* db/push-cleanup (Sun Mar 8 21:06:07 2009 -0400) 2 commits\n + Move push matching and reporting logic into transport.c\n + Use a common function to get the pretty name of refs\n\n* kb/tracking-count-no-merges (Wed Mar 4 18:47:39 2009 +0100) 1 commit\n + stat_tracking_info(): only count real commits\n\nThis gives the merge commits zero weight when talking about how many\ncommits you have ahead (or behind) of the branch you are tracking.  Even\nthough I agree that they should carry much less weight than the \"real\"\ncommits, because your repeated merge from the other branch does not really\nadd any real value to the end result, giving them absolute zero weight\nsomehow feels wrong. At least it shows that your have been _active_ on the\nbranch.  But I do not feel very strongly about it.\n\n----------------------------------------------------------------\n[On Hold]\n\n* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit\n - receive-pack: default receive.denyDeleteCurrent to refuse\n\n* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit\n - Refuse updating the current branch in a non-bare repository via\n   push\n\nThese are for 1.7.0, but the messages when they trigger together may need\nto be rethought.\n"},{"id":"108798","messageId":"0768D909-FCD5-4E5B-95A7-2602824FC431@wincent.com","threadId":"18444","inReplyTo":"7vk56jfgt2.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-03-21T16:20:21Z","receivedAt":"2009-03-21T16:20:21Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 21/3/2009, a las 8:58, Junio C Hamano escribió:\n\n> * da/difftool (Thu Mar 19 01:25:25 2009 -0700) 1 commit\n> - difftool: move 'git-difftool' out of contrib\n\nBefore this one goes any further, I noticed that nobody replied to my  \nemail on this thread a few days ago:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/113609\n\nMy concern was:\n\n> Given that git-difftool shares basically all the same options as  \n> \"git diff\", I think a good long-term plan would be looking at adding  \n> the \"--tool\" option to \"git diff\" itself so that users wouldn't have  \n> to learn a new subcommand, just a new option.\n\n\nWhat do people think?\n\nCheers,\nWincent\n"},{"id":"108806","messageId":"20090321185817.GA22540@gmail.com","threadId":"18444","inReplyTo":"0768D909-FCD5-4E5B-95A7-2602824FC431@wincent.com","subject":"Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2009-03-21T18:58:18Z","receivedAt":"2009-03-21T18:58:18Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On  0, Wincent Colaiuta <win@wincent.com> wrote:\n> El 21/3/2009, a las 8:58, Junio C Hamano escribió:\n>\n>> * da/difftool (Thu Mar 19 01:25:25 2009 -0700) 1 commit\n>> - difftool: move 'git-difftool' out of contrib\n>\n> Before this one goes any further, I noticed that nobody replied to my  \n> email on this thread a few days ago:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/113609\n>\n> My concern was:\n>\n>> Given that git-difftool shares basically all the same options as \"git \n>> diff\", I think a good long-term plan would be looking at adding the \n>> \"--tool\" option to \"git diff\" itself so that users wouldn't have to \n>> learn a new subcommand, just a new option.\n>\n>\n> What do people think?\n>\n> Cheers,\n> Wincent\n\nThat could be interesting.  git-difftool is just a\nfrontend to git-diff so there isn't really any maintenance\nworries about keeping the options in sync.  I do agree that\nkeeping things easy for users is a noble goal and that that\nwas your only concern.\n\ngit-difftool is pure porcelain, so I'm interested in how we\ncould implement this.  Right now the call stack is:\n\n$ git difftool\n... GIT_EXT_DIFF=git-difftool-helper\n... git diff\n... ... git-difftool-helper\n... ... ... xxdiff\n\n\nWhat should it look like instead?\n\nAre you envisioning this (1):\n\n$ git diff --tool\n... --tool was passed, so set GIT_EXT_DIFF?\n... git-difftool-helper\n... ... xxdiff ...\n\n\nOr do you mean this? (2):\n\n$ git diff --tool=xxdiff\n... --tool was passed, so set GIT_EXT_DIFF?\n... git-difftool-helper\n... ... xxdiff\n\n\nOr even... (3):\n\n$ git diff --tool\n... --tool was passed, delegate to git-diff--tool,\n...        remove --tool from *argv\n... git-diff--tool\n... GIT_EXT_DIFF=git-diff--tool-helper\n... git-diff\n... ... git-diff--tool-helper\n... ... ... xxdiff ...\n\n(git-diff calls itself in this scenario...)\n\n\nRight now users only specify --tool=<tool> as an override.\n\nThe default behavior without --tool is:\n- difftool looks up diff.tool and uses that value, or\n- difftool makes a best guess based on the environ\n\nHmm.. if --tool supported both '--tool' and '--tool=<tool>'\nthen that could work.  That would make '--tool' both a switch\nand an option-with-argument.  Is there anything in git that\ndoes that?  I can imaging that being a little surprising from\na ui point of view, but it's not horrible.\n\nWhat about the --no-prompt option?\nWould we need that in git-diff too, or would we be able to\nblindly pass it along to git-diff--tool without worrying that\ngit-diff would try to interpret it?\n\nI personally like the separation of concerns --\ngit-diff is plumbing and git-difftool is porcelain.\nBut, I also agree with making it easier for users.\n\n\nThat said...  (off-topic)\n\nI have a patch for difftool that lets you do stuff like this:\n\n\t$ git difftool Makefile~3\n\t$ git difftool Makefile~~~ Makefile~\n\nThat is *completely* the antithesis of git because git is not\nfile-centric.  Nonetheless, this is something people ask me\nall the time and users really hate the \"right\" way to do it:\n\n\t$ git difftool \\\n\t\t$(git log --pretty=format:%H -3 Makefile |\n\t\t\ttail -1) \\\n\t\t-- Makefile\n\n\nThe point here is that since git-difftool is a frontend to\ngit-diff I was actually able to implement it without changing\nany of the core git commands (or extend its revision syntax).\nThis is both good and bad.  It's good because users are much\nhappier using the extended file-rev syntax, and it's bad\nbecause git-diff doesn't know about it.\n\nWhat it illustrates, though, is that the separation of\nconcerns between the porcelain git-difftool and plumbing\ngit-diff is helpful specifically because it makes such things\npossible.\n\nThe really cute thing, though, is that\n\t$ git difftool --no-ext-diff Makefile~3\n\n...actually makes it so that git-diff understands the new\nsyntax.  It's quite a clever hack.  It's user-friendly\nand extremely helpful, which is why I entertained the\nnotion of implementing it.  It basically transforms user intent\n\"give me Makefile from 3 changes ago back\" into something that\ngit-diff understands, which is in my opinion the whole point of\nporcelains.\n\nThat said.. it would be really user-friendly if diff and\nfriends understood the extended file-rev syntax directly, but\nbeing that it overloads the '~' character and \"looks\" just\nlike a rev-parse revision specifier, I don't even know if its:\n\n\ta. possible, or\n\tb. something we'd want given that git is\n\t   commit-centric, not file-centric.\n\nI should really start a second thread about the file-rev\nsyntax because I made it out of thin air and it's exactly the\nkind of thing that the wisdom of the list can help vet.\n\n\nAn interesting thing is that users have been mailing me\ndirectly with questions about difftool and I really want to\nuse the full potential of the community, which I think will\ncome naturally with the move out of contrib.\n\nSo.. I agree in principle but also think it wouldn't hurt to\ngo forward with moving git-difftool out of contrib so that we\ncan get more user feedback.  I also think that a scheme most\nsimilar to (3) above seems like an interesting way to go and\nwould be interested to hear if it's what you envisioned.\n\n\nI hope I didn't just muddy the waters further =)\n\nHave fun,\n\n-- \n\n\tDavid\n"},{"id":"108808","messageId":"7vskl6ekve.fsf@gitster.siamese.dyndns.org","threadId":"18444","inReplyTo":"0768D909-FCD5-4E5B-95A7-2602824FC431@wincent.com","subject":"Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-21T19:28:21Z","receivedAt":"2009-03-21T19:28:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wincent Colaiuta <win@wincent.com> writes:\n\n>> Given that git-difftool shares basically all the same options as\n>> \"git diff\", I think a good long-term plan would be looking at adding\n>> the \"--tool\" option to \"git diff\" itself so that users wouldn't have\n>> to learn a new subcommand, just a new option.\n>\n> What do people think?\n\nI am not \"people\" but since I was \"To:\"ed not \"Cc:\"ed...\n\nI did not comment on it because personally I was not very interested in\nit; admittedly, I do not use difftool myself, but:\n\n (1) \"git diff --tool\" is more to type than \"git difftool\"; and\n\n (2) it requires adding more code to \"git diff\" for a dubious benefit from\n     end user's point of view.\n\n\"git diff\" itself is already just a thin command dispatcher that calls\nunderlying vastly different modes operations, and it is designed that way\nin order to make it easy to add a new totally different mode of operation.\n\nWe originally had four underlying modes of operation (index-with-worktree,\ntree-with-tree, tree-with-worktree, and tree-with-index), and Dscho\nmanaged to add random-file-with-random-file without disturbing existing\ncodepaths too much.\n\nEven though it is a \"thin\" dispatcher, command line parsing is largely\ndone by \"git diff\" itself, and its results are fed to the underlying modes\nof operations, for two reasons:\n\n (1) These \"modes of operations\" share large set of options (e.g. \"-U20\"\n     works the same way no matter which mode you invoke); and\n\n (2) the dispatcher needs to inspect command line option and arguments to\n     decide which mode to invoke anyway.\n\nWhen an end user says \"I want to compare two things with these settings\n(e.g. use color, with 5 lines of context, only inside Documentation/howto\ndirectory, detect renames with lower-than-usual threashold, ...)\", the\nmental model is same whether the two things being compared happens to be\nindex-vs-worktree or tree-vs-index from the end user's point of view.  It\nmakes a lot of sense for \"git diff --options\" to invoke both modes of\noperations with a similar-looking command line.\n\nEven though the --no-index mode of operation internally does not fit very\nwell compared to the original four modes from the implementation point of\nview, it still naturally fits the end user's mental model and that is why\nit is given as an option to \"git diff\".\n\nDoes \"git difftool\" fit well in the end user's mental model in a similar\nway to \"git diff\"?  I somehow suspect it doesn't.  What does it mean to\ngive \"-U8 --color --stat --summary -p --ignore-space-at-eol\" options when\nyou invoke it, for example?\n"},{"id":"108840","messageId":"200903212321.18283.j6t@kdbg.org","threadId":"18444","inReplyTo":"7vk56jfgt2.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2009-03-21T22:21:18Z","receivedAt":"2009-03-21T22:21:18Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Samstag, 21. März 2009, Junio C Hamano wrote:\n> * js/maint-1.6.0-exec-path-env (Wed Mar 18 08:42:53 2009 +0100) 1 commit\n>  - export GIT_EXEC_PATH when git is run with --exec-path\n\nHere is the patch again with a commit message that explains what's going on.\n\nBut notice that this is probably not a complete solution: As you can see\n(below) from the analysis, a git-repack that was taken from $prefix would\ninvoke a git that is not from $prefix, but from the initial command's\n--exec-path. I think this can be solved by installing the git executable\nin $prefix/libexec/git-core as well.\n\n-- Hannes\n\n-- 8< --\nSubject: [PATCH] Propagate --exec-path setting to external commands via GIT_EXEC_PATH\n\nLet PATH0=$PATH that was set before the invocation.\nLet /foo be a build directory.\nLet /pfx be the installation prefix.\nLet pfxexecpath=/pfx/libexec/git-core.\n\nThe following is going on when 'git --exec-path=/foo gc' is invoked:\n\n1. git sets PATH=/foo:$PATH0 using the path from --exec-path\n\n2. gc execs 'git repack' (note: no dash).\n\n3. Since there is a git in /foo (it's a build directory), /foo/git is\n   taken.\n\n4. No explicit exec-path is set this time, hence, this secondary git sets\n   PATH=$pfxexecpath:/foo:$PATH\n\n5. Since 'repack' is not a built-in, execv_dashed_external execs\n   'git-repack' (note: dash).\n\n6. There is a $pfxexecpath/git-repack, and it is taken.\n\n7. This git-repack runs 'git pack-objects' (note: no dash).\n\n8. There is no git in $pfxexecpath, but there is one in /foo. Hence,\n   /foo/git is run.\n\n9. pack-objects is a builtin, hence, in effect /foo/git-pack-objects\n   is run.\n\nAs you can see, the way in which we previously set the PATH allowed to\nmix gits of different vintage.  By setting GIT_EXEC_PATH when --exec-path\nwas given on the command line, we reduce the confusion.\n\nSigned-off-by: Johannes Sixt <j6t@kdbg.org>\n---\n exec_cmd.c |    4 ++++\n 1 files changed, 4 insertions(+), 0 deletions(-)\n\ndiff --git a/exec_cmd.c b/exec_cmd.c\nindex 217c125..408e4e5 100644\n--- a/exec_cmd.c\n+++ b/exec_cmd.c\n@@ -61,6 +61,10 @@ const char *git_extract_argv0_path(const char *argv0)\n void git_set_argv_exec_path(const char *exec_path)\n {\n \targv_exec_path = exec_path;\n+\t/*\n+\t * Propagate this setting to external programs.\n+\t */\n+\tsetenv(EXEC_PATH_ENVIRONMENT, exec_path, 1);\n }\n \n \n-- \n1.6.2.1.224.g2225f\n"},{"id":"108905","messageId":"FC18101D-268C-40DF-9733-598EE25CAFA6@wincent.com","threadId":"18444","inReplyTo":"7vskl6ekve.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-03-22T15:54:23Z","receivedAt":"2009-03-22T15:54:23Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 21/3/2009, a las 20:28, Junio C Hamano escribió:\n\n> Wincent Colaiuta <win@wincent.com> writes:\n>\n>>> Given that git-difftool shares basically all the same options as\n>>> \"git diff\", I think a good long-term plan would be looking at adding\n>>> the \"--tool\" option to \"git diff\" itself so that users wouldn't have\n>>> to learn a new subcommand, just a new option.\n>>\n>> What do people think?\n>\n> I am not \"people\" but since I was \"To:\"ed not \"Cc:\"ed...\n>\n> I did not comment on it because personally I was not very interested  \n> in\n> it; admittedly, I do not use difftool myself, but:\n>\n> (1) \"git diff --tool\" is more to type than \"git difftool\"; and\n\nTrue, although an alias would fix that.\n\n> (2) it requires adding more code to \"git diff\" for a dubious benefit  \n> from\n>     end user's point of view.\n\nFair enough. I was just wondering if we could avoid adding yet another  \ncommand to the already long list of installed commands. I understand  \nthat \"diff\" is actually a thin dispatcher for different modes of  \noperation, but seeing as all of those modes basically boil down to  \n\"show me the difference between two things\", and that happens to be  \nthe purpose of \"difftool\" as well, I thought it might make sense to  \ncombine them.\n\n> When an end user says \"I want to compare two things with these  \n> settings\n> (e.g. use color, with 5 lines of context, only inside Documentation/ \n> howto\n> directory, detect renames with lower-than-usual threashold, ...)\", the\n> mental model is same whether the two things being compared happens  \n> to be\n> index-vs-worktree or tree-vs-index from the end user's point of  \n> view.  It\n> makes a lot of sense for \"git diff --options\" to invoke both modes of\n> operations with a similar-looking command line.\n>\n> Even though the --no-index mode of operation internally does not fit  \n> very\n> well compared to the original four modes from the implementation  \n> point of\n> view, it still naturally fits the end user's mental model and that  \n> is why\n> it is given as an option to \"git diff\".\n>\n> Does \"git difftool\" fit well in the end user's mental model in a  \n> similar\n> way to \"git diff\"?  I somehow suspect it doesn't.  What does it mean  \n> to\n> give \"-U8 --color --stat --summary -p --ignore-space-at-eol\" options  \n> when\n> you invoke it, for example?\n\nGood question. Seeing as right now \"difftool\" just passes all options  \nthrough to \"diff\", I guess it's up to the user to pass in options  \nwhich actually make sense.\n\nCheers,\nWincent\n"},{"id":"108906","messageId":"150271EF-9B2B-4B48-9A17-F9E423830E60@wincent.com","threadId":"18444","inReplyTo":"20090321185817.GA22540@gmail.com","subject":"Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-03-22T15:57:20Z","receivedAt":"2009-03-22T15:57:20Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 21/3/2009, a las 19:58, David Aguilar escribió:\n\n> On  0, Wincent Colaiuta <win@wincent.com> wrote:\n>> El 21/3/2009, a las 8:58, Junio C Hamano escribió:\n>>\n>>> * da/difftool (Thu Mar 19 01:25:25 2009 -0700) 1 commit\n>>> - difftool: move 'git-difftool' out of contrib\n>>\n>> Before this one goes any further, I noticed that nobody replied to my\n>> email on this thread a few days ago:\n>>\n>> http://article.gmane.org/gmane.comp.version-control.git/113609\n>>\n>> My concern was:\n>>\n>>> Given that git-difftool shares basically all the same options as  \n>>> \"git\n>>> diff\", I think a good long-term plan would be looking at adding the\n>>> \"--tool\" option to \"git diff\" itself so that users wouldn't have to\n>>> learn a new subcommand, just a new option.\n>>\n>>\n>> What do people think?\n>>\n>> Cheers,\n>> Wincent\n>\n> That could be interesting.  git-difftool is just a\n> frontend to git-diff so there isn't really any maintenance\n> worries about keeping the options in sync.  I do agree that\n> keeping things easy for users is a noble goal and that that\n> was your only concern.\n>\n> git-difftool is pure porcelain, so I'm interested in how we\n> could implement this.  Right now the call stack is:\n>\n> $ git difftool\n> ... GIT_EXT_DIFF=git-difftool-helper\n> ... git diff\n> ... ... git-difftool-helper\n> ... ... ... xxdiff\n>\n>\n> What should it look like instead?\n>\n> Are you envisioning this (1):\n>\n> $ git diff --tool\n> ... --tool was passed, so set GIT_EXT_DIFF?\n> ... git-difftool-helper\n> ... ... xxdiff ...\n\nYeah, something like that. I wasn't actually imagining that the logic  \nof git-difftool-helper would itself be rolled into \"git diff\". I was  \njust wondering if we could keep the command-count down.\n\nCheers,\nWincent\n"},{"id":"109074","messageId":"20090323144650.GA20058@pvv.org","threadId":"18444","inReplyTo":"7vk56jfgt2.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2009-03-23T14:46:50Z","receivedAt":"2009-03-23T14:46:50Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Sat, Mar 21, 2009 at 12:58:33AM -0700, Junio C Hamano wrote:\n[...]\n> * fg/push-default (Mon Mar 16 16:42:52 2009 +0100) 2 commits\n>  - Display warning for default git push with no push.default config\n>  + New config push.default to decide default behavior for push\n> \n> Replaced the old series with the first step to allow a smooth transition.\n> Some might argue that this should not give any warning but just give users\n> this new configuration to play with first, and after we know we are going\n> to switch default some day, start the warning.\n\nIf you feel that talking about a possible future change is premature,\nyou could omit that part of the second commit I guess, but I think\nprinting some kind of warning is valuable.  Are you waiting for more\ninput?  It seems that this topic is pretty dead now.\n\nMost people who get bitten by this directly are probably not active on\nthis list so I don't think you will hear from many of them.\n\n- Finn Arne\n"},{"id":"109082","messageId":"7v4oxk6wk2.fsf@gitster.siamese.dyndns.org","threadId":"18444","inReplyTo":"20090323144650.GA20058@pvv.org","subject":"Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-23T16:19:57Z","receivedAt":"2009-03-23T16:19:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Finn Arne Gangstad <finnag@pvv.org> writes:\n\n> On Sat, Mar 21, 2009 at 12:58:33AM -0700, Junio C Hamano wrote:\n> [...]\n>> * fg/push-default (Mon Mar 16 16:42:52 2009 +0100) 2 commits\n>>  - Display warning for default git push with no push.default config\n>>  + New config push.default to decide default behavior for push\n>> \n>> Replaced the old series with the first step to allow a smooth transition.\n>> Some might argue that this should not give any warning but just give users\n>> this new configuration to play with first, and after we know we are going\n>> to switch default some day, start the warning.\n>\n> If you feel that talking about a possible future change is premature,\n> you could omit that part of the second commit I guess, but I think\n> printing some kind of warning is valuable.  Are you waiting for more\n> input?  It seems that this topic is pretty dead now.\n>\n> Most people who get bitten by this directly are probably not active on\n> this list so I don't think you will hear from many of them.\n\nI have already judged that the cause of this series is good, and that is\nwhy the series was even considered to be in git.git to begin with.  I also\nlooked at the code change in them, and I found it Ok, and that is why the\nfirst one is queued in 'next'.\n\nAt this point we do not need \"Yes, it is a good idea\" from people, even\nthough \"No, it is a horrible change because of such and such reasons\"\ncould reverse its course, if the argument is new.\n\nThe reason the patch has been sitting in 'next' is entirely unrelated to\nthe above.  It is to hear from people about unintended side effects, if\nany.  It's only been a week, isn't it?\n\nUnlike documentation reformatting and other kinds of patches in which\npotential breakages will not cause a disaster, push is one of the things\nwe would want to keep working for people.  In general, the more important\nthe area a patch touches, the patch needs to cook longer in 'next'.\n"},{"id":"109187","messageId":"7vljqv2t05.fsf@gitster.siamese.dyndns.org","threadId":"18444","inReplyTo":"7v4oxk6wk2.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-24T09:02:34Z","receivedAt":"2009-03-24T09:02:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Finn Arne Gangstad <finnag@pvv.org> writes:\n>\n>> If you feel that talking about a possible future change is premature,\n>> you could omit that part of the second commit I guess, but I think\n>> printing some kind of warning is valuable.  Are you waiting for more\n>> input?  It seems that this topic is pretty dead now.\n\nNow it turns out that it has been \"pretty dead\" because nobody, not even\nthe original author, was doing any testing and fixing.\n\nAfter merging this \"warning\" thing to next, I mistype the name of the\nremote I wanted to push with the default \"matching\" semantics and got this:\n\n  $ git push --dry-run sf.net\n  warning: You did not specify any refspecs to push, and the current remote\n  warning: has not configured any push refspecs. The default action in this\n  warning: case is to push all matching refspecs, that is, all branches\n  warning: that exist both locally and remotely will be updated.  This may\n  warning: not necessarily be what you want to happen.\n  warning:\n  warning: You can specify what action you want to take in this case, and\n  warning: avoid seeing this message again, by configuring 'push.default' to:\n  warning:   'nothing'  : Do not push anythig\n  warning:   'matching' : Push all matching branches (default)\n  warning:   'tracking' : Push the current branch to whatever it is tracking\n  warning:   'current'  : Push the current branch\n  fatal: 'sf.net' does not appear to be a git repository\n  fatal: The remote end hung up unexpectedly\n\nThe final, most important error messages are dwarfed out by the warning\nthat talks about setting configuration on the remote that does not even\nexist.\n\nIn this particular case, it does not corrupt the local nor remote\nrepositories, and because it was me who tried this who knew what he was\ndoing, so it is Ok, and that is the point of keeping any new features out\nof 'master' until such silly misfeatures are found and fixed.  But it\nwould have been nicer if I weren't the only one testing and finding bugs.\n"},{"id":"109190","messageId":"7vhc1j2si9.fsf@gitster.siamese.dyndns.org","threadId":"18444","inReplyTo":"7vljqv2t05.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-24T09:13:18Z","receivedAt":"2009-03-24T09:13:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>   $ git push --dry-run sf.net\n>   warning: You did not specify any refspecs to push, and the current remote\n>   warning: has not configured any push refspecs. The default action in this\n>   warning: case is to push all matching refspecs, that is, all branches\n>   warning: that exist both locally and remotely will be updated.  This may\n>   warning: not necessarily be what you want to happen.\n>   warning:\n>   warning: You can specify what action you want to take in this case, and\n>   warning: avoid seeing this message again, by configuring 'push.default' to:\n>   warning:   'nothing'  : Do not push anythig\n>   warning:   'matching' : Push all matching branches (default)\n>   warning:   'tracking' : Push the current branch to whatever it is tracking\n>   warning:   'current'  : Push the current branch\n>   fatal: 'sf.net' does not appear to be a git repository\n>   fatal: The remote end hung up unexpectedly\n>\n> The final, most important error messages are dwarfed out by the warning\n> that talks about setting configuration on the remote that does not even\n> exist.\n\nActually, I take it back.  It is still annoying, but the point of these\nwarning lines is to warn even for a one-off push you make to a place\nwithout having any [remote \"sf.net\"] entry anywhere in the config.  In the\nworst case, the above \"sf.net\" may even be just a full URL of the remote,\nand we do want to trigger the warning.\n\nSo this is not even a usability bug.  Sorry for a thinko.\n"},{"id":"109204","messageId":"20090324111645.GA6084@pvv.org","threadId":"18444","inReplyTo":"7vhc1j2si9.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2009-03-24T11:16:45Z","receivedAt":"2009-03-24T11:16:45Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Tue, Mar 24, 2009 at 02:13:18AM -0700, Junio C Hamano wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> >   $ git push --dry-run sf.net\n> >   warning: You did not specify any refspecs to push, and the current remote\n> >   warning: has not configured any push refspecs. The default action in this\n> >   warning: case is to push all matching refspecs, that is, all branches\n> >   warning: that exist both locally and remotely will be updated.  This may\n> >   warning: not necessarily be what you want to happen.\n> >   warning:\n> >   warning: You can specify what action you want to take in this case, and\n> >   warning: avoid seeing this message again, by configuring 'push.default' to:\n> >   warning:   'nothing'  : Do not push anythig\n> >   warning:   'matching' : Push all matching branches (default)\n> >   warning:   'tracking' : Push the current branch to whatever it is tracking\n> >   warning:   'current'  : Push the current branch\n> >   fatal: 'sf.net' does not appear to be a git repository\n> >   fatal: The remote end hung up unexpectedly\n> >\n> > The final, most important error messages are dwarfed out by the warning\n> > that talks about setting configuration on the remote that does not even\n> > exist.\n\nI actually agree, but that final error is printed in a very ugly\nplace! It would require some surgery to pause the warning until we\nfigure out that sf.net is not a valid remote in the current setup.\n\nget_refs_via_connect->connect_setup->git_connect-> .. fork()s .., runs\n   \"sh -c git-receive-pack 'sf.net'\" (which prints the first error)\nand get_remote_heads->packet_read_line->safe_read() dumps the final error\nand dies.\n\nIs there any reason why remote_get needs to return a valid remote for\na value like \"sf.net\"?  If it didn't, the error message would be even\nbetter, and not complain about a \"remote end\".\n\nJust thinking aloud, if what is specified as a remote does not contain\na \":\" it cannot really be a URL(?), and we can assume it is a local\ndirectory. If that directory does not exist is not a valid git\nrepository, it might be safe to fail in remote_get?\n\n- Finn Arne\n"},{"id":"109387","messageId":"7vzlf94gv8.fsf@gitster.siamese.dyndns.org","threadId":"18444","inReplyTo":"20090324111645.GA6084@pvv.org","subject":"Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-25T18:06:19Z","receivedAt":"2009-03-25T18:06:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Finn Arne Gangstad <finnag@pvv.org> writes:\n\n> On Tue, Mar 24, 2009 at 02:13:18AM -0700, Junio C Hamano wrote:\n>> Junio C Hamano <gitster@pobox.com> writes:\n>> \n>> >   $ git push --dry-run sf.net\n>> >   warning: ...\n>> >   warning: You can specify what action you want to take in this case, and\n>> >   warning: avoid seeing this message again, by configuring 'push.default' to:\n>> >...\n>> >   warning:   'current'  : Push the current branch\n>> >   fatal: 'sf.net' does not appear to be a git repository\n>> >   fatal: The remote end hung up unexpectedly\n>> >\n>> > The final, most important error messages are dwarfed out by the warning\n>> > that talks about setting configuration on the remote that does not even\n>> > exist.\n>\n> I actually agree, but that final error is printed in a very ugly\n> place! It would require some surgery to pause the warning until we\n> figure out that sf.net is not a valid remote in the current setup.\n>\n> get_refs_via_connect->connect_setup->git_connect-> .. fork()s .., runs\n>    \"sh -c git-receive-pack 'sf.net'\" (which prints the first error)\n> and get_remote_heads->packet_read_line->safe_read() dumps the final error\n> and dies.\n>\n> Is there any reason why remote_get needs to return a valid remote for\n> a value like \"sf.net\"?  If it didn't, the error message would be even\n> better, and not complain about a \"remote end\".\n\nYeah, you could work around by special casing colon-less ones as you\nsuggested, but I do not think it is worth it.\n\nInstead of \"sf.net\", the example could have been\n\n\tgit-core.git.sourceforge.net:/gitroot/gut-core\n\nwhich looks like a perfectly valid push destination, but it has a typo in\nthe pathname, and the remote end will hang up unexpectedly in such a case,\ntoo.  I do not think remote_get() is a wrong thing to blame; in that\ncodepath you simply do not know.\n\nIf you want to remove warning when we will eventually go \"fatal\", the way\nto do so is to remember you need to issue a warning but defer it until you\nactually start telling the other end in do_send_pack(), or something like\nthat.\n\nI do not think we would want nor need to go that route.  This warning is\nabout a local configuration that applies to _all_ remotes, and setting the\nconfiguration once will squelch it for future push to any remotes.  Giving\nthe warning even for an _incorrect_ remote is not wrong per-se.\n\nIssuing the warning at first looked incorrect to me, but it warns exactly\nabout what the patch that added the warning messages wanted to warn about:\n\n    If you did not misspell the name of the remote or the URL, you would\n    have triggered the default \"matching refs\" semantics, but you may not\n    have meant to do so, hence we are warning.  If you want to change the\n    default, here is how.  If you find this message irritating, you can\n    squelch it this way.\n\nIn this particular case, I _did_ want the default matching refs semantics,\nso it was irritating whether I had the last two \"fatal\" lines or not.  But\nthe point of your patch was to help new people for the cost of irritating\npeople like me (once), so...\n"}]}