RE: git pull on ia64 linux tree

On Wed, 27 Apr 2005 tony.luck@intel.com wrote:

quoted

please pull from:

	

rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git

Merged and pushed out. You should probably check the end 
result, but it all looks good from here.

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:

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

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 [off-list ref] told me that...

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.

Actually, grep has -z parameter. ;-)

Fixed and pushed out.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

On Thu, 28 Apr 2005, Petr Baudis wrote:

Actually, grep has -z parameter. ;-)

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:

Fixed and pushed out.

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 [off-list ref] told me that...

On Thu, 28 Apr 2005, Petr Baudis wrote:

quoted

Fixed and pushed out.

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?

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

On Thu, 28 Apr 2005, Petr Baudis wrote:

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

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 [off-list ref] told me that...

On Thu, 28 Apr 2005, Petr Baudis wrote:

quoted

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

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

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

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

On Thu, 28 Apr 2005, Petr Baudis wrote:

quoted

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

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

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

Linus Torvalds wrote:

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

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

@@ -227,7 +227,8 @@
  * are hidden, for chist sake.
  *
  * Also, we don't want double slashes or slashes at the
- * end that can make pathnames ambiguous.
+ * end that can make pathnames ambiguous nor any control
+ * chars.
  */
 static int verify_path(char *path)
 {

@@ -237,6 +238,8 @@
 	for (;;) {
 		if (!c)
 			return 1;
+		if ((unsigned char)c < 32)
+			return 0;
 		if (c == '/') {
 inside:
 		c = *path++;

Ciao, ET.

Dear diary, on Thu, Apr 28, 2005 at 03:08:29AM CEST, I got a letter
where Linus Torvalds [off-list ref] told me that...

On Thu, 28 Apr 2005, Petr Baudis wrote:

quoted

quoted

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

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

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.

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor