On 6/15/07, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
Well, the thing is, I actually pull into dirty trees all the time. So I can really see the point of wanting to have some dirty state (you're not ready to commit it yet), but still wanting to update your tree to some newer state..
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. cheers, martin - 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
