On Wed, Jun 13, 2012 at 7:19 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > >> On Mon, Jun 11, 2012 at 4:54 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Felipe Contreras <felipe.contreras@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html