Please undo "Use git-merge instead of git-resolve in git-pull"

The new merge is totally unusable in real life.

I get 

	Need real merge but the working tree has local changes.

which is totally bogus. Sure, my working tree has local changes, but they have absolutely nothing to do with the stuff I merge. I almost _always_ keep local changes in my tree, and I worked hard to make sure that merging works well even despite that, and does the right thing.

Local changes are a problem ONLY IF THOSE LOCAL CHANGES INTERFERE WITH THE MERGE.

If the new merge policies do not allow that, then the new merge policies are incredibly broken. The old one did exactly the right thing for this case, and "git-read-tree -m" did

	Entry '%s' would be overwritten by merge. Cannot merge.

only if a file that actually needed merging was different.

			Linus

On Wed, 21 Sep 2005, Linus Torvalds wrote:

I just checked.

It _is_ incredibly broken. 

It will do 

	echo "Rewinding the tree to pristine..."
	git reset --hard $head

if any merge strategy every fails, so that check is needed for the new merger.

This makes merges totally unusable. It feels like the dark ages.

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

True, sorry, and reverted.

* Regardless of whatever else, we could detect when there is
  only one strategy applicable and bypass that check -- "reset
  --hard" should never happen in that case and 'git pull -s
  stupid' would regain the traditional behaviour and we should
  probably make this the default for 'git pull'.

* Otherwise, if the user wants it to try multiple strategies, we
  need to detect the local changes in the tree that _could_
  interfere with the merge more precisely.

  In order for that, we need to have a way to figure out the set
  of paths that _could_ potentially be involved in the merge.
  Once we have that set, we can just check if we have local
  changes on those paths, and the "restoring to the pre-merge
  state" currently done with "reset --hard" kludge could just
  restore those paths from the pre-merge HEAD.

  This is however harder than it sounds once we start allowing
  renaming merges.  If the ancestor had A/foo, you kept it and
  have an addition of A/bar as a local change, and the head that
  is being merged renames stuff in A/ to B/A/, it is more likely
  than not that you would want to have A/bar moved to B/A/bar in
  your merge result.  Once we go this route, the only thing it
  makes sense would be to make it responsibility for each merge
  strategy to preserve before starting its work and to restore
  after it has failed.

* I thought you do not multitask and wonder why you are merging
  while you still have local changes, but that does not justify
  this regression.

On Wed, 21 Sep 2005, Junio C Hamano wrote:

I've always multi-tasked, but when I started git I was ready to drop it. Then I came up with that wonderful "merge in the index" approach, and I could do it again, and I was _soo_ happy.

I often have local changes in my tree that I don't want to commit but that I'm testing out. Havign them interfere with merging other peoples work would mean that I'd have to have a totally separate tree for that, which I could do, but I'm much much happier not having to.

		Linus

From: Linus Torvalds <torvalds@osdl.org>
Date: Wed, 21 Sep 2005 15:03:39 -0700 (PDT)

You know, I personally was unaware that this was supported until now. I have been always reverting local debugging changes in order to merge other people's work in, then reapply the debugging changes afterwards.

I guess I won't have to do that any more. :-)

So as long as they don't interfere, you can keep local debugging changes out of GITs way for just about anything right? For example, as long as you don't "git-update-cache foo.c" those files in your local debugging hack, you can just "git commit" afterwards and only put in the changes you want. It won't myseriously find those modified files and what to do something with them right?

This goes with the idea that GIT only works with what you tell it about, I suppose.

On Wed, 21 Sep 2005, David S. Miller wrote:

Absolutely. 

It will happily merge a dirty tree, as long as none of the dirty files were modified.

And by "dirty" I mean "index matches HEAD, but contents do not match index".

It's very convenient. I usually have my local Makefile updated for the next version for a few days before actually committing it, and I tend to have any experimental patches that I sent out to people uncommitted in my tree too, just to remind me and to test them.

That's correct. Also, since this is how I work, I've tried to make sure that the tools I work with are "safe". For example, git-applymbox will happily apply patches to a dirty tree, because it uses "git-apply --index" that refuses to apply a patch to a file that is modified.

So it's perfectly safe to merge somebody elses _patch_ too - even with a tree with patches. But git-applymbox will refuse to apply patches on a tree where your index doesn't match the HEAD commit. So it's safe to have a _dirty_ tree, but if you've done an "update-cache" and have an index that doesn't match the parent any more, git-applymbox will refuse to run.

(Btw, that's something that I haven't checked whether I verified properly in git-read-tree.. I basically never have my index out of sync with my HEAD, but I should probably verify).

			Linus

On Wed, Sep 21, 2005 at 05:28:49PM -0700, David S. Miller wrote:

Why don't you commit the debugging changes, go back one step in the tree (reverting them through git in practice), merge other's people work then merge the debugging changes back in ? You never know when the debug changes will be useful again, so it's nice to have them in your private tree, and this method makes it reasonably automatic.

  OG.

On 9/22/05, David S. Miller <davem@davemloft.net> wrote:

Using Cogito, we've found a couple of cases where merging on a dirty tree messed things up. The local changes were lost after the merge.

I didn't bother to investigate further, because I didn't know whether it was supported "formally", or meant to be supported for long. Instead, I added a check in cg-merge that refuses to run on a dirty tree.

I guess I'll take that out, and try and debug any future sightings of the problem...

martin

On Thu, 22 Sep 2005, Martin Langhoff wrote:

Hmm. I merge a ton of stuff, and as mentioned, I probably have a dirty tree at least half the time. I don't think I've seen a problem yet.

But cogito at least _used_ to have some special logic for moving patches forward. git-resolve-script never had that - it only ever did the per-file three-way merge, and refused to touch dirty state except for the "everything stays the same" case.

Oh. I'm looking at the current cg-merge thing, and I think I see the problem: it's doing

	git-checkout-index -f -u -a

at the end. That's not only unnecessary, since it uses the "-u" flag to "git-read-tree", but it will force an overwrite of the working tree, and is thus actively incorrect.

Pasky?

		Linus

Dear diary, on Thu, Sep 22, 2005 at 04:10:08AM CEST, I got a letter where Linus Torvalds <torvalds@osdl.org> told me that...

Yes, but it is used only in case of fast-forward commits.

Oops. How brown-paper-bag-ish. Thanks for pointing this out, that was obviously horribly wrong, and it was indeed apparently happily trashing all the local changes. I've removed it, and added proper handling for cases when conflicts arise from merge over a tree with local changes - that was troublesome since cg-commit after resolving the conflicts would commit the local changes too. It won't anymore, and cg-status will mark those files appropriately. Woohoo.

I've also added a rather elaborate regression testing for cg-merge, so I hope that will help catch any future breakages. Hmm, I have to say that while I find writing those tests incredibly boring and annoying, it is pretty nice when I already have them. ;-)

This fix alone is worthy a release, so I'll do one tomorrow.