mingw_offset_1st_component() returns "foo" for inputs "/foo" and
"c:/foo", but inconsistently returns "/foo" for UNC input
"/machine/share/foo".  Fix it to return "foo" for all cases.

Reference: http://groups.google.com/group/msysgit/browse_thread/thread/c0af578549b5dda0

Signed-off-by: Eric Sunshine <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

On Windows, we would like to be able to have a default http.sslCAinfo
that points to an MSys path (i.e. relative to the installation root of
Git).  As Git is a MinGW program, it has to handle the conversion
of the MSys path into a MinGW32 path itself.

Since system_path() considers paths starting with '/' as absolute, we
have to convince it to make a Windows path by stripping the leading
slash.

Signed-off-by: Johannes Schindelin <[email protected]>

On Windows XP3 in git bash
git clone [email protected]:octocat/Spoon-Knife.git
cd Spoon-Knife
git gui
menu Remote\Fetch from\origin
error: cannot spawn git: No such file or directory
error: could not run rev-list

if u run
git fetch --all
it worked normal in git bash or gitgui tools

In second version CreateProcess get 'C:\Git\libexec\git-core/git.exe' in
first version - C:/Git/libexec/git-core/git.exe and not executes (unix
slashes)

after fixing C:\Git\libexec\git-core\git.exe or
C:/Git/libexec/git-core\git.exe it works normal

Signed-off-by: Johannes Schindelin <[email protected]>

It appears that `pwd` returns the POSIX-style or the DOS-style path
depending which style the previous `cd` used. To normalize, enforce `pwd
-W` in scripts.

From the original e-mail exchange:

On Thu, Mar 22, 2012 at 11:13:37AM +0100, Sebastian Schuberth wrote:
> On Wed, Mar 21, 2012 at 22:21, Johannes Sixt <[email protected]> wrote:
>
> > I build git and run its tests outside the msysgit environment. Does that
> > explain the difference? (And I use CMD.)
>
> It does not make a difference for me. I started cmd.exe at
> c:\msysgit\git\t, added c:\msysgit\bin temporarily to PATH, and ran
> "sh t5526-fetch-submodules.sh -i -v", and the test still fails.

Yes it probably does. Johannes said that he runs the tests outside of
the msysgit folder. That way there is only one path the submodule script
gets reported and not two like '/c/msysgit/git' and '/git'.

That would explain to me why it is passing.

I am afraid that the only solution is to patch msys itself to report the
long absolute path when passing window style paths to cd. Currently when
I do

	cd c:/msysgit/git

I will end up in '/git' instead of the long path.

I found that there is a -W option to pwd in msys bash which makes it
always return the real windows path. A normalization in that direction
is unique and thus might be more robust. Have a look at the attached
patch. With this at least t5526 passes. I was not able to run the whole
testsuite properly at the moment. I can have a look at that tomorrow.

What do you think?

Cheers Heiko

Signed-off-by: Johannes Schindelin <[email protected]>

Signed-off-by: Johannes Schindelin <[email protected]>

Signed-off-by: Johannes Schindelin <[email protected]>

…ript

Gitweb is not exactly what you would call server-friendly, so let's
offload one more task onto the client.

To enable this, put something like this into your gitweb_config.perl:

	$feature{'syntaxhighlighter_js'}{'default'} = [{
		url => '/SyntaxHighlighter/',
		style => 'Django',
		theme => 'FadeToGrey'
	}];

and clone git://github.com/alexgorbatchev/SyntaxHighlighter into the
directory you specified via the 'url' parameter.

Signed-off-by: Johannes Schindelin <[email protected]>

Signed-off-by: Johannes Schindelin <[email protected]>

It is pretty convenient to refer to a line number by appending, say,
highlighter, too.

Signed-off-by: Johannes Schindelin <[email protected]>

Signed-off-by: Johannes Schindelin <[email protected]>

Incidentally, this makes grep -I respect the "binary" attribute (actually,
the "-text" attribute, but "binary" implies that).

Since the attributes are not thread-safe, we now need to switch off
threading if -I was passed.

Signed-off-by: Johannes Schindelin <[email protected]>

This commit fixes the issue with the handling of large files causing an
'Out of memory' perl exception. Instead of reading and writing the whole
blob at once now the blob is written in small pieces.

The problem was raised and discussed in this mail to the msysGit mailing
list: http://thread.gmane.org/gmane.comp.version-control.msysgit/12080

Signed-off-by: Gregor Uhlenheuer <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

In msysGit, echo used in scripts outputs DOS line-endings while built-ins
use Unix line-endings in their output. This causes t7508-status to fail
due to mixed line endings in the output of git status (which calls
git-submodule).

Signed-off-by: Sebastian Schuberth <[email protected]>

Again, avoid using echo (which issues DOS line endings on msysGit) to not mix
with Unix line-endings issued by git built-ins, even if this is at the cost of
calling an external executable (cat) instead of a shell built-in (echo).

Along the lines of 05d0e3b and f33946d, use cat instead of echo to avoid
line ending mismatches in the test result of "am empty-file does not
infloop" which make the test fail.

Signed-off-by: Sebastian Schuberth <[email protected]>

Signed-off-by: Johannes Schindelin <[email protected]>

Signed-off-by: Johannes Schindelin <[email protected]>

…ctive'

Signed-off-by: Johannes Schindelin <[email protected]>

This is really a problem with shell scripts being called on msysGit,
but there are more important bugs to fix for the moment.

Signed-off-by: Johannes Schindelin <[email protected]>

Git on Windows was made aware of the fact that sometimes a file may be
used by another process and so an operation may fail but the user might
be able to fix it and is asking for confirmation whether it should
retry.

This is implemented in a way that git only asks in case stdin and stderr
are attached to a tty. Unfortunately this seems to be misdetected
sometimes causing the testsuite to hang when git is waiting for a user
answer.

This patch works around the situation.

Signed-off-by: Heiko Voigt <[email protected]>

Signed-off-by: Johannes Schindelin <[email protected]>

... because that does not work in MinGW.

Signed-off-by: Johannes Schindelin <[email protected]>

Exclude these tests when using MINGW.

Signed-off-by: Pat Thoyts <[email protected]>

On msysGit creating the post-rewrite.args file using 'echo' has different
line endings from the expected comparison. Using perl normalizes the line
endings for each generated file.

Signed-off-by: Pat Thoyts <[email protected]>

It is the old shell-script issue we had in a few other tests already.

Signed-off-by: Johannes Schindelin <[email protected]>

This happens only when the corresponding commits are not exported in
the current fast-export run. This can happen either when the relevant
commit is already marked, or when the commit is explicitly marked
as UNINTERESTING with a negative ref by another argument.

This breaks fast-export basec remote helpers.

Signed-off-by: Sverre Rabbelier <[email protected]>

The skip message takes about remote-hg while the tests are about the
general remote helper framework (and don't require hg). Correct the
message.

This happens to shut up t7602 on Windows which would otherwise take
the different line endings for a sign that the merge failed.

Signed-off-by: Johannes Schindelin <[email protected]>

On Windows, we suffer from frequently leaked DOS line endings. Let's
ignore them.

Signed-off-by: Johannes Schindelin <[email protected]>