Presumably it's a good model because it's easier, more productive, more
predictable, more reliable, or some combination of those things; that's
the incentive. If it's none of those things for a given developer, then
maybe it's not in fact a better model for them.
Of course, even if it is better for them, some people will never move --
but those are the people who won't willingly move to git anyway unless
the bad model is supported. There are enough of them out there that
people who *do* want to use the good model, but have to work in an
environment where they're outnumbered by those other folks, find they
can't sell the organization on git because it forces a change in work
style on people who aren't interested in changing their work styles.
(Not a purely hypothetical statement, sadly.)
You can view this in terms of being a leg up for people who *do* want to
use git, but are in environments where they are unable to convince or
force everyone else to adopt git-style workflows. I think it's telling
that almost all the discussions about this kind of feature are of the
form, "I'm trying to convince my team to use git, and they find it no
good because of X." It's the person trying to sell git to the group,
presumably so they can use it themselves without having to go through a
CVS or Subversion or p4 gateway, that this stuff really helps. That the
rest of the team will benefit down the road too is nice but probably not
the immediate selfish personal goal of the people who are asking for
this kind of feature.
-Steve
-
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
