* Possibly-spurious 'not uptodate. Cannot merge'
@ 2008-12-14 16:47 Nix
2008-12-14 19:33 ` Junio C Hamano
2008-12-15 1:03 ` Sitaram Chamarty
0 siblings, 2 replies; 5+ messages in thread
From: Nix @ 2008-12-14 16:47 UTC (permalink / raw)
To: git
Recently (as of perhaps git 1.5.4?), whenever I update my l-k tree I get
this:
loki 504 /usr/packages/linux/linux% git pull
remote: Counting objects: 638, done.
remote: Compressing objects: 100% (86/86), done.
remote: Total 517 (delta 430), reused 516 (delta 430)
Receiving objects: 100% (517/517), 74.91 KiB, done.
Resolving deltas: 100% (430/430), completed with 120 local objects.
From git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.27.y
078bb16..5defaf8 master -> 2.6.27-stable/master
* [new tag] v2.6.27.9 -> v2.6.27.9
error: Entry 'Makefile' not uptodate. Cannot merge.
fatal: merging of trees 34f70ec1fadcaad7de6979491e2dea9da735e6f9 and ded3f44559ce050e0ef014ebce093c5d9295ede8 failed
Merge with strategy recursive failed.
In this situation, 'git diff' reports no changes at all, but 'git reset
--hard' gets the tree back into a state where merging succeeds, as does
'git update-index --refresh'.
I suspect the 'problem' is that I've hardlinked a bunch of build trees
to this tree in the interim via 'cp -al', then applied patches to each
of those trees with quilt, then deleted all those trees prior to the git
pull. This doesn't change the original files at all, but *does* update
their link count: is git getting annoyed by the corresponding change in
ctime? (If so, why did it start happening only fairly recently?)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Possibly-spurious 'not uptodate. Cannot merge'
2008-12-14 16:47 Possibly-spurious 'not uptodate. Cannot merge' Nix
@ 2008-12-14 19:33 ` Junio C Hamano
2008-12-14 23:15 ` Nix
2008-12-15 1:03 ` Sitaram Chamarty
1 sibling, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2008-12-14 19:33 UTC (permalink / raw)
To: Nix; +Cc: git
Nix <nix@esperi.org.uk> writes:
> Recently (as of perhaps git 1.5.4?), whenever I update my l-k tree I get
> this:
> ...
> I suspect the 'problem' is that I've hardlinked a bunch of build trees
> to this tree in the interim via 'cp -al', then applied patches to each
> of those trees with quilt, then deleted all those trees prior to the git
> pull. This doesn't change the original files at all, but *does* update
> their link count: is git getting annoyed by the corresponding change in
> ctime? (If so, why did it start happening only fairly recently?)
In git timescale 1.5.4 is not recent at all ;-)
Ancient git, whose "git merge" was a scripted command, refreshed the index
before starting, but it lost that when the command was rewritten in C soon
after v1.5.6 by 1c7b76b (Build in merge, 2008-07-07), and nobody noticed
it until 76c3fb1 (Merge branch 'mv/merge-refresh', 2008-10-09). In other
words, the tip of 'master' (and upcoming 1.6.1) already has the fix.
The fix should have been cherry-picked to 'maint' to be part of 1.6.0.X
series, but it apparently was forgotten. Fault of mine and Shawn ;-)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Possibly-spurious 'not uptodate. Cannot merge'
2008-12-14 19:33 ` Junio C Hamano
@ 2008-12-14 23:15 ` Nix
0 siblings, 0 replies; 5+ messages in thread
From: Nix @ 2008-12-14 23:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On 14 Dec 2008, Junio C. Hamano said:
> Ancient git, whose "git merge" was a scripted command, refreshed the index
> before starting, but it lost that when the command was rewritten in C soon
> after v1.5.6 by 1c7b76b (Build in merge, 2008-07-07), and nobody noticed
> it until 76c3fb1 (Merge branch 'mv/merge-refresh', 2008-10-09). In other
> words, the tip of 'master' (and upcoming 1.6.1) already has the fix.
Excellent! I do love this precognitive bugfixing thing.
(It's not as if the update-index workaround is terribly onerous, but
it's annoying and not something a git newbie might think of.)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Possibly-spurious 'not uptodate. Cannot merge'
2008-12-14 16:47 Possibly-spurious 'not uptodate. Cannot merge' Nix
2008-12-14 19:33 ` Junio C Hamano
@ 2008-12-15 1:03 ` Sitaram Chamarty
2008-12-15 1:27 ` Junio C Hamano
1 sibling, 1 reply; 5+ messages in thread
From: Sitaram Chamarty @ 2008-12-15 1:03 UTC (permalink / raw)
To: git
On 2008-12-14, Nix <nix@esperi.org.uk> wrote:
> In this situation, 'git diff' reports no changes at all, but 'git reset
> --hard' gets the tree back into a state where merging succeeds, as does
> 'git update-index --refresh'.
Wasn't there some situation in which merely running 'git
status' would have a similar effect? I seem to recall
reading that somewhere but now I can't find any mention of
it in 'git help status'.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Possibly-spurious 'not uptodate. Cannot merge'
2008-12-15 1:03 ` Sitaram Chamarty
@ 2008-12-15 1:27 ` Junio C Hamano
0 siblings, 0 replies; 5+ messages in thread
From: Junio C Hamano @ 2008-12-15 1:27 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
Sitaram Chamarty <sitaramc@gmail.com> writes:
> On 2008-12-14, Nix <nix@esperi.org.uk> wrote:
>> In this situation, 'git diff' reports no changes at all, but 'git reset
>> --hard' gets the tree back into a state where merging succeeds, as does
>> 'git update-index --refresh'.
>
> Wasn't there some situation in which merely running 'git
> status' would have a similar effect? I seem to recall
> reading that somewhere but now I can't find any mention of
> it in 'git help status'.
It would, but this is a pure bug in the re-implementation of git-merge
that was introduced soon after v1.5.6. The users shouldn't be required to
run refresh to work this around.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-12-15 1:29 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-12-14 16:47 Possibly-spurious 'not uptodate. Cannot merge' Nix
2008-12-14 19:33 ` Junio C Hamano
2008-12-14 23:15 ` Nix
2008-12-15 1:03 ` Sitaram Chamarty
2008-12-15 1:27 ` Junio C Hamano
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.