Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > > On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> So when "the user" is running "git fetch" on "mywork" branch that > >> happens to be forked from a local "master",... > >> we still need to have FETCH_HEAD updated to point at what we would > >> be merging if she did a "git pull". > > > > No, we don't need that. That is only needed by 'git pull', and in > > fact, it should be possible to reimplement 'git pull' so that it skips > > FETCH_HEAD when the remote is local. > > > > These are mere implementation details. > > You seem to be incapable to understand what backward compatibility > is. Really? Do you even remember the time when you changed out of nowhere all the 'git-foo' commands with 'git foo' and all hell broke loose? I remember some lonely voice of reason shouting for clear deprecation warnings: http://article.gmane.org/gmane.comp.version-control.git/94262 You seem to not understand what is the purpose of backwards compatibility, so let me explain. The most important aspect of a project is not the technical details, or the performance, but it's *usefulness* to the users; once a user has decided to use the software, he expects it to keep working for his use-cases in the foreseeable future. If something changes, and the user was relying on that, the user would get annoyed, but most likely would not stop using the software. If this happens time and again, he might. In order to keep as many users as possible, and ensure the project keeps growing with as strong user and developer base, the old behaviors should remain in place as much as possible. This keeps old users happy, and allows the project to achieve it's goal; to be useful to many people as possible. The safest way to never break old behaviors is to never make any change, but this is not ideal, no software is perfect, and the software needs to be constantly evolving, otherwise users will stop using the software as well. Moving forward while not breaking old behaviors is often times difficult, but necessary, to keep the old users, and the steady growth. Many projects make the mistake of simply disregarding old users, and breaking things constantly; and while doing so, they keep loosing users, and never grow as much as they could. *Nobody* is suggesting Git should do that. It's inevitable that there would come a point in time where there would be a conflict of interests, and in order to move forward it's necessary to break old behaviors. When such situation arises, it's important to exhaust any other options that might allow both the old and new behaviors (like a configuration option), or different implementations. But it might be, that there are no alternatives, and either the project doesn't move forward, or compatibility is retained. When analyzing such cases, it's important to understand the impact it has, and how many users it affects; if it's a small change to the user work-flow, but it affects too many users, it might be best to don't go forward with the change, or only do so after a major version release, with good communication to minimize the damage. And if it's a big change, but it affects a small user base, it still might make sense to go ahead with the change. Many times it won't be possible to know how many users would be affects, and in those cases it might make sense to release, with a hand in the breaks, so, if a lot of users complain, the change is reverted, and nobody, or very few, complain, leave it there. The Linux project does this; revert when somebody shouts. In conclusion; you shouldn't blindly dogmatically avoid changes for the sake of it; you have to understand *why* you _try_ to retain backwards compatibility, and when it best serves the project not to do so. If you try to be too overzealous in your backwards compatibility, you run the risk of not moving fast enough in order to not annoy a handful of users, or even imaginary ones who don't even exist. This is not good for the project. A few days ago somebody used a very appropriate name for it: compabeaten[1]. We want to keep our users happy, but we also want to keep our developers happy, and not being able to move forward with as many features as one would want to is very annoying. In the worst case scenario, we can revert a change that many users are complaining about, we are not GNOME. [1] http://article.gmane.org/gmane.comp.version-control.git/224510 -- 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