threads / discuss / 30696

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

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

## tl;dr

12 messages between Jun 4, 2012 and Jun 13, 2012.

replies: 11people: 3as markdown or json

Junio C Hamano· Jun 4, 2012, 00:23 UTC · lore

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.
Felipe Contreras· Jun 6, 2012, 12:22 UTC · re: Junio C Hamano · lore

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

On Mon, Jun 4, 2012 at 2:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> * 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
Junio C Hamano· Jun 6, 2012, 17:58 UTC · re: Felipe Contreras · lore

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

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 6 quoted lines
>> 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.

Felipe Contreras· Jun 6, 2012, 18:17 UTC · re: Junio C Hamano · lore

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

On Wed, Jun 6, 2012 at 7:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> 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*.

Show 6 quoted lines
>> 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
Junio C Hamano· Jun 10, 2012, 07:26 UTC · re: Felipe Contreras · lore

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

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 5 quoted lines
>> 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"
Felipe Contreras· Jun 10, 2012, 15:09 UTC · re: Junio C Hamano · lore

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

On Sun, Jun 10, 2012 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 11 quoted lines
> 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:

Show 10 quoted lines
>> 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
Junio C Hamano· Jun 11, 2012, 14:54 UTC · re: Felipe Contreras · lore

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

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.
Felipe Contreras· Jun 13, 2012, 14:55 UTC · re: Junio C Hamano · lore

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

On Mon, Jun 11, 2012 at 4:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 7 quoted lines
> 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?
Show 5 quoted lines
> 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
Junio C Hamano· Jun 13, 2012, 17:19 UTC · re: Felipe Contreras · lore

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

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 16 quoted lines
> 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.

Felipe Contreras· Jun 13, 2012, 18:04 UTC · re: Junio C Hamano · lore

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

On Wed, Jun 13, 2012 at 7:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 31 quoted lines
> 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.

Show 5 quoted lines
> 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.
Show 7 quoted lines
> 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
René Scharfe· Jun 10, 2012, 17:39 UTC · re: Felipe Contreras · lore

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

Am 06.06.2012 20:17, schrieb Felipe Contreras:
Show 9 quoted lines
> 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".
Show 5 quoted lines
>> 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é
Felipe Contreras· Jun 11, 2012, 10:27 UTC · re: René Scharfe · lore

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

On Sun, Jun 10, 2012 at 7:39 PM, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:

Show 30 quoted lines
> 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

← back to recent threads