Kyle Neath <kneath@xxxxxxxxx> writes: >> * jk/http-auth-keyring (2011-08-03) 13 commits >> ... >> >> Looked mostly reasonable except for the limitation that it is not clear >> how to deal with a site at which a user needs to use different passwords >> for different repositories. Will keep it in "next" at least for one cycle, >> until we start hearing real-world success reports on the list. >> >> Not urgent; will not be in 1.7.7. > > This is very disheartening to hear. Of all the minor changes, bugs, and > potential features, I believe that http credential caching is the absolute > most important thing that git core can do to promote adoption. I've believed > this for more than a year now and I'm incredibly disappointed that it's being > shelved for yet another release. You are misreading the message utterly wrong that it is not even funny. If this were a new, insignificant, and obscure feature in a piece of software with mere 20k users, it may be OK to release a new version with the feature in an uncooked shape. The feature may turn out to work only in a very limited scope but not general enough to accomodate other needs you did not anticipate, and your next version may have to fix it in a backward incompatible way, forcing existing users to unlearn what the initial uncooked design and implementation gave them, but by definition such an insignificant and obscure new feature in a system with a small userbase wouldn't have been used by too many people by the time you have to fix it, and the extent of the damage is limited. Git is not that piece of software with only 20k users, and a lot more importantly, credential caching API is not a feature in an insignificant and obscure corner of the user experience. We have to have at least a warm fuzzy feeling that the API is right from the start so the plug-ins people write for our initial version and the data its users will accumulate with it will not go to waste by hastily releasing a version with an uncooked design and implementation. "Not urgent" is not "Not important". Quite the contrary, it is important enough that we cannot afford to be hasty. See http://thread.gmane.org/gmane.comp.version-control.git/180245 for an example of how a discussion can be done to help us get closer to the warm fuzzy feeling of getting the API right in a more mature manner. Don't feel too bad if you become ashamed of the rant you wrote contrasting with that exchange. It is a sign that you are learning. > Then again, perhaps the fact that we spent development time hacking around > git's limitation is a data point in itself. Git GUI developers are spending > development time to fill a hole in git core. Welcome to open source. Do not expect others to scratch every itch of your niche. Think of it as an opportunity granted to you to make a difference, not as a roadblock somebody else threw at you because they hate you. Be thankful, not whiny. Be good. Have fun. -- 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