{"thread":{"id":"15663","subject":"having to pull twice","startedAt":"2008-09-25T00:58:20Z","lastAt":"2008-10-03T13:02:31Z","messageCount":11,"participants":["Michael P. Soulier","Shawn O. Pearce","Thomas Rast","Alex Riesen","Miklos Vajna"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"91551","messageId":"fb6605670809241758r186eef51sc6ed6d334a64495d@mail.gmail.com","threadId":"15663","inReplyTo":null,"subject":"having to pull twice","fromName":"Michael P. Soulier","fromEmail":"msoulier@digitaltorque.ca","sentAt":"2008-09-25T00:58:20Z","receivedAt":"2008-09-25T00:58:20Z","isPatch":false,"sender":{"key":"msoulier@digitaltorque.ca","avatar":"https://gravatar.com/avatar/f32ca317cc5c1787a51e1f2388f33303ce743b458fd67669c3d14a21fd5dabc7?d=mp&s=160"},"body":"I'm finding this happening from time to time.\n\nsoulierm@espresso:~/work/mitel-msl-tug$ git pull\nremote: Counting objects: 97, done.\nremote: Compressing objects: 100% (54/54), done.\nremote: Total 65 (delta 34), reused 0 (delta 0)\nUnpacking objects: 100% (65/65), done.\nFrom pa:git/mitel-msl-tug\n   92437d6..9c784c8  master     -> origin/master\nUpdating 92437d6..9c784c8\nerror: Entry 'mitel-msl-tug.spec' not uptodate. Cannot merge.\nsoulierm@espresso:~/work/mitel-msl-tug$ git status\n# On branch master\n# Your branch is behind 'origin/master' by 4 commits, and can be fast-forwarded.\n#\nnothing to commit (working directory clean)\nsoulierm@espresso:~/work/mitel-msl-tug$ git pull\nUpdating 92437d6..9c784c8\nFast forward\n mitel-msl-tug.spec                                 |    7 +-\n .../etc/e-smith/pgsql/init/tugdb.sh/20auth         |    4 +-\n .../etc/e-smith/pgsql/init/tugdb.sh/50apps         |   37 ---\n .../etc/e-smith/pgsql/init/tugdb.sh/90loaddata     |    8 +-\n .../etc/e-smith/pgsql/init/tugdb.sh/95schema       |    2 +-\n root/etc/e-smith/templates/etc/tug/tug.ini/00setup |    2 +\n .../e-smith/templates/etc/tug/tug.ini/10teleworker |   37 +++-\n .../templates/etc/tug/tug.ini/11teleworker_fixed   |    1 -\n .../e-smith/web/django/teleworker/scrc/views.py    |   11 +-\n root/usr/lib/scrc/migrate.pl                       |  322 --------------------\n root/usr/lib/tug/migrate/30_add_scrc               |    2 +-\n root/usr/lib/tug/migrate/31_add_scrc_connections   |   22 ++-\n 12 files changed, 77 insertions(+), 378 deletions(-)\n delete mode 100755 root/usr/lib/scrc/migrate.pl\nsoulierm@espresso:~/work/mitel-msl-tug$ git --version\ngit version 1.6.0\n\nWhen I pulled the first time, I was told that one of the files was\n not up-to-date, but status did not note any modified files. The\nsecond pull then worked as expected.\n\nThat directory is mounted via NFS, and I'm curious as to\nwhether some kind of time skew could be the problem. But\nthen, if it is, why did it go away after the first pull?\n\nThanks,\nMike\n-- \nMichael P. Soulier <msoulier@digitaltorque.ca>\n\"Any intelligent fool can make things bigger and more complex... It takes a\ntouch of genius - and a lot of courage to move in the opposite direction.\"\n--Albert Einstein\n"},{"id":"91552","messageId":"20080925010150.GI3669@spearce.org","threadId":"15663","inReplyTo":"fb6605670809241758r186eef51sc6ed6d334a64495d@mail.gmail.com","subject":"Re: having to pull twice","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-09-25T01:01:50Z","receivedAt":"2008-09-25T01:01:50Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Michael P. Soulier\" <msoulier@digitaltorque.ca> wrote:\n> I'm finding this happening from time to time.\n> \n> soulierm@espresso:~/work/mitel-msl-tug$ git pull\n...\n> error: Entry 'mitel-msl-tug.spec' not uptodate. Cannot merge.\n> soulierm@espresso:~/work/mitel-msl-tug$ git status\n> # On branch master\n> # Your branch is behind 'origin/master' by 4 commits, and can be fast-forwarded.\n> #\n> nothing to commit (working directory clean)\n...\n> That directory is mounted via NFS, and I'm curious as to\n> whether some kind of time skew could be the problem. But\n> then, if it is, why did it go away after the first pull?\n\nTime or dev/ino skew in the index file vs. what we read from stat.\n\nRunning git-status rematched the index file to the working directory,\nand during that rematch it noticed the file wasn't actually modified.\n\nSo it prints \"nothing to commit\" and the next pull works fine,\nnow that the stat data in the index matches the working directory.\n\n-- \nShawn.\n"},{"id":"91559","messageId":"200809250905.09646.trast@student.ethz.ch","threadId":"15663","inReplyTo":"20080925010150.GI3669@spearce.org","subject":"Re: having to pull twice","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2008-09-25T07:05:02Z","receivedAt":"2008-09-25T07:05:02Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Shawn O. Pearce wrote:\n> \"Michael P. Soulier\" <msoulier@digitaltorque.ca> wrote:\n> > I'm finding this happening from time to time.\n> > \n> > soulierm@espresso:~/work/mitel-msl-tug$ git pull\n> ...\n> > error: Entry 'mitel-msl-tug.spec' not uptodate. Cannot merge.\n[fixed by 'git status's index refresh]\n> \n> Time or dev/ino skew in the index file vs. what we read from stat.\n> \n> Running git-status rematched the index file to the working directory,\n> and during that rematch it noticed the file wasn't actually modified.\n\nThis keeps coming up every week or so... maybe git-merge should\nattempt to refresh the index automatically?  Of course it's an\nexpensive operation, but if you really want to do the merge you have\nto bite that bullet anyway.\n\nUnfortunately I can't see an obvious place to do that---the above\nmessage comes from unpack-trees.c, where changes would also affect\ne.g. checkout.\n\nOn the other hand, as near as I can tell this is a regression in\nbuiltin-merge.  Miklos, do you know if/how this can be fixed?\n\n- Thomas\n\n-- \nThomas Rast\ntrast@student.ethz.ch\n\n\n"},{"id":"91619","messageId":"20080925184942.GA3959@blimp.localhost","threadId":"15663","inReplyTo":"200809250905.09646.trast@student.ethz.ch","subject":"Re: having to pull twice","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-09-25T18:49:42Z","receivedAt":"2008-09-25T18:49:42Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Thomas Rast, Thu, Sep 25, 2008 09:05:02 +0200:\n> Shawn O. Pearce wrote:\n> > \"Michael P. Soulier\" <msoulier@digitaltorque.ca> wrote:\n> > > I'm finding this happening from time to time.\n> > > \n> > > soulierm@espresso:~/work/mitel-msl-tug$ git pull\n> > ...\n> > > error: Entry 'mitel-msl-tug.spec' not uptodate. Cannot merge.\n> [fixed by 'git status's index refresh]\n> > \n> > Time or dev/ino skew in the index file vs. what we read from stat.\n> > \n> > Running git-status rematched the index file to the working directory,\n> > and during that rematch it noticed the file wasn't actually modified.\n> \n> This keeps coming up every week or so... maybe git-merge should\n> attempt to refresh the index automatically?  Of course it's an\n> expensive operation, but if you really want to do the merge you have\n> to bite that bullet anyway.\n\nMaybe set \"core.trustctime\" for this repo to false?\n"},{"id":"91643","messageId":"20080925212823.GC21421@tigger.digitaltorque.ca","threadId":"15663","inReplyTo":"20080925184942.GA3959@blimp.localhost","subject":"Re: having to pull twice","fromName":"Michael P. Soulier","fromEmail":"msoulier@digitaltorque.ca","sentAt":"2008-09-25T21:28:25Z","receivedAt":"2008-09-25T21:28:25Z","isPatch":false,"sender":{"key":"msoulier@digitaltorque.ca","avatar":"https://gravatar.com/avatar/f32ca317cc5c1787a51e1f2388f33303ce743b458fd67669c3d14a21fd5dabc7?d=mp&s=160"},"body":"On 25/09/08 Alex Riesen said:\n\n> Maybe set \"core.trustctime\" for this repo to false?\n\nI can certainly try that, and mention it if it happens again. \n\nMike\n-- \nMichael P. Soulier <msoulier@digitaltorque.ca>\n\"Any intelligent fool can make things bigger and more complex... It\ntakes a touch of genius - and a lot of courage to move in the opposite\ndirection.\" --Albert Einstein\n"},{"id":"91648","messageId":"20080925232525.GP23137@genesis.frugalware.org","threadId":"15663","inReplyTo":"200809250905.09646.trast@student.ethz.ch","subject":"Re: having to pull twice","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-09-25T23:25:25Z","receivedAt":"2008-09-25T23:25:25Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Thu, Sep 25, 2008 at 09:05:02AM +0200, Thomas Rast <trast@student.ethz.ch> wrote:\n> On the other hand, as near as I can tell this is a regression in\n> builtin-merge.  Miklos, do you know if/how this can be fixed?\n\nI think Junio already fixed this in 446247d (merge: fix numerus bugs\naround \"trivial merge\" area, 2008-08-23), so 1.6.0.1 or 1.6.0.2 should\nnot have this bug.\n\nMichael, could you please upgrade frm 1.6.0 and confirm your problem\ngoes away?\n\nThanks.\n"},{"id":"91742","messageId":"200809271616.32082.trast@student.ethz.ch","threadId":"15663","inReplyTo":"20080925232525.GP23137@genesis.frugalware.org","subject":"Re: having to pull twice","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2008-09-27T14:16:29Z","receivedAt":"2008-09-27T14:16:29Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Miklos Vajna wrote:\n> On Thu, Sep 25, 2008 at 09:05:02AM +0200, Thomas Rast <trast@student.ethz.ch> wrote:\n> > On the other hand, as near as I can tell this is a regression in\n> > builtin-merge.  Miklos, do you know if/how this can be fixed?\n> \n> I think Junio already fixed this in 446247d (merge: fix numerus bugs\n> around \"trivial merge\" area, 2008-08-23), so 1.6.0.1 or 1.6.0.2 should\n> not have this bug.\n> \n> Michael, could you please upgrade frm 1.6.0 and confirm your problem\n> goes away?\n\nThat won't help.  I decided this was a good opportunity to learn about\n'git bisect run', and bisected it to 1c7b76b (Build in merge,\n2008-07-07).  This was with bad = 47a765d (pulled from Shawn's repo\nthis week) and good = v1.5.6.\n\nIn case you want to check my logic, the commands are below.\n\n- Thomas\n\n\n* Setup:\n\n  mkdir $temp_repo\n  cd $temp_repo\n  git init\n  echo foo > foo\n  git add foo\n  git commit -m initial\n  echo a > foo\n  git commit -m a foo\n  git checkout -b side HEAD^\n  echo b > foo\n  git commit -m b foo\n  git checkout master\n\n* Bisection script:\n\n-- 8< --\n#!/bin/sh\n\nrm -rf $temp_repo/{bin,libexec}\nmake -j3 prefix=$temp_repo install\n\nPATH=$temp_repo/bin:$PATH\ncd $temp_repo\ntouch foo\ngit merge side\ntest -f .git/MERGE_HEAD\ns=$?\ngit reset --hard\nif test $s != 0; then\n    echo did not work\n    exit 1\nelse\n    echo worked\n    exit 0\nfi\n-- >8 --\n\n\n"},{"id":"91802","messageId":"20080928151135.GF23137@genesis.frugalware.org","threadId":"15663","inReplyTo":"200809271616.32082.trast@student.ethz.ch","subject":"Re: having to pull twice","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-09-28T15:11:35Z","receivedAt":"2008-09-28T15:11:35Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Sat, Sep 27, 2008 at 04:16:29PM +0200, Thomas Rast <trast@student.ethz.ch> wrote:\n> * Setup:\n> \n>   mkdir $temp_repo\n>   cd $temp_repo\n>   git init\n>   echo foo > foo\n>   git add foo\n>   git commit -m initial\n>   echo a > foo\n>   git commit -m a foo\n>   git checkout -b side HEAD^\n>   echo b > foo\n>   git commit -m b foo\n>   git checkout master\n\nOh, the racy git problem. ;-)\n\n$ git reset --hard; touch foo; git merge side\nHEAD is now at 5bafc63 a\nAuto-merging foo\nCONFLICT (content): Merge conflict in foo\nAutomatic merge failed; fix conflicts and then commit the result.\n\n$ git reset --hard; sleep 1; touch foo;git merge side\nHEAD is now at 5bafc63 a\nerror: Entry 'foo' not uptodate. Cannot merge.\nfatal: merging of trees 86de5e13286a8449a8a706a58e63be6781770b12 and 9ee610433fb8854e497d62c648a612b5deb090cf failed\n\nThanks for the reproducer, I'll write a proper testcase for this and try to\nprovide a fix for it as well.\n"},{"id":"91805","messageId":"200809281726.23062.trast@student.ethz.ch","threadId":"15663","inReplyTo":"20080928151135.GF23137@genesis.frugalware.org","subject":"Re: having to pull twice","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2008-09-28T15:26:20Z","receivedAt":"2008-09-28T15:26:20Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Miklos Vajna wrote:\n> \n> Oh, the racy git problem. ;-)\n> \n> $ git reset --hard; touch foo; git merge side\n\nIIUC, this is not the same as \"racy git\".  The racy case is if you\nmanage to get a file changed immediately after its index entry was\nupdated, so that it will look unchanged.  In this case, it's simply\nthe same file with a new mtime, which means it looks changed\nsuperficially but still has the same contents.\n\nGranted, you could call my test \"racy\" because it relies on 'make\ninstall' taking at least one second, which by Moore's law should\nhappen sometime around 2019 ;-)\n\n> Thanks for the reproducer, I'll write a proper testcase for this and try to\n> provide a fix for it as well.\n\nThanks.\n\n- Thomas\n\n-- \nThomas Rast\ntrast@student.ethz.ch\n\n\n\n"},{"id":"91844","messageId":"20080929150049.GT23137@genesis.frugalware.org","threadId":"15663","inReplyTo":"200809281726.23062.trast@student.ethz.ch","subject":"Re: having to pull twice","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-09-29T15:00:49Z","receivedAt":"2008-09-29T15:00:49Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Sun, Sep 28, 2008 at 05:26:20PM +0200, Thomas Rast <trast@student.ethz.ch> wrote:\n> IIUC, this is not the same as \"racy git\".  The racy case is if you\n> manage to get a file changed immediately after its index entry was\n> updated, so that it will look unchanged.  In this case, it's simply\n> the same file with a new mtime, which means it looks changed\n> superficially but still has the same contents.\n\nRight. I called it \"racy\" because it had something to do with\ntimestamps. I guess we have no proper term for this kind of problem yet.\n;-)\n"},{"id":"92248","messageId":"1223038951-25190-1-git-send-email-vmiklos@frugalware.org","threadId":"15663","inReplyTo":"20080928151135.GF23137@genesis.frugalware.org","subject":"[PATCH] builtin-merge: refresh the index before calling a strategy","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-10-03T13:02:31Z","receivedAt":"2008-10-03T13:02:31Z","isPatch":true,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"In case a file is touched but has no real changes then we just have to\nupdate the index and should not error out.\n\nSigned-off-by: Miklos Vajna <vmiklos@frugalware.org>\n---\n\nOn Sun, Sep 28, 2008 at 05:11:35PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:\n> Thanks for the reproducer, I'll write a proper testcase for this and\n> try to\n> provide a fix for it as well.\n\nTry this one.\n\n builtin-merge.c  |   10 ++++++++++\n t/t7600-merge.sh |    9 +++++++++\n 2 files changed, 19 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-merge.c b/builtin-merge.c\nindex 4c9ed5d..6c9dfe6 100644\n--- a/builtin-merge.c\n+++ b/builtin-merge.c\n@@ -548,6 +548,16 @@ static int try_merge_strategy(const char *strategy, struct commit_list *common,\n \tint i = 0, ret;\n \tstruct commit_list *j;\n \tstruct strbuf buf;\n+\tint index_fd;\n+\tstruct lock_file *lock = xcalloc(1, sizeof(struct lock_file));\n+\n+\tindex_fd = hold_locked_index(lock, 1);\n+\trefresh_cache(REFRESH_QUIET);\n+\tif (active_cache_changed &&\n+\t\t\t(write_cache(index_fd, active_cache, active_nr) ||\n+\t\t\t commit_locked_index(lock)))\n+\t\treturn error(\"Unable to write index.\");\n+\trollback_lock_file(lock);\n \n \tif (!strcmp(strategy, \"recursive\") || !strcmp(strategy, \"subtree\")) {\n \t\tint clean;\ndiff --git a/t/t7600-merge.sh b/t/t7600-merge.sh\nindex 98cfc53..61db3c3 100755\n--- a/t/t7600-merge.sh\n+++ b/t/t7600-merge.sh\n@@ -520,4 +520,13 @@ test_expect_success 'merge --no-ff --no-commit && commit' '\n \n test_debug 'gitk --all'\n \n+test_expect_success 'refresh the index before merging' '\n+\tgit reset --hard c1 &&\n+\tsleep 1 &&\n+\ttouch file &&\n+\tgit merge c3\n+'\n+\n+test_debug 'gitk --all'\n+\n test_done\n-- \n1.6.0.2\n"}]}