On Wed, 7 Nov 2007, Aghiles wrote: > > [...] > > 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 - 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
