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

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

[Jon Loeliger]

So, like, the other day Linus Torvalds mumbled:
> Still with me?

Grasshopper still trying to keep up.

You and Petr have given me much to think about and try.
Give me a moment of tree-building to grasp the pebble...

jdl

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

[Linus Torvalds]

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

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

[Linus Torvalds]

On Wed, 21 Sep 2005, Linus Torvalds wrote:
> 
> If the new merge policies do not allow that, then the new merge policies 
> are incredibly broken.

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

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

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

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

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.

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

[Linus Torvalds]

On Wed, 21 Sep 2005, Junio C Hamano wrote:
> 
> * 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.

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

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

[David S. Miller]

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

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

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.

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

[Linus Torvalds]

On Wed, 21 Sep 2005, David S. Miller wrote:
> 
> 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. :-)

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.

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

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

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

[Olivier Galibert]

On Wed, Sep 21, 2005 at 05:28:49PM -0700, David S. Miller wrote:
> 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.

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.

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

[Martin Langhoff]

On 9/22/05, David S. Miller <davem@davemloft.net> wrote:
> From: Linus Torvalds <torvalds@osdl.org>
> > 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.
>
> 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. :-)

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

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

[Linus Torvalds]

On Thu, 22 Sep 2005, Martin Langhoff 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.

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

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

[Petr Baudis]

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...
> But cogito at least _used_ to have some special logic for moving patches
> forward.

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

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

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.