Re: git pull opinion

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Nov 10, 2007, 00:36 UTC
Message-ID: <alpine.LFD.0.999.0711091633380.15101@woody.linux-foundation.org>
In-Reply-To: <3abd05a90711071325y397434efq7d4e50cb7a1cf07e@mail.gmail.com>

On Wed, 7 Nov 2007, Aghiles wrote:

Show 18 quoted lines

> > [...]
> > Now, I do think that we could relax the rule so that "files that are
> > modified must be clean in the working tree" could instead become "files
> > that actually don't merge _trivially_ must be clean in the working tree".
> > But basically, if it's not a trivial merge, then since it's done in the
> > working tree, the working tree has to be clean (or the merge would
> > overwrite it).
> >[...]
> 
> I really think this is a good idea. It seems to me that the first "bad"
> surprise a svn/cvs/bk user will have is the result of a "git pull" command
> on a dirty tree. With the proposed change, and if I understand correctly:
>   - users that are used to commit often and fetch into clean trees
> will never be bothered by this change.
>   - users that are used to "update" often are expecting to resolve
> conflicts in their working copy anyway.
> 
> In both cases git does not get in your way and everyone is happy.

Well, there will still be cases where people won't be happy.

That said, all fast-forward cases (which is, I guess, a fairly common way of operating for anybody who has ever just uses anoncvs to track others) would be handled by the "three-way-merge dirty data for trivial merges".

So even if it would only handle that special case (and it handles a *lot* of other cases too!) it probably would be useful to some people.

That said, I still don't think I have the energy to actually try to do it. I do suspect it's not that hard, and I outlined where it would go, but it's really quite core and important code... IOW, this needs *lots* of deep thought and care.

			Linus