Re: git pull on ia64 linux tree

Re: git pull on ia64 linux tree

[Linus Torvalds]

On Fri, 22 Apr 2005 tony.luck@intel.com wrote:
> 
> "git log" seems to have problems interpreting the dates ... looking at the
> commit entries, the time is right ... but it appears that git log applies
> the timezone correction twice, so the changes I just applied at 14:46 PDT
> look like I made them at quarter to five tomorrow morning (+14 hours from
> when I did).

Looks like you are right.

The seconds are already in UTC format, so I think "git log" is wrong to 
pass the UTC seconds in to "date", and then tell date that it was done in 
the original timezone.

I think it would be nice to use the TZ data to show the thing in the 
timezone of the committer, though. Dunno how to do that, maybe something 
like

	TZ=$tz date -d "1970-01-01 + $sec sec"

or whatever. Sadly, it looks like "date" doesn't understand timezone 
syntax like that - looks like TZ has to be in the long machine-unreadable 
format like "US/Pacific" etc. Stupid (either TZ or me - maybe I just 
don't know what the right format is).

		Linus

Re: git pull on ia64 linux tree

[Sanjoy Mahajan]

> I think it would be nice to use the TZ data to show the thing in the
> timezone of the committer, though. Dunno how to do that, maybe
> something like
>	TZ=$tz date -d "1970-01-01 + $sec sec"
> Sadly, it looks like "date" doesn't understand timezone syntax like
> that

Try:

negzone=`echo $tz | tr '[-]+' '+-'`
date -u -R -d "1970-01-01 $negzone + $sec sec" | sed "s/+0000/$tz/"

Or as a script:

#!/bin/bash
# usage: show-date.sh <utcseconds> <zone>
negzone=`echo $2 | tr '[-]+' '+-'`
date -u -R -d "1970-01-01 $negzone + $1 sec" | sed "s/+0000/$2/"

A simple test:

$ show-date.sh 10 +0200
Thu, 01 Jan 1970 02:00:10 +0200

Negating the timezone is an ugly workaround for date not understanding
a sensible TZ format.  I almost always use -u with date, otherwise I
get confused about what timezone it is using to interpret and to print
the date.

-Sanjoy

RE: git pull on ia64 linux tree

[Luck, Tony]

>On Wed, 27 Apr 2005 tony.luck@intel.com wrote:
>> 
>> 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

RE: git pull on ia64 linux tree

[Linus Torvalds]

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

Re: git pull on ia64 linux tree

[Petr Baudis]

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

Re: git pull on ia64 linux tree

[Linus Torvalds]

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

Re: git pull on ia64 linux tree

[Linus Torvalds]

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

Re: git pull on ia64 linux tree

[Petr Baudis]

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

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

Re: git pull on ia64 linux tree

[Linus Torvalds]

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

Re: git pull on ia64 linux tree

[Petr Baudis]

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

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

Re: git pull on ia64 linux tree

[Linus Torvalds]

On Thu, 28 Apr 2005, Petr Baudis wrote:
>
> > (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

Re: git pull on ia64 linux tree

[Petr Baudis]

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...
> 
> 
> On Thu, 28 Apr 2005, Petr Baudis wrote:
> >
> > > (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

Re: git pull on ia64 linux tree

[Edgar Toernig]

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.