More git pull problems

More git pull problems

[Russell King]

My automatic pull this morning produced the following messages, which
seem to indicate that something's up with git pull now.

git-pasky-0.4 (7bef49b5d53218ed3fa8bac291b5515c6479810c)

> MOTD:	
> MOTD:	Welcome to the Linux Kernel Archive.
> MOTD:	
> MOTD:	Due to U.S. Exports Regulations, all cryptographic software on this
> MOTD:	site is subject to the following legal notice:
> MOTD:	
> MOTD:	This site includes publicly available encryption source code
> MOTD:	which, together with object code resulting from the compiling of
> MOTD:	publicly available source code, may be exported from the United
> MOTD:	States under License Exception "TSU" pursuant to 15 C.F.R. Section
> MOTD:	740.13(e).
> MOTD:	
> MOTD:	This legal notice applies to cryptographic software only.
> MOTD:	Please see the Bureau of Industry and Security,
> MOTD:	http://www.bis.doc.gov/ for more information about current
> MOTD:	U.S. regulations.
> MOTD:	
> 
> 
> rsync: link_stat "/linux/kernel/people/torvalds/sparse.git/tags" (in pub) failed: No such file or directory (2)
> rsync error: some files could not be transferred (code 23) at main.c(723)
> 
> client: nothing to do: perhaps you need to specify some filenames or the --recursive option?
> New branch: 945a2562ee9e632bc6b3399fd49e028c39d19023
> Tracked branch, applying changes...
> Fast-forwarding 945a2562ee9e632bc6b3399fd49e028c39d19023 -> 945a2562ee9e632bc6b3399fd49e028c39d19023
> 	on top of 945a2562ee9e632bc6b3399fd49e028c39d19023...
> gitdiff.sh: trying to diff 67607f05a66e36b2f038c77cfb61350d2110f7e8 against itself

-- 
Russell King

Re: More git pull problems

[Petr Baudis]

Dear diary, on Tue, Apr 19, 2005 at 09:02:51AM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> My automatic pull this morning produced the following messages, which
> seem to indicate that something's up with git pull now.
> 
> git-pasky-0.4 (7bef49b5d53218ed3fa8bac291b5515c6479810c)
> 
> > New branch: 945a2562ee9e632bc6b3399fd49e028c39d19023
> > Tracked branch, applying changes...
> > Fast-forwarding 945a2562ee9e632bc6b3399fd49e028c39d19023 -> 945a2562ee9e632bc6b3399fd49e028c39d19023
> > 	on top of 945a2562ee9e632bc6b3399fd49e028c39d19023...
> > gitdiff.sh: trying to diff 67607f05a66e36b2f038c77cfb61350d2110f7e8 against itself

This means nothing more than you pulled your tracked branch for the
first time, but before you already had the latest copy; this wouldn't
have happened with subsequent pulls, and it was fixed some time ago - it
would be really nice if you could try the new pull and merge.

It is harmless anyway. It got confused and tried to do "zero-length fast
forward", which git diff complained about, but it couldn't do any harm
(I hope).

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

Re: More git pull problems

[Russell King]

On Tue, Apr 19, 2005 at 10:23:41AM +0200, Petr Baudis wrote:
> Dear diary, on Tue, Apr 19, 2005 at 09:02:51AM CEST, I got a letter
> where Russell King <rmk@arm.linux.org.uk> told me that...
> > My automatic pull this morning produced the following messages, which
> > seem to indicate that something's up with git pull now.
> > 
> > git-pasky-0.4 (7bef49b5d53218ed3fa8bac291b5515c6479810c)
> > 
> > > New branch: 945a2562ee9e632bc6b3399fd49e028c39d19023
> > > Tracked branch, applying changes...
> > > Fast-forwarding 945a2562ee9e632bc6b3399fd49e028c39d19023 -> 945a2562ee9e632bc6b3399fd49e028c39d19023
> > > 	on top of 945a2562ee9e632bc6b3399fd49e028c39d19023...
> > > gitdiff.sh: trying to diff 67607f05a66e36b2f038c77cfb61350d2110f7e8 against itself
> 
> This means nothing more than you pulled your tracked branch for the
> first time, but before you already had the latest copy; this wouldn't
> have happened with subsequent pulls, and it was fixed some time ago - it
> would be really nice if you could try the new pull and merge.

That's not the case.  This tree has been sitting around for about 6 days
now, and every day at 7am it gets a git pull.  One thing which did change
was the version of git installed, which now has this "fast forwarding"
feature in.

Maybe gitmerge.sh should check whether it needs to do anything before
attempting to do something?

-- 
Russell King

Re: More git pull problems

[Petr Baudis]

Dear diary, on Tue, Apr 19, 2005 at 10:31:13AM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> On Tue, Apr 19, 2005 at 10:23:41AM +0200, Petr Baudis wrote:
> > Dear diary, on Tue, Apr 19, 2005 at 09:02:51AM CEST, I got a letter
> > where Russell King <rmk@arm.linux.org.uk> told me that...
> > > My automatic pull this morning produced the following messages, which
> > > seem to indicate that something's up with git pull now.
> > > 
> > > git-pasky-0.4 (7bef49b5d53218ed3fa8bac291b5515c6479810c)
> > > 
> > > > New branch: 945a2562ee9e632bc6b3399fd49e028c39d19023
> > > > Tracked branch, applying changes...
> > > > Fast-forwarding 945a2562ee9e632bc6b3399fd49e028c39d19023 -> 945a2562ee9e632bc6b3399fd49e028c39d19023
> > > > 	on top of 945a2562ee9e632bc6b3399fd49e028c39d19023...
> > > > gitdiff.sh: trying to diff 67607f05a66e36b2f038c77cfb61350d2110f7e8 against itself
> > 
> > This means nothing more than you pulled your tracked branch for the
> > first time, but before you already had the latest copy; this wouldn't
> > have happened with subsequent pulls, and it was fixed some time ago - it
> > would be really nice if you could try the new pull and merge.
> 
> That's not the case.  This tree has been sitting around for about 6 days
> now, and every day at 7am it gets a git pull.  One thing which did change
> was the version of git installed, which now has this "fast forwarding"
> feature in.

Yes, the way to store this information changed. But by now, it [the
$orig_head which caused the havoc] is completely informational anyway
and git pull is completely rewritten not to need it for the merging
itself; just for the fancy stuff like showing diff-tree.

If I go for the pull/update change (or even if I don't), I might drop
this information anyway; I basically needed it only before merge-base
was around anyway, so that I would know what tree to use as the merge
base.

> Maybe gitmerge.sh should check whether it needs to do anything before
> attempting to do something?

That's the case with the latest git-pasky night version.

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