threads / bug / 15115

[BUG] pull faulty 'not uptodate'

Subject: [BUG] pull faulty 'not uptodate'

## tl;dr

7 messages between Aug 20, 2008 and Aug 20, 2008.

replies: 6people: 3as markdown or json

Pieter de Bie· Aug 20, 2008, 21:00 UTC · lore

Hi,

I think git pull does not refresh the index before trying to merge:

Tirana:gitbot pieter$ git reset --hard 5ff4dff
HEAD is now at 5ff4dff Add a Git FAQ plugin
Tirana:gitbot pieter$ touch test/gitfaq.rb
Tirana:gitbot pieter$ git pull
Updating 5ff4dff..931a247
error: Entry 'test/gitfaq.rb' not uptodate. Cannot merge.
Tirana:gitbot pieter$ git st
# On branch master
# Your branch is behind 'origin/master' by 2 commits, and can be fast- 
forwarded.
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	GitLink.py
#	faq.yaml
#	test.py
nothing added to commit but untracked files present (use "git add" to  
track)
Tirana:gitbot pieter$ git pull
Updating 5ff4dff..931a247
Fast forward
  plugins/gitfaq.rb  |   46 ++++++++++++++++++++++--------------------
  plugins/irc.rb     |   56 +++++++++++++++++++++++++ 
+-------------------------
  test/faq-test.html |   10 +++++++++
  test/gitfaq.rb     |   42 +++++++++++++++++++-------------------
  4 files changed, 84 insertions(+), 70 deletions(-)
  create mode 100644 test/faq-test.html

Junio C Hamano· Aug 20, 2008, 21:22 UTC · re: Pieter de Bie · lore

Re: [BUG] pull faulty 'not uptodate'

Pieter de Bie <pdebie@ai.rug.nl> writes:

> I think git pull does not refresh the index before trying to merge:

Yeah, that is another regression from C rewrite.  Thanks for reporting.

But I also have to wonder why a git-list regular like you are reporting this _long after_ v1.6.0-rc1 was released. Perhaps this is not really a big-deal bug spelled in capital letters like you have on your Subject line?

Pieter de Bie· Aug 20, 2008, 21:29 UTC · re: Junio C Hamano · lore

Re: [bug] pull faulty 'not uptodate'

On Aug 20, 2008, at 11:22 PM, Junio C Hamano wrote:

Show 6 quoted lines

> But I also have to wonder why a git-list regular like you are  
> reporting
> this _long after_ v1.6.0-rc1 was released.  Perhaps this is not  
> really a
> big-deal bug spelled in capital letters like you have on your Subject
> line?

I just noticed it and wanted to report it. I thought the usual way to do this is to put [BUG] in the subject line. If that is not the common way to report bugs, I'm sorry. I can also downcase it ;)

- Pieter

Junio C Hamano· Aug 20, 2008, 21:50 UTC · re: Pieter de Bie · lore

Re: [bug] pull faulty 'not uptodate'

Pieter de Bie <pdebie@ai.rug.nl> writes:

Show 11 quoted lines

> On Aug 20, 2008, at 11:22 PM, Junio C Hamano wrote:
>> But I also have to wonder why a git-list regular like you are
>> reporting
>> this _long after_ v1.6.0-rc1 was released.  Perhaps this is not
>> really a
>> big-deal bug spelled in capital letters like you have on your Subject
>> line?
>
> I just noticed it and wanted to report it. I thought the usual way to
> do this is to put [BUG] in the subject line. If that is not the common
> way to report bugs, I'm sorry. I can also downcase it ;)

Nah, don't bother --- that wouldn't help.

Checking if it is a regression ("it used to work but recently broken") or a bug ("it does not work as I expect it") and marking the report as such would have helped, though.

Junio C Hamano· Aug 20, 2008, 21:50 UTC · re: Pieter de Bie · lore

Re: [bug] pull faulty 'not uptodate'

Pieter de Bie <pdebie@ai.rug.nl> writes:

Show 11 quoted lines

> On Aug 20, 2008, at 11:22 PM, Junio C Hamano wrote:
>> But I also have to wonder why a git-list regular like you are
>> reporting
>> this _long after_ v1.6.0-rc1 was released.  Perhaps this is not
>> really a
>> big-deal bug spelled in capital letters like you have on your Subject
>> line?
>
> I just noticed it and wanted to report it. I thought the usual way to
> do this is to put [BUG] in the subject line. If that is not the common
> way to report bugs, I'm sorry. I can also downcase it ;)

Nah, don't bother --- that wouldn't help.  A bug is a bug is a bug.

Checking if it is a regression ("it used to work but recently broken") or a bug ("it does not work as I expect it") and marking the report as such would have helped, though.

Junio C Hamano· Aug 20, 2008, 22:09 UTC · re: Pieter de Bie · lore

"git-merge": allow fast-forwarding in a stat-dirty tree

We used to refresh the index to clear stat-dirtyness before a fast-forward merge. Recent C rewrite forgot to do this.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-merge.c  |    2 +-
 t/t7600-merge.sh |   10 ++++++++++
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git c/builtin-merge.c w/builtin-merge.c
index dde0c7e..a201c66 100644
--- c/builtin-merge.c
+++ w/builtin-merge.c
@@ -566,6 +566,7 @@ static int checkout_fast_forward(unsigned char *head, unsigned char *remote)
 
 	if (read_cache_unmerged())
 		die("you need to resolve your current index first");
+	refresh_cache(REFRESH_QUIET);
 
 	fd = hold_locked_index(lock_file, 1);
 
@@ -936,7 +937,6 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
 			hex,
 			find_unique_abbrev(remoteheads->item->object.sha1,
 			DEFAULT_ABBREV));
-		refresh_cache(REFRESH_QUIET);
 		strbuf_init(&msg, 0);
 		strbuf_addstr(&msg, "Fast forward");
 		if (have_message)
diff --git c/t/t7600-merge.sh w/t/t7600-merge.sh
index 5eeb6c2..fee8fb7 100755
--- c/t/t7600-merge.sh
+++ w/t/t7600-merge.sh
@@ -488,4 +488,14 @@ test_expect_success 'merge c1 with c1 and c2' '
 
 test_debug 'gitk --all'
 
+test_expect_success 'merge fast-forward in a dirty tree' '
+       git reset --hard c0 &&
+       mv file file1 &&
+       cat file1 >file &&
+       rm -f file1 &&
+       git merge c2
+'
+
+test_debug 'gitk --all'
+
 test_done

Miklos Vajna· Aug 20, 2008, 22:35 UTC · re: Junio C Hamano · lore

Re: "git-merge": allow fast-forwarding in a stat-dirty tree

On Wed, Aug 20, 2008 at 03:09:28PM -0700, Junio C Hamano <gitster@pobox.com> wrote:

>  	if (read_cache_unmerged())
>  		die("you need to resolve your current index first");
> +	refresh_cache(REFRESH_QUIET);

I did not realise that we need a refresh_cache() after read_cache_unmerged() here, and thus the other refresh_cache() call is unnecessary.

Thanks.