Those arguments are somewhat flawed. If we stick to "BK did it that way
and it was first", then following that logic we would also carry a lot
of CVS baggage because "CVS did it that way, and it was the most
successful of its kind". Still, we decided not to follow CVS nor BK in
many ways already.
As for the fraction of people complaining being a small fraction of
current GIT users: that is easily explainable by the fact that most
people who would have grown the complainers group are simply not GIT
users anymore since they were turned away by GIT's current user
interface issues. The only complainers remaining are those who see
value in the GIT technology but who would like to bring more
intuitiveness to the GIT interface instead of going for the alternative
technology. And those kind of people are always few.
The counter part of that is the possibility to fall for the "ivory tower
syndrome" where seasoned GIT users feel they are well satisfied with
what is currently available and unwilling to consider changes that would
reduce the barrier to entry for new users... simply because they are so
used to the way things work that they can't see why others have problems
with it.
Agreed. This is why the current discussion led to a proposition that
allows for "pull" to remain as is but to have a "get" version that would
be the alternate (saner) version.
Do you have comments on my proposed syntax (that would be implemented
with a git-get command) which I think doesn't really look like cogito?
Agreed.
I agree with you in general, except for the "pull" behavior which is
really really odd. Maybe it made sense in the BK context, maybe it is
fine _once_ you get used to it, but otherwise it is really overloaded.
Agreed again.
Nicolas
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html