RE: git pull on ia64 linux tree

The merge is right ... but "cg-update" leaves files that have been deleted lying around in the checked out tree.

-Tony

On Wed, 27 Apr 2005, Luck, Tony wrote:

Yes. I _think_ the right thing to do ends up being something like the update script doing

	diff-tree -r $orig $final | grep '^-'

at the end to get the list of deleted files, and just doing 'rm' on the result.

One problem with this is that "grep" always thinks lines end in '\n', and what we'd really want (from a scriptability angle) is

	diff-tree -z -r $orig $final | grep -0 '^-'

but I don't think you can tell grep to think that lines are zero-terminated instead of terminated with \n'. But I don't see how to do that with grep.

Another similar alternative is to use "show-files --others" before and after the merge and seeing what files got added to the list of "files we don't track", but that just sounds horribly hacky.

Anyway, there are clearly at least two ways of doing this, and we'll just have to have people work on the scripts to do it right..

		Linus

Dear diary, on Thu, Apr 28, 2005 at 12:35:07AM CEST, I got a letter where Linus Torvalds <torvalds@osdl.org> told me that...

Actually, grep has -z parameter. ;-)

Fixed and pushed out.

On Thu, 28 Apr 2005, Petr Baudis wrote:

Ahh. It's not even mentioned in the grep man-page (which mentions -Z, but that's for grep _output_, not input).

		Linus

On Thu, 28 Apr 2005, Petr Baudis wrote:

It looks like you only did the fix for the pure "just update to the version at the other end" case.

So if you actually end up doing a merge, it still leaves all the old files (that the merge may have removed from the tree) around. Or did I miss something?

		Linus

Dear diary, on Thu, Apr 28, 2005 at 01:36:19AM CEST, I got a letter where Linus Torvalds <torvalds@osdl.org> told me that...

Hmm, doesn't the three-way read-tree -m take care of that? Then it should hit

	#
	# deleted in one and unchanged in the other
	#
	"$1.$1" | "$1$1.")
		#echo "Removing $4"
		rm -f -- "$4"; update-cache --remove -- "$4"
		exit 0
		;;

in cg-Xmergefile.

On Thu, 28 Apr 2005, Petr Baudis wrote:

Yes, you're right, I didn't think about the fact that the helper script actually does the checkout for the clashing files it merges.

(Which is not really nice, because it means that some files get updated and others don't, depending on how they were merged, but whatever..)

			Linus

Dear diary, on Thu, Apr 28, 2005 at 02:21:19AM CEST, I got a letter where Linus Torvalds <torvalds@osdl.org> told me that...

We always do checkout-cache -f -a after we do merge-cache, so it should end up in a consistent state.

On Thu, 28 Apr 2005, Petr Baudis wrote:

I agree that for the common case it doesn't really matter, since we'll always update the working directory regardless.

It was more of a conceptual complaint. We do everything else purely in the index, so it's a bit confusing that in that intermediate stage _some_ files end up being up-to-date, and others end up not.

		Linus

Dear diary, on Thu, Apr 28, 2005 at 03:08:29AM CEST, I got a letter where Linus Torvalds <torvalds@osdl.org> told me that...

This actually came all the way from git-merge-one-file-script.

I don't think the intermediate stage matters at all, actually; from the user's point of view it is nearly instantenous, and the tree keeps changing during the merge anyway, when you are trying to resolve non-exact merges by the merge utility. From the user's point of view, the act of merging is atomic and you always end up with something consistent, unless cg-merge is killed. But in that case it's all messed up anyway and you'll better just cg-cancel and try again.

Linus Torvalds wrote:

Don't you think it's much easier to reject filenames with control chars? Forget all this -z/-0 stuff. It only complicates life and supporting filenames with embedded newlines is useless in practice.

--- x/update-cache.c Thu Apr 21 19:58:47 2005 +++ y/update-cache.c Thu Apr 28 02:55:27 2005