Thread (22 messages) flat view 22 messages, 9 authors, 2016-06-15

Re: pull into dirty working tree

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:17


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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help