Re: pull into dirty working tree

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 15, 2007, 01:07 UTC
Message-ID: <alpine.LFD.0.98.0706141801030.14121@woody.linux-foundation.org>
In-Reply-To: <46a038f90706141746n1cb69258r23ba676bbcf7c425@mail.gmail.com>

On Fri, 15 Jun 2007, Martin Langhoff wrote:

Show 18 quoted lines

> 
> 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