Re: pull into dirty working tree

Linus Torvalds [off-list ref] writes:

It might make it a bit easier for CVS people to get used to the git model: 
keep your dirty working tree, and do "git pull" to update it, and fix up 
any conflicts in the working tree. That's how CVS works - it's a bad 
model, but it's a model that may be worth supporting just to get people 
more easily into the _good_ model.

If a bad model _is_ supported, what incentive is there for these
people to move into the good model, I honestly wonder...

On Thu, 2007-06-14 at 00:49 -0700, Junio C Hamano wrote:

Linus Torvalds [off-list ref] writes:

quoted

It might make it a bit easier for CVS people to get used to the git model: 
keep your dirty working tree, and do "git pull" to update it, and fix up 
any conflicts in the working tree. That's how CVS works - it's a bad 
model, but it's a model that may be worth supporting just to get people 
more easily into the _good_ model.

If a bad model _is_ supported, what incentive is there for these
people to move into the good model, I honestly wonder...

Is it a bad model for the normal development process? Probably.

Would it solve the problem of "I want to keep my debug-statements that I
won't ever commit in the merged result"? ... yes

I think that's at least one valid usecase we should probably support.
One I'd also like to use ;-)

-- 
best regards

  Ray

Junio C Hamano wrote:

If a bad model _is_ supported, what incentive is there for these
people to move into the good model, I honestly wonder..

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

On Thu, 14 Jun 2007, Steven Grimm wrote:

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.

Personally, I think there is a point where it isn't worth trying to 
convert the world.  If people consider GIT bad and unwilling to use it 
because of X or Z then they probably better stay with CVS.  There is a 
limit to how backward bending should GIT do to accomodate everyone, 
especially if it is about compromize in its usage model just to make 
life easier for people who want to preserve their inferior work flow.

This being said, I don't claim to have a particular opinion about the 
issue discussed in this thread.  Simply that things should be decided on 
a technical basis and be justified with good arguments.  Saying that "I 
can't convince my co-workers to use GIT if it doesn't do X" is _not_ a 
good argument.


Nicolas