login
Search
Hi, I'm running git 1.5.2.2 under Cygwin on Windows XP. This is what I'm (reproducibly) getting if I try to clone QGit's repository: sschuber@xp-sschuber2 ~ $ git clone git://git.kernel.org/pub/scm/qgit/qgit4.git Initialized empty Git repository in /home/sschuber/qgit4/.git/ remote: Generating pack... remote: Done counting 2295 objects. remote: Deltifying 2295 objects... remote: 100% (2295/2295) done Indexing 2295 objects... remote: Total 2295 (delta 1793), reused 1218 (delta 955) 100% (2295/2295) done Resolving 1793 deltas... fatal: Not a valid object name HEAD sschuber@xp-sschuber2 ~ $ git --version git version 1.5.2.2 I'm not sure whether the cause for this is the same as mentioned at http://article.gmane.org/gmane.comp.version-control.git/54825 However, the most recent msysGit worked fine for me. Any clues whether this is a repository problem, a Cygwin problem, or a git problem? Thanks. -- Sebastian Schuberth -
Hi, I suspect that there is no master branch on the remote side, but the remote's HEAD points there. Try "git ls-remote <url>" to find out. Ciao, Dscho -
I'm not too familiar with git yet, but to me this looks alright:
sschuber@xp-sschuber2 ~
$ git ls-remote git://git.kernel.org/pub/scm/qgit/qgit4.git
6c4444edbc4b870df7cde1e05ee76d1d15ea428f HEAD
6c4444edbc4b870df7cde1e05ee76d1d15ea428f refs/heads/master
70cd59500e8113901333741d82bbd055f96787f6 refs/tags/qgit-2.0rc1
1fe8ecc6a47d47a883beab1afa4607b1ca5da698 refs/tags/qgit-2.0rc1^{}
29bb10bf0397924489a51adb759f2df4b17fc31f refs/tags/qgit-2.0rc2
243cd78b72b1a4021d63829f62419f5483e70c7d refs/tags/qgit-2pre1
738063eb6f0f8f706e5f8609eab003ab19628617 refs/tags/qgit-2pre1^{}
17245c4248feab0d0425355ab5ff1cd4d7f83872 refs/tags/qgit2-pre2
7e02b07bc910a1d49b2cb4846641e01b7f6512aa refs/tags/qgit2-pre2^{}
--
Sebastian Schuberth
-
As Mark Levedahl assumed by e-mail, the problem is with Cygwin's binary vs. text mount mode feature. Thanks Mark. I'm running on NTFS and I did try the "binary mount" stuff before "git clone" by issuing mount -bc /cygdrive but I overlooked that this command only affects /cygdrive paths, and I did clone into a non /cygdrive path. So cloning to a /cygdrive mounted path works now. I wonder if this happens because git never passes "b" to any fopen() calls (as there is no such thing like opening a file in binary mode under Linux, because files are always opened "binary"). If fopen() safely ignores the "b" option under Linux, I think it should always be specified so Cygwin's git will work with text mode mounts when compiled from the original git sources. -- Sebastian Schuberth -
Actually we never use fopen() when we care about the data (and we always care about object data and working tree data). We always use open(2) and use system call IO directly to perform all reads and writes. fopen() is only used on trivial things, like say the .git/config file. Now on a normal UNIX system open(2) *always* by definition does binary IO. But Cygwin's text mount option tries to make UNIX programs DOS-friendly by making all files treated as text, even if it supposedly doing binary IO via open(2). I think its a mis-feature of Cygwin. Git has no way (that I know of) to defend itself from this, other than to tell the user to make sure they only store a Git repository in a location that is mounted with the binary flag. -- Shawn. -
Cygwin, like Windows' own open(2) simulation, defines an O_BINARY to pass as a flag to open(2). I once got Git half-working on Cygwin text-mode mounts by doing a horrible hack approximating: #define open(name, flag, ...) \ open(name, (flag) | O_BINARY, ## __VA_ARGS__) But it only half worked. Eventually it managed to corrupt itself again, and worse, the test suite was completely hopeless, as all shell activity still results in text-mode files. -bcd -
Something like that would have been my suggested work-around, too. Unfortunate to hear this alone won't fix the problem. I've spotted several fopen() calls in git where "b" is not explicitly used. Maybe fixing those, too, would to do it. -- Sebastian Schuberth -
Why that? Although I don't fully understand the description of the (no)binmode CYGWIN environment variable option [1], it sound to me as if shells might do the right thing by default. But wait ... further down in the document there's more magic. (no)tty might be related as well. My question is, is there any chance to handle the shell activity by setting the right CYGWIN options? Here's another idea. Could git somehow check if the file operations work as expected and if not refuse to work. Git would at least have a well defined behaviour on cygwin, independently of the weird binmode/textmode stuff. Either it works, or it tells that it can't work. Something like fp = fopen ("tmp-test", "w"); /* no b */ fprintf (fp, "\n"); fclose (fp) fp = fopen (tmp-test", "rb"); /* with b */ if (freads returns crap) die; I checked a couple of cygwin installations on our machines and the results are quite scary. Some have all binmode, some have all textmode, and some have some parts mounted as binmode and other as textmode. I'd not dare to recommend using git on these machines. Steffen [1] http://www.cygwin.com/cygwin-ug-net/using-cygwinenv.html -
See my other message: text mounts are best considered obsolescent if not deprecated, and that mode is definitely not actively developed. There are just too many loopholes with forks and pipes to reliably "do the right thing." Your suggested tests for non-binary mode mounts (properly #ifdef'd for Cygwin, possibly only enabled if specifically configured in) are a reasonable idea. Mark -
The discussion below basically leads to two questions: Is there any chance that git can be ported to cygwin's textmode? Is there any chance that patches would be accepted that try to do so? Even if they add "b" to fopen and O_BINARY to open, which both are useless on Unix? Junio, Linus? I read your message and I just checked the most recent installer of cygwin (screenshot attached). I see three choices I'm offered: 1) the path to install; 2) install for all or just me; 3) choose the default text file type. I wouldn't call that deprecated, not even obsolenscent. To me it looks, as if the installer offers me a real choice. Besides the default path (which I never changed) and the decision whether I install for all (which I would always do) I see a single real choice in this installer -- the text file type. That's far from deprecated. I am strongly convinced that many consider to choose DOS/text if it offers a benefit for them, for example if they want to run CVS in cygwin. And if the option to choose is around today, a reasonable assumption is that cygwin installations in textmode will be around for another couple of years. I was convinced that git supports Windows, at least in cygwin. I am no longer convinced. I would no longer call this Windows support -- not even in cygwin. The first four people I asked to test git on Windows came back to me and told me that something is broken. They didn't do anything wrong. They just used an option that cygwin offers them during installation -- not hidden, not deprecated, no indication that they shouldn't use this option. They or someone else may have made the choice years ago. Their first impression was: git doesn't work. One of them is now testing Mercurial. He explained me today: "well, git can't even clone its own development repo. I recognized that Mercurial is basically doing the same and it's working fine for me." I'd really prefer if git handled textmode (or at least refuses to We could try to restrict that to ...
I certainly don't think it would be wrong to add O_BINARY to the open()
parameters (and "b" to fopen() and friends), if it makes a difference.
Add a
#ifndef O_BINARY
#define O_BINARY 0
#endif
and it should be harmless anywhere else.
So if you're willing to test, and extend on this, maybe something like
this gets you started (I think the main issue will be the object files,
no?)
Linus
---
diff --git a/sha1_file.c b/sha1_file.c
index aca741b..0f613c0 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -23,6 +23,10 @@
#endif
#endif
+#ifndef O_BINARY
+#define O_BINARY 0
+#endif
+
#ifdef NO_C99_FORMAT
#define SZ_FMT "lu"
#else
@@ -444,7 +448,7 @@ static int check_packed_git_idx(const char *path, struct packed_git *p)
struct pack_idx_header *hdr;
size_t idx_size;
uint32_t version, nr, i, *index;
- int fd = open(path, O_RDONLY);
+ int fd = open(path, O_BINARY | O_RDONLY);
struct stat st;
if (fd < 0)
@@ -631,7 +635,7 @@ static int open_packed_git_1(struct packed_git *p)
if (!p->index_data && open_pack_index(p))
return error("packfile %s index unavailable", p->pack_name);
- p->pack_fd = open(p->pack_name, O_RDONLY);
+ p->pack_fd = open(p->pack_name, O_BINARY | O_RDONLY);
if (p->pack_fd < 0 || fstat(p->pack_fd, &st))
return -1;
@@ -983,12 +987,12 @@ static void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
return NULL;
}
- fd = open(filename, O_RDONLY | sha1_file_open_flag);
+ fd = open(filename, O_BINARY | O_RDONLY | sha1_file_open_flag);
if (fd < 0) {
/* See if it works without O_NOATIME */
switch (sha1_file_open_flag) {
default:
- fd = open(filename, O_RDONLY);
+ fd = open(filename, O_BINARY | O_RDONLY);
if (fd >= 0)
break;
/* Fallthrough */
@@ -2023,6 +2027,12 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
return 0;
}
+static void close_or_die(int fd, const char *file)
+{
+ if (close(fd))
+ die("unable to close %s (%s)", ...Gaah, that was unintentional. Just random noise I had in my tree, and didn't even realize made it into the patch. That "close_or_die()" was because I saw somebody report a write error without the error string, apparently because the error only got reported on the close (probably NFS). This way you see if the reason the close failed was due to out of diskspace or whatever. But I should have split them up properly - the close_or_die() part obviously had nothing to do with the O_BINARY part. Feel free to take it regardless, or split it yourself. Linus -
I took a more radical approach and used a small script to add
"b" to all calls to fopen and O_BINARY to all calls to open.
O_BINARY is provided by the Makefile if not on cygwin. I don't
think we need to differentiate between binary and textfiles.
I'll send the patch shortly.
I started to run the tests on cygwin in textmode. I chose the
following setup.
- cygwin is set to binmode, that is cygwin's git is working.
- I used git to cloned git to a Windows directory, say c:\git
and compiled there. The Windows directory is mounted in binmode.
- For testing I 'mount' this directory in text mode, in my example
cd /
mkdir git-textmode
mount --text 'c:\git' git-textmode
This setup allows you to work with git and test in the same
working directory in textmode. You should double check in which
of your directories you commit. Right now, committing in the
textmode directory is only for the brave ones.
'git read-tree HEAD' in the binmode directory should help if
you executed the wrong git in the wrong directory and your index
got corrupted.
The first problems I ran into are pre-computed sha1's for the
test cases. I started to add d2u to the test scripts to generate
files with unix style line endings even if cygwin is in textmode.
This is needed to match the expected results that come with
the test files. I'll send the first changes in a second patch.
The patch is only for illustrating the problem. It's not thought
to be applied.
The tests are running. t0000-basic and t0010-racy-git pass. I'll
send a testlog later. It's running inside a virtual machine on a
laptop, so it may take some more time.
I suspect the tests will report a lot of errors. At least all
tests that compare 'echo' output with precomputed sha1's or
expected results that come with the tests should fail. I haven't
fully understood the details of line conversion of cygwin. Some
work may be needed to eliminate false fails from the tests, e.g. by
adding 'd2u', and find the real ...O_BINARY = 0 is provided by the Makefile for all architectures
except Cygwin.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Makefile | 5 +++++
attr.c | 2 +-
builtin-apply.c | 8 ++++----
builtin-blame.c | 4 ++--
builtin-bundle.c | 4 ++--
builtin-fetch--tool.c | 4 ++--
builtin-fmt-merge-msg.c | 2 +-
builtin-fsck.c | 2 +-
builtin-grep.c | 4 ++--
builtin-init-db.c | 4 ++--
builtin-mailinfo.c | 4 ++--
builtin-mailsplit.c | 6 +++---
builtin-reflog.c | 2 +-
builtin-rerere.c | 12 ++++++------
combine-diff.c | 2 +-
commit.c | 2 +-
config.c | 4 ++--
daemon.c | 4 ++--
diff.c | 2 +-
diffcore-order.c | 2 +-
dir.c | 2 +-
entry.c | 2 +-
fast-import.c | 6 +++---
hash-object.c | 2 +-
http-fetch.c | 6 +++---
http-push.c | 6 +++---
imap-send.c | 2 +-
index-pack.c | 6 +++---
local-fetch.c | 6 +++---
lockfile.c | 2 +-
mailmap.c | 2 +-
merge-recursive.c | 4 ++--
pack-write.c | 2 +-
path.c | 4 ++--
read-cache.c | 4 ++--
refs.c | 14 +++++++-------
remote.c | 4 ++--
run-command.c | 2 +-
server-info.c | 6 +++---
sha1_file.c | 14 +++++++-------
shallow.c | 2 +-
test-delta.c | 6 +++---
trace.c | 2 +-
43 files changed, 95 insertions(+), 90 deletions(-)
I took a more radical approach and used a small script to add
"b" to all calls to fopen and O_BINARY to all calls to open.
I don't think we need to differentiate between binary and
textfiles.
...This is needed if the content of files is compared with
precomputed sha1s or stored expected results.
***WARNING***
This patch is useful for testing and illustrating the problem
but not thought to be applied to any official git branch.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
t/t0000-basic.sh | 2 +-
t/t0020-crlf.sh | 8 ++++----
t/t0021-conversion.sh | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 4e49d59..bf71ce6 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -91,7 +91,7 @@ test_expect_success \
mkdir path2 path3 path3/subp3
for p in path0 path2/file2 path3/file3 path3/subp3/file3
do
- echo "hello $p" >$p
+ echo "hello $p" | d2u >$p
ln -s "hello $p" ${p}sym
done
test_expect_success \
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index fe1dfd0..52dc739 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -21,10 +21,10 @@ test_expect_success setup '
git repo-config core.autocrlf false &&
- for w in Hello world how are you; do echo $w; done >one &&
+ for w in Hello world how are you; do echo $w; done | d2u >one &&
mkdir dir &&
- for w in I am very very fine thank you; do echo $w; done >dir/two &&
- for w in Oh here is NULQin text here; do echo $w; done | q_to_nul >three &&
+ for w in I am very very fine thank you; do echo $w; done | d2u >dir/two &&
+ for w in Oh here is NULQin text here; do echo $w; done | q_to_nul | d2u >three &&
git add . &&
git commit -m initial &&
@@ -34,7 +34,7 @@ test_expect_success setup '
two=`git rev-parse HEAD:dir/two` &&
three=`git rev-parse HEAD:three` &&
- for w in Some extra lines here; do echo $w; done >>one &&
+ for w in Some extra lines here; do echo $w; done | d2u >>one &&
git diff >patch.file &&
patched=`git hash-object --stdin <one` &&
git read-tree --reset -u HEAD &&
diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
index a839f4e..9ca11bb 100755
--- ...Quite frankly, *much* rather than having d2u everywhere, why not make the default for DOS/Windows be to have [core] autocrlf=true and then none of this should hopefully be needed. (We still need to write the internal git objects using O_BINARY to make sure that cygwin doesn't corrupt binary data, but that's a totally different issue). Linus -
Thanks for that idea. I'll check how far I can get with it. Steffen -
I apologize, I didn't check the size of the attachment in the previous mail (which probably got blocked from the list). This time with a link to the logfile. I attached the log of a testrun on an textmode mounted directory in cygwin with the two recently sent patches applied. It doesn't look too bad, but it's far from perfect: 1470 ok to 637 FAIL http://www.zib.de/prohaska/hidden/2007/git-cygwin-textmode/ testlog-2007-08-08.txt Steffen -
In addition to all the other stuff discussed, I believe you also need to worry about the binaryness of stdin and stdout. Looking at: http://www.cygwin.com/cygwin-ug-net/using-textbinary.html I think this can be achieved by putting something like: setmode(0, O_BINARY); setmode(1, O_BINARY); at the start of git's main(). When I was trying to get this to work, I did this as well as fixing up open() and fopen() calls as has already been discussed. What got me to quit, however, was that I never found a decent way to make the Git shell scripts binary safe, and enough of the system was in shell as to make it pretty much useless for everyday use. Looking at the examples on the above page: To illustrate the various rules, we provide scripts to delete CRs from files by using the tr program, which can only write to standard output. The script #!/bin/sh # Remove \r from the file given as argument tr -d '\r' < "$1" > "$1".nocr will not work on a text mounted systems because the \r will be reintroduced on writing. However scripts such as #!/bin/sh # Remove \r from the file given as argument tr -d '\r' | gzip | gunzip > "$1".nocr work fine. In the first case (assuming the pipes are binary) we rely on gunzip to set its output to binary mode, possibly overriding the mode used by the shell. was all it took to convince me this was probably a fool's errand. I wound up fixing our software so it would build on a binary mount, which I decided was a much more sane solution. -bcd -
Yeah, it looks quite crazy. I started to search for an option that would force the shell to provide redirection in binary mode, overriding the standard rules. I found the igncr option [1], which is not what I need. But apparently there have been some efforts to deal with line endings in bash beyond the cygwin standard rules. Maybe there's a useful option that I haven't found yet. Well, our software already builds and I was not even aware that there is a problem with git on cygwin until I asked more people to test it. I naively chose the default option because I didn't have a reason to do otherwise. But apparently there is an option, and people use this option. My fear is that the first impression of git is too bad on Windows if it can't handle textmode. I can't recommend it. People will make me responsible for recommending them a tool that only cause troubles or forces them to reconfigure their cygwin, which worked for them for years. I even remember that we had a policy to explicitly set cygwin to textmode to avoid problems with cvs commits in combination with Visual Studio 6. Steffen -
Hopefully fopen() would not barf upon seeing "b", and O_BINARY can be ifdefed to 0 on platforms where it is not applicable and or'ed in to the flags. As long as they can be proven to be useful on Cygwin, I do not see an issue. -
According to http://www.cygwin.com/faq/faq.api.html#faq.api.cr-lf adding those flags should be okay: "Note that because the open/fopen switches are defined by ANSI, they exist under most flavors of Unix; open/fopen will just ignore the switch since they have no meaning to UNIX." -- Sebastian Schuberth -
Call it passively deprecated. there has been a lot of discussion about removing it, or at least hiding it behind the mount command and not offering it at all during installation. The objective of text mounts was noble, but it really is hard to automatically convert any occurrence of crlf->lf and lf->crlf everywhere it should be done but not where it should not be done. However, a lot of people use text mounts without trouble (or at least without complaining to the lists), so removing the option outright was thought too likely to cause an uproar. So, consider that Cygwin is taking the "let it rot, remove it later" approach. Anyone who has troubles is generally and not so gently encouraged to just use binary mounts. There are some known crlf problems, largely with bash/sh, pipes, forks, and redirection (of which git is a heavy user so git is a prime candidate to get into trouble) that are not being worked. For instance, when working on git-bundle.sh, I got bit by crlf conversions corrupting packfiles sent through a pipe on a system with pure binary mounts and CYGWIN=binmode. The cure to that bug is *removing* auto-crlf conversion from Cygwin. Mark -
That is what I'm facing now. A policy I need to handle tells people explicitly to choose textmode to force cvs in cygwin to do the right thing: converting lf->crlf->lf. I'm not in a position to tell them not to follow this policy; and I don't think it's reasonable to change the policy right away. They have a lot of cvs working copies checked out and if they switched from textmode to binmode now, they'd get crlf's on the next commit, which they deliberately chose to avoid by using This may take years. For me it would be easier if Cygwin (not I) told the world very clearly: You must no longer use binary mounts. Consider switching now, but you must switch until end of 2007. This would make my life much more easier. I could tell that it's not my fault and not git's fault, it's Cygwins decision to drop support for textmode. People might complain but I think they would understand. Providing an option and letting people install software that is not able to handle this option causes nothing but trouble. The very least would be to only allow installing software that is known to handle textmode. Or provide another mode that guarantees that no conversion takes place and offers a larger Technically I agree. The problem is, textmode is not removed, but appears as if it was supported (see installer). I'm running out of options: git in cygwin appeared to work for me, but it's not working in the context of the organization that I need to deal with. I can't force them to switch to binary mode. Other approaches to git on Windows are on their way, but, to my understanding, are not mature enough. git-cvsserver doesn't provide sufficient cvs functionality to be compatible with the needed workflows. The bottom line for me is, git does not yet support Windows in a usable way for the organizations that I need to convince. Steffen -
Have you considered jumping in to help on the msys git port Johannes Schindelin is working? He has very generously offered to do essentially everything except find bugs, the latter because he does not actually use Windows so can't, and is clearly putting a great deal of effort into this. A stable and complete Windows port may be much closer than you think. Mark -
Hi, To be fair, we are already a team of five working on it. The 3rd generation of the net installer works as flawlessly as the first, but msysgit.git is a superproject now, containing the complete build environment you need, and has git/mingw/4msysgit.git as a submodule (yes, that is a fork of a fork; they work now on repo.or.cz). Please find it on http://msysgit.googlecode.com/ (It's a meager 1.4 MB, so the whole rest is git-cloned natively!) It already passes all tests, is able to start gitk and git-gui, and more is to come! And no, I did not agree to do _everything_. I agreed to do things _when I get something in return_. For example, we have a functional script sitting in msysgit.git which builds a complete WinGit installer (WinGit being the code name for "Git on MSys without the whole build environment"). It is incomplete in only a few issues: - it does not install anything in the start menu - it does not install any short cut on the Desktop - it does not install anything in the Quick Launch bar - it does not include a nice WelcomeToGit.html, to be launched after a successful install - it does not contain a nice way to start git-gui (you have to start it by hand from the command line inside bash) - etc. So go for it, everybody, or alternatively do not even bother to whine. Ciao, Dscho P.S.: I'll be not really available for a few days, starting from tomorrow, so do use the mailing list to keep in touch with others working on msysgit or 4msysgit, and do use the mob branch (you can bug the project members listed on the homepage to cherry-pick, sign off and push if need be). -
I'll look into it. However, my situation is similar to Johannes'. I do not regularly work on Windows. I use my Mac for all office work and typically code on Linux. However, I do use Windows from time to time because the majority of the people I work with use Windows. I have a real Windows running in a Virtual Machine and I consider switching to it for a while, to see if things run smoothly. Here is what I plan to do: I will set cygwin to textmode (!), although I know better. But this is what most of the people I work with have. I'll uninstall cygwin's git and install msysgit instead. I'll try to do all the integration work, that is import from cvs on Linux, pull to Windows and do coding and merges on Windows. I'll push back to Linux and Mac for testing. After the basic stuff, like pull, push, merge, commit, gitk, and git gui, here's my first more difficult task: Will git-mergetool launch something useful for me on Windows? I heard that WinDiff I read this before. At the time you wrote about this on the mailing list I thought that cygwin would be fine. I wasn't aware of the binmode/ textmode I don't care about these things. I typically start the Explorer by typing explorer into the 'Run ...' box of the start meny. So don't expect anything from me that makes git more beautiful. The only thing I want to achieve is a flawlessly running git that works out-of-the box in the presence of a cygwin in textmode (!). If possible git should have the same version number that I have on Linux and Mac, which means the master branch of Junio's repo on my Mac. Lagging a bit behind for a while is ok, but in general I'd prefer to have the same version on Linux, Mac, and Windows. What I described means Windows support ok. I'll be available for one more week and will then be offline for three weeks. Steffen -
Here we go... I tried GitMe-3.exe.
I have two 'crashes' during installation. I attached snapshots
of the requesters. I don't know how to copy text from the
installer. Therefore I attached snapshots.
As mentioned before, I run in a virtual machine, Parallels to be exact.
I use my Windows installation rarely but I did not have any problems
with Windows in Parallels before.
Steffen
Hmm... how do I get started? I naively chose cygwin as my shell. I set export PATH=$PATH:/cygdrive/c/msysgit/bin then I tried $ git clone git://git.kernel.org/pub/scm/git/git.git c:/msysgit/bin/git-clone: line 214: git-init: command not found Maybe it's related to the errors during installation? How can I build and install git manually, based on the result of GitMe-3's basic setup? Steffen -
Let me guess, you have Cygwin on the path along with Msys, and had it that way when you downloaded the package and it tried to build. Hmmm. Maybe Cygwin executables conflict with Msys executables. Nah. Couldn't be. Must be a bug. Mark -
I don't think so. At least I did not actively do something to have Cygwin in my path. Steffen -
Ok, first, which system is this? Windows 2000/XP/Vista?
(The Gitme installer doesn't work on old ones for now)
Try running gitme from a terminal. Download gitme-3.exe into C:\temp,=20
open a native terminal (Start - Run - Type "cmd" <enter>); then in the=20
terminal, type:
C:\temp> set PATH=3D%WINDIR%\system32;%WINDIR%
C:\temp> gitme-3
Does it work then? If so, the problem is likely to be that you have=20
Cygwin in the system path, which is not advisable/compatible with MSys.
--=20
=2Emarius
I had cygwin at the tail of my PATH. After removing it the installation went through flawlessly. A check in the installer would be a good idea. Would you recommend running git only from the mingw shell prompt, or can I start it also from a Cygwin shell prompt? Thanks a lot, Steffen -
Well, some say that you can, but I'm not sure (especially since you're=20 using Cygwin in Windows EOL mode, which is opposite of MSys). The way I use it is either from the MSys shell, or directly from CMD=20 shell. (If you have PATH=3Dc:\msysgit\bin;C:\msysgit\mingw\bin;%PATH% it = works quite well like that.) Actually, I use CMD most of the time.. --=20 =2Emarius
Hi, And there I thought that you download GitMe-3.exe, and then double click on it... Ciao, Dscho -
Heh, yeah, normally that's indeed what you do. However, in this case I=20 asked him to start it from the terminal to make sure that it wasn't=20 affected by anything suspicious in his system PATH. Clearly having Cygwin in his path messed things up. --=20 =2Emarius
I think checking for a proper setup in the installer would be a good idea, like checking if 'cygpath' runs and if so, die with the request to cleanup the system PATH first. The problem was not too hard to solve, but the first impression was not optimal. Where would I have to look to add something like this? Steffen -
Hi, That's nice to hear. Finally somebody honest. I'll return the favour: I have no time to work on the bugs you sent in a reply. Ciao, Dscho -
That's fine. I don't expect anything, except for being honest about the level of Windows support that is currently available. In retrospect, I relied on the claim that git works in Cygwin without problems (not made by you but on the mailing list in general). This claim turns out to be wrong for me, because it highly depends on the details of how you configure your Cygwin, which makes it impossible to run git in Cygwin that is configured according to the 'wrong' policy. Any hint how I can start debugging? I saw mingw for the first time in my life, yesterday. I only worked with cygwin and various Visual Studio versions, before. [ btw, my point was that I'm mostly interested in getting the basic stuff going first. That is git with the same functionality that I have on Linux and Mac. The next would be a good integration with useful tools on Windows, for example git-mergetool should launch Windows three-way merge tools. The thing I'm least interested is a beautiful installer, which clutters my Desktop with icons, which I never use and need to cleanup later anyway. Bottom line: if you have points on your list that better fit the described priorities, there would be a good chance that I can look into one or two of them, for example Is anything needed to get mingw changes merged to the official repo? Is anything needed to get changes from the official repo to mingw? My goal would be to type 'make windist' in the official repo and get a very basic installer (maybe just a zip archive) that contains everything needed to run git on Windows. Unpacking this self-contained installer on a freshly installed Windows should get you going. There should be no need to install Cygwin or something else. Is this realistic? What is needed to get there? What would be an estimated timeframe to achieve this goal? Will all this run on Windows XP 64 bit and Windows Vista 64 bit? After I'm convinced that the level of support for Windows is sufficient, I will recommend using it, which means ...
How fast can you type? Why does it have to be the _official_ repo? Git have submodule support, so you could do a repo called "my_excellent_git_environment_for_windows.git" and have the official repo as submodule (msysgit is done this way). You could even start with cloning the TortoiseSVN repo using git. Or maybe even better, since KDE4 will compile on Windows [take on wood], do it as a kioslave (or whatever mechanism) to have an environment that works in both Windows and Linux and most OtherOs:es. Aiming for environments that works on several OSes is a good thing for future migrations. //Torgil -
I think both. I'm currently conducting a survey what the Windows users I'm working with are using. Up to now I have no idea what these tools do. Note, I'm not working on Windows. But I would like to see git starting the tools that users prefer to use. Git would just feel more like a useful Windows tool if it interacted with other useful Windows tools. Here is what I have on my list (not yet prioritized): - WinMerge (http://winmerge.org/) - Visual Comparer (http://www.nikeware.com/vc-features.htm) - Araxis Merge, http://www.araxis.com/merge/ (expensive!) - Beyond Compare, http://www.scootersoftware.com/file-comparison.php (will support 3-way with upcoming version 3; reasonable price) - KDiff3, http://kdiff3.sourceforge.net/ (comes with Windows- installer from SF) - ECMerge, http://www.elliecomputing.com/Products/merge_overview.asp (OSS developer can get a "Pro" license for free upon request) A complete list at I don't see your point. The question is if git runs flawlessly on 64 bit systems, which we use for development. I have no experience with mingw. Maybe there are some issues with 64 bit Windows, maybe The official repo would indicate a real commitment to me that Windows support if officially maintained. I agree that there may be more tools group around core git. But core git itself should be the master from the official repo. This seems to be a reasonable goal to me. At least that is what we do. The head must compile on all supported platforms I work for years now on cross platform code. I never needed a whole environment. I need Qt and the native development environment, like Visual Studio, gcc, Xcode. I don't need KDE on Windows, I don't need KDE on Mac. Everything's there already. Steffen -
Hi, It would be, if - more people had 64-bit platforms to run on, and - more people had Windows 64-bit. Both cost money, so I suggest just trying it for yourself if you are one of the few lucky ones being actually _able_ to test. I cannot speak for others, of course, but this is a freeloader mentality I do not want to support. If you want first class Windows support, you'll have to pay for that, methinks. And seeing all those less-than-even-lousy SCMs getting major financial contributions to support their mediocrity, I do not see a reason to get small amounts from private people, but rather substantial money-flow from big companies. Git is an excellent tool. If people want it badly enough, they should do Guess why mingw.git is called a "fork"? It is _not good enough_ yet to be included. Not necessarily function-wise, but definitely code-wise. We have quite strict coding rules, being an Open Source project where everybody can see your mess, should there be one. It has _never_ been the plan to maintain mingw.git independently for eternity. But the progress has been slow, and the _only_ reason that there was any progress _at all_ was that Hannes stepped up, and did some actual work instead of talking. So yes, mingw.git's target destination is git.git. Ciao, Dscho -
I'll try. I only asked if there is any experience on this. I didn't You may have noticed that I'm willing to put some time into it. I can't offer money. Time should be fine, too as you state on msysgit's homepage "Testing and reporting bugs is really already a big help. Of course, it is even better if you get involved, for example by hacking on mingw.git." That is what I'm doing. You get bug reports and you get patches. I don't understand your point about freeloader mentality. In the long run it's just easier to keep functionality in sync if it is maintained in a single repo, and this is what Well and here, again, is my point of one single repo that officially supports Windows. If the official support is part of the 'quite strict coding' rules then I'm more convinced that Windows is supported with appropriate quality. This is the point I want to make. Good to hear. Again, I prefer to put work into pushing the merge with git.git forward, than putting work into any fancy gui stuff, as you proposed recently. So if there's a list of todos that hinder a merge back to git.git, I'd happy to learn about it. Steffen -
I agree it's reasonable questions. My point is that to get something, you have to be active (and you're a prime example of that I think). Quoted from http://git.or.cz/ : "Traditionally, the low-level part of Git is called plumbing and the interfaces and frontends are called porcelains. Git itself comes with a default porcelain bundled and that is actually what you will normally mean when you say you use Git." What do you include in the "make windist" installer and the "Windows Good thing you're flexible and have a broad experience. Not everyone out there has that and it can be tricky to try to lure those people away from 10yrs habits. //Torgil -
I hope to have an improved list on monday, sorted by priority of the developers I'm working with. I thought I do some coding, to find out a bit more about the stability of msysgit. So I started and added support for kdiff3 on Windows (see patches in separate mail). I'm impressed. Pretty much everything I tried today worked for me. After I got git gui running, and learned how to avoid pitfalls of git submodule, development went smoothly. I pushed and pulled a bit from linux and mac and did some coding. Thanks for the vim setup! I think you (and more people I don't yet know) did a great job with msysgit. I'd recommend it over cygwin's git, which caused some trouble for me. Hard to say. I believe now, from what I learned today, that the msysgit approach is quite reasonable: Grouping all needed unix tools around a submodule containing git. But the submodule should be git.git. I think this is what I'd expect. I like the idea of bringing everything needed along, and keeping it separate from the rest of the system. This avoids conflicts with, for example, cygwin. I don't think I would expect much more for a basic setup. All tests should run, maybe some msysgit tests would be needed to test the pitfalls we'll discover; maybe not. I'll test XP 64 bit and Vista 64 bit beginning of next week. Getting started hacking msysgit could be a bit easier. I didn't like the submodule problems I ran into and I still didn't find out how to push to the git mob branch. For me a next step would be do some polishing. For example tune git to integrate with other Windows tools, like what I proposed for git-mergetool. I really started to love git when it launched a graphical mergetool automatically for me. After that point I never edited merge markers again. Things I needed too much time before are now running so smoothly. I think such a tight integration is really useful to convince people. I'd also expect default choices to be reasonable. I'm not yet 100% sure, but my feeling it ...
Hi, It is _all_ compatibility stuff. Basically, it all boils down to grabbing a specific part of the diff related to a certain concept (such as NO_IPV6), and whip the patch (series) into shape. Submit it to git.git. Work on it until it is part of the official distribution. Continue with the next part of the diff. Ciao, Dscho -
neat.The hardest part for me was to find out that I didn't have to configure anything or add a command line option to get kdiff3 running. (I cheated looking in the source, I think we should add #ifdef __MINGW32__ / #endif around the registry reading part. Thanks. I'm as fresh as you in msysgit development but it is quite straightforward. I've fiddled around with cygwin/msys before but now I I'm lacking several things. Many usability-glitches, some bugs, easy access to documentation. Also we want to integrate the mingw git parts This is weird. I haven't had such problems with this (dirty submodule in working dir), but that probably is because the supermodule doesn't depend on files in the submodule [submodule "make install" copies files to the supermodule]. Otherwise we should be more dependent on a clean submodule state. I would though expect a "git reset --hard" to Yeah. there's plenty of stuff to do. You could add this stuff to the issue tracker Dimitry has initiated. //Torgil -
What does __MINGW32__ mean for shell code? The registry reading
should just be ignored if registry access 'reg.exe' is not available.
However, the code was not yet robust. I pushed the patch below to
4msysgit.git's mob.
Steffen
commit 816f61fecd9e90879afcbad9234f19bf6d982b76
Author: Johannes Schmidt-Ehrenberg <schmidt-ehrenberg@zib.de>
Date: Mon Aug 13 19:00:39 2007 +0200
mergetool: fixed parsing of registry entry for kdiff3
The old code failed on Windows Vista. The output of
reg.exe or something else may be a bit different.
This patch improves the parsing code to be more robust.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
-
I seem to remember that you can't rely on reg.exe being available on Windows. The Microsoft support pages talk about using regedit.exe instead (which is quite more cumbersome). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -
I successfully ran it on at least Windows XP and Vista. On Vista, it was present on a quite fresh system (Visual Studio not yet installed). So I'm quite confident that it's likely to be there. Do you have a reference? I searched msdn and was not able to immediately find the recommendation you're referring to. Steffen -
<http://www.microsoft.com/technet/prodtechnol/Windows2000serv/support/FAQW2KCP.mspx>
Q. What other tools are available for using the registry in batch?
A.
If you install the Support Tools from the Windows 2000 CD-ROM, you
can use REG.EXE to Add, Delete, Copy, Compare, Export, Import,
Load a Hive, Query, Save, Restore, and Unload a Hive. To install
the Support Tools:
1.
Insert the Windows 2000 CD-ROM into your CD-ROM drive.
2.
Click Browse this CD, and then open the Support\Tools folder.
3.
Double-click Setup.exe, and follow the on-screen instructions.
That does not sound like one could rely on its presence out of the
box, at least on Windows 2000.
--
David Kastrup
-
If you follow the Cygwin mailing lists, you'll find that the developers *really* want to kill off the whole text mount thing: ultimately, this has proved unsupportable as it requires deep modifications of every tool "ported" over to Cygwin and invariably leads to strange bugs as you have just discovered. Originally, Cygwin had the goal of porting Unix tools to Windows, requiring that every tool work on text mounts, but they restated their goal as providing a POSIX environment under Windows that matches what Linux does. So, I doubt you'll get support from the Cygwin developer's or the Cygwin git maintainer for a text mount aware version of git. Clearly, the mingw port has to deal with these issues, and it might be possible to leverage that work for Cygwin, but the flip side is that under POSIX, git explicitly recognizes the difference between \0d\0a and \0a while on a text mount, programs do not, and this would make such a ported git violate the currently stated Cygwin goals. Mark -
