Oh, wow.  Is this issue still current?

I once saw this issue, too, but cannot currently reproduce it with git version
1.6.2.1217.gd7bc3.

I asked because I imagine that it is an issue with msys-1.0.dll: the message is
produced by git-pull.sh, a shell script, and the bash pipes its output through that
.dll.  So chances are that our upgrading msys-1.0.dll was a "drive-by fix".

I'll call this bug fixed until we see it again ;-)

Not fixed. git version 1.6.2.1217.gd7bc3

S:\>git pull
From git@github.com:myuser/myrepo
   6a01ea7..db6f6f2  master     -> origin/master
Updating 6a01ea7..db6f6f2
error: Entry 'app/controllers/some_


The file name is 'app/controllers/some_controller.rb'

You need to provide way more information, then.  It is of uttermost importance to
know the Windows version you are using, if you run the thing from inside a
PowerShell, or a cmd window, or anything else... Unless you can provide enough
information for me to _reproduce_ your issue, there is little chance I can do
anything about it.

WinXP SP3, running from a cmd window.

Unfortunately, that scarce documentation puts us back at square one: AFAICT I have
the _same_ setup, but everything works here.  Except maybe that I use Git Bash
instead of the Windows shell.  Maybe you want to verify that the issue only ever
arises in the Windows Shell, but never in Git Bash on your side.

I can't get it to happen in Git Bash.

Git pull is still a shell script, I imagine this would be the reason we do not see
this problem more often.

I see this issue with the latest msysGit, for example:

>git pull
Alre

instead of saying "Already up-to-date".

System is WinXP SP2, Git version is 1.6.2.msysgit.0.186.gf7512.

I have only seen this issue in CMD windows. It never occurs for me when I use Git 
bash.

For what its worth, even in CMD windows it doesn't occur always, but it does happen 
often enough to be noticeable. When it does occur, it only seems to occur with "git 
pull", I don't recall seeing it with any other command.

Hope this helps.

Yes, it helps indeed.  It shows that the most likely source is some misunderstanding
between bash (through msys-1.0.dll) and cmd.

So I guess the problem is best solved by converting "git pull" to be a proper Git
builtin.

One thing that strikes me as a bit odd from looking at the source code, is that 
"Already up-to-date" does not seem to be an error message that originates from git-
pull.sh, it seems to come from git-merge which is already written in C. Another thing 
I noticed is that the call to git-merge is the last line of the script. Could it be 
that bash somehow manages to close the application without flushing the output-stream 
properly?

I would expect so, yes.

The "You are in the middle of a conflicted merge." message is maybe attributable to
something with sh, because that message is just generated with an echo >&2 before
exiting. But the "Already up-to-date" message goes to stdout and is only generated in
builtin-merge.c (9b69cf1, line 991), which is called from git.c, which flushes stdout
(9b69cf1, line 259) before quitting. For that message to truncate in cmd (not bash),
I guess the fflush would have to fail??

I tried running git pull a few thousand times in a loop in cmd, but the output
wouldn't truncate for me. Maybe I can try another computer later.

'git merge' is called via exec from within git-pull.sh, so I expect stdout to go
through msys-1.0.dll.

Next time someone sees the problem, please remove the word 'exec' in the 
next-to-last line of the git-pull script (the script is in 
$installdir/libexec/git-core). Does that make a difference?

I get this, too.
ex:

use cygwin's cat:

C:\cygwin\bin>cat tester
;alskdjf;laskjfd;laskdjfa;lskjfd;laskjfd;laskdjf
asdfasdf
sadf
asdf
asdf
asdf

C:\cygwin\bin>cd ..

# use msys cat:

C:\cygwin>cat bin\tester
;alskdjf;laskjfd;laskdjfa;ls
C:\cygwin>

this is probably an msys problem.

Running it through msys bash didn't help:
C:\cygwin>bash -c "cat bin/tester"
;alskdjf;laskjfd;laskdjfa;lskjfd;laskjfd;laskdjf
asdfasdf

so I'd guess an msys.dll problem?
I ran into it once about a year ago, and now for some reason it's back.  And only on 
one computer and not on another (using the same binaries).  I tried it with several 
different versions of msysgit and they all do the same thing, so it's not a recent 
problem only.
-=r

appears that running it through msys bash does work, though (any ideas what is going 
on here?)

C:\dev\ruby\p2pwebclient>c:\dev\ruby\rubyinstaller\sandbox\msys\bin\ls
distro  d
C:\dev\ruby\p2pwebclient>c:\dev\ruby\rubyinstaller\sandbox\msys\bin\bash
bash-3.1$ ls
distro  documents  logs  pic templates  pics_old  src
bash-3.1$

hi rogerpack2005!

well i think the difference between 
bash -c "cat bin/tester" 
and your interactive bash instance is a pretty good testcase with which to work. 

But did you try what the big guy's asked above:
  Next time someone sees the problem, please remove the word 'exec' in the 
  next-to-last line of the git-pull script (the script is in 
  $installdir/libexec/git-core). Does that make a difference?

this could give more clue about the role of the specific mechanisms involved. 

what are the system-specifics of the machine reproducing the bug? 
what windows? what cmd shell? how many cores? 32bit or 64 bit? what servicepack? 

a couple more observations:
C:\dev\ruby\rubyinstaller>set CYGWIN=ntsec tty

C:\dev\ruby\rubyinstaller>git pull
You are in the middle of
C:\dev\ruby\rubyinstaller>set CYGWIN=

C:\dev\ruby\rubyinstaller>git pull
You are in the middle of a conflicted merge.

curious.