On Fri, 15 Jun 2007, Martin Langhoff wrote: > > Right now git merges/fforwards well with dirty state as long as the > same path is not touched on both sides. But there are several > situations where it could do better allowing those ops to go through > if they don't result in any conflict. > > - For Fast Forwards on a dirty path - attempt the merge on a temp file > and refuse to complete the FF there is a conflict. > - For merges on a dirty path, attempt the merge. If both the tree > merge _and_ the subsequent with the dirty state are clean, then there > is no problem updating the checkout. > > In both cases, we can still go ahead in the case of a conflict against > the local state and give the user the normal conflict markers (or > separate files of the patch doesn't apply at all. The situation where > I think it is valid to refuse to go ahead is in the "merge on dirty > path" where the tree merge results in a conflict. Too many states to > keep track of -- not for git but for the user. I agree, but there is actually a practical implementation problem with doing that: - currently, we can decide *ahead* of time (by just looking at the index, whether the index entry is clean, and the two branches) whether the merge can go ahead or not. - so we actually do two passes: the first pass checks that we can do what we want to do cleanly, and the second pass actually starts changing the working tree! Now, if you actually start doing the *merge* thing, the biggest practical problem ends up being that the natural place where you find out that "oops, we can't get a clean result" is in phase 2 - *after* you have potentially already done earlier merges in the working directory! And that's unacceptable. A "git pull" needs to either fail early without making any modifications at all (telling people that the tree is dirty and cannot be merged), or it needs to complete but leave conflict markers. But yeah, if you can check in stage 1 (_without_ changing the working tree) whether the merge will work, then everything is fine. 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
