On Mon, Jan 30, 2012 at 1:19 PM, Frans Klaver <fransklaver@xxxxxxxxx> wrote: > On Mon, Jan 30, 2012 at 11:51 AM, Felipe Contreras > <felipe.contreras@xxxxxxxxx> wrote: >> On Mon, Jan 30, 2012 at 6:27 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: >>> >>>> OK, maybe some people use it, but most likely they are using an old >>>> version of git, and thus an old version of the completion script. >>> >>> Please adjust your attitude about backward compatibility to match the >>> standard used for other parts of Git. >> >> What attitude? > > This attitude: > >> I am simply stating a fact. How much percentage of >> people do you think still have .git/remotes around? How many people do >> you think have clones more than 3 years old? And how many of these >> people would complain if remotes were not properly completed for these >> repos? >> >> I doubt anybody would have complained, but I guess we would never >> know, because I already proposed a solution that would work for them >> and only uses a *single* line of code, unlike the current 40 ones. >> >> I don't see what is the problem with the attitude of sending a patch >> to remove code that most likely nobody cares about (neither you or I >> have numbers on this), and then finding an alternative when people do >> care about it. > > I don't think Junio actually meant an "attitude", but just your angle > of approach (== attitude) on backwards compatibility. We are not talking about backwards compatibility; we are talking about compatibility of remotes completion of the bash completion script of repositories more than 3 years old with remotes that haven't been migrated. This barely resembles the git-foo -> 'git foo', which truly broke backwards compatibility, and at the time I proposed many different approaches to deal with these type of problems, which seem to be followed now (although probably not because of my recommendations). But this has nothing to do with _attitude_; I am merely stating fact. I have never expressed any opinion or attitude with respect to how backwards compatibility should be handled in this thread, have I? > Maybe numbers for this could be generated from the next git user > survey. If numbers justify this change, maybe this or something like > it could be scheduled for a major release of git. Maybe, but I doubt this issue hardly deserves much discussion. Nobody is proposing to break backwards compatibility--as you can see, I already proposed a simple solution that should work. And FTR, when I wrote 'We don't need to check for GIT_DIR/remotes, right? This was removed long time ago." I clearly wasn't sure if .git/remotes was still used or not, after Jonathan Nieder replied, I checked the source code of remotes.c, and I found that it was still supported, so I wrote the proposed alternative. -- 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