What's cooking in git.git (Jun 2012, #01; Sun, 3)

What's cooking in git.git (Jun 2012, #01; Sun, 3)

[Junio C Hamano]

What's cooking in git.git (Jun 2012, #01; Sun, 3)
--------------------------------------------------

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.

v1.7.11-rc1 has been tagged.  Except for trivially obvious and small
fixes to older bugs and trivially obvious and small patches to
documentation, please consider we are in "regression fix only"
mode.  Finding and fixing since v1.7.10 is the top priority.

You can find the changes described here in the integration branches of the
repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

--------------------------------------------------
[New Topics]

* jc/ls-files-i-dir (2012-06-03) 2 commits
 - ls-files -i: micro-optimize path_excluded()
 - ls-files -i: pay attention to exclusion of leading paths

"git ls-files --exclude=t -i" did not consider anything under t/
as excluded, as it did not pay attention to exclusion of leading
paths while walking the index.

* jc/request-pull-match-tagname (2012-06-01) 1 commit
 - request-pull: really favor a matching tag

"git request-pull $url dev" when the tip of "dev" branch was tagged
with "ext4-for-linus" used the contents from the tag in the output
but still asked the "dev" branch to be pulled, not the tag.

* db/vcs-svn (2012-06-01) 6 commits
 - vcs-svn: drop no-op reset methods
 - vcs-svn: fix signedness warnings
 - vcs-svn: prefer strstr over memmem
 - vcs-svn: prefer constcmp to prefixcmp
 - vcs-svn: simplify cleanup in apply_one_window()
 - vcs-svn: fix clang-analyzer error

* jk/version-string (2012-06-03) 3 commits
 - http: get default user-agent from git_user_agent
 - version: add git_user_agent function
 - move git_version_string into version.c

* mm/api-credentials-doc (2012-06-03) 3 commits
 - api-credentials.txt: mention credential.helper explicitly
 - api-credentials.txt: add "see also" section
 - api-credentials.txt: show the big picture first

--------------------------------------------------
[Graduated to "master"]

* ef/http-o-depends-on-gvf (2012-05-31) 1 commit
  (merged to 'next' on 2012-05-31 at 11af7cd)
 + Makefile: add missing GIT-VERSION-FILE dependency

A compilation fix.

* ef/maint-rebase-error-message (2012-05-30) 1 commit
  (merged to 'next' on 2012-05-30 at 5194fe3)
 + rebase: report invalid commit correctly

When "git rebase" was given a bad commit to replay the history on,
its error message did not correctly give the command line argument
it had trouble parsing.

* jl/submodule-report-new-path-once (2012-05-29) 1 commit
  (merged to 'next' on 2012-05-30 at e482dd9)
 + submodules: print "registered for path" message only once

"git submodule init" said "registered for path" even for a submodule
that was already registered.

* mm/levenstein-penalize-deletion-less (2012-05-29) 1 commit
  (merged to 'next' on 2012-05-30 at b2a0346)
 + Reduce cost of deletion in levenstein distance (4 -> 3)

"git tags" errored out, suggesting "git stage" while "git tag" is
a far more appropriate choice.

* nh/empty-rebase (2012-05-29) 1 commit
  (merged to 'next' on 2012-05-30 at 270703a)
 + cherry-pick: regression fix for empty commits

Fix for a new topic that happened in the 1.7.11 track.

* vr/rebase-autosquash-does-not-imply-i (2012-05-29) 1 commit
  (merged to 'next' on 2012-05-30 at 10dd3af)
 + Do not autosquash in case of an implied interactive rebase

"git rebase -p" should not pay attention to rebase.autosquash nor
"git rebase -p --autosquash".

--------------------------------------------------
[Stalled]

* nl/http-proxy-more (2012-05-11) 2 commits
 - http: rename HTTP_REAUTH to HTTP_AUTH_RETRY
 - http: Avoid limit of retrying request only twice

I queued only the later two patches from this series, even though they do
not make much sense without the first one that seems to need a bit more
work, so that we won't forget.

* jk/no-op-push-message (2012-05-30) 1 commit
 - improve no-op push output

Rewords the status message of "git push" that pushed only one ref
differently from "Everything up-to-date", to give a bit more help to
people who get the message when their current branch is not pushed.

It probably is a better idea to add a message that says that the
current was not pushed to address the problem in a more direct way.

* fc/git-prompt-script (2012-05-22) 5 commits
 - completion: split __git_ps1 into a separate script
 - completion: remove executable mode
 - Merge branch 'fc/git-complete-helper' into fc/git-prompt-script
 - tests: add tests for the bash prompt functions in the completion script
 - tests: move code to run tests under bash into a helper library
 (this branch is tangled with sg/bash-prompt.)

The last remaining sticking point is what to do with the duplicated shell
function.

* sg/bash-prompt (2012-05-09) 4 commits
 - completion: respect $GIT_DIR
 - completion: use __gitdir() in _git_log()
 - tests: add tests for the bash prompt functions in the completion script
 - tests: move code to run tests under bash into a helper library
 (this branch is tangled with fc/git-prompt-script.)

This is only the "correction" bits taken from the beginning of a larger
series that is to be rerolled.  The first two are tangled with Felipe's
topic so a reroll, if comes, should build on top of them.

* jc/apply-3way (2012-05-16) 12 commits
 - WIP: the message is bogus in apply:::check_patch()
 - apply: refactor "previous patch" logic
 - apply: a bit more comments on PATH_TO_BE_DELETED
 - apply: document --3way option
 - apply: allow rerere() upon --3way results
 - apply: register conflicted stages to the index
 - apply: plug the three-way merge logic in
 - apply: fall back on three-way merge
 - apply: accept -3/--3way command line option
 - apply: split load_preimage() helper function out
 - apply: refactor read_file_or_gitlink()
 - apply: clear_image() clears things a bit more

"git apply" learns to wiggle the base version and perform three-way merge
when a patch does not exactly apply to the version you have.

It turns out that it is somewhat unpleasant to handle add/add conflicts in
this code, but it seems necessary if we want to use "apply -3" to replace
the use of "apply --build-fake-ancestor" followed by the slow "merge" in
"am -3".

* jc/maint-push-refs-all (2012-05-04) 2 commits
 - get_fetch_map(): tighten checks on dest refs
 - fetch/push: allow refs/*:refs/*

Allows pushing and fetching refs/stash.
Not ready.
There still seem to be other bugs hiding (e.g. try pushing twice).

* jc/run-hook-env-1 (2012-03-11) 1 commit
 - run_hook(): enhance the interface to pass arbitrary environment

Not urgent.

Updates run_hook() API to be much less specific to "commit".  It would
only be useful if people start doing more interesting things with hooks.

* jc/split-blob (2012-04-03) 6 commits
 - chunked-object: streaming checkout
 - chunked-object: fallback checkout codepaths
 - bulk-checkin: support chunked-object encoding
 - bulk-checkin: allow the same data to be multiply hashed
 - new representation types in the packstream
 - packfile: use varint functions

Not ready.

I finished the streaming checkout codepath, but as explained in
127b177 (bulk-checkin: support chunked-object encoding, 2011-11-30),
these are still early steps of a long and painful journey. At least
pack-objects and fsck need to learn the new encoding for the series
to be usable locally, and then index-pack/unpack-objects needs to
learn it to be used remotely.

Given that I heard a lot of noise that people want large files, and
that I was asked by somebody at GitTogether'11 privately for an
advice on how to pay developers (not me) to help adding necessary
support, I am somewhat dissapointed that the original patch series
that was sent almost two months ago still remains here without much
comments and updates from the developer community. I even made the
interface to the logic that decides where to split chunks easily
replaceable, and I deliberately made the logic in the original patch
extremely stupid to entice others, especially the "bup" fanboys, to
come up with a better logic, thinking that giving people an easy
target to shoot for, they may be encouraged to help out. The plan is
not working :-(.

--------------------------------------------------
[Cooking]

* nd/exclude-workaround-top-heavy (2012-05-29) 2 commits
 - exclude: do strcmp as much as possible before fnmatch
 - Unindent excluded_from_list()

Attempts to optimize matching with an exclude pattern with a deep
directory hierarchy by taking the part that specifies leading path
without wildcard literally.

The code to check for wildcard needs to be redone.

* nd/stream-pack-objects (2012-05-29) 1 commit
 - pack-objects: use streaming interface for reading large loose blobs

* jk/clone-local (2012-05-30) 2 commits
 - clone: allow --no-local to turn off local optimizations
 - docs/clone: mention that --local may be ignored

"git clone --local $path" started its life as an experiment to
optionally use link/copy when cloning a repository on the disk, but
we didn't deprecate it after we made the option a no-op to always
use the optimization.

* jk/no-more-asciidoc7 (2012-05-30) 2 commits
 - docs: drop antique comment from Makefile
 - docs: drop asciidoc7compatible flag

* cr/persistent-https (2012-05-30) 1 commit
  (merged to 'next' on 2012-06-01 at c647464)
 + Add persistent-https to contrib

A remote helper that acts as a proxy that caches ssl session for the
https:// transport is added to the contrib/ area.

* nd/stream-index-pack (2012-05-24) 4 commits
 - index-pack: use streaming interface for collision test on large blobs
 - index-pack: factor out unpack core from get_data_from_pack
 - index-pack: use streaming interface on large blobs (most of the time)
 - index-pack: hash non-delta objects while reading from stream

Use streaming API to read from the object store to avoid having to hold
a large blob object in-core while running index-pack.

* js/submodule-relative (2012-06-03) 4 commits
 - submodule: fix handling of superproject origin URLs like foo, ./foo and ./foo/bar
 - submodule: fix sync handling of some relative superproject origin URLs
 - submodule: document failure to handle relative superproject origin URLs
 - submodule: additional regression tests for relative URLs

* mm/push-default-switch-warning (2012-04-26) 2 commits
 - t5541: warning message is given even with --quiet
 - push: start warning upcoming default change for push.default

Will squash the two, but this has to wait for a few release cycles.

--------------------------------------------------
[Discarded]

* cb/daemon-test-race-fix (2012-04-27) 2 commits
  (merged to 'next' on 2012-04-27 at 84bbcf8)
 + Revert "git-daemon wrapper to wait until daemon is ready"
  (merged to 'next' on 2012-04-24 at d5c30be)
 + git-daemon wrapper to wait until daemon is ready

Reverted from 'next' to replace it with js/daemon-test-race-fix.

Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)

[Felipe Contreras]

On Mon, Jun 4, 2012 at 2:23 AM, Junio C Hamano <gitster@pobox.com> wrote:

> * fc/git-prompt-script (2012-05-22) 5 commits
>  - completion: split __git_ps1 into a separate script
>  - completion: remove executable mode
>  - Merge branch 'fc/git-complete-helper' into fc/git-prompt-script
>  - tests: add tests for the bash prompt functions in the completion script
>  - tests: move code to run tests under bash into a helper library
>  (this branch is tangled with sg/bash-prompt.)
>
> The last remaining sticking point is what to do with the duplicated shell
> function.

What is the problem with leaving it as it is; having it as a duplicate
function. It's not a *huge* maintenance burden, and it's a big problem
if the functions diverge.

I still plan to add a native helper for this, but I don't see what
that would block these patches.

-- 
Felipe Contreras

Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

>> The last remaining sticking point is what to do with the duplicated shell
>> function.
>
> What is the problem with leaving it as it is; having it as a duplicate
> function. It's not a *huge* maintenance burden, and it's a big problem
> if the functions diverge.

It is not even funny to see these two conflicting claims made in a
single sentence.  Given that you are aware that it will cause a huge
problem to the end users if they diverge, is there any mechanism in
the result of applying the series to prevent it from happening?

The preventative measure could be any of these:

 (1) a build structure that arranges the sources in such a way that
     there is only one copy for anybody who edits the function, so
     that by definition they cannot diverge;

 (2) a test that causes "make test" to notice that the duplicated
     copies diverged and makes the test fail, so that such a
     breakage is caught before being pushed out; or

 (3) a note near each of the duplicated definitions of the function,
     telling people that when touching one copy, the modifier must
     change the other copy to keep the duplicated definitions match,
     so that reviewers would notice the note in the context of a
     faulty patch that touches only one side.

I did not see anything like these.

I think I've sent out a patch along the line of (1) in an attempt to
help, but I do not recall you responded to it in any way. And the
first thing you do is to complain. The maintenance burden could be
made into "not huge", but what you are doing is to actively make it
more burdensome than necessary.

> I still plan to add a native helper for this, but I don't see what
> that would block these patches.

I do not want to see a native helper, if other approaches would
equally work to prevent divergence from happening, in which case
such a change to the core would be a useless code churn.

Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)

[Felipe Contreras]

On Wed, Jun 6, 2012 at 7:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> The last remaining sticking point is what to do with the duplicated shell
>>> function.
>>
>> What is the problem with leaving it as it is; having it as a duplicate
>> function. It's not a *huge* maintenance burden, and it's a big problem
>> if the functions diverge.
>
> It is not even funny to see these two conflicting claims made in a
> single sentence.  Given that you are aware that it will cause a huge
> problem to the end users if they diverge,

What would be that *huge* problem?

Suppose __gitdir() in git-prompt.sh is never updated again; it won't
be any worst than it is currently, would it?

Sow what would be this _theoretical_ problem?

> I did not see anything like these.

Nor is it needed *right now*. You could release v1.7.11 without any of
these, and then v1.7.11.1 or even v1.7.12 with a solution; I bet
__gitdir() would not have changed by that point.

But more importantly; the world would not end.

> I think I've sent out a patch along the line of (1) in an attempt to
> help, but I do not recall you responded to it in any way.

I just saw it now, and I think it's unnecessary extra complexity.

> And the
> first thing you do is to complain. The maintenance burden could be
> made into "not huge", but what you are doing is to actively make it
> more burdensome than necessary.

I don't think it's needed *right now*. It's more important to fix the
dynamic loading, which is a *real problem* users are experiencing
*right now*.

>> I still plan to add a native helper for this, but I don't see what
>> that would block these patches.
>
> I do not want to see a native helper, if other approaches would
> equally work to prevent divergence from happening, in which case
> such a change to the core would be a useless code churn.

Feel free to reject my patches and implement whatever you want, but I
think this is the cleanest and simplest solution, and I will give it a
try. But not right now.

Cheers.

-- 
Felipe Contreras

Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

>> I did not see anything like these.
>
> Nor is it needed *right now*. You could release v1.7.11 without any of
> these, and then v1.7.11.1 or even v1.7.12 with a solution; I bet
> __gitdir() would not have changed by that point.

And by that time on whom are you placing the burden of making sure
they do not diverge?  Don't you still realize that you are being
irresponsible?

In any case, I am tired of your arguing without being constructive,
so let's try again.  This is the third option I suggested to you.

Notice in the post context lines that they are already subtly
different; one pays attention to $GIT_DIR, and the other does not.
Shouldn't they be not just kept in sync, but start out in sync in
the first place?

Aren't there other functions or variables that need to be kept in
sync between these, by the way?

-- >8 --
Subject: completion: warn people about duplicated function

The __gitdir function is duplicated between completion and prompt
scripts, and these definitions should not diverge; otherwise one of
them can be subtly broken depending on the order the user's shell
dot-sources them.

Leave a note to people who may want to touch one copy to make sure
they update the other one in sync.  Hopefully this line would also
appear in the context of the patch to allow reviewers to notice a
patch that attempts to update only one of them.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 contrib/completion/git-completion.bash | 2 ++
 contrib/completion/git-prompt.sh       | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index abf8215..efcd875 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -33,12 +33,14 @@ case "$COMP_WORDBREAKS" in
 esac
 
 # __gitdir accepts 0 or 1 arguments (i.e., location)
 # returns location of .git repo
 __gitdir ()
 {
+	# Note: this function is duplicated in git-prompt.sh
+	# When updating it, make sure you update the other one to match.
 	if [ -z "${1-}" ]; then
 		if [ -n "${__git_dir-}" ]; then
 			echo "$__git_dir"
 		elif [ -d .git ]; then
 			echo .git
 		else
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 8e2e9f3..29b1ec9 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -50,12 +50,14 @@
 # setting the bash.showUpstream config variable.
 
 # __gitdir accepts 0 or 1 arguments (i.e., location)
 # returns location of .git repo
 __gitdir ()
 {
+	# Note: this function is duplicated in git-completion.bash
+	# When updating it, make sure you update the other one to match.
 	if [ -z "${1-}" ]; then
 		if [ -n "${__git_dir-}" ]; then
 			echo "$__git_dir"
 		elif [ -n "${GIT_DIR-}" ]; then
 			test -d "${GIT_DIR-}" || return 1
 			echo "$GIT_DIR"

Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)

[Felipe Contreras]

On Sun, Jun 10, 2012 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> I did not see anything like these.
>>
>> Nor is it needed *right now*. You could release v1.7.11 without any of
>> these, and then v1.7.11.1 or even v1.7.12 with a solution; I bet
>> __gitdir() would not have changed by that point.
>
> And by that time on whom are you placing the burden of making sure
> they do not diverge?  Don't you still realize that you are being
> irresponsible?

There would be no divergence, that is my bet. There has been only
*two* changes since the creation of __gitdir(), and one is in the
queue.

And even if it does change, there would be *no problem*. Since you
have avoided the question, here it goes again:

>> It is not even funny to see these two conflicting claims made in a
>> single sentence.  Given that you are aware that it will cause a huge
>> problem to the end users if they diverge,
>
> What would be that *huge* problem?
>
> Suppose __gitdir() in git-prompt.sh is never updated again; it won't
> be any worst than it is currently, would it?
>
> Sow what would be this _theoretical_ problem?

You say I'm being irresponsible, I say you are being preoccupied by a
theoretical problem that will not occur, and would not cause any
problems if it does.

> In any case, I am tired of your arguing without being constructive,
> so let's try again.  This is the third option I suggested to you.

I could say the same about you :)

> Subject: completion: warn people about duplicated function

If you want to solve fictional problems, sure go ahead, now the 0
persons that plan to change __git_dir() before v1.7.11.1  would be
warned. As long as the real problem is fixed I'm fine with it.

Cheers.

-- 
Felipe Contreras

Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)

[René Scharfe]

Am 06.06.2012 20:17, schrieb Felipe Contreras:
> On Wed, Jun 6, 2012 at 7:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>>> The last remaining sticking point is what to do with the duplicated shell
>>>> function.
>>>
>>> What is the problem with leaving it as it is; having it as a duplicate
>>> function. It's not a *huge* maintenance burden, and it's a big problem
>>> if the functions diverge.

In the last sentence you say that there would be a "big problem".

>> It is not even funny to see these two conflicting claims made in a
>> single sentence.  Given that you are aware that it will cause a huge
>> problem to the end users if they diverge,
>
> What would be that *huge* problem?

Here you ask what's so bad about it.

Perhaps you meant to write "it's NOT a big problem" in the first place?

René

Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)

[Felipe Contreras]

On Sun, Jun 10, 2012 at 7:39 PM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> Am 06.06.2012 20:17, schrieb Felipe Contreras:
>
>> On Wed, Jun 6, 2012 at 7:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>>> The last remaining sticking point is what to do with the duplicated
>>>>> shell
>>>>> function.
>>>>
>>>>
>>>> What is the problem with leaving it as it is; having it as a duplicate
>>>> function. It's not a *huge* maintenance burden, and it's a big problem
>>>> if the functions diverge.
>
>
> In the last sentence you say that there would be a "big problem".
>
>
>>> It is not even funny to see these two conflicting claims made in a
>>> single sentence.  Given that you are aware that it will cause a huge
>>> problem to the end users if they diverge,
>>
>>
>> What would be that *huge* problem?
>
>
> Here you ask what's so bad about it.
>
> Perhaps you meant to write "it's NOT a big problem" in the first place?

Yeap, that's what I meant.

-- 
Felipe Contreras

Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> You say I'm being irresponsible, I say you are being preoccupied by a
> theoretical problem that will not occur, and would not cause any
> problems if it does.

See how the two implementations are different and think what happens
when a user dot sources these two scripts in different order. Callers
of __gitdir in one expects it to pay attention to GIT_DIR, callers in
the other don't, but you can't have both at the same time in the
same shell, can you?

It is not theoretical, as you yourself already made it happen.

Get over it.

Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)

[Felipe Contreras]

On Mon, Jun 11, 2012 at 4:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> You say I'm being irresponsible, I say you are being preoccupied by a
>> theoretical problem that will not occur, and would not cause any
>> problems if it does.
>
> See how the two implementations are different

They are not.

http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-completion.bash;h=13690eaecb4d8fafa67b79d33e804e6f8c64d742;hb=refs/heads/pu#l37

http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-prompt.sh;h=29b1ec9eb1797e0f2c3c9f7067222432150ba85f;hb=refs/heads/pu#l54

Where is the difference?

> and think what happens
> when a user dot sources these two scripts in different order. Callers
> of __gitdir in one expects it to pay attention to GIT_DIR, callers in
> the other don't, but you can't have both at the same time in the
> same shell, can you?

So, what you are saying is that we would end up with the "wrong" __gitdir()?

But that "wrong" version is the one that everybody has been using both
for completion and prompt since 2006, and *nobody* has complained
(except SZEDER, recently).

So, as user, how would having this ancient __gitdir() would affect me?
What is this "huge" issue that we want to avoid at all costs?

> It is not theoretical, as you yourself already made it happen.

Nope. I haven't.

Even if I did, what are the *effects*?

> Get over it.

Indeed, please do.

Cheers.

-- 
Felipe Contreras

Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Mon, Jun 11, 2012 at 4:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> You say I'm being irresponsible, I say you are being preoccupied by a
>>> theoretical problem that will not occur, and would not cause any
>>> problems if it does.
>>
>> See how the two implementations are different
>
> They are not.
>
> http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-completion.bash;h=13690eaecb4d8fafa67b79d33e804e6f8c64d742;hb=refs/heads/pu#l37
>
> http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-prompt.sh;h=29b1ec9eb1797e0f2c3c9f7067222432150ba85f;hb=refs/heads/pu#l54
>
> Where is the difference?

Look at your patch that introduces the separate file af31a45
(completion: split __git_ps1 into a separate script, 2012-05-22)
instead.  The extra $GIT_DIR one in git-completion.sh bba88ea
(completion: respect $GIT_DIR, 2012-05-09) is on another topic that
is stalled and waiting for a reroll.

And your message brings things back to my exact point. 

Unlike the other topic, the topic fc/git-prompt-script we have been
discussing is almost ready except for this nit.  If we make it
graduate to 'master' without doing anything about the other commit,
we will have two different versions from day one.

And the worst part of the story is that you are not just placing the
burden of noticing and having to worry about these things on other
people (in this case, me), but are actively sabotaging the effort to
make future mistakes less likely to happen by endlessly bitching and
refusing to admit that there is a problem.  It seems that it is too
difficult for you to admit that you were wrong and say "Yes there is
a problem, and among the three approaches you suggested, this is the
least intrusive one" or "Yes there is a problem, but I do not like
any of the approaches you suggested, so I propose this alternative
that is much less intrusive than any of them", and until that
happens I do not see a point in talking with you at all.

Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)

[Felipe Contreras]

On Wed, Jun 13, 2012 at 7:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Mon, Jun 11, 2012 at 4:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> You say I'm being irresponsible, I say you are being preoccupied by a
>>>> theoretical problem that will not occur, and would not cause any
>>>> problems if it does.
>>>
>>> See how the two implementations are different
>>
>> They are not.
>>
>> http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-completion.bash;h=13690eaecb4d8fafa67b79d33e804e6f8c64d742;hb=refs/heads/pu#l37
>>
>> http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-prompt.sh;h=29b1ec9eb1797e0f2c3c9f7067222432150ba85f;hb=refs/heads/pu#l54
>>
>> Where is the difference?
>
> Look at your patch that introduces the separate file af31a45
> (completion: split __git_ps1 into a separate script, 2012-05-22)
> instead.  The extra $GIT_DIR one in git-completion.sh bba88ea
> (completion: respect $GIT_DIR, 2012-05-09) is on another topic that
> is stalled and waiting for a reroll.
>
> And your message brings things back to my exact point.
>
> Unlike the other topic, the topic fc/git-prompt-script we have been
> discussing is almost ready except for this nit.  If we make it
> graduate to 'master' without doing anything about the other commit,
> we will have two different versions from day one.

Emphasis on *if*. Currently there's no difference on 'pu', which is
where all the current patches are.

If there's a difference, I wouldn't be doing that, you would.

Of course it's easy to fix; just rebase and copy the relevant version.
Anybody could do that, I could do that; just tell me on top of which
commit I should rebase the patches.

> And the worst part of the story is that you are not just placing the
> burden of noticing and having to worry about these things on other
> people (in this case, me), but are actively sabotaging the effort to
> make future mistakes less likely to happen by endlessly bitching and
> refusing to admit that there is a problem.

What is the problem?

Let's say you pick the patches as they are, and the newer version of
__gitdir() ends up in 1.7.11. What would happen?

Absolutely nothing.

> It seems that it is too
> difficult for you to admit that you were wrong and say "Yes there is
> a problem, and among the three approaches you suggested, this is the
> least intrusive one" or "Yes there is a problem, but I do not like
> any of the approaches you suggested, so I propose this alternative
> that is much less intrusive than any of them", and until that
> happens I do not see a point in talking with you at all.

There is no problem. There would be a problem if you cherry-pick the
patches out of 'pu' without synchronizing. This could be fixed in 1
minute; literally. Just tell me on top of which commit you want these
patches and you would have them immediately. No problem.

Then, if __gitdir() is updated later on (which is likely, but only
because Szeder is already working on it), there _would_ be a tiny,
insignificant problem.

No user would care about this "problem". Basically __gitdir() _might_
be a little slower; whoa, we'll get tons of users complaining in the
mailing list... NOT.

The "problem" you mention is hypothetical, and if you want to discuss
imaginary issues, you would have to discuss with an imaginary me that
cares, because I do not; I care about *real* issues, and dynamic
loading is a *real* issuers that is hitting *real* users right now,
and *real* distributions need workarounds. You are the one that
doesn't accept that.

There's no reason not to fix it; we can fix it _right now_, and there
would be no problems.

How about we make a bet; I bet no user would complain with something
like "'git foo --tab' completion stopped working", and the root of the
problem turns out to be a difference in __gitdir(); if somebody does
complain, you win; and my penalty would be to accept what you say
without discussion from that point on forward.

Cheers.

-- 
Felipe Contreras