{"thread":{"id":"30696","subject":"What's cooking in git.git (Jun 2012, #01; Sun, 3)","startedAt":"2012-06-04T00:23:13Z","lastAt":"2012-06-13T18:04:32Z","messageCount":12,"participants":["Junio C Hamano","Felipe Contreras","René Scharfe"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"192785","messageId":"7vr4twudqm.fsf@alter.siamese.dyndns.org","threadId":"30696","inReplyTo":null,"subject":"What's cooking in git.git (Jun 2012, #01; Sun, 3)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-04T00:23:13Z","receivedAt":"2012-06-04T00:23:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"What's cooking in git.git (Jun 2012, #01; Sun, 3)\n--------------------------------------------------\n\nHere are the topics that have been cooking.  Commits prefixed with '-' are\nonly in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.\n\nv1.7.11-rc1 has been tagged.  Except for trivially obvious and small\nfixes to older bugs and trivially obvious and small patches to\ndocumentation, please consider we are in \"regression fix only\"\nmode.  Finding and fixing since v1.7.10 is the top priority.\n\nYou can find the changes described here in the integration branches of the\nrepositories listed at\n\n    http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[New Topics]\n\n* jc/ls-files-i-dir (2012-06-03) 2 commits\n - ls-files -i: micro-optimize path_excluded()\n - ls-files -i: pay attention to exclusion of leading paths\n\n\"git ls-files --exclude=t -i\" did not consider anything under t/\nas excluded, as it did not pay attention to exclusion of leading\npaths while walking the index.\n\n* jc/request-pull-match-tagname (2012-06-01) 1 commit\n - request-pull: really favor a matching tag\n\n\"git request-pull $url dev\" when the tip of \"dev\" branch was tagged\nwith \"ext4-for-linus\" used the contents from the tag in the output\nbut still asked the \"dev\" branch to be pulled, not the tag.\n\n* db/vcs-svn (2012-06-01) 6 commits\n - vcs-svn: drop no-op reset methods\n - vcs-svn: fix signedness warnings\n - vcs-svn: prefer strstr over memmem\n - vcs-svn: prefer constcmp to prefixcmp\n - vcs-svn: simplify cleanup in apply_one_window()\n - vcs-svn: fix clang-analyzer error\n\n* jk/version-string (2012-06-03) 3 commits\n - http: get default user-agent from git_user_agent\n - version: add git_user_agent function\n - move git_version_string into version.c\n\n* mm/api-credentials-doc (2012-06-03) 3 commits\n - api-credentials.txt: mention credential.helper explicitly\n - api-credentials.txt: add \"see also\" section\n - api-credentials.txt: show the big picture first\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* ef/http-o-depends-on-gvf (2012-05-31) 1 commit\n  (merged to 'next' on 2012-05-31 at 11af7cd)\n + Makefile: add missing GIT-VERSION-FILE dependency\n\nA compilation fix.\n\n* ef/maint-rebase-error-message (2012-05-30) 1 commit\n  (merged to 'next' on 2012-05-30 at 5194fe3)\n + rebase: report invalid commit correctly\n\nWhen \"git rebase\" was given a bad commit to replay the history on,\nits error message did not correctly give the command line argument\nit had trouble parsing.\n\n* jl/submodule-report-new-path-once (2012-05-29) 1 commit\n  (merged to 'next' on 2012-05-30 at e482dd9)\n + submodules: print \"registered for path\" message only once\n\n\"git submodule init\" said \"registered for path\" even for a submodule\nthat was already registered.\n\n* mm/levenstein-penalize-deletion-less (2012-05-29) 1 commit\n  (merged to 'next' on 2012-05-30 at b2a0346)\n + Reduce cost of deletion in levenstein distance (4 -> 3)\n\n\"git tags\" errored out, suggesting \"git stage\" while \"git tag\" is\na far more appropriate choice.\n\n* nh/empty-rebase (2012-05-29) 1 commit\n  (merged to 'next' on 2012-05-30 at 270703a)\n + cherry-pick: regression fix for empty commits\n\nFix for a new topic that happened in the 1.7.11 track.\n\n* vr/rebase-autosquash-does-not-imply-i (2012-05-29) 1 commit\n  (merged to 'next' on 2012-05-30 at 10dd3af)\n + Do not autosquash in case of an implied interactive rebase\n\n\"git rebase -p\" should not pay attention to rebase.autosquash nor\n\"git rebase -p --autosquash\".\n\n--------------------------------------------------\n[Stalled]\n\n* nl/http-proxy-more (2012-05-11) 2 commits\n - http: rename HTTP_REAUTH to HTTP_AUTH_RETRY\n - http: Avoid limit of retrying request only twice\n\nI queued only the later two patches from this series, even though they do\nnot make much sense without the first one that seems to need a bit more\nwork, so that we won't forget.\n\n* jk/no-op-push-message (2012-05-30) 1 commit\n - improve no-op push output\n\nRewords the status message of \"git push\" that pushed only one ref\ndifferently from \"Everything up-to-date\", to give a bit more help to\npeople who get the message when their current branch is not pushed.\n\nIt probably is a better idea to add a message that says that the\ncurrent was not pushed to address the problem in a more direct way.\n\n* fc/git-prompt-script (2012-05-22) 5 commits\n - completion: split __git_ps1 into a separate script\n - completion: remove executable mode\n - Merge branch 'fc/git-complete-helper' into fc/git-prompt-script\n - tests: add tests for the bash prompt functions in the completion script\n - tests: move code to run tests under bash into a helper library\n (this branch is tangled with sg/bash-prompt.)\n\nThe last remaining sticking point is what to do with the duplicated shell\nfunction.\n\n* sg/bash-prompt (2012-05-09) 4 commits\n - completion: respect $GIT_DIR\n - completion: use __gitdir() in _git_log()\n - tests: add tests for the bash prompt functions in the completion script\n - tests: move code to run tests under bash into a helper library\n (this branch is tangled with fc/git-prompt-script.)\n\nThis is only the \"correction\" bits taken from the beginning of a larger\nseries that is to be rerolled.  The first two are tangled with Felipe's\ntopic so a reroll, if comes, should build on top of them.\n\n* jc/apply-3way (2012-05-16) 12 commits\n - WIP: the message is bogus in apply:::check_patch()\n - apply: refactor \"previous patch\" logic\n - apply: a bit more comments on PATH_TO_BE_DELETED\n - apply: document --3way option\n - apply: allow rerere() upon --3way results\n - apply: register conflicted stages to the index\n - apply: plug the three-way merge logic in\n - apply: fall back on three-way merge\n - apply: accept -3/--3way command line option\n - apply: split load_preimage() helper function out\n - apply: refactor read_file_or_gitlink()\n - apply: clear_image() clears things a bit more\n\n\"git apply\" learns to wiggle the base version and perform three-way merge\nwhen a patch does not exactly apply to the version you have.\n\nIt turns out that it is somewhat unpleasant to handle add/add conflicts in\nthis code, but it seems necessary if we want to use \"apply -3\" to replace\nthe use of \"apply --build-fake-ancestor\" followed by the slow \"merge\" in\n\"am -3\".\n\n* jc/maint-push-refs-all (2012-05-04) 2 commits\n - get_fetch_map(): tighten checks on dest refs\n - fetch/push: allow refs/*:refs/*\n\nAllows pushing and fetching refs/stash.\nNot ready.\nThere still seem to be other bugs hiding (e.g. try pushing twice).\n\n* jc/run-hook-env-1 (2012-03-11) 1 commit\n - run_hook(): enhance the interface to pass arbitrary environment\n\nNot urgent.\n\nUpdates run_hook() API to be much less specific to \"commit\".  It would\nonly be useful if people start doing more interesting things with hooks.\n\n* jc/split-blob (2012-04-03) 6 commits\n - chunked-object: streaming checkout\n - chunked-object: fallback checkout codepaths\n - bulk-checkin: support chunked-object encoding\n - bulk-checkin: allow the same data to be multiply hashed\n - new representation types in the packstream\n - packfile: use varint functions\n\nNot ready.\n\nI finished the streaming checkout codepath, but as explained in\n127b177 (bulk-checkin: support chunked-object encoding, 2011-11-30),\nthese are still early steps of a long and painful journey. At least\npack-objects and fsck need to learn the new encoding for the series\nto be usable locally, and then index-pack/unpack-objects needs to\nlearn it to be used remotely.\n\nGiven that I heard a lot of noise that people want large files, and\nthat I was asked by somebody at GitTogether'11 privately for an\nadvice on how to pay developers (not me) to help adding necessary\nsupport, I am somewhat dissapointed that the original patch series\nthat was sent almost two months ago still remains here without much\ncomments and updates from the developer community. I even made the\ninterface to the logic that decides where to split chunks easily\nreplaceable, and I deliberately made the logic in the original patch\nextremely stupid to entice others, especially the \"bup\" fanboys, to\ncome up with a better logic, thinking that giving people an easy\ntarget to shoot for, they may be encouraged to help out. The plan is\nnot working :-(.\n\n--------------------------------------------------\n[Cooking]\n\n* nd/exclude-workaround-top-heavy (2012-05-29) 2 commits\n - exclude: do strcmp as much as possible before fnmatch\n - Unindent excluded_from_list()\n\nAttempts to optimize matching with an exclude pattern with a deep\ndirectory hierarchy by taking the part that specifies leading path\nwithout wildcard literally.\n\nThe code to check for wildcard needs to be redone.\n\n* nd/stream-pack-objects (2012-05-29) 1 commit\n - pack-objects: use streaming interface for reading large loose blobs\n\n* jk/clone-local (2012-05-30) 2 commits\n - clone: allow --no-local to turn off local optimizations\n - docs/clone: mention that --local may be ignored\n\n\"git clone --local $path\" started its life as an experiment to\noptionally use link/copy when cloning a repository on the disk, but\nwe didn't deprecate it after we made the option a no-op to always\nuse the optimization.\n\n* jk/no-more-asciidoc7 (2012-05-30) 2 commits\n - docs: drop antique comment from Makefile\n - docs: drop asciidoc7compatible flag\n\n* cr/persistent-https (2012-05-30) 1 commit\n  (merged to 'next' on 2012-06-01 at c647464)\n + Add persistent-https to contrib\n\nA remote helper that acts as a proxy that caches ssl session for the\nhttps:// transport is added to the contrib/ area.\n\n* nd/stream-index-pack (2012-05-24) 4 commits\n - index-pack: use streaming interface for collision test on large blobs\n - index-pack: factor out unpack core from get_data_from_pack\n - index-pack: use streaming interface on large blobs (most of the time)\n - index-pack: hash non-delta objects while reading from stream\n\nUse streaming API to read from the object store to avoid having to hold\na large blob object in-core while running index-pack.\n\n* js/submodule-relative (2012-06-03) 4 commits\n - submodule: fix handling of superproject origin URLs like foo, ./foo and ./foo/bar\n - submodule: fix sync handling of some relative superproject origin URLs\n - submodule: document failure to handle relative superproject origin URLs\n - submodule: additional regression tests for relative URLs\n\n* mm/push-default-switch-warning (2012-04-26) 2 commits\n - t5541: warning message is given even with --quiet\n - push: start warning upcoming default change for push.default\n\nWill squash the two, but this has to wait for a few release cycles.\n\n--------------------------------------------------\n[Discarded]\n\n* cb/daemon-test-race-fix (2012-04-27) 2 commits\n  (merged to 'next' on 2012-04-27 at 84bbcf8)\n + Revert \"git-daemon wrapper to wait until daemon is ready\"\n  (merged to 'next' on 2012-04-24 at d5c30be)\n + git-daemon wrapper to wait until daemon is ready\n\nReverted from 'next' to replace it with js/daemon-test-race-fix.\n"},{"id":"192979","messageId":"CAMP44s0cQe3jdfzbJmFVoFS50Ho5hVPg9dpZx0KhG3sP_J8=_g@mail.gmail.com","threadId":"30696","inReplyTo":"7vr4twudqm.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-06-06T12:22:59Z","receivedAt":"2012-06-06T12:22:59Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Jun 4, 2012 at 2:23 AM, Junio C Hamano <gitster@pobox.com> wrote:\n\n> * fc/git-prompt-script (2012-05-22) 5 commits\n>  - completion: split __git_ps1 into a separate script\n>  - completion: remove executable mode\n>  - Merge branch 'fc/git-complete-helper' into fc/git-prompt-script\n>  - tests: add tests for the bash prompt functions in the completion script\n>  - tests: move code to run tests under bash into a helper library\n>  (this branch is tangled with sg/bash-prompt.)\n>\n> The last remaining sticking point is what to do with the duplicated shell\n> function.\n\nWhat is the problem with leaving it as it is; having it as a duplicate\nfunction. It's not a *huge* maintenance burden, and it's a big problem\nif the functions diverge.\n\nI still plan to add a native helper for this, but I don't see what\nthat would block these patches.\n\n-- \nFelipe Contreras\n"},{"id":"193002","messageId":"7vbokwmifp.fsf@alter.siamese.dyndns.org","threadId":"30696","inReplyTo":"CAMP44s0cQe3jdfzbJmFVoFS50Ho5hVPg9dpZx0KhG3sP_J8=_g@mail.gmail.com","subject":"Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-06T17:58:02Z","receivedAt":"2012-06-06T17:58:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n>> The last remaining sticking point is what to do with the duplicated shell\n>> function.\n>\n> What is the problem with leaving it as it is; having it as a duplicate\n> function. It's not a *huge* maintenance burden, and it's a big problem\n> if the functions diverge.\n\nIt is not even funny to see these two conflicting claims made in a\nsingle sentence.  Given that you are aware that it will cause a huge\nproblem to the end users if they diverge, is there any mechanism in\nthe result of applying the series to prevent it from happening?\n\nThe preventative measure could be any of these:\n\n (1) a build structure that arranges the sources in such a way that\n     there is only one copy for anybody who edits the function, so\n     that by definition they cannot diverge;\n\n (2) a test that causes \"make test\" to notice that the duplicated\n     copies diverged and makes the test fail, so that such a\n     breakage is caught before being pushed out; or\n\n (3) a note near each of the duplicated definitions of the function,\n     telling people that when touching one copy, the modifier must\n     change the other copy to keep the duplicated definitions match,\n     so that reviewers would notice the note in the context of a\n     faulty patch that touches only one side.\n\nI did not see anything like these.\n\nI think I've sent out a patch along the line of (1) in an attempt to\nhelp, but I do not recall you responded to it in any way. And the\nfirst thing you do is to complain. The maintenance burden could be\nmade into \"not huge\", but what you are doing is to actively make it\nmore burdensome than necessary.\n\n> I still plan to add a native helper for this, but I don't see what\n> that would block these patches.\n\nI do not want to see a native helper, if other approaches would\nequally work to prevent divergence from happening, in which case\nsuch a change to the core would be a useless code churn.\n"},{"id":"193003","messageId":"CAMP44s2VGLj8kRih-95A0VDq86WKWHF3EhLvz0etyHHtP27qLA@mail.gmail.com","threadId":"30696","inReplyTo":"7vbokwmifp.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-06-06T18:17:36Z","receivedAt":"2012-06-06T18:17:36Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Jun 6, 2012 at 7:58 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>>> The last remaining sticking point is what to do with the duplicated shell\n>>> function.\n>>\n>> What is the problem with leaving it as it is; having it as a duplicate\n>> function. It's not a *huge* maintenance burden, and it's a big problem\n>> if the functions diverge.\n>\n> It is not even funny to see these two conflicting claims made in a\n> single sentence.  Given that you are aware that it will cause a huge\n> problem to the end users if they diverge,\n\nWhat would be that *huge* problem?\n\nSuppose __gitdir() in git-prompt.sh is never updated again; it won't\nbe any worst than it is currently, would it?\n\nSow what would be this _theoretical_ problem?\n\n> I did not see anything like these.\n\nNor is it needed *right now*. You could release v1.7.11 without any of\nthese, and then v1.7.11.1 or even v1.7.12 with a solution; I bet\n__gitdir() would not have changed by that point.\n\nBut more importantly; the world would not end.\n\n> I think I've sent out a patch along the line of (1) in an attempt to\n> help, but I do not recall you responded to it in any way.\n\nI just saw it now, and I think it's unnecessary extra complexity.\n\n> And the\n> first thing you do is to complain. The maintenance burden could be\n> made into \"not huge\", but what you are doing is to actively make it\n> more burdensome than necessary.\n\nI don't think it's needed *right now*. It's more important to fix the\ndynamic loading, which is a *real problem* users are experiencing\n*right now*.\n\n>> I still plan to add a native helper for this, but I don't see what\n>> that would block these patches.\n>\n> I do not want to see a native helper, if other approaches would\n> equally work to prevent divergence from happening, in which case\n> such a change to the core would be a useless code churn.\n\nFeel free to reject my patches and implement whatever you want, but I\nthink this is the cleanest and simplest solution, and I will give it a\ntry. But not right now.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"193231","messageId":"7vmx4baaqc.fsf@alter.siamese.dyndns.org","threadId":"30696","inReplyTo":"CAMP44s2VGLj8kRih-95A0VDq86WKWHF3EhLvz0etyHHtP27qLA@mail.gmail.com","subject":"Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-10T07:26:35Z","receivedAt":"2012-06-10T07:26:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n>> I did not see anything like these.\n>\n> Nor is it needed *right now*. You could release v1.7.11 without any of\n> these, and then v1.7.11.1 or even v1.7.12 with a solution; I bet\n> __gitdir() would not have changed by that point.\n\nAnd by that time on whom are you placing the burden of making sure\nthey do not diverge?  Don't you still realize that you are being\nirresponsible?\n\nIn any case, I am tired of your arguing without being constructive,\nso let's try again.  This is the third option I suggested to you.\n\nNotice in the post context lines that they are already subtly\ndifferent; one pays attention to $GIT_DIR, and the other does not.\nShouldn't they be not just kept in sync, but start out in sync in\nthe first place?\n\nAren't there other functions or variables that need to be kept in\nsync between these, by the way?\n\n-- >8 --\nSubject: completion: warn people about duplicated function\n\nThe __gitdir function is duplicated between completion and prompt\nscripts, and these definitions should not diverge; otherwise one of\nthem can be subtly broken depending on the order the user's shell\ndot-sources them.\n\nLeave a note to people who may want to touch one copy to make sure\nthey update the other one in sync.  Hopefully this line would also\nappear in the context of the patch to allow reviewers to notice a\npatch that attempts to update only one of them.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n\n contrib/completion/git-completion.bash | 2 ++\n contrib/completion/git-prompt.sh       | 2 ++\n 2 files changed, 4 insertions(+)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex abf8215..efcd875 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -33,12 +33,14 @@ case \"$COMP_WORDBREAKS\" in\n esac\n \n # __gitdir accepts 0 or 1 arguments (i.e., location)\n # returns location of .git repo\n __gitdir ()\n {\n+\t# Note: this function is duplicated in git-prompt.sh\n+\t# When updating it, make sure you update the other one to match.\n \tif [ -z \"${1-}\" ]; then\n \t\tif [ -n \"${__git_dir-}\" ]; then\n \t\t\techo \"$__git_dir\"\n \t\telif [ -d .git ]; then\n \t\t\techo .git\n \t\telse\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 8e2e9f3..29b1ec9 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -50,12 +50,14 @@\n # setting the bash.showUpstream config variable.\n \n # __gitdir accepts 0 or 1 arguments (i.e., location)\n # returns location of .git repo\n __gitdir ()\n {\n+\t# Note: this function is duplicated in git-completion.bash\n+\t# When updating it, make sure you update the other one to match.\n \tif [ -z \"${1-}\" ]; then\n \t\tif [ -n \"${__git_dir-}\" ]; then\n \t\t\techo \"$__git_dir\"\n \t\telif [ -n \"${GIT_DIR-}\" ]; then\n \t\t\ttest -d \"${GIT_DIR-}\" || return 1\n \t\t\techo \"$GIT_DIR\"\n"},{"id":"193264","messageId":"CAMP44s2US+PoxfboZSML84GEvUwiHV4eQBOQSp6zhruT8xrKdg@mail.gmail.com","threadId":"30696","inReplyTo":"7vmx4baaqc.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-06-10T15:09:22Z","receivedAt":"2012-06-10T15:09:22Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 10, 2012 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>>> I did not see anything like these.\n>>\n>> Nor is it needed *right now*. You could release v1.7.11 without any of\n>> these, and then v1.7.11.1 or even v1.7.12 with a solution; I bet\n>> __gitdir() would not have changed by that point.\n>\n> And by that time on whom are you placing the burden of making sure\n> they do not diverge?  Don't you still realize that you are being\n> irresponsible?\n\nThere would be no divergence, that is my bet. There has been only\n*two* changes since the creation of __gitdir(), and one is in the\nqueue.\n\nAnd even if it does change, there would be *no problem*. Since you\nhave avoided the question, here it goes again:\n\n>> It is not even funny to see these two conflicting claims made in a\n>> single sentence.  Given that you are aware that it will cause a huge\n>> problem to the end users if they diverge,\n>\n> What would be that *huge* problem?\n>\n> Suppose __gitdir() in git-prompt.sh is never updated again; it won't\n> be any worst than it is currently, would it?\n>\n> Sow what would be this _theoretical_ problem?\n\nYou say I'm being irresponsible, I say you are being preoccupied by a\ntheoretical problem that will not occur, and would not cause any\nproblems if it does.\n\n> In any case, I am tired of your arguing without being constructive,\n> so let's try again.  This is the third option I suggested to you.\n\nI could say the same about you :)\n\n> Subject: completion: warn people about duplicated function\n\nIf you want to solve fictional problems, sure go ahead, now the 0\npersons that plan to change __git_dir() before v1.7.11.1  would be\nwarned. As long as the real problem is fixed I'm fine with it.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"193270","messageId":"4FD4DBD7.5070204@lsrfire.ath.cx","threadId":"30696","inReplyTo":"CAMP44s2VGLj8kRih-95A0VDq86WKWHF3EhLvz0etyHHtP27qLA@mail.gmail.com","subject":"Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2012-06-10T17:39:35Z","receivedAt":"2012-06-10T17:39:35Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 06.06.2012 20:17, schrieb Felipe Contreras:\n> On Wed, Jun 6, 2012 at 7:58 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>\n>>>> The last remaining sticking point is what to do with the duplicated shell\n>>>> function.\n>>>\n>>> What is the problem with leaving it as it is; having it as a duplicate\n>>> function. It's not a *huge* maintenance burden, and it's a big problem\n>>> if the functions diverge.\n\nIn the last sentence you say that there would be a \"big problem\".\n\n>> It is not even funny to see these two conflicting claims made in a\n>> single sentence.  Given that you are aware that it will cause a huge\n>> problem to the end users if they diverge,\n>\n> What would be that *huge* problem?\n\nHere you ask what's so bad about it.\n\nPerhaps you meant to write \"it's NOT a big problem\" in the first place?\n\nRené\n"},{"id":"193296","messageId":"CAMP44s1ESu0WKYmR6g51q3cwJ-BWC22SuTHucGVSEsGuGTrxDQ@mail.gmail.com","threadId":"30696","inReplyTo":"4FD4DBD7.5070204@lsrfire.ath.cx","subject":"Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-06-11T10:27:02Z","receivedAt":"2012-06-11T10:27:02Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 10, 2012 at 7:39 PM, René Scharfe\n<rene.scharfe@lsrfire.ath.cx> wrote:\n> Am 06.06.2012 20:17, schrieb Felipe Contreras:\n>\n>> On Wed, Jun 6, 2012 at 7:58 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>>>\n>>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>>\n>>>>> The last remaining sticking point is what to do with the duplicated\n>>>>> shell\n>>>>> function.\n>>>>\n>>>>\n>>>> What is the problem with leaving it as it is; having it as a duplicate\n>>>> function. It's not a *huge* maintenance burden, and it's a big problem\n>>>> if the functions diverge.\n>\n>\n> In the last sentence you say that there would be a \"big problem\".\n>\n>\n>>> It is not even funny to see these two conflicting claims made in a\n>>> single sentence.  Given that you are aware that it will cause a huge\n>>> problem to the end users if they diverge,\n>>\n>>\n>> What would be that *huge* problem?\n>\n>\n> Here you ask what's so bad about it.\n>\n> Perhaps you meant to write \"it's NOT a big problem\" in the first place?\n\nYeap, that's what I meant.\n\n-- \nFelipe Contreras\n"},{"id":"193307","messageId":"7v7gvdaogr.fsf@alter.siamese.dyndns.org","threadId":"30696","inReplyTo":"CAMP44s2US+PoxfboZSML84GEvUwiHV4eQBOQSp6zhruT8xrKdg@mail.gmail.com","subject":"Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-11T14:54:28Z","receivedAt":"2012-06-11T14:54:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> You say I'm being irresponsible, I say you are being preoccupied by a\n> theoretical problem that will not occur, and would not cause any\n> problems if it does.\n\nSee how the two implementations are different and think what happens\nwhen a user dot sources these two scripts in different order. Callers\nof __gitdir in one expects it to pay attention to GIT_DIR, callers in\nthe other don't, but you can't have both at the same time in the\nsame shell, can you?\n\nIt is not theoretical, as you yourself already made it happen.\n\nGet over it.\n"},{"id":"193541","messageId":"CAMP44s1SOOBHRD7=u78S0dyRMdY0Q=zzkULxoz72ZzBaGC8Fyg@mail.gmail.com","threadId":"30696","inReplyTo":"7v7gvdaogr.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-06-13T14:55:41Z","receivedAt":"2012-06-13T14:55:41Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Jun 11, 2012 at 4:54 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> You say I'm being irresponsible, I say you are being preoccupied by a\n>> theoretical problem that will not occur, and would not cause any\n>> problems if it does.\n>\n> See how the two implementations are different\n\nThey are not.\n\nhttp://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-completion.bash;h=13690eaecb4d8fafa67b79d33e804e6f8c64d742;hb=refs/heads/pu#l37\n\nhttp://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-prompt.sh;h=29b1ec9eb1797e0f2c3c9f7067222432150ba85f;hb=refs/heads/pu#l54\n\nWhere is the difference?\n\n> and think what happens\n> when a user dot sources these two scripts in different order. Callers\n> of __gitdir in one expects it to pay attention to GIT_DIR, callers in\n> the other don't, but you can't have both at the same time in the\n> same shell, can you?\n\nSo, what you are saying is that we would end up with the \"wrong\" __gitdir()?\n\nBut that \"wrong\" version is the one that everybody has been using both\nfor completion and prompt since 2006, and *nobody* has complained\n(except SZEDER, recently).\n\nSo, as user, how would having this ancient __gitdir() would affect me?\nWhat is this \"huge\" issue that we want to avoid at all costs?\n\n> It is not theoretical, as you yourself already made it happen.\n\nNope. I haven't.\n\nEven if I did, what are the *effects*?\n\n> Get over it.\n\nIndeed, please do.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"193554","messageId":"7v8vfri0xx.fsf@alter.siamese.dyndns.org","threadId":"30696","inReplyTo":"CAMP44s1SOOBHRD7=u78S0dyRMdY0Q=zzkULxoz72ZzBaGC8Fyg@mail.gmail.com","subject":"Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-13T17:19:54Z","receivedAt":"2012-06-13T17:19:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> On Mon, Jun 11, 2012 at 4:54 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>\n>>> You say I'm being irresponsible, I say you are being preoccupied by a\n>>> theoretical problem that will not occur, and would not cause any\n>>> problems if it does.\n>>\n>> See how the two implementations are different\n>\n> They are not.\n>\n> http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-completion.bash;h=13690eaecb4d8fafa67b79d33e804e6f8c64d742;hb=refs/heads/pu#l37\n>\n> http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-prompt.sh;h=29b1ec9eb1797e0f2c3c9f7067222432150ba85f;hb=refs/heads/pu#l54\n>\n> Where is the difference?\n\nLook at your patch that introduces the separate file af31a45\n(completion: split __git_ps1 into a separate script, 2012-05-22)\ninstead.  The extra $GIT_DIR one in git-completion.sh bba88ea\n(completion: respect $GIT_DIR, 2012-05-09) is on another topic that\nis stalled and waiting for a reroll.\n\nAnd your message brings things back to my exact point. \n\nUnlike the other topic, the topic fc/git-prompt-script we have been\ndiscussing is almost ready except for this nit.  If we make it\ngraduate to 'master' without doing anything about the other commit,\nwe will have two different versions from day one.\n\nAnd the worst part of the story is that you are not just placing the\nburden of noticing and having to worry about these things on other\npeople (in this case, me), but are actively sabotaging the effort to\nmake future mistakes less likely to happen by endlessly bitching and\nrefusing to admit that there is a problem.  It seems that it is too\ndifficult for you to admit that you were wrong and say \"Yes there is\na problem, and among the three approaches you suggested, this is the\nleast intrusive one\" or \"Yes there is a problem, but I do not like\nany of the approaches you suggested, so I propose this alternative\nthat is much less intrusive than any of them\", and until that\nhappens I do not see a point in talking with you at all.\n"},{"id":"193560","messageId":"CAMP44s2yPJq=zF-pvC0O7jb-4BjXa2GL3fM=2Zh7zos-Jkduxg@mail.gmail.com","threadId":"30696","inReplyTo":"7v8vfri0xx.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-06-13T18:04:32Z","receivedAt":"2012-06-13T18:04:32Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Jun 13, 2012 at 7:19 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> On Mon, Jun 11, 2012 at 4:54 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>>\n>>>> You say I'm being irresponsible, I say you are being preoccupied by a\n>>>> theoretical problem that will not occur, and would not cause any\n>>>> problems if it does.\n>>>\n>>> See how the two implementations are different\n>>\n>> They are not.\n>>\n>> http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-completion.bash;h=13690eaecb4d8fafa67b79d33e804e6f8c64d742;hb=refs/heads/pu#l37\n>>\n>> http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-prompt.sh;h=29b1ec9eb1797e0f2c3c9f7067222432150ba85f;hb=refs/heads/pu#l54\n>>\n>> Where is the difference?\n>\n> Look at your patch that introduces the separate file af31a45\n> (completion: split __git_ps1 into a separate script, 2012-05-22)\n> instead.  The extra $GIT_DIR one in git-completion.sh bba88ea\n> (completion: respect $GIT_DIR, 2012-05-09) is on another topic that\n> is stalled and waiting for a reroll.\n>\n> And your message brings things back to my exact point.\n>\n> Unlike the other topic, the topic fc/git-prompt-script we have been\n> discussing is almost ready except for this nit.  If we make it\n> graduate to 'master' without doing anything about the other commit,\n> we will have two different versions from day one.\n\nEmphasis on *if*. Currently there's no difference on 'pu', which is\nwhere all the current patches are.\n\nIf there's a difference, I wouldn't be doing that, you would.\n\nOf course it's easy to fix; just rebase and copy the relevant version.\nAnybody could do that, I could do that; just tell me on top of which\ncommit I should rebase the patches.\n\n> And the worst part of the story is that you are not just placing the\n> burden of noticing and having to worry about these things on other\n> people (in this case, me), but are actively sabotaging the effort to\n> make future mistakes less likely to happen by endlessly bitching and\n> refusing to admit that there is a problem.\n\nWhat is the problem?\n\nLet's say you pick the patches as they are, and the newer version of\n__gitdir() ends up in 1.7.11. What would happen?\n\nAbsolutely nothing.\n\n> It seems that it is too\n> difficult for you to admit that you were wrong and say \"Yes there is\n> a problem, and among the three approaches you suggested, this is the\n> least intrusive one\" or \"Yes there is a problem, but I do not like\n> any of the approaches you suggested, so I propose this alternative\n> that is much less intrusive than any of them\", and until that\n> happens I do not see a point in talking with you at all.\n\nThere is no problem. There would be a problem if you cherry-pick the\npatches out of 'pu' without synchronizing. This could be fixed in 1\nminute; literally. Just tell me on top of which commit you want these\npatches and you would have them immediately. No problem.\n\nThen, if __gitdir() is updated later on (which is likely, but only\nbecause Szeder is already working on it), there _would_ be a tiny,\ninsignificant problem.\n\nNo user would care about this \"problem\". Basically __gitdir() _might_\nbe a little slower; whoa, we'll get tons of users complaining in the\nmailing list... NOT.\n\nThe \"problem\" you mention is hypothetical, and if you want to discuss\nimaginary issues, you would have to discuss with an imaginary me that\ncares, because I do not; I care about *real* issues, and dynamic\nloading is a *real* issuers that is hitting *real* users right now,\nand *real* distributions need workarounds. You are the one that\ndoesn't accept that.\n\nThere's no reason not to fix it; we can fix it _right now_, and there\nwould be no problems.\n\nHow about we make a bet; I bet no user would complain with something\nlike \"'git foo --tab' completion stopped working\", and the root of the\nproblem turns out to be a difference in __gitdir(); if somebody does\ncomplain, you win; and my penalty would be to accept what you say\nwithout discussion from that point on forward.\n\nCheers.\n\n-- \nFelipe Contreras\n"}]}