Re: More git pull problems
- From
Petr Baudis <pasky@ucw.cz>
- Date
- Apr 19, 2005, 08:35 UTC
- Message-ID
- <20050419083551.GD2393@pasky.ji.cz>
- In-Reply-To
- <20050419093113.D13488@flint.arm.linux.org.uk>
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...
Show 23 quoted lines
> 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