www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - There's new GIT instructions on Github now

reply Andrej Mitrovic <none none.none> writes:
I'm not sure when these came out, but the last time I've tried using git and
github the instructions were a little bit messed up (i.e. windows instructions
mixed up with linux instructions) and I couldn't really get anything to work
back then. But they've made new ones, with screenshots and the works:

http://help.github.com/win-set-up-git/

I've finally managed to make a pull and a push, yay! I'm still trying to figure
out an alternative to ssh-agent, since that is unavailable on Windows.
Otherwise I'll have to copy/paste the pass all the time or just use a
passwordless key (eh, it's not like I'll be storing sensitive information on
github..).

Time for me to check my bug reports and see if there's anything to commit. :Þ
May 19 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <none none.none> wrote in message 
news:ir43p5$21q7$1 digitalmars.com...

 I'm not sure when these came out, but the last time I've tried using git 
 and github the instructions were a little bit messed up (i.e. windows 
 instructions mixed up with linux instructions) and I couldn't really get 
 anything to work back then. But they've made new ones, with screenshots 
 and the works:

 http://help.github.com/win-set-up-git/

 I've finally managed to make a pull and a push, yay! I'm still trying to 
 figure out an alternative to ssh-agent, since that is unavailable on 
 Windows. Otherwise I'll have to copy/paste the pass all the time or just 
 use a passwordless key (eh, it's not like I'll be storing sensitive 
 information on github..).


I came across some instructions somewhere that involved using something 
called Pageant, and it's working for me. Basically, I gave Pageant the keys, 
set Pageant to load at startup and it sits there in the background handing 
all that git ssh stuff for me. I don't have a clue what any of the details 
were, though. Can't remember. I did install TortoiseGit, too, I don't know 
if that might have something to do with it...  With a brief googling, this 
*might* be it, but I'm not sure: 
http://stackoverflow.com/questions/3625148/how-do-i-store-a-password-for-my-key-so-i-can-commit-and-pull-from-repository-whe

God I fucking hate broken documentation and half-assed windows ports (which 
Git clearly is)...

Now if only the Dulwich people would quit pretending this was a minor issue: 
https://bugs.launchpad.net/dulwich/+bug/670035   ...Then I'd actually be 
able to start using hg-git/TortoiseHg instead of putting up with the 
convoluted mess that git is...(Rebase? Seriously?!)
May 19 2011
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 19/05/2011 23:45, Nick Sabalausky wrote:

 Now if only the Dulwich people would quit pretending this was a minor issue:
 https://bugs.launchpad.net/dulwich/+bug/670035   ...Then I'd actually be
 able to start using hg-git/TortoiseHg instead of putting up with the
 convoluted mess that git is...(Rebase? Seriously?!)


Mercurial has rebase too, just as an extension. Rebase is incredibly 
useful if you want to avoid having hundreds of "Merge from revision ..." 
commits everywhere. Of course, if you rebase commits that other people 
have already pulled you're gonna mess things up, but for local changes 
it's fine.

-- 
Robert
http://octarineparrot.com/
May 19 2011
parent Trass3r <un known.com> writes:
Am 20.05.2011, 01:14 Uhr, schrieb Robert Clipsham  
<robert octarineparrot.com>:

 Mercurial has rebase too, just as an extension. Rebase is incredibly  
 useful if you want to avoid having hundreds of "Merge from revision ..."  
 commits everywhere. Of course, if you rebase commits that other people  
 have already pulled you're gonna mess things up, but for local changes  
 it's fine.


Yeah, unfortunately most people don't even seem to know about rebase.
May 19 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ir46pp$26h7$1 digitalmars.com...

 Now if only the Dulwich people would quit pretending this was a minor 
 issue: https://bugs.launchpad.net/dulwich/+bug/670035   ...Then I'd 
 actually be able to start using hg-git/TortoiseHg instead of putting up 
 with the convoluted mess that git is...


Heh, I just noticed that the guy who keeps insisting that a breaking bug on 
Windows is of "medium" importance is employed by Canonical. Can you say, 
"conflict of interest"? Fucking politics.
May 19 2011
parent reply Kagamin <spam here.lot> writes:
Nick Sabalausky Wrote:


 "Nick Sabalausky" <a a.a> wrote in message 
 news:ir46pp$26h7$1 digitalmars.com...

 Now if only the Dulwich people would quit pretending this was a minor 
 issue: https://bugs.launchpad.net/dulwich/+bug/670035   ...Then I'd 
 actually be able to start using hg-git/TortoiseHg instead of putting up 
 with the convoluted mess that git is...


 
 Heh, I just noticed that the guy who keeps insisting that a breaking bug on 
 Windows is of "medium" importance is employed by Canonical. Can you say, 
 "conflict of interest"? Fucking politics.


What politics? If there's less interoperability between linux and windows, this
hinders adoption of linux.
May 20 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Kagamin" <spam here.lot> wrote in message 
news:ir5q27$1par$1 digitalmars.com...

 Nick Sabalausky Wrote:


 "Nick Sabalausky" <a a.a> wrote in message
 news:ir46pp$26h7$1 digitalmars.com...

 Now if only the Dulwich people would quit pretending this was a minor
 issue: https://bugs.launchpad.net/dulwich/+bug/670035   ...Then I'd
 actually be able to start using hg-git/TortoiseHg instead of putting up
 with the convoluted mess that git is...


 Heh, I just noticed that the guy who keeps insisting that a breaking bug 
 on
 Windows is of "medium" importance is employed by Canonical. Can you say,
 "conflict of interest"? Fucking politics.


 What politics? If there's less interoperability between linux and windows, 
 this hinders adoption of linux.


If XYZ works on Ubuntu/Linux and not on Windows, that benefits Ubuntu/Linux, 
not Windows. "If you need XYZ, then you'll just have to use ABC" That's 
called "exclusivity" and corporations have always tried to use it to 
gain/keep customers. And even aside from such overt tactics, it could still 
just be a matter of "This company's product is Ubuntu/Linux, so we're only 
mildy interested in putting any effort into Windows issues." (In fact, I do 
think the later is far more likely.)
May 20 2011
parent Kagamin <spam here.lot> writes:
Nick Sabalausky Wrote:


 What politics? If there's less interoperability between linux and windows, 
 this hinders adoption of linux.


 
 If XYZ works on Ubuntu/Linux and not on Windows, that benefits Ubuntu/Linux, 
 not Windows. "If you need XYZ, then you'll just have to use ABC" That's 
 called "exclusivity" and corporations have always tried to use it to 
 gain/keep customers.


The question is WHAT works on linux. From windows user perspective XYZ is just
a piece of crap. Who would want to do anything to look at a working piece of
crap?


 And even aside from such overt tactics, it could still 
 just be a matter of "This company's product is Ubuntu/Linux, so we're only 
 mildy interested in putting any effort into Windows issues." (In fact, I do 
 think the later is far more likely.)


That's a resource management. Because no windows user uses their piece of crap,
the target audience becomes exclusively linux users. Of course linux users
support will get higher priority provided absence of windows users.
May 23 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-05-20 00:45, Nick Sabalausky wrote:

 "Andrej Mitrovic"<none none.none>  wrote in message
 news:ir43p5$21q7$1 digitalmars.com...

 I'm not sure when these came out, but the last time I've tried using git
 and github the instructions were a little bit messed up (i.e. windows
 instructions mixed up with linux instructions) and I couldn't really get
 anything to work back then. But they've made new ones, with screenshots
 and the works:

 http://help.github.com/win-set-up-git/

 I've finally managed to make a pull and a push, yay! I'm still trying to
 figure out an alternative to ssh-agent, since that is unavailable on
 Windows. Otherwise I'll have to copy/paste the pass all the time or just
 use a passwordless key (eh, it's not like I'll be storing sensitive
 information on github..).


 I came across some instructions somewhere that involved using something
 called Pageant, and it's working for me. Basically, I gave Pageant the keys,
 set Pageant to load at startup and it sits there in the background handing
 all that git ssh stuff for me. I don't have a clue what any of the details
 were, though. Can't remember. I did install TortoiseGit, too, I don't know
 if that might have something to do with it...  With a brief googling, this
 *might* be it, but I'm not sure:
 http://stackoverflow.com/questions/3625148/how-do-i-store-a-password-for-my-key-so-i-can-commit-and-pull-from-repository-whe

 God I fucking hate broken documentation and half-assed windows ports (which
 Git clearly is)...

 Now if only the Dulwich people would quit pretending this was a minor issue:
 https://bugs.launchpad.net/dulwich/+bug/670035   ...Then I'd actually be
 able to start using hg-git/TortoiseHg instead of putting up with the
 convoluted mess that git is...(Rebase? Seriously?!)


If it's possible, I would recommend using git via Linux, Mac OS X or 
similar. If you have access to a Linux computer you can use SSH and SSHFS.

-- 
/Jacob Carlborg
May 19 2011
prev sibling parent reply Don <nospam nospam.com> writes:
Nick Sabalausky wrote:

 "Andrej Mitrovic" <none none.none> wrote in message 
 news:ir43p5$21q7$1 digitalmars.com...

 I'm not sure when these came out, but the last time I've tried using git 
 and github the instructions were a little bit messed up (i.e. windows 
 instructions mixed up with linux instructions) and I couldn't really get 
 anything to work back then. But they've made new ones, with screenshots 
 and the works:

 http://help.github.com/win-set-up-git/

 I've finally managed to make a pull and a push, yay! I'm still trying to 
 figure out an alternative to ssh-agent, since that is unavailable on 
 Windows. Otherwise I'll have to copy/paste the pass all the time or just 
 use a passwordless key (eh, it's not like I'll be storing sensitive 
 information on github..).


 
 I came across some instructions somewhere that involved using something 
 called Pageant, and it's working for me. Basically, I gave Pageant the keys, 
 set Pageant to load at startup and it sits there in the background handing 
 all that git ssh stuff for me. I don't have a clue what any of the details 
 were, though. Can't remember. I did install TortoiseGit, too, I don't know 
 if that might have something to do with it...  With a brief googling, this 
 *might* be it, but I'm not sure: 
 http://stackoverflow.com/questions/3625148/how-do-i-store-a-password-for-my-key-so-i-can-commit-and-pull-from-repository-whe
 
 God I fucking hate broken documentation and half-assed windows ports (which 
 Git clearly is)...


Here's my list of bugs in git for windows which I found in the first 
fews days of using it:

1. Windows git's handling of paths is completely screwed.
If you've checked out your working copy into (say) c:\foo\bar\dmd
and you rename a parent directory, eg to c:\foo2\bar\dmd, your working 
copy gets hosed.
Maybe this happens only after you've performed a git operation; didn't 
experiment with it much.
2. It does something really horrible with the idea of your 'home' 
directory. I'm not sure exactly what it does, but it seems to equate 'My 
Documents' with $HOME. If ActiveDirectory is in use,
you can end up with more than one $HOME. I've also had it suddenly think 
that my home directory lies on a file server. This corrupts your 
configuration file, and you lose your public keys.
3. The 'gittutorial' is ridiculous and insulting. In the first two 
minutes of using git, you already need to know far more commands than 
are included in the tutorial. Most obviously, it should talk about 
git-reset before discussing branching and collaboration.
4. If a large number of files have been changed in a single commit, gitk 
can pop up a message box that is larger than your full screen -- so the 
'OK' button is not visible!
5. TortoiseGit has a manual which is full of references to Subversion. 
You cannot trust anything you read in that manual. I quickly gave up any 
attempts to use TortoiseGit.
6. Git bash and/or vim is very amateurish. Eg, pressing cursor keys when 
you're at the start of a line causes the screen to flash.
7. In git diff, using scroll bars to view an earlier part of the screen, 
then pressing a key corrupts the bash screen.
8. Git diff's highlighting is wrong when a modified line is longer than 
80 characters long.

You've really got to be a fanboy to claim that git is supported on 
Windows. Sure, it "works" -- in the same way that hammering a nail with 
a rock "works".
May 20 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Fri, 20 May 2011 10:33:31 +0300, Don <nospam nospam.com> wrote:


 You've really got to be a fanboy to claim that git is supported on  
 Windows. Sure, it "works" -- in the same way that hammering a nail with  
 a rock "works".


You've mentioned some fairly untypical usage, so it's not surprising you  
ran into so many problems. Why would you want to use the interactive bash  
shell?

I found that all git commands work fine from CMD. The only reason to use  
bash that I can think of is to allow copy-pasting commands with parameters  
quoted/escaped in a way incompatible to CMD. I'm not sure how vim fits the  
toolchain at all, I think it's just provided as a bonus in msysgit. If you  
need a proper *nix-like environment on Windows, have you looked at Cygwin?  
For a long while, Cygwin was the only supported way to run git on Windows.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 20 2011
next sibling parent Kagamin <spam here.lot> writes:
Vladimir Panteleev Wrote:


 I found that all git commands work fine from CMD.


I wonder, whether stock portablegit has useless bonuses.
May 20 2011
prev sibling parent reply Don <nospam nospam.com> writes:
Vladimir Panteleev wrote:

 On Fri, 20 May 2011 10:33:31 +0300, Don <nospam nospam.com> wrote:
 

 You've really got to be a fanboy to claim that git is supported on 
 Windows. Sure, it "works" -- in the same way that hammering a nail 
 with a rock "works".


 
 You've mentioned some fairly untypical usage,


Huh????


 so it's not surprising you 
 ran into so many problems. Why would you want to use the interactive 
 bash shell?


Because it has slightly fewer bugs than the other alternatives.


 I found that all git commands work fine from CMD. 


Not in my experience. Initially I tried that, but I *immediately* 

I've just tried again:

C:\sandbox\dmd>git fetch walter
remote: Counting objects: 23, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 14 (delta 11), reused 0 (delta 0)
Unpacking objects: 100% (14/14), done.
 From git://github.com/D-Programming-Language/dmd
    afd1728..50de957  dmd-1.x    -> walter/dmd-1.x
    145d753..eb38e18  master     -> walter/master

C:\sandbox\dmd>git status
ignoring REUC extension


....<etc, this bit works OK>


nothing added to commit but untracked files present (use "git add" to track)

C:\sandbox\dmd>git status
error: bad index file sha1 signature
fatal: index file corrupt

Words fail me...



 The only reason to use 
 bash that I can think of is to allow copy-pasting commands with 
 parameters quoted/escaped in a way incompatible to CMD. I'm not sure how 
 vim fits the toolchain at all, I think it's just provided as a bonus in 
 msysgit. If you need a proper *nix-like environment on Windows, have you 
 looked at Cygwin? For a long while, Cygwin was the only supported way to 
 run git on Windows.


Sorry, but your reply is a textbook example of fanboyism. On Windows, 
git is an utterly lousy product. And yes, I have both cygwin and Msys.
May 20 2011
next sibling parent David Nadlinger <see klickverbot.at> writes:
On 5/20/11 4:52 PM, Don wrote:

 C:\sandbox\dmd>git status
 ignoring REUC extension


Are you maybe using an older Git version from the regular command line?

David
May 20 2011
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Fri, 20 May 2011 17:52:53 +0300, Don <nospam nospam.com> wrote:


 Vladimir Panteleev wrote:

 On Fri, 20 May 2011 10:33:31 +0300, Don <nospam nospam.com> wrote:


 You've really got to be a fanboy to claim that git is supported on  
 Windows. Sure, it "works" -- in the same way that hammering a nail  
 with a rock "works".


  You've mentioned some fairly untypical usage,


 Huh????


You wouldn't consider using msysgit's bash shell and utilities on an AD  
computer "untypical"?

I believe the typical usage of msysgit is:
1) Using the GUI utilities in combination with Git-Cheetah
2) Using git from the Windows command line via the git.cmd wrapper


 so it's not surprising you ran into so many problems. Why would you  
 want to use the interactive bash shell?


 Because it has slightly fewer bugs than the other alternatives.



They might not exist in, for example, cygwin.


 fatal: index file corrupt

 Words fail me...


Don't you think that a common data corruption problem would get a lot more  
attention, given the number of Windows git users?

Can you describe a way for me to reproduce it? I'm genuinely curious.


 The only reason to use bash that I can think of is to allow  
 copy-pasting commands with parameters quoted/escaped in a way  
 incompatible to CMD. I'm not sure how vim fits the toolchain at all, I  
 think it's just provided as a bonus in msysgit. If you need a proper  
 *nix-like environment on Windows, have you looked at Cygwin? For a long  
 while, Cygwin was the only supported way to run git on Windows.


 Sorry, but your reply is a textbook example of fanboyism. On Windows,  
 git is an utterly lousy product. And yes, I have both cygwin and Msys.


Hm, are we pointing fingers now? :/
This is your post: "I tried X and it sucked! Therefore, anyone who says  
that X doesn't suck MUST be a fanboy, number of world-wide happy X users  
be damned."
"textbook example of fanboyism" seems to have become a textbook reply to  
anyone trying to argue with a rant.

All I'm saying is that the problems you're encountering are not typical,  
and I'm wondering if it might be caused by your approach at using Git. I'm  
not arguing that Git is perfect or as polished on Windows as, e.g.,  
Mercurial.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 20 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.vvsd4ef3tuzx1w cybershadow.mshome.net...

 On Fri, 20 May 2011 17:52:53 +0300, Don <nospam nospam.com> wrote:


 Vladimir Panteleev wrote:

 On Fri, 20 May 2011 10:33:31 +0300, Don <nospam nospam.com> wrote:


 You've really got to be a fanboy to claim that git is supported on 
 Windows. Sure, it "works" -- in the same way that hammering a nail 
 with a rock "works".


  You've mentioned some fairly untypical usage,


 Huh????


 You wouldn't consider using msysgit's bash shell and utilities on an AD 
 computer "untypical"?


Half of github's "setting up on windows" instructions ( 
http://help.github.com/win-set-up-git/ ) use Git bash. Sounds like it's 
*expected* to be typical usage. That fact that it's even there at all 
strongly suggests the Git developers feel that it will be needed.



 I believe the typical usage of msysgit is:
 1) Using the GUI utilities in combination with Git-Cheetah
 2) Using git from the Windows command line via the git.cmd wrapper


 so it's not surprising you ran into so many problems. Why would you 
 want to use the interactive bash shell?


 Because it has slightly fewer bugs than the other alternatives.



 They might not exist in, for example, cygwin.


And yet Git still chooses to rely on msys for operation on Windows, despite 
msys's problems.

If I were to release a Windows program and then package it up together with 
Wine and claim I've made a Linux version, too: that would be total BS. It 
*wouldn't* be a Linux version. At best it could be considered a half-assed 
attempt, and naturally it would have problems. And I very much doubt Linux 
users would put up it it being considered a real Linux version. But that's 
*exactly* what Git on Windows is, as well as all software that relies on 
msys, mingw or cygwin for so-called "windows support". Except that, in my 
experience, wine works far better than msys, mingw and cygwin.
May 20 2011
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Fri, 20 May 2011 23:12:54 +0300, Nick Sabalausky <a a.a> wrote:


 "Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message
 news:op.vvsd4ef3tuzx1w cybershadow.mshome.net...

 On Fri, 20 May 2011 17:52:53 +0300, Don <nospam nospam.com> wrote:


 Vladimir Panteleev wrote:

 On Fri, 20 May 2011 10:33:31 +0300, Don <nospam nospam.com> wrote:


 You've really got to be a fanboy to claim that git is supported on
 Windows. Sure, it "works" -- in the same way that hammering a nail
 with a rock "works".


  You've mentioned some fairly untypical usage,


 Huh????


 You wouldn't consider using msysgit's bash shell and utilities on an AD
 computer "untypical"?


 Half of github's "setting up on windows" instructions (
 http://help.github.com/win-set-up-git/ ) use Git bash. Sounds like it's
 *expected* to be typical usage. That fact that it's even there at all
 strongly suggests the Git developers feel that it will be needed.


Good point (one can argue why Github chose to instruct users to use bash),  
but what about vim and the rest of the suite?


 I believe the typical usage of msysgit is:
 1) Using the GUI utilities in combination with Git-Cheetah
 2) Using git from the Windows command line via the git.cmd wrapper


 so it's not surprising you ran into so many problems. Why would you
 want to use the interactive bash shell?


 Because it has slightly fewer bugs than the other alternatives.



 They might not exist in, for example, cygwin.


 And yet Git still chooses to rely on msys for operation on Windows,  
 despite
 msys's problems.

 If I were to release a Windows program and then package it up together  
 with
 Wine and claim I've made a Linux version, too: that would be total BS. It
 *wouldn't* be a Linux version. At best it could be considered a  
 half-assed
 attempt, and naturally it would have problems. And I very much doubt  
 Linux
 users would put up it it being considered a real Linux version. But  
 that's
 *exactly* what Git on Windows is, as well as all software that relies on
 msys, mingw or cygwin for so-called "windows support". Except that, in my
 experience, wine works far better than msys, mingw and cygwin.


Yeah. It's a direct consequence of half of git being written in bash  
script. I believe there is some effort in the last few years to transition  
to a fully C implementation... I think there's actually a native Git DLL  
that shell extensions and IDEs can use now.

Anyway, I've done plenty of rebasing, branch-filtering, merging and  
rewriting and never needed the git bash prompt, so I think it's there as  
an option, and not because you're expected to use it.

Note that the msysgit network install requires using the msys prompt to  
update the git source repos and build/install git from source. That could  
explain why vim and other tools are included.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 20 2011
prev sibling parent reply Don <nospam nospam.com> writes:
Vladimir Panteleev wrote:

 On Fri, 20 May 2011 17:52:53 +0300, Don <nospam nospam.com> wrote:
 

 Vladimir Panteleev wrote:

 On Fri, 20 May 2011 10:33:31 +0300, Don <nospam nospam.com> wrote:


 You've really got to be a fanboy to claim that git is supported on 
 Windows. Sure, it "works" -- in the same way that hammering a nail 
 with a rock "works".


  You've mentioned some fairly untypical usage,


 Huh????


 
 You wouldn't consider using msysgit's bash shell and utilities on an AD 
 computer "untypical"?
 
 I believe the typical usage of msysgit is:
 1) Using the GUI utilities in combination with Git-Cheetah
 2) Using git from the Windows command line via the git.cmd wrapper
 

 so it's not surprising you ran into so many problems. Why would you 
 want to use the interactive bash shell?


 Because it has slightly fewer bugs than the other alternatives.


 

 They might not exist in, for example, cygwin.
 

 fatal: index file corrupt

 Words fail me...


 
 Don't you think that a common data corruption problem would get a lot 
 more attention, given the number of Windows git users?


Yeah, I would have thought so. I wouldn't expect to find the root cause 


http://code.google.com/p/msysgit/issues/detail?id=21
---
"To my horror my first attempt at using git on the PC was a total 
failure:  since I  was a cygwin guy I'd downloaded git for cygwin and 
after finding that it failed on even the simplest init db I got the 
comment from the lead developer that I should be using bin mode for my 
file systems, and text mode mounts simply weren't 'the way to
emulate linux on windows' and there was no point in even thinking about 
it! Aargh!

The cygwin git developer kindly hinted that there was a mingw/msys 
version of git, and so I find myself here in this forum."
----

 
 Can you describe a way for me to reproduce it? I'm genuinely curious.


I don't know exactly what causes it. It may have something to do with 
the fact that I have a symlink in my path. Here's the result of a quick 
google:
----
http://www.nishioka.com/blog/2008/01/source-control-with-git-and-cygwin.html

"If you use git on cygwin, you must be sure your disks are mounted 
binmode or your database will get corrupted!

I had all my disks but one mounted binmode, but I also had a symbolic 
link that ended up using that one textmode mount. This corrupted the 
index and I got:

error: bad index file sha1 signature
fatal: index file corrupt"

Still not fixed in cygwin in 2011.



 The only reason to use bash that I can think of is to allow 
 copy-pasting commands with parameters quoted/escaped in a way 
 incompatible to CMD. I'm not sure how vim fits the toolchain at all, 
 I think it's just provided as a bonus in msysgit. If you need a 
 proper *nix-like environment on Windows, have you looked at Cygwin? 
 For a long while, Cygwin was the only supported way to run git on 
 Windows.


 Sorry, but your reply is a textbook example of fanboyism. On Windows, 
 git is an utterly lousy product. And yes, I have both cygwin and Msys.


 
 Hm, are we pointing fingers now? :/
 This is your post: "I tried X and it sucked! Therefore, anyone who says 
 that X doesn't suck MUST be a fanboy, number of world-wide happy X users 
 be damned."
 "textbook example of fanboyism" seems to have become a textbook reply to 
 anyone trying to argue with a rant.


No, fanboyism is evidenced in dismissing a list of bugs. I think that 
was a darn good list.
May 20 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
What the duck has happened to this topic?

Ok anyway, I found out a few things:

I can change $HOME by adding this line into C:\Program
Files\Git\etc\profile file:
HOME="/d/dev/git/"

right *above* this line:
HOME="$(cd "$HOME" ; pwd)"

This was from someone's blogs post. And then if I want to start git
bash from a different initial directory I just change the git bash
shortcut "Start In" field to whatever directory.

Anyways I've made a bunch of commits to my forked repo of dpl.org, and
now have to figure out how to make a pull request. I haven't made any
branches or anything because I'm way too new to this.

I would also like to know how to uncommit a change which hasn't been
pushed yet. So if I locally do:
git add someFile.d
git commit -m "woops wrong comment"

I'd like to just uncommit that message. I couldn't find an easy way to
do this. Isn't this just hg revert on mercurial? I had to resort to
backing up the files and re-fetching from the repo because git kept
complaining about being "ahead" of changes. Damn complicated software
that needs a book to operate it. :]

Also I'd add the first time I tried using GIT GUI a few months ago it
froze and crashed when I tried to do a simple clone.
May 20 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/20/2011 3:05 PM, Andrej Mitrovic wrote:

 I would also like to know how to uncommit a change which hasn't been
 pushed yet. So if I locally do:
 git add someFile.d
 git commit -m "woops wrong comment"

 I'd like to just uncommit that message. I couldn't find an easy way to
 do this.


What I do is rm -rf the entire project directory, then re-clone it from github. 
Voila!

(Yes, I suck at git. But I like it anyway.)
May 21 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/11, Walter Bright <newshound2 digitalmars.com> wrote:

 On 5/20/2011 3:05 PM, Andrej Mitrovic wrote:

 I would also like to know how to uncommit a change which hasn't been
 pushed yet. So if I locally do:
 git add someFile.d
 git commit -m "woops wrong comment"

 I'd like to just uncommit that message. I couldn't find an easy way to
 do this.


 What I do is rm -rf the entire project directory, then re-clone it from
 github.
 Voila!

 (Yes, I suck at git. But I like it anyway.)


Turns out all I had to do after I commited was edit the file I messed
up, add it again and do a commit --amend:
git add fileThatsFixed.d
git commit --amend

And then I can edit the last commit message, and it replaces the
previous message.

No rebase shenanigans or whatever I was recommended.
May 22 2011
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 21 May 2011 01:05:56 +0300, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:


 I would also like to know how to uncommit a change which hasn't been
 pushed yet. So if I locally do:
 git add someFile.d
 git commit -m "woops wrong comment"

 I'd like to just uncommit that message. I couldn't find an easy way to
 do this.


git reset "HEAD^"

If you just want to edit the commit message of your last commit, use:

git commit -am "New message"


 Isn't this just hg revert on mercurial? I had to resort to
 backing up the files and re-fetching from the repo because git kept
 complaining about being "ahead" of changes. Damn complicated software
 that needs a book to operate it. :]

 Also I'd add the first time I tried using GIT GUI a few months ago it
 froze and crashed when I tried to do a simple clone.


I don't use git gui for cloning/pushing/etc., but it's really nice for  
reviewing and picking out your changes before committing.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 21 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/11, Vladimir Panteleev <vladimir thecybershadow.net> wrote:

 If you just want to edit the commit message of your last commit, use:

 git commit -am "New message"


Super. Thanks.
May 21 2011
prev sibling next sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 5/21/11 12:05 AM, Andrej Mitrovic wrote:

 I would also like to know how to uncommit a change which hasn't been
 pushed yet. So if I locally do:
 git add someFile.d
 git commit -m "woops wrong comment"


If you just want to modify the commit, e.g. because you made a typo in 
the message, forgot some files, etc., use »git commit --amend«:

git add someFilePreviouslyLeftOut.d
git commit --amend …

(This will obviously change an existing commit, don't do it if you have 
already pushed your changes somewhere else.)


To, entirely remove the, say, two last commits from history, but not 
modify the contents of the files in your working tree, use »git reset«:

git reset HEAD~2 (or HEAD^ for just one commit)



 I'd like to just uncommit that message. I couldn't find an easy way to
 do this. Isn't this just hg revert on mercurial?


Nope, hg revert checks out individual files from a recorded changeset 
(usually the last), much like »git checkout some/file«. If you want to 
remove the last two commits like above, say r1001 and 1002, you have to 
do something like this:

hg update -r1000
hg revert -all -r1002
hg strip --force 1001


David
May 21 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/11, David Nadlinger <see klickverbot.at> wrote:

 snip lots of awesome info


These are great, thanks. In fact, all of these tips deserve to be put
on a "contributing code via git" page on dwiki, which will have to be
made.
May 21 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 21 May 2011 14:58:55 +0300, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:


 On 5/21/11, David Nadlinger <see klickverbot.at> wrote:

 snip lots of awesome info


 These are great, thanks. In fact, all of these tips deserve to be put
 on a "contributing code via git" page on dwiki, which will have to be
 made.


How about this?

http://www.prowiki.org/wiki4d/wiki.cgi?PullRequest

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 21 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/11, Vladimir Panteleev <vladimir thecybershadow.net> wrote:

 How about this?

 http://www.prowiki.org/wiki4d/wiki.cgi?PullRequest


That's great.

We should link these from somewhere though as they're free-standing
pages that have to be search for to be found. Maybe a "Contributing to
D" section in one of the menus on the left (under About maybe?).
May 21 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Nevermind, it's already linked from
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel but I didn't
realize it.

On 5/21/11, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 On 5/21/11, Vladimir Panteleev <vladimir thecybershadow.net> wrote:

 How about this?

 http://www.prowiki.org/wiki4d/wiki.cgi?PullRequest


 That's great.

 We should link these from somewhere though as they're free-standing
 pages that have to be search for to be found. Maybe a "Contributing to
 D" section in one of the menus on the left (under About maybe?).
May 21 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Ok so apparently the reason why ~ would be added on delete is because
msysgit or something else (sh.exe?) thought the terminal was dead.
Something like that. Apparently a known bug, but you can add this into
~/.bashrc to fix it:
TERM=msys
May 21 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Well setting up the diff tool was a bitch. msysgit/git doesn't like
spaces no matter what is escaped. So I had to add the diff exe to PATH
and invoke it from a shell script, which itself is invoked by git.
Good thing I don't have to phone Linus home to invoke shell.exe to
invoke git to invoke a shell script to invoke diff.
May 21 2011
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 21 May 2011 18:24:31 +0300, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:


 Well setting up the diff tool was a bitch. msysgit/git doesn't like
 spaces no matter what is escaped. So I had to add the diff exe to PATH
 and invoke it from a shell script, which itself is invoked by git.
 Good thing I don't have to phone Linus home to invoke shell.exe to
 invoke git to invoke a shell script to invoke diff.


Do you mean a custom diff tool, or perhaps a merge tool? git comes with a  
"diff" command...

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 21 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
So I did "git log --stat" on one of my test repos to view my logs,
scrolled to the bottom via hitting enter until I saw an END marker. So
now how do I exit back to the prompt? Hitting enter or escape or break
doesn't work.

God I hate wasting time on these stupid usability issues.
May 21 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 21 May 2011 18:40:40 +0300, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:


 So I did "git log --stat" on one of my test repos to view my logs,
 scrolled to the bottom via hitting enter until I saw an END marker. So
 now how do I exit back to the prompt? Hitting enter or escape or break
 doesn't work.

 God I hate wasting time on these stupid usability issues.


Press q. Note that the component this relates to is "less", which is a  
standard *nix utility.

You can press h to view the utility's online help, as well.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 21 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/11, Vladimir Panteleev <vladimir thecybershadow.net> wrote:

 Press q. Note that the component this relates to is "less", which is a
 standard *nix utility.

 You can press h to view the utility's online help, as well.


Thanks.
May 21 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Yeah it comes with a diff command, I was trying to set up a custom one
actually. And I made it work so this is no longer a problem.
May 21 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
It was 'q'. I had to hit q. Well who would have thought.
May 21 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2011 8:44 AM, Andrej Mitrovic wrote:

 It was 'q'. I had to hit q. Well who would have thought.


I was reading an article about older folks having problems setting the alarm on 
an iphone. They simply didn't realize that one has to press the '+' to set the 
alarm.
May 21 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/11, Walter Bright <newshound2 digitalmars.com> wrote:

 On 5/21/2011 8:44 AM, Andrej Mitrovic wrote:

 It was 'q'. I had to hit q. Well who would have thought.


 I was reading an article about older folks having problems setting the alarm
 on
 an iphone. They simply didn't realize that one has to press the '+' to set
 the
 alarm.


I took a look at the man-page (btw. for those not in the know, it's
called a man page because linux is for MEN, DAMMIT!).

It basically simulates vim keybindings (or whatever app first came up
with JKL movement keys).

But there are graphical glitches and text seems to disappear when I
scroll through the text lines. LOL.
May 21 2011
prev sibling next sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Andrej Mitrovic wrote:


 Also I'd add the first time I tried using GIT GUI a few months ago it
 froze and crashed when I tried to do a simple clone.


I like git cola for gui. I has some nice features such as picking the lines 
from a file you want to stage for a commit.

http://cola.tuxfamily.org/
May 21 2011
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 21 May 2011 14:14:18 +0300, Lutger Blijdestijn  
<lutger.blijdestijn gmail.com> wrote:


 Andrej Mitrovic wrote:


 Also I'd add the first time I tried using GIT GUI a few months ago it
 froze and crashed when I tried to do a simple clone.


 I like git cola for gui. I has some nice features such as picking the  
 lines
 from a file you want to stage for a commit.


git gui can do that too (right-click on a line, select "stage line for  
commit").

A nice thing that git cola can do that git gui can't, is revert changes  
line-by-line, so you can easily throw away some unintentional or test  
changes.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 21 2011
prev sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Andrej Mitrovic wrote:


 What the duck has happened to this topic?
 
 Ok anyway, I found out a few things:
 
 I can change $HOME by adding this line into C:\Program
 Files\Git\etc\profile file:
 HOME="/d/dev/git/"
 
 right *above* this line:
 HOME="$(cd "$HOME" ; pwd)"
 
 This was from someone's blogs post. And then if I want to start git
 bash from a different initial directory I just change the git bash
 shortcut "Start In" field to whatever directory.
 
 Anyways I've made a bunch of commits to my forked repo of dpl.org, and
 now have to figure out how to make a pull request. I haven't made any
 branches or anything because I'm way too new to this.
 
 I would also like to know how to uncommit a change which hasn't been
 pushed yet. So if I locally do:
 git add someFile.d
 git commit -m "woops wrong comment"


I recently starting using interactive rebasing which is a tremendous help 
for these kind of situations. This is usually what I do:

start a branch for work on feature foo:
  git checkout -b foo

* do a bunch of commits on foo *

update master with newest changes:
  git checkout master
  git pull

when foo is done, rebase it on top of master:
  git checkout foo
  git rebase -i master

This will popup your editor and let you squash some commits together and 
edit the message. The text in your editor is fairly self-explanatory. It 
also 'replays' the commits on top of those from master you have pulled in 
*after* creating the foo branch. This helps with two things: you can resolve 
any conflicts inside the foo branch and prevents annoying merge commits. It 
will look in history like you have starting the foo branch from the latest 
commit from master. Sometimes this is not what you want, but most of the 
time it makes sense.

From here you can either merge it with master (it will fast-forward) and 
push to github, or push the foo branch to a foo branch on github. Doing 
interactive rebasing like this allows you to organize the series of commits 
and messages *after* you are done developing something, resulting in very 
nice pull requests.

There is one thing you should never do: rebase a branch which you have 
already pushed to some place other people can see / use / depend on. Then 
you are taking away the history on which people have build. It is to be used 
strictly with private branches.

I use this workflow to work concurrently on lot's of different topics, each 
in a seperate branch. Without rebasing the history will be cluttered with 
merge commits. I also don't have to worry anymore about other people when I 
commit, since making nice messages and such is postponed to the point of a 
rebase. This makes life much more pleasant.
May 21 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/11, Lutger Blijdestijn <lutger.blijdestijn gmail.com> wrote:

 I recently starting using interactive rebasing which is a tremendous help
 for these kind of situations. This is usually what I do: <snip>


Ah, this could be quite useful. In one instance I've made a change,
committed (locally) and then found a typo in the code and had to make
another commit just to fix a typo I've introduced. So I could use
rebasing here (like merging two changes into one, I guess I can do
that?).
May 21 2011
parent David Nadlinger <see klickverbot.at> writes:
On 5/21/11 2:04 PM, Andrej Mitrovic wrote:

 On 5/21/11, Lutger Blijdestijn<lutger.blijdestijn gmail.com>  wrote:

 I recently starting using interactive rebasing which is a tremendous help
 for these kind of situations. This is usually what I do:<snip>


 Ah, this could be quite useful. In one instance I've made a change,
 committed (locally) and then found a typo in the code and had to make
 another commit just to fix a typo I've introduced. So I could use
 rebasing here (like merging two changes into one, I guess I can do
 that?).


Yes: Let's assume you have some commits A, B, C, D, E on your branch. 
Using »git rebase -i/--interactive HEAD~5«, you could choose to drop 
commit A altogether, merge C into B, and stop at commit D for editing.

Due to the comments in the generated file and the verbose console 
messages, »git rebase -i« is pretty much self-explanatory, just give it 
a try!

David
May 21 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Anywho, I'll start reading this http://progit.org/book/ to get the
hang of things.
May 21 2011
parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Andrej Mitrovic wrote:


 Anywho, I'll start reading this http://progit.org/book/ to get the
 hang of things.


That's a good book. I recommend to read closely chapter 3 and 9, goof around 
in a test repo and browse the .git/refs directory. Doing that made me 
understand how simple the core of git really is and then a lot of commands 
suddenly made much more sense.
May 21 2011
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 21 May 2011 00:47:46 +0300, Don <nospam nospam.com> wrote:


 Yeah, I would have thought so. I wouldn't expect to find the root cause  



Sorry, but did you read the bug report and the whole comment you linked  
to? It's completely unrelated, core.auto-crlf is related to the conversion  
of files in the working directory - this setting will not affect the way  
the index is accessed. You're not making much of sense, and I'm the  
"fanboy" here...


 I don't know exactly what causes it. It may have something to do with  
 the fact that I have a symlink in my path. Here's the result of a quick  
 google:
 ----
 http://www.nishioka.com/blog/2008/01/source-control-with-git-and-cygwin.html

 "If you use git on cygwin, you must be sure your disks are mounted  
 binmode or your database will get corrupted!

 I had all my disks but one mounted binmode, but I also had a symbolic  
 link that ended up using that one textmode mount. This corrupted the  
 index and I got:

 error: bad index file sha1 signature
 fatal: index file corrupt"

 Still not fixed in cygwin in 2011.


How did you end up with a text mount? Did you create it yourself?

Will you agree, at least, that cygwin + text-mode mount (I had never even  
heard of this before you brought it up) is not a typical set up?

(I imagine this might be an easy fix... fopen(index, "w") -> fopen(index,  
"wb") oslt)


 No, fanboyism is evidenced in dismissing a list of bugs. I think that  
 was a darn good list.


That depends on what do you mean by "dismiss". Am I arguing that these are  
not bugs? No. Am I arguing that these are not bugs in Git for Windows that  
the majority of users will encounter? Maybe.

I had actually typed a reply where I replied to each item in your list  
(with my own observations and suggestions), but that would have definitely  
landed me a "fanboy" label...

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 20 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I think all I have to do is actually click the "Pull Request" button.
It's actually showing me 11 commits, I think this is it.

Do I have to type something in as the title/description? Each of the
actual commits are commented, although I've completely forgot to add
which bug reports should be closed due to the fixes.

Some of my bug reports will still be opened because I only did partial
fixes on them, since I'm not sure about the validity of some issues in
the reports. Next time I won't create a bug report that is a
*collection* of bugs, I can see the pain it's giving me now. :)
May 20 2011
parent David Nadlinger <see klickverbot.at> writes:
On 5/21/11 12:29 AM, Andrej Mitrovic wrote:

 Do I have to type something in as the title/description? Each of the
 actual commits are commented, although I've completely forgot to add
 which bug reports should be closed due to the fixes.


You should give it a sensible title, because that's what appears in the 
pull requests list view. The description is pretty much optional, but 
it's a great place to put any additional information, as it appears 
before all the commits itself on the pull request page (e.g. the text at 
https://github.com/D-Programming-Language/phobos/pull/15).

David
May 20 2011
prev sibling parent reply Don <nospam nospam.com> writes:
Vladimir Panteleev wrote:

 On Sat, 21 May 2011 00:47:46 +0300, Don <nospam nospam.com> wrote:
 

 Yeah, I would have thought so. I wouldn't expect to find the root 



 
 Sorry, but did you read the bug report and the whole comment you linked 
 to? It's completely unrelated, core.auto-crlf is related to the 
 conversion of files in the working directory - this setting will not 
 affect the way the index is accessed. You're not making much of sense,
 and I'm the "fanboy" here...
 

 I don't know exactly what causes it. It may have something to do with 
 the fact that I have a symlink in my path. Here's the result of a 
 quick google:
 ----
 http://www.nishioka.com/blog/2008/01/source-control-with-git-and-cygwin.html 


 "If you use git on cygwin, you must be sure your disks are mounted 
 binmode or your database will get corrupted!

 I had all my disks but one mounted binmode, but I also had a symbolic 
 link that ended up using that one textmode mount. This corrupted the 
 index and I got:

 error: bad index file sha1 signature
 fatal: index file corrupt"

 Still not fixed in cygwin in 2011.


 
 How did you end up with a text mount? Did you create it yourself?


I don't even know what a text mount is.  (That's a quote from the page).
But my symptoms seem exactly the same as that.

My experience is:
* download, standard install.
* As far as I know there is nothing unusual to my Windows setup.
* Running 'git status' corrupts the database.
* Googling for the error message I find other people have encountered 
this before.
* I find many other bugs within a couple of hours of use.
Conclude this is an _extremely_ immature product.

I'm amazed anyone disagrees with that.
May 21 2011
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 21 May 2011 12:28:04 +0300, Don <nospam nospam.com> wrote:


  How did you end up with a text mount? Did you create it yourself?


 I don't even know what a text mount is.  (That's a quote from the page).
 But my symptoms seem exactly the same as that.

 My experience is:
 * download, standard install.
 * As far as I know there is nothing unusual to my Windows setup.
 * Running 'git status' corrupts the database.
 * Googling for the error message I find other people have encountered  
 this before.
 * I find many other bugs within a couple of hours of use.
 Conclude this is an _extremely_ immature product.

 I'm amazed anyone disagrees with that.


Well, there you have the main point of our argument: your experience with  
Git on Windows was indeed awful, but why should someone (the overwhelming  
majority?) who never encountered these problems agree with you?

All I'm saying is that you are presenting the conclusions based on your  
personal experience as an objective truth. Git may appear to be "an  
_extremely_ immature product" when used on a system and in a manner  
similar to yours, but you can't say that about everyone.

Have you had a chance to try DustMite yet? I was looking for the  
std.datetime problem you referred to in the D.learn post, but couldn't  
find it.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 21 2011
prev sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 11:28, schrieb Don:

 Vladimir Panteleev wrote:

 On Sat, 21 May 2011 00:47:46 +0300, Don <nospam nospam.com> wrote:


 Yeah, I would have thought so. I wouldn't expect to find the root

 database.


 Sorry, but did you read the bug report and the whole comment you
 linked to? It's completely unrelated, core.auto-crlf is related to the
 conversion of files in the working directory - this setting will not
 affect the way the index is accessed. You're not making much of sense,
 and I'm the "fanboy" here...


 I don't know exactly what causes it. It may have something to do with
 the fact that I have a symlink in my path. Here's the result of a
 quick google:
 ----
 http://www.nishioka.com/blog/2008/01/source-control-with-git-and-cygwin.html


 "If you use git on cygwin, you must be sure your disks are mounted
 binmode or your database will get corrupted!

 I had all my disks but one mounted binmode, but I also had a symbolic
 link that ended up using that one textmode mount. This corrupted the
 index and I got:

 error: bad index file sha1 signature
 fatal: index file corrupt"

 Still not fixed in cygwin in 2011.


 How did you end up with a text mount? Did you create it yourself?


 I don't even know what a text mount is. (That's a quote from the page).
 But my symptoms seem exactly the same as that.

 My experience is:
 * download, standard install.
 * As far as I know there is nothing unusual to my Windows setup.
 * Running 'git status' corrupts the database.
 * Googling for the error message I find other people have encountered
 this before.
 * I find many other bugs within a couple of hours of use.
 Conclude this is an _extremely_ immature product.

 I'm amazed anyone disagrees with that.


By the way: Have you ever tried JGIT? http://www.eclipse.org/jgit/
I don't know how mature it is, but at least it doesn't seem to rely on 
bash scripts and such.

Cheers,
- Daniel
May 21 2011
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 21/05/2011 11:02, Daniel Gibson wrote:

 Am 21.05.2011 11:28, schrieb Don:

 Vladimir Panteleev wrote:

 On Sat, 21 May 2011 00:47:46 +0300, Don <nospam nospam.com> wrote:


 Yeah, I would have thought so. I wouldn't expect to find the root

 database.


 Sorry, but did you read the bug report and the whole comment you
 linked to? It's completely unrelated, core.auto-crlf is related to the
 conversion of files in the working directory - this setting will not
 affect the way the index is accessed. You're not making much of sense,
 and I'm the "fanboy" here...


 I don't know exactly what causes it. It may have something to do with
 the fact that I have a symlink in my path. Here's the result of a
 quick google:
 ----
 http://www.nishioka.com/blog/2008/01/source-control-with-git-and-cygwin.html



 "If you use git on cygwin, you must be sure your disks are mounted
 binmode or your database will get corrupted!

 I had all my disks but one mounted binmode, but I also had a symbolic
 link that ended up using that one textmode mount. This corrupted the
 index and I got:

 error: bad index file sha1 signature
 fatal: index file corrupt"

 Still not fixed in cygwin in 2011.


 How did you end up with a text mount? Did you create it yourself?


 I don't even know what a text mount is. (That's a quote from the page).
 But my symptoms seem exactly the same as that.

 My experience is:
 * download, standard install.
 * As far as I know there is nothing unusual to my Windows setup.
 * Running 'git status' corrupts the database.
 * Googling for the error message I find other people have encountered
 this before.
 * I find many other bugs within a couple of hours of use.
 Conclude this is an _extremely_ immature product.

 I'm amazed anyone disagrees with that.


 By the way: Have you ever tried JGIT? http://www.eclipse.org/jgit/
 I don't know how mature it is, but at least it doesn't seem to rely on
 bash scripts and such.

 Cheers,
 - Daniel


Yeah, it's a pure Java implementation, and thus much more portable. From 
what I hear JGit and EGit (the Eclipse GUI/team-provider for JGit) are 
still a bit in their infancy, but they are good enough for use (I hear a 
lot of Eclipse devs are using them already). It doesn't support all Git 
features yet, but what it does support should not be too buggy.

In any case it's worth to watch this, it is a project getting a lot of 
traction in Eclipse, since Git was chosen to be the replacement for CVS 
(yes, CVS, they are still using that) for hosting the official Eclipse 
projects, so they have a lot of developers working on it (backed by 
several companies),

-- 
Bruno Medeiros - Software Engineer
May 26 2011
prev sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 5/20/11 11:47 PM, Don wrote:

 Still not fixed in cygwin in 2011.


So, just to make this clear, you are using Git via Cygwin instead of 
msysgit (which is pretty much the default for Git on Windows these days)?


 No, fanboyism is evidenced in dismissing a list of bugs. I think that
 was a darn good list.


Honestly, I hardly think so, given that half of the items arent't even bugs…

David
May 20 2011
parent Don <nospam nospam.com> writes:
David Nadlinger wrote:

 On 5/20/11 11:47 PM, Don wrote:

 Still not fixed in cygwin in 2011.


 So, just to make this clear, you are using Git via Cygwin instead of 
 msysgit (which is pretty much the default for Git on Windows these days)?
 

 No, fanboyism is evidenced in dismissing a list of bugs. I think that
 was a darn good list.


 Honestly, I hardly think so, given that half of the items arent't even 
 bugs…
 
 David


Which ones aren't bugs? Yes, there's one which is just a poorly written 
man page (that's my opinion, and is debatable). Do you think any of the 
others aren't valid bugzilla entries?
May 21 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/20/2011 7:52 AM, Don wrote:

 Sorry, but your reply is a textbook example of fanboyism. On Windows, git is an
 utterly lousy product. And yes, I have both cygwin and Msys.


Reminds me of when I tried to run Latex on Windows. What a disaster.

Also, git just doesn't work right with files that end in CRLF. I fought this
for 
a while, and finally gave up. Everything I check in I run through a converter 
which strips out the CR. No more troubles.
May 21 2011
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 21/05/2011 09:14, Walter Bright wrote:

 On 5/20/2011 7:52 AM, Don wrote:

 Sorry, but your reply is a textbook example of fanboyism. On Windows,
 git is an
 utterly lousy product. And yes, I have both cygwin and Msys.


 Reminds me of when I tried to run Latex on Windows. What a disaster.

 Also, git just doesn't work right with files that end in CRLF. I fought
 this for a while, and finally gave up. Everything I check in I run
 through a converter which strips out the CR. No more troubles.


The install instructions mentioned eariler that started this whole 
debate has an installer which has an option to sort out line endings, is 
that not what you need? (see the screenshots on the link provided).

-- 
Robert
http://octarineparrot.com/
May 21 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2011 9:07 AM, Robert Clipsham wrote:

 The install instructions mentioned eariler that started this whole debate has
an
 installer which has an option to sort out line endings, is that not what you
 need? (see the screenshots on the link provided).


There seem to be at least 6 ways of dealing with this on git. The documentation 
on each of them is execrable.

Git just has a fundamental problem with it - that is, git wants to make a
unique 
hash for each file. That hash works on the binary contents of a file. Git also 
works with binary files.

So, what do you do with a file with CRLFs? Is it or is it not a binary file? Do 
you autodetect it and risk messing up a "binary" file? When you check in a file 
with CRLFs, do you convert it first to LFs? What happens when you check that 
file out? Do CRLFs get restored or not? Is a file "changed" if only CR's were 
added/deleted? How do you detect that?

There simply isn't a correct answer, and the 6 ways and their schizo 
documentation are utterly unclear about these issues.

The answer (for me) is to always strip CR's before git ever sees the files. 
Voila, no more issues.
May 21 2011
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 21/05/2011 09:14, Walter Bright wrote:

 On 5/20/2011 7:52 AM, Don wrote:

 Sorry, but your reply is a textbook example of fanboyism. On Windows,
 git is an
 utterly lousy product. And yes, I have both cygwin and Msys.


 Reminds me of when I tried to run Latex on Windows. What a disaster.

 Also, git just doesn't work right with files that end in CRLF. I fought
 this for a while, and finally gave up. Everything I check in I run
 through a converter which strips out the CR. No more troubles.


Also, doesn't your editor leave line endings in tact? Every editor I've 
used for programming detects the line endings and doesn't play with 
them, and they generally have an option to chose the default line ending 
style for new files.

-- 
Robert
http://octarineparrot.com/
May 21 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2011 9:09 AM, Robert Clipsham wrote:

 Also, doesn't your editor leave line endings in tact? Every editor I've used
for
 programming detects the line endings and doesn't play with them, and they
 generally have an option to chose the default line ending style for new files.


My editor sets the line endings to match the default of the OS it is running 
under. In my experience, it is nearly always the right thing to do.

There isn't a right or wrong answer here, unfortunately. Unfortunately, even
now 
a lot of unix programs still crash and burn with CRLF files (I'm looking at
you, 
make on FreeBSD).
May 21 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:ir8uro$151e$1 digitalmars.com...

 On 5/21/2011 9:09 AM, Robert Clipsham wrote:

 Also, doesn't your editor leave line endings in tact? Every editor I've 
 used for
 programming detects the line endings and doesn't play with them, and they
 generally have an option to chose the default line ending style for new 
 files.


 My editor sets the line endings to match the default of the OS it is 
 running under. In my experience, it is nearly always the right thing to 
 do.


I'm becoming convinced that just using Unix-style \n even on Windows is 
nearly always the right thing to do. Windows Notepad is the only Windows 
program I've come across that still has any problem with Unix-style line 
endings. And what programmer ever uses that? Everything else handles \n just 
fine these days, even on Windows. (With the possible exception of Batch 
files - I haven't tried that...)


 There isn't a right or wrong answer here, unfortunately. Unfortunately, 
 even now a lot of unix programs still crash and burn with CRLF files (I'm 
 looking at you, make on FreeBSD).
May 21 2011
prev sibling parent Russel Winder <russel russel.org.uk> writes:
On Sat, 2011-05-21 at 11:00 -0700, Walter Bright wrote:


 There isn't a right or wrong answer here, unfortunately. Unfortunately, e=


ven now=20

 a lot of unix programs still crash and burn with CRLF files (I'm looking =


at you,=20

 make on FreeBSD).



dismally on all non-Windows platforms tried.  Must be a kernel thing.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 21 2011
prev sibling next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 20/05/2011 08:33, Don wrote:

 Here's my list of bugs in git for windows which I found in the first
 fews days of using it:


-- long list of bugs --

 You've really got to be a fanboy to claim that git is supported on
 Windows. Sure, it "works" -- in the same way that hammering a nail with
 a rock "works".


Have you reported any of these issues?

-- 
Robert
http://octarineparrot.com/
May 20 2011
prev sibling next sibling parent Jesse Phillips <jessekphililps+D gmail.com> writes:
Personally my experience has been adequate. But I don't put a great demand on
what I need it to do. Most problem I had has just come from my
misunderstandings, such as my recent use of submodules and path differences.

Don Wrote:


 Here's my list of bugs in git for windows which I found in the first 
 fews days of using it:
 
 1. Windows git's handling of paths is completely screwed.
 If you've checked out your working copy into (say) c:\foo\bar\dmd
 and you rename a parent directory, eg to c:\foo2\bar\dmd, your working 
 copy gets hosed.


May have done this without thinking about it, but I'd remember if I'd run into
problems. I've tended not to move repositories and apparently just went
straight to using git clone --bare to do it.


 Maybe this happens only after you've performed a git operation; didn't 
 experiment with it much.
 2. It does something really horrible with the idea of your 'home' 
 directory. I'm not sure exactly what it does, but it seems to equate 'My 
 Documents' with $HOME. If ActiveDirectory is in use,
 you can end up with more than one $HOME. I've also had it suddenly think 
 that my home directory lies on a file server. This corrupts your 
 configuration file, and you lose your public keys.


I use GVim all the time, and I believe it sets up a HOME variable for you (or I
did it myself so I can refer to it after installing Vim) but yes it will use My
Documents if you don't have a Variable for HOME (my experience in the past).

Not sure if git will follow the rules, and I don't use ActiveDirectory myself
(or don't know I am)


 3. The 'gittutorial' is ridiculous and insulting. In the first two 
 minutes of using git, you already need to know far more commands than 
 are included in the tutorial. Most obviously, it should talk about 
 git-reset before discussing branching and collaboration.


I've used reset maybe 4-5 times in the past year, and have looked it up every
time. Generally I'm just using git checkout .  and git stash.


 4. If a large number of files have been changed in a single commit, gitk 
 can pop up a message box that is larger than your full screen -- so the 
 'OK' button is not visible!


Never seen this, don't know if I've ever had a large enough change to make it
happen.


 5. TortoiseGit has a manual which is full of references to Subversion. 
 You cannot trust anything you read in that manual. I quickly gave up any 
 attempts to use TortoiseGit.


I prefer svn to TortoiseSVN so I've just stuck with git.


 6. Git bash and/or vim is very amateurish. Eg, pressing cursor keys when 
 you're at the start of a line causes the screen to flash.


That is a feature of vim, it is the visual bell and tells you that the
operation you preformed has no effect. Disable:

:set vb t_vb=""

http://vim.wikia.com/wiki/Disable_beeping_and_flashing


 7. In git diff, using scroll bars to view an earlier part of the screen, 
 then pressing a key corrupts the bash screen.


gvimdiff is my diff program, don't have any issues.


 8. Git diff's highlighting is wrong when a modified line is longer than 
 80 characters long.


above


 You've really got to be a fanboy to claim that git is supported on 
 Windows. Sure, it "works" -- in the same way that hammering a nail with 
 a rock "works".


No, I just haven't had problems which have been related to it running on
Windows.
May 20 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don:


 Here's my list of bugs in git for windows which I found in the first 
 fews days of using it:


Have you reported those bugs to the devs, or are they known bugs?

Bye,
bearophile
May 20 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/20/11 2:33 AM, Don wrote:

 You've really got to be a fanboy to claim that git is supported on
 Windows. Sure, it "works" -- in the same way that hammering a nail with
 a rock "works".


Fanboyism for Windows or git? :o)

I'm not surprised in the least. I was just remarking to Walter the other 
day that Unix has become the path of least resistance for doing 
programming-at-large and in particular OSS kind of work, just the same 
as Windows is for office computing and OSX and portable derivatives for 
computer-based entertainment.

The confusing part is that roughly all OSs offer (at least nominally) 
means for achieving most any given typical task, so comparing in terms 
of "has/doesn't have" is not relevant. It's the many little differences 
and nuances that add up to a long tail. So it's not surprising that 
git/Windows has many issues, just the same it's not surprising that 
people are having trouble playing media or using OpenOffice on Unixen.


Andrei
May 20 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:ir67mk$2jfi$1 digitalmars.com...

 On 5/20/11 2:33 AM, Don wrote:

 You've really got to be a fanboy to claim that git is supported on
 Windows. Sure, it "works" -- in the same way that hammering a nail with
 a rock "works".


 Fanboyism for Windows or git? :o)

 I'm not surprised in the least. I was just remarking to Walter the other 
 day that Unix has become the path of least resistance for doing 
 programming-at-large and in particular OSS kind of work, just the same as 
 Windows is for office computing and OSX and portable derivatives for 
 computer-based entertainment.

 The confusing part is that roughly all OSs offer (at least nominally) 
 means for achieving most any given typical task, so comparing in terms of 
 "has/doesn't have" is not relevant. It's the many little differences and 
 nuances that add up to a long tail. So it's not surprising that 
 git/Windows has many issues, just the same it's not surprising that people 
 are having trouble playing media or using OpenOffice on Unixen.


I realize you're not actually accusing him of Windows fanboyism, but that 
trouble with media, etc on Unix brings up an interesting issue: Unix users 
have a real, legitimate complaint regarding those problems. And when they 
voice those complaints nobody would ever even consider dismissing that as 
Unix fanboyism. And when those Unix users accuse various companies of 
playing Windows favoritism: Well, they're absolutely right. It *is* 
inexcusable Windows favoritism.

But OTOH, when a Unix program has a shoddy "port" to Windows, and Windows 
users complain, all of a sudden there are people (not necessarily you) that 
push back with what basically amounts to "What the hell are you whining 
about? Either shut up and use it or switch to Linux."

It really reminds me of the old crusades: The Linux side feels it has the 
moral high ground (and frankly, I can't totally disagree), but then ends up 
using that to excuse going around employing whatever normally-questionable 
tactics they damn well feel like using.
May 20 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 20.05.2011 22:41, schrieb Nick Sabalausky:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:ir67mk$2jfi$1 digitalmars.com...

 On 5/20/11 2:33 AM, Don wrote:

 You've really got to be a fanboy to claim that git is supported on
 Windows. Sure, it "works" -- in the same way that hammering a nail with
 a rock "works".


 Fanboyism for Windows or git? :o)

 I'm not surprised in the least. I was just remarking to Walter the other 
 day that Unix has become the path of least resistance for doing 
 programming-at-large and in particular OSS kind of work, just the same as 
 Windows is for office computing and OSX and portable derivatives for 
 computer-based entertainment.

 The confusing part is that roughly all OSs offer (at least nominally) 
 means for achieving most any given typical task, so comparing in terms of 
 "has/doesn't have" is not relevant. It's the many little differences and 
 nuances that add up to a long tail. So it's not surprising that 
 git/Windows has many issues, just the same it's not surprising that people 
 are having trouble playing media or using OpenOffice on Unixen.


 
 I realize you're not actually accusing him of Windows fanboyism, but that 
 trouble with media, etc on Unix brings up an interesting issue: Unix users 
 have a real, legitimate complaint regarding those problems. And when they 
 voice those complaints nobody would ever even consider dismissing that as 
 Unix fanboyism. And when those Unix users accuse various companies of 
 playing Windows favoritism: Well, they're absolutely right. It *is* 
 inexcusable Windows favoritism.
 
 But OTOH, when a Unix program has a shoddy "port" to Windows, and Windows 
 users complain, all of a sudden there are people (not necessarily you) that 
 push back with what basically amounts to "What the hell are you whining 
 about? Either shut up and use it or switch to Linux."
 


It's the same when it's the other way round. "You can't properly view
that docx file? Just use Windows and MS Office like everybody else"
"Stop complaining that there are no games for Linux, just boot Windows
and be thankful that there's a PC port at all (and not just
xbox360/PS3)" "If you want to use Photoshop just get a Mac or Windows" etc


 It really reminds me of the old crusades: The Linux side feels it has the 
 moral high ground (and frankly, I can't totally disagree), but then ends up 
 using that to excuse going around employing whatever normally-questionable 
 tactics they damn well feel like using.
 


The difference is: The Unix/Linux programs are mostly open source, so
anybody can create a Windows port or improve an existing port.
Windows only programs (that are missed on Linux) tend to be closed
source so you'd have to completely reimplement them for Linux support
(and even then you'd probably have troubles with proprietary file
formats and network protocols).

So if there are really big problems with git on Windows anybody can (try
to) fix them or even reimplement git for Windows (or platform
independent with a higher focus on Windows) - the source is available
(and with it documentation for file formats and network protocols).

I do of course understand that you (or Don) personally don't have time
for that and would prefer if it'd just work.


Cheers,
- Daniel
May 20 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ir6l0q$1he8$2 digitalmars.com...

 Am 20.05.2011 22:41, schrieb Nick Sabalausky:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:ir67mk$2jfi$1 digitalmars.com...

 On 5/20/11 2:33 AM, Don wrote:

 You've really got to be a fanboy to claim that git is supported on
 Windows. Sure, it "works" -- in the same way that hammering a nail with
 a rock "works".


 Fanboyism for Windows or git? :o)

 I'm not surprised in the least. I was just remarking to Walter the other
 day that Unix has become the path of least resistance for doing
 programming-at-large and in particular OSS kind of work, just the same 
 as
 Windows is for office computing and OSX and portable derivatives for
 computer-based entertainment.

 The confusing part is that roughly all OSs offer (at least nominally)
 means for achieving most any given typical task, so comparing in terms 
 of
 "has/doesn't have" is not relevant. It's the many little differences and
 nuances that add up to a long tail. So it's not surprising that
 git/Windows has many issues, just the same it's not surprising that 
 people
 are having trouble playing media or using OpenOffice on Unixen.


 I realize you're not actually accusing him of Windows fanboyism, but that
 trouble with media, etc on Unix brings up an interesting issue: Unix 
 users
 have a real, legitimate complaint regarding those problems. And when they
 voice those complaints nobody would ever even consider dismissing that as
 Unix fanboyism. And when those Unix users accuse various companies of
 playing Windows favoritism: Well, they're absolutely right. It *is*
 inexcusable Windows favoritism.

 But OTOH, when a Unix program has a shoddy "port" to Windows, and Windows
 users complain, all of a sudden there are people (not necessarily you) 
 that
 push back with what basically amounts to "What the hell are you whining
 about? Either shut up and use it or switch to Linux."


 It's the same when it's the other way round. "You can't properly view
 that docx file? Just use Windows and MS Office like everybody else"


Yea, but 99.9% those are just moron office drones who barely even know how 
to use a mouse (Not that I mean to excuse it. It *does* piss me off when 
some dipshit service rep insists I should use Adobe's PDF viewer or MS's 
word processor "It works for all our other [idiot] customers, so quit being 
difficult!" Stupid fucking bitch...). Most Linux users, OTOH, are power 
users and should know better.


 "Stop complaining that there are no games for Linux, just boot Windows
 and be thankful that there's a PC port at all (and not just
 xbox360/PS3)" "If you want to use Photoshop just get a Mac or Windows" etc


Yea, and that's exactly the sort of thing I meant about corporations playing 
inexcusable Windows favoritism. But what I was talking about is just 
ordinary (knowledgeable) users and OSS contributors who actually know what 
they're doing. From what I've seen, there are a lot on Linux that consider 
shoddy msys/mingw/cygwin "ports" to be acceptable, but not so many Linux 
users who consider shoddy Windows->Linux ports acceptable.

(Although I'd modify that "xbox360/ps3" to just "xbox360". After all, one of 
the most important game engine developers out there, Epic, clearly cares 
about as much about the PS3 as they do Linux. Anything that isn't an MS 
platform, Epic just refuses to give a rat's ass about. Not that I'm a PS3 
fan, I think all the current game platforms are crap, but that's a whole 
other rant.)


 It really reminds me of the old crusades: The Linux side feels it has the
 moral high ground (and frankly, I can't totally disagree), but then ends 
 up
 using that to excuse going around employing whatever 
 normally-questionable
 tactics they damn well feel like using.


 The difference is: The Unix/Linux programs are mostly open source, so
 anybody can create a Windows port or improve an existing port.
 Windows only programs (that are missed on Linux) tend to be closed
 source so you'd have to completely reimplement them for Linux support
 (and even then you'd probably have troubles with proprietary file
 formats and network protocols).

 So if there are really big problems with git on Windows anybody can (try
 to) fix them or even reimplement git for Windows (or platform
 independent with a higher focus on Windows) - the source is available
 (and with it documentation for file formats and network protocols).

 I do of course understand that you (or Don) personally don't have time
 for that and would prefer if it'd just work.


Well, I'm primarily a Windows user, but when I write an OSS app, I actually 
*design* it specifically to be cross-platform (ex: I don't design the whole 
damn thing around hundreds of Windows-specific assumptions), *and* then I 
actually test on Linux (And I plan to add FreeBSD now that VirtualBox makes 
installing/using another OS safe and easy. I'd happily do OSX, too, but 
that's locked into expensive proprietary hardware. But that's not so even 
with Windows). Maybe I'm just blind but to me that seems to be typical of 
Windows OSS developers: We don't just design with *only* our OS in mind and 
then pawn off the inevitably large porting job to someone else who may or 
may not come along. At least I sure as hell don't. But the other way around 
doesn't seem to happen much.
May 20 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 20.05.2011 23:55, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:ir6l0q$1he8$2 digitalmars.com...

 Am 20.05.2011 22:41, schrieb Nick Sabalausky:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:ir67mk$2jfi$1 digitalmars.com...

 On 5/20/11 2:33 AM, Don wrote:

 You've really got to be a fanboy to claim that git is supported on
 Windows. Sure, it "works" -- in the same way that hammering a nail with
 a rock "works".


 Fanboyism for Windows or git? :o)

 I'm not surprised in the least. I was just remarking to Walter the other
 day that Unix has become the path of least resistance for doing
 programming-at-large and in particular OSS kind of work, just the same 
 as
 Windows is for office computing and OSX and portable derivatives for
 computer-based entertainment.

 The confusing part is that roughly all OSs offer (at least nominally)
 means for achieving most any given typical task, so comparing in terms 
 of
 "has/doesn't have" is not relevant. It's the many little differences and
 nuances that add up to a long tail. So it's not surprising that
 git/Windows has many issues, just the same it's not surprising that 
 people
 are having trouble playing media or using OpenOffice on Unixen.


 I realize you're not actually accusing him of Windows fanboyism, but that
 trouble with media, etc on Unix brings up an interesting issue: Unix 
 users
 have a real, legitimate complaint regarding those problems. And when they
 voice those complaints nobody would ever even consider dismissing that as
 Unix fanboyism. And when those Unix users accuse various companies of
 playing Windows favoritism: Well, they're absolutely right. It *is*
 inexcusable Windows favoritism.

 But OTOH, when a Unix program has a shoddy "port" to Windows, and Windows
 users complain, all of a sudden there are people (not necessarily you) 
 that
 push back with what basically amounts to "What the hell are you whining
 about? Either shut up and use it or switch to Linux."


 It's the same when it's the other way round. "You can't properly view
 that docx file? Just use Windows and MS Office like everybody else"


 
 Yea, but 99.9% those are just moron office drones who barely even know how 
 to use a mouse (Not that I mean to excuse it. It *does* piss me off when 
 some dipshit service rep insists I should use Adobe's PDF viewer or MS's 
 word processor "It works for all our other [idiot] customers, so quit being 
 difficult!" Stupid fucking bitch...). Most Linux users, OTOH, are power 
 users and should know better.
 

 "Stop complaining that there are no games for Linux, just boot Windows
 and be thankful that there's a PC port at all (and not just
 xbox360/PS3)" "If you want to use Photoshop just get a Mac or Windows" etc


 
 Yea, and that's exactly the sort of thing I meant about corporations playing 
 inexcusable Windows favoritism. But what I was talking about is just 
 ordinary (knowledgeable) users and OSS contributors who actually know what 
 they're doing. From what I've seen, there are a lot on Linux that consider 
 shoddy msys/mingw/cygwin "ports" to be acceptable, but not so many Linux 
 users who consider shoddy Windows->Linux ports acceptable.


Isn't mingw just a port of GCC, GDB etc? I don't think using it to build
software (even together with MSYS when it's just used for configure etc
and is not needed to run the program itself) is bad.


 (Although I'd modify that "xbox360/ps3" to just "xbox360". After all, one of 
 the most important game engine developers out there, Epic, clearly cares 
 about as much about the PS3 as they do Linux. Anything that isn't an MS 
 platform, Epic just refuses to give a rat's ass about. Not that I'm a PS3 
 fan, I think all the current game platforms are crap, but that's a whole 
 other rant.)
 

 It really reminds me of the old crusades: The Linux side feels it has the
 moral high ground (and frankly, I can't totally disagree), but then ends 
 up
 using that to excuse going around employing whatever 
 normally-questionable
 tactics they damn well feel like using.


 The difference is: The Unix/Linux programs are mostly open source, so
 anybody can create a Windows port or improve an existing port.
 Windows only programs (that are missed on Linux) tend to be closed
 source so you'd have to completely reimplement them for Linux support
 (and even then you'd probably have troubles with proprietary file
 formats and network protocols).

 So if there are really big problems with git on Windows anybody can (try
 to) fix them or even reimplement git for Windows (or platform
 independent with a higher focus on Windows) - the source is available
 (and with it documentation for file formats and network protocols).

 I do of course understand that you (or Don) personally don't have time
 for that and would prefer if it'd just work.


 
 Well, I'm primarily a Windows user, but when I write an OSS app, I actually 
 *design* it specifically to be cross-platform (ex: I don't design the whole 
 damn thing around hundreds of Windows-specific assumptions), *and* then I 
 actually test on Linux (And I plan to add FreeBSD now that VirtualBox makes 
 installing/using another OS safe and easy. I'd happily do OSX, too, but 
 that's locked into expensive proprietary hardware. But that's not so even 
 with Windows). Maybe I'm just blind but to me that seems to be typical of 
 Windows OSS developers: We don't just design with *only* our OS in mind and 
 then pawn off the inevitably large porting job to someone else who may or 
 may not come along. At least I sure as hell don't. But the other way around 
 doesn't seem to happen much.
 
 


There are also Windows only OSS projects. Especially when it comes to
programs with a GUI (and most programs Windows have a GUI) people tend
to ignore portability because they're used to Windows specific toolkits.
It's great that you care so much for portability, but unfortunately many
other developers (developing for Linux, Windows or especially OSX) don't.
And sometimes there are just technical reasons, like Windows not
supporting fork()

I think in the case of git it's just a bit of bad luck.. as I wrote in
another branch of this thread, Linus probably didn't care at all about
Windows when developing git (it was meant to be used for Linux kernel
development) and because it relies heavily on bash it's hard to port to
Windows without msys or cygwin (which provide bash).
May 20 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ir6p9s$1he8$6 digitalmars.com...

 Am 20.05.2011 23:55, schrieb Nick Sabalausky:

 Yea, and that's exactly the sort of thing I meant about corporations 
 playing
 inexcusable Windows favoritism. But what I was talking about is just
 ordinary (knowledgeable) users and OSS contributors who actually know 
 what
 they're doing. From what I've seen, there are a lot on Linux that 
 consider
 shoddy msys/mingw/cygwin "ports" to be acceptable, but not so many Linux
 users who consider shoddy Windows->Linux ports acceptable.


 Isn't mingw just a port of GCC, GDB etc?


*shrug* All I know is that I've dealt with stuff that required it before and 
it was always a royal PITA.


 I don't think using it to build
 software (even together with MSYS when it's just used for configure etc
 and is not needed to run the program itself) is bad.


It's bad if the program is open source and it's required to build the 
program.
May 20 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 00:20, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:ir6p9s$1he8$6 digitalmars.com...

 Am 20.05.2011 23:55, schrieb Nick Sabalausky:

 Yea, and that's exactly the sort of thing I meant about corporations 
 playing
 inexcusable Windows favoritism. But what I was talking about is just
 ordinary (knowledgeable) users and OSS contributors who actually know 
 what
 they're doing. From what I've seen, there are a lot on Linux that 
 consider
 shoddy msys/mingw/cygwin "ports" to be acceptable, but not so many Linux
 users who consider shoddy Windows->Linux ports acceptable.


 Isn't mingw just a port of GCC, GDB etc?


 
 *shrug* All I know is that I've dealt with stuff that required it before and 
 it was always a royal PITA.
 

 I don't think using it to build
 software (even together with MSYS when it's just used for configure etc
 and is not needed to run the program itself) is bad.


 
 It's bad if the program is open source and it's required to build the 
 program.
 


Why? MSYS and mingw are available on Windows and mingw is even available
on linux for cross-compiling so it makes sense to use it for building
the Windows version.
As long as the resulting program doesn't have these dependencies it's ok
IMHO.
And if you really care it shouldn't be too hard to make it use another
build-system (so you don't need MSYS) and maybe even another compiler..
May 20 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ir6q2j$1he8$8 digitalmars.com...

 Am 21.05.2011 00:20, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:ir6p9s$1he8$6 digitalmars.com...

 I don't think using it to build
 software (even together with MSYS when it's just used for configure etc
 and is not needed to run the program itself) is bad.


 It's bad if the program is open source and it's required to build the
 program.


 Why? MSYS and mingw are available on Windows and mingw is even available
 on linux for cross-compiling so it makes sense to use it for building
 the Windows version.
 As long as the resulting program doesn't have these dependencies it's ok
 IMHO.
 And if you really care it shouldn't be too hard to make it use another
 build-system (so you don't need MSYS) and maybe even another compiler..


The way I see it, msys and mingw are total pains in the ass that should 
never be forced on anyone regardless of whether they're just using a program 
or compiling it (and cygwin's even worse). If someone wants to use it 
themself, then fine, but that garbage should never be forced on anyone.

And again, using Wine doesn't count as supporting Linux, so why the hell 
should the other way around be any different?
May 20 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I'm ok with msysgit simulating a linux shell, it's not too hard to use
it. cd.. -> cd ..\, dir -> ls, etc.

But why oh why does the delete key generate a ~ character, what kind
of nonsense is that? Cygwin suffers from the same problem.
May 20 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 00:34, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:ir6q2j$1he8$8 digitalmars.com...

 Am 21.05.2011 00:20, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:ir6p9s$1he8$6 digitalmars.com...

 I don't think using it to build
 software (even together with MSYS when it's just used for configure etc
 and is not needed to run the program itself) is bad.


 It's bad if the program is open source and it's required to build the
 program.


 Why? MSYS and mingw are available on Windows and mingw is even available
 on linux for cross-compiling so it makes sense to use it for building
 the Windows version.
 As long as the resulting program doesn't have these dependencies it's ok
 IMHO.
 And if you really care it shouldn't be too hard to make it use another
 build-system (so you don't need MSYS) and maybe even another compiler..


 
 The way I see it, msys and mingw are total pains in the ass that should 
 never be forced on anyone regardless of whether they're just using a program 
 or compiling it (and cygwin's even worse). If someone wants to use it 
 themself, then fine, but that garbage should never be forced on anyone.
 
 And again, using Wine doesn't count as supporting Linux, so why the hell 
 should the other way around be any different?
 


Come on, that comparison is BS.
You can /maybe/ compare cygwin to libwine (but not wine itself)..
But MinGW is just a compiler and some other tools that are native and
produce native code that doesn't need wrappers for posix-interfaces or
such. And MSYS is just a shell environment with some Unix tools like
bash, make, grep, ... and not some kind of Linux emulator.
May 20 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ir6r32$1he8$11 digitalmars.com...

 Am 21.05.2011 00:34, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:ir6q2j$1he8$8 digitalmars.com...

 Am 21.05.2011 00:20, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:ir6p9s$1he8$6 digitalmars.com...

 I don't think using it to build
 software (even together with MSYS when it's just used for configure 
 etc
 and is not needed to run the program itself) is bad.


 It's bad if the program is open source and it's required to build the
 program.


 Why? MSYS and mingw are available on Windows and mingw is even available
 on linux for cross-compiling so it makes sense to use it for building
 the Windows version.
 As long as the resulting program doesn't have these dependencies it's ok
 IMHO.
 And if you really care it shouldn't be too hard to make it use another
 build-system (so you don't need MSYS) and maybe even another compiler..


 The way I see it, msys and mingw are total pains in the ass that should
 never be forced on anyone regardless of whether they're just using a 
 program
 or compiling it (and cygwin's even worse). If someone wants to use it
 themself, then fine, but that garbage should never be forced on anyone.

 And again, using Wine doesn't count as supporting Linux, so why the hell
 should the other way around be any different?


 Come on, that comparison is BS.
 You can /maybe/ compare cygwin to libwine (but not wine itself)..
 But MinGW is just a compiler and some other tools that are native and
 produce native code that doesn't need wrappers for posix-interfaces or
 such. And MSYS is just a shell environment with some Unix tools like
 bash, make, grep, ... and not some kind of Linux emulator.


In other words, Wine does even *more* to make windows programs work on 
linux...
May 20 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 01:11, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:ir6r32$1he8$11 digitalmars.com...

 Am 21.05.2011 00:34, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:ir6q2j$1he8$8 digitalmars.com...

 Am 21.05.2011 00:20, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:ir6p9s$1he8$6 digitalmars.com...

 I don't think using it to build
 software (even together with MSYS when it's just used for configure 
 etc
 and is not needed to run the program itself) is bad.


 It's bad if the program is open source and it's required to build the
 program.


 Why? MSYS and mingw are available on Windows and mingw is even available
 on linux for cross-compiling so it makes sense to use it for building
 the Windows version.
 As long as the resulting program doesn't have these dependencies it's ok
 IMHO.
 And if you really care it shouldn't be too hard to make it use another
 build-system (so you don't need MSYS) and maybe even another compiler..


 The way I see it, msys and mingw are total pains in the ass that should
 never be forced on anyone regardless of whether they're just using a 
 program
 or compiling it (and cygwin's even worse). If someone wants to use it
 themself, then fine, but that garbage should never be forced on anyone.

 And again, using Wine doesn't count as supporting Linux, so why the hell
 should the other way around be any different?


 Come on, that comparison is BS.
 You can /maybe/ compare cygwin to libwine (but not wine itself)..
 But MinGW is just a compiler and some other tools that are native and
 produce native code that doesn't need wrappers for posix-interfaces or
 such. And MSYS is just a shell environment with some Unix tools like
 bash, make, grep, ... and not some kind of Linux emulator.


 
 In other words, Wine does even *more* to make windows programs work on 
 linux...
 


Of course, because more is needed, because they're less portable.
Wine provides the Win API and a lot of libs (like directx) and runs
windows binaries.
MSYS/cygwin don't run Linux binaries. Cygwin provides a POSIX API. So
it's kind of comparable to libwine.
However MinGW uses the Windows API => is native. It's just a different
compiler (and related tools) than e.g. MSVC or DMC and its tools.

BTW: I don't consider programs that need cygwin on Windows proper
Windows ports.
But I don't mind MinGW (and MSYS, to some degree).
May 20 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Okie, the pull is here:
https://github.com/D-Programming-Language/d-programming-language.org/pull/9

Looks like I'm 5th in line. :p
May 20 2011
prev sibling next sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 5/21/11 12:34 AM, Nick Sabalausky wrote:

 And again, using Wine doesn't count as supporting Linux, so why the hell
 should the other way around be any different?


Because, at least in my eyes, there is a huge difference between telling 
your users that using Wine they might be able to get your software to 
work on Linux (which is typically the most you can hope for if you are a 
Linux user), and using MinGW to make porting your application to Windows 
easier, which is not necessarily visible to the end user.

(Yes, Wine is occasionally used by software vendors themselves as well, 
like in the form of Transgaming Cider by Riot Games for the Mac version 
of their League of Legends game, but I hope you'll agree that this is 
not what one typically thinks about when Wine is mentioned.)

David
May 20 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"David Nadlinger" <see klickverbot.at> wrote in message 
news:ir6r72$l38$1 digitalmars.com...

 On 5/21/11 12:34 AM, Nick Sabalausky wrote:

 And again, using Wine doesn't count as supporting Linux, so why the hell
 should the other way around be any different?


 Because, at least in my eyes, there is a huge difference between telling 
 your users that using Wine they might be able to get your software to work 
 on Linux (which is typically the most you can hope for if you are a Linux 
 user), and using MinGW to make porting your application to Windows easier, 
 which is not necessarily visible to the end user.


OSS programs, which most Linux programs are, are expected to be compilable 
by the user. Therefore, if msys or mingw are required to build it, then it 
*is* visible to the end user.


 (Yes, Wine is occasionally used by software vendors themselves as well, 
 like in the form of Transgaming Cider by Riot Games for the Mac version of 
 their League of Legends game, but I hope you'll agree that this is not 
 what one typically thinks about when Wine is mentioned.)


So if wine is used to make "porting" a windows program to linux easier 
(which doesn't have to be visible to the end user - wine can just be 
packaged together with it), it's a giant blunder and doesn't count. But if 
an open source linux program is "ported" to windows, and anyone who wants to 
make any use of it's open source nature is required to use 
msys/mingw/cygwin, then that's just plain good porting.
May 20 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 01:18, schrieb Nick Sabalausky:

 "David Nadlinger" <see klickverbot.at> wrote in message 
 news:ir6r72$l38$1 digitalmars.com...

 On 5/21/11 12:34 AM, Nick Sabalausky wrote:

 And again, using Wine doesn't count as supporting Linux, so why the hell
 should the other way around be any different?


 Because, at least in my eyes, there is a huge difference between telling 
 your users that using Wine they might be able to get your software to work 
 on Linux (which is typically the most you can hope for if you are a Linux 
 user), and using MinGW to make porting your application to Windows easier, 
 which is not necessarily visible to the end user.


 
 OSS programs, which most Linux programs are, are expected to be compilable 
 by the user. Therefore, if msys or mingw are required to build it, then it 
 *is* visible to the end user.


Compiling on Windows always sucks and is generally not done by the end
*user* (who generally is not a coder).
And I think it's easier for the user to install MinGW and MSYS and run
make than installing and configuring Visual Studio (especially when the
project is for another, maybe older, version) and use that for compiling.


 

 (Yes, Wine is occasionally used by software vendors themselves as well, 
 like in the form of Transgaming Cider by Riot Games for the Mac version of 
 their League of Legends game, but I hope you'll agree that this is not 
 what one typically thinks about when Wine is mentioned.)


 
 So if wine is used to make "porting" a windows program to linux easier 
 (which doesn't have to be visible to the end user - wine can just be 
 packaged together with it), it's a giant blunder and doesn't count. But if 
 an open source linux program is "ported" to windows, and anyone who wants to 
 make any use of it's open source nature is required to use 
 msys/mingw/cygwin, then that's just plain good porting.
May 20 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
What's there to configuring visual studio? You just open a solution
file and hit compile. If there are any dependencies you usually
download the libs and put them in some subfolder.

At least that's my experience.

Now compare that to having to follow that gigantic tutorial for
compiling GDC using msys.
May 20 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 01:34, schrieb Andrej Mitrovic:

 What's there to configuring visual studio? You just open a solution
 file and hit compile. If there are any dependencies you usually
 download the libs and put them in some subfolder.
 


I don't have much experience with visual studio, but I've read that
using a project from one version in another (newer) version may not
always be painless, e.g.


And how well do projects from a professional version work in the free
(Visual Studio Express) version?


 At least that's my experience.
 
 Now compare that to having to follow that gigantic tutorial for
 compiling GDC using msys.
May 20 2011
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 21/05/2011 00:46, Daniel Gibson wrote:

 Am 21.05.2011 01:34, schrieb Andrej Mitrovic:

 What's there to configuring visual studio? You just open a solution
 file and hit compile. If there are any dependencies you usually
 download the libs and put them in some subfolder.


 I don't have much experience with visual studio, but I've read that
 using a project from one version in another (newer) version may not
 always be painless, e.g.



Each version contains a migration tool, which has worked reasonably well 
for me in the past.


 And how well do projects from a professional version work in the free
 (Visual Studio Express) version?


Last time I checked they don't.


 At least that's my experience.

 Now compare that to having to follow that gigantic tutorial for
 compiling GDC using msys.





-- 
Robert
http://octarineparrot.com/
May 20 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 02:17, schrieb Robert Clipsham:

 On 21/05/2011 00:46, Daniel Gibson wrote:

 Am 21.05.2011 01:34, schrieb Andrej Mitrovic:

 What's there to configuring visual studio? You just open a solution
 file and hit compile. If there are any dependencies you usually
 download the libs and put them in some subfolder.


 I don't have much experience with visual studio, but I've read that
 using a project from one version in another (newer) version may not
 always be painless, e.g.



 
 Each version contains a migration tool, which has worked reasonably well
 for me in the past.


OK


 

 And how well do projects from a professional version work in the free
 (Visual Studio Express) version?


 
 Last time I checked they don't.
 


And the other way round?
It seems to me that providing a Visual Studio project isn't any better
for the average end user (or even developer, who may use the other kind
of Visual Studio or DMC or even Code::Blocks, Eclipse or Dev-C++) than
providing a configure script and a Makefile for MSYS/MinGW (and maybe a
batch script that triggers the build).

But, as I said before, end users on Windows don't compile, they expect
ready to use binaries, preferably with a nice installer - and they don't
care if those binaries were produced by DMC, MSVC or MinGW as long as
the resulting program doesn't need cygwin to run.
And developers that want to mess around with the code should be able to
deal with it or even port it to DMC or MSVC or whatever themselves.
May 20 2011
prev sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Daniel Gibson wrote:


 Am 21.05.2011 01:34, schrieb Andrej Mitrovic:

 What's there to configuring visual studio? You just open a solution
 file and hit compile. If there are any dependencies you usually
 download the libs and put them in some subfolder.
 


 
 I don't have much experience with visual studio, but I've read that
 using a project from one version in another (newer) version may not
 always be painless, e.g.



Going from one version of a *solution* to the next usually just works. I 
expect tech5 to be somewhat more complex though. What usually doesn't work 
is going from one compiler version to the next, at least for C++. 'Managed' 
.Net is a different story.
 

 And how well do projects from a professional version work in the free
 (Visual Studio Express) version?


That should work, the professional version is mostly about extra ide 
features, the basics and the toolchain is exactly the same.
 

 At least that's my experience.
 
 Now compare that to having to follow that gigantic tutorial for
 compiling GDC using msys.




That's not really a fair comparison, GDC is very complex. There are also a 
lot of OSS projects which are much less arcane than what GNU usually does. 
Windows has it's share of complex build setups too, I believe the visual 
studio shell is such an example. I generally also find the boatloads of 
msbuild / nant xml scripts to be pretty incomprehensible when you need to 
work with them if something doesn't work.
May 21 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 13:09, schrieb Lutger Blijdestijn:

 Daniel Gibson wrote:


 Am 21.05.2011 01:34, schrieb Andrej Mitrovic:

 What's there to configuring visual studio? You just open a solution
 file and hit compile. If there are any dependencies you usually
 download the libs and put them in some subfolder.


 I don't have much experience with visual studio, but I've read that
 using a project from one version in another (newer) version may not
 always be painless, e.g.



 Going from one version of a *solution* to the next usually just works. I
 expect tech5 to be somewhat more complex though. What usually doesn't work
 is going from one compiler version to the next, at least for C++.


Probably that was the problem.
So this seems to be a general problem: You can't just import and build a 
C++ project of VSC version X in you VSC version Y - and fixing the code 
to make compile errors go away is not something the "end user" will want 
to do.
But of course this problem also exists with different versions of 
g++/MinGW. It should be possible to install multiple versions of MinGW's 
gcc/g++ in parallel though.


 'Managed'
 .Net is a different story.


 And how well do projects from a professional version work in the free
 (Visual Studio Express) version?


 That should work, the professional version is mostly about extra ide
 features, the basics and the toolchain is exactly the same.


hmm Robert said it didn't work for him.


 At least that's my experience.

 Now compare that to having to follow that gigantic tutorial for
 compiling GDC using msys.




 That's not really a fair comparison, GDC is very complex. There are also a
 lot of OSS projects which are much less arcane than what GNU usually does.
 Windows has it's share of complex build setups too, I believe the visual
 studio shell is such an example. I generally also find the boatloads of
 msbuild / nant xml scripts to be pretty incomprehensible when you need to
 work with them if something doesn't work.


I agree.
May 21 2011
prev sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 5/21/11 1:09 PM, Lutger Blijdestijn wrote:

 And how well do projects from a professional version work in the free
 (Visual Studio Express) version?


 That should work, the professional version is mostly about extra ide
 features, the basics and the toolchain is exactly the same.


I have encountered quite a few problems though. For example, 64 bit code 
generation used to be absent by default from Express versions (maybe it 
still is, haven't checked), which is a sensible marketing decision per 
se. However, it was implemented in such a way that I couldn't open a 
solution file from an open source project I was working on with my 
Express edition installation, just because it contained an x64 target…

David
May 21 2011
parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
David Nadlinger wrote:


 On 5/21/11 1:09 PM, Lutger Blijdestijn wrote:

 And how well do projects from a professional version work in the free
 (Visual Studio Express) version?


 That should work, the professional version is mostly about extra ide
 features, the basics and the toolchain is exactly the same.


 
 I have encountered quite a few problems though. For example, 64 bit code
 generation used to be absent by default from Express versions (maybe it
 still is, haven't checked), which is a sensible marketing decision per
 se. However, it was implemented in such a way that I couldn't open a
 solution file from an open source project I was working on with my
 Express edition installation, just because it contained an x64 target…
 
 David


ouch, that sucks. Wikipedia suggests this works now for 2010 though.
May 21 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ir6tel$1he8$13 digitalmars.com...

 Am 21.05.2011 01:18, schrieb Nick Sabalausky:

 "David Nadlinger" <see klickverbot.at> wrote in message
 news:ir6r72$l38$1 digitalmars.com...

 On 5/21/11 12:34 AM, Nick Sabalausky wrote:

 And again, using Wine doesn't count as supporting Linux, so why the 
 hell
 should the other way around be any different?


 Because, at least in my eyes, there is a huge difference between telling
 your users that using Wine they might be able to get your software to 
 work
 on Linux (which is typically the most you can hope for if you are a 
 Linux
 user), and using MinGW to make porting your application to Windows 
 easier,
 which is not necessarily visible to the end user.


 OSS programs, which most Linux programs are, are expected to be 
 compilable
 by the user. Therefore, if msys or mingw are required to build it, then 
 it
 *is* visible to the end user.


 Compiling on Windows always sucks and is generally not done by the end
 *user* (who generally is not a coder).
 And I think it's easier for the user to install MinGW and MSYS and run
 make than installing and configuring Visual Studio (especially when the
 project is for another, maybe older, version) and use that for compiling.


My experience has been the other way around. Besides, a *lot* of windows 
programmers don't use Visual Studio. I don't. (Used to, back around versions 
5-6 and early .NET, but not anymore.)

And with D, compiling is equally easy/hard on both Windows/Linux :)
May 20 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 21 May 2011 08:12:24 +0300, Nick Sabalausky <a a.a> wrote:


 My experience has been the other way around. Besides, a *lot* of windows
 programmers don't use Visual Studio. I don't. (Used to, back around  
 versions
 5-6 and early .NET, but not anymore.)


I frequently hear that Visual Studio is the all-round best IDE for C/C++  
development (I rarely use it myself, so I don't have an opinion). I  
suppose that's the power of dogfooding...

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 21 2011
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 21/05/2011 09:43, Vladimir Panteleev wrote:

 On Sat, 21 May 2011 08:12:24 +0300, Nick Sabalausky <a a.a> wrote:


 My experience has been the other way around. Besides, a *lot* of windows
 programmers don't use Visual Studio. I don't. (Used to, back around
 versions
 5-6 and early .NET, but not anymore.)


 I frequently hear that Visual Studio is the all-round best IDE for C/C++
 development (I rarely use it myself, so I don't have an opinion). I
 suppose that's the power of dogfooding...


For programs intended to run on Windows, sure. But for example, for 
embedded systems I hear that Eclipse CDT is incredibly popular.

-- 
Bruno Medeiros - Software Engineer
May 26 2011
prev sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 07:12, schrieb Nick Sabalausky:

 "Daniel Gibson"<metalcaedes gmail.com>  wrote in message
 news:ir6tel$1he8$13 digitalmars.com...

 Am 21.05.2011 01:18, schrieb Nick Sabalausky:

 "David Nadlinger"<see klickverbot.at>  wrote in message
 news:ir6r72$l38$1 digitalmars.com...

 On 5/21/11 12:34 AM, Nick Sabalausky wrote:

 And again, using Wine doesn't count as supporting Linux, so why the
 hell
 should the other way around be any different?


 Because, at least in my eyes, there is a huge difference between telling
 your users that using Wine they might be able to get your software to
 work
 on Linux (which is typically the most you can hope for if you are a
 Linux
 user), and using MinGW to make porting your application to Windows
 easier,
 which is not necessarily visible to the end user.


 OSS programs, which most Linux programs are, are expected to be
 compilable
 by the user. Therefore, if msys or mingw are required to build it, then
 it
 *is* visible to the end user.


 Compiling on Windows always sucks and is generally not done by the end
 *user* (who generally is not a coder).
 And I think it's easier for the user to install MinGW and MSYS and run
 make than installing and configuring Visual Studio (especially when the
 project is for another, maybe older, version) and use that for compiling.


 My experience has been the other way around. Besides, a *lot* of windows
 programmers don't use Visual Studio. I don't. (Used to, back around versions
 5-6 and early .NET, but not anymore.)


So how do you compile C/C++ code on windows? DMC? Fine for your code but 
I guess most open source projects don't support it.
Dev-C++, Eclpse CDT, ...? AFAIK they use the mingw compiler :P


 And with D, compiling is equally easy/hard on both Windows/Linux :)


If the projects uses GNU makefiles (which is quite common on Linux) you 
need MSYS or something like that to compile it on Windows.
May 21 2011
prev sibling parent Kagamin <spam here.lot> writes:
Nick Sabalausky Wrote:


 The way I see it, msys and mingw are total pains in the ass that should 
 never be forced on anyone regardless of whether they're just using a program 
 or compiling it (and cygwin's even worse). If someone wants to use it 
 themself, then fine, but that garbage should never be forced on anyone.


Didn't use msys, but stock mingw+make work just fine for me (I've made some
contributions to scintilla and use them for my projects). What's your problem?
May 24 2011
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-05-20 18:13:30 -0400, Daniel Gibson <metalcaedes gmail.com> said:


 I think in the case of git it's just a bit of bad luck.. as I wrote in
 another branch of this thread, Linus probably didn't care at all about
 Windows when developing git (it was meant to be used for Linux kernel
 development) and because it relies heavily on bash it's hard to port to
 Windows without msys or cygwin (which provide bash).


Sometime wanting to get to every platform at first try puts 
restrictions on what you can do or how fast you can develop. Time helps 
overcome those early limitations, but the early adopters suffer.

For git, I think libgit2 will help a lot once it's complete.
<http://libgit2.github.com/>

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 20 2011
parent "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:ir6tqm$pbf$1 digitalmars.com...

 On 2011-05-20 18:13:30 -0400, Daniel Gibson <metalcaedes gmail.com> said:


 I think in the case of git it's just a bit of bad luck.. as I wrote in
 another branch of this thread, Linus probably didn't care at all about
 Windows when developing git (it was meant to be used for Linux kernel
 development) and because it relies heavily on bash it's hard to port to
 Windows without msys or cygwin (which provide bash).


 Sometime wanting to get to every platform at first try puts restrictions 
 on what you can do or how fast you can develop. Time helps overcome those 
 early limitations, but the early adopters suffer.


I guess for all I know that might be the case for some people in some 
situations. In my personal experience though, I've always found that 
designing with cross-compatibility in mind right from the start makes things 
go *much* more smoothly in the long run. Separating out platform-specific 
code and avoiding too much reliance on platform specific tools/libs is 
usually very easy. Unless maybe you're writing a kerenel module or 
something, but that's not really what we're talking about ;)


 For git, I think libgit2 will help a lot once it's complete.
 <http://libgit2.github.com/>


Interesting. That's the first I've heard of that. Thanks for the link.

Although, personally, I'm still more in the hg camp than the git camp, even 
if git did work well on windows (hence my strong interest in seeing that 
dulwich/hg-git issue get fixed instead of passed off as only moderately 
important)...But I'm not sure I want to get into a vi-vs-emacs sort of 
debate...
May 20 2011
prev sibling parent reply Don <nospam nospam.com> writes:
Daniel Gibson wrote:

 Am 20.05.2011 22:41, schrieb Nick Sabalausky:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:ir67mk$2jfi$1 digitalmars.com...

 On 5/20/11 2:33 AM, Don wrote:

 You've really got to be a fanboy to claim that git is supported on
 Windows. Sure, it "works" -- in the same way that hammering a nail with
 a rock "works".


 Fanboyism for Windows or git? :o)

 I'm not surprised in the least. I was just remarking to Walter the other 
 day that Unix has become the path of least resistance for doing 
 programming-at-large and in particular OSS kind of work, just the same as 
 Windows is for office computing and OSX and portable derivatives for 
 computer-based entertainment.

 The confusing part is that roughly all OSs offer (at least nominally) 
 means for achieving most any given typical task, so comparing in terms of 
 "has/doesn't have" is not relevant. It's the many little differences and 
 nuances that add up to a long tail. So it's not surprising that 
 git/Windows has many issues, just the same it's not surprising that people 
 are having trouble playing media or using OpenOffice on Unixen.


 I realize you're not actually accusing him of Windows fanboyism, but that 
 trouble with media, etc on Unix brings up an interesting issue: Unix users 
 have a real, legitimate complaint regarding those problems. And when they 
 voice those complaints nobody would ever even consider dismissing that as 
 Unix fanboyism. And when those Unix users accuse various companies of 
 playing Windows favoritism: Well, they're absolutely right. It *is* 
 inexcusable Windows favoritism.

 But OTOH, when a Unix program has a shoddy "port" to Windows, and Windows 
 users complain, all of a sudden there are people (not necessarily you) that 
 push back with what basically amounts to "What the hell are you whining 
 about? Either shut up and use it or switch to Linux."


 
 It's the same when it's the other way round. "You can't properly view
 that docx file? Just use Windows and MS Office like everybody else"
 "Stop complaining that there are no games for Linux, just boot Windows
 and be thankful that there's a PC port at all (and not just
 xbox360/PS3)" "If you want to use Photoshop just get a Mac or Windows" etc
 

 It really reminds me of the old crusades: The Linux side feels it has the 
 moral high ground (and frankly, I can't totally disagree), but then ends up 
 using that to excuse going around employing whatever normally-questionable 
 tactics they damn well feel like using.


 
 The difference is: The Unix/Linux programs are mostly open source, so
 anybody can create a Windows port or improve an existing port.
 Windows only programs (that are missed on Linux) tend to be closed
 source so you'd have to completely reimplement them for Linux support
 (and even then you'd probably have troubles with proprietary file
 formats and network protocols).
 
 So if there are really big problems with git on Windows anybody can (try
 to) fix them or even reimplement git for Windows (or platform
 independent with a higher focus on Windows) - the source is available
 (and with it documentation for file formats and network protocols).
 
 I do of course understand that you (or Don) personally don't have time
 for that and would prefer if it'd just work.


For me, the issue is not that it doesn't work. I actually don't mind 
that. It's only when there are claims that it does work. Denying that 
there is a problem is a great way to ensure it never gets fixed.

Same thing with D, actually -- it's important for us to be honest about 
what maturity level the language is really at.
May 20 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 00:06, schrieb Don:

 
 For me, the issue is not that it doesn't work. I actually don't mind
 that. It's only when there are claims that it does work. Denying that
 there is a problem is a great way to ensure it never gets fixed.
 
 Same thing with D, actually -- it's important for us to be honest about
 what maturity level the language is really at.


OK, I totally agree that one should be honest about bugs and the general
level of maturity of software.

I recently tried to use (and enhance) software that more or less claimed
to be stable enough for productive usage and claimed to have a plethora
of great features (scalability etc).. and when I read the code (a few
thousand lines of undocumented/uncommented ruby, *urgh*) I realized that
it was more of a dirty hack that didn't have most of the advertised
features.. that's really annoying and disappointing.
May 20 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 20/05/2011 23:06, Don wrote:

 For me, the issue is not that it doesn't work. I actually don't mind
 that. It's only when there are claims that it does work. Denying that
 there is a problem is a great way to ensure it never gets fixed.

 Same thing with D, actually -- it's important for us to be honest about
 what maturity level the language is really at.


Well said.

-- 
Bruno Medeiros - Software Engineer
May 26 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/20/2011 10:12 AM, Andrei Alexandrescu wrote:

 So it's not surprising that git/Windows has many issues, just
 the same it's not surprising that people are having trouble playing media or
 using OpenOffice on Unixen.


I gave up again on using Unix to play music. I got tired of continually having 
to reboot the machine to get it unhung.

There is one exceptional program - Thunderbird email. It works great on
Windows, 
OS X and Linux. No issues.
May 21 2011
next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Sat, 2011-05-21 at 01:23 -0700, Walter Bright wrote:
[ . . . ]

=20
 I gave up again on using Unix to play music. I got tired of continually h=


aving=20

 to reboot the machine to get it unhung.


Music plays just fine on Linux.  It also plays fine on Apple's brand of
Unix.  I haven't tried on Solaris recently.

[ . . . ]

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 21 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2011 1:47 AM, Russel Winder wrote:

 On Sat, 2011-05-21 at 01:23 -0700, Walter Bright wrote:
 [ . . . ]

 I gave up again on using Unix to play music. I got tired of continually having
 to reboot the machine to get it unhung.


 Music plays just fine on Linux.  It also plays fine on Apple's brand of
 Unix.  I haven't tried on Solaris recently.


Rhythmbox, the default music player on Ubuntu, does not. Oh, it'll work for a 
while, maybe a day or two, and then it'll freeze up. A reboot will revive it
for 
a while, and then it'll corrupt its database, which has to be deleted and
rebuilt.

Oh, and if you add some files to your shared music directory on your lan, just 
try to get Rhythmbox to rescan it and add the new files. Just try. Bah.
May 21 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Sat, 2011-05-21 at 11:15 -0700, Walter Bright wrote:
[ . . . ]

 Rhythmbox, the default music player on Ubuntu, does not. Oh, it'll work f=


or a=20

 while, maybe a day or two, and then it'll freeze up. A reboot will revive=


 it for=20

 a while, and then it'll corrupt its database, which has to be deleted and=


 rebuilt.

=20
 Oh, and if you add some files to your shared music directory on your lan,=


 just=20

 try to get Rhythmbox to rescan it and add the new files. Just try. Bah.


Your experience of Rhythmbox is totally inconsistent with my experience
of Rhythmbox.  I run it for days on end without hassle.  I am using
0.12.8 (Debian Testing), which version are you using?

Ubuntu have dropped Rhythmbox for Banshee.  Reasons unknown.
Consequences:  Ubuntu now depends on Mono even more than ever.  One
assumes Canonical will indemnify Ubuntu users against any possible M$
patent attack.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 21 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/21/2011 10:47 PM, Russel Winder wrote:

 On Sat, 2011-05-21 at 11:15 -0700, Walter Bright wrote:
 [ . . . ]

 Rhythmbox, the default music player on Ubuntu, does not. Oh, it'll work for a
 while, maybe a day or two, and then it'll freeze up. A reboot will revive it
for
 a while, and then it'll corrupt its database, which has to be deleted and
rebuilt.

 Oh, and if you add some files to your shared music directory on your lan, just
 try to get Rhythmbox to rescan it and add the new files. Just try. Bah.


 Your experience of Rhythmbox is totally inconsistent with my experience
 of Rhythmbox.  I run it for days on end without hassle.  I am using
 0.12.8 (Debian Testing), which version are you using?


0.13.1

The older versions behaved badly, too.
May 21 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 21/05/2011 09:23, Walter Bright wrote:

 On 5/20/2011 10:12 AM, Andrei Alexandrescu wrote:

 So it's not surprising that git/Windows has many issues, just
 the same it's not surprising that people are having trouble playing
 media or
 using OpenOffice on Unixen.


 I gave up again on using Unix to play music. I got tired of continually
 having to reboot the machine to get it unhung.

 There is one exceptional program - Thunderbird email. It works great on
 Windows, OS X and Linux. No issues.


What about Firefox? Seems to work just as well as Thunderbird, from what 
I hear, across all platforms.

-- 
Bruno Medeiros - Software Engineer
May 26 2011
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 20/05/2011 18:12, Andrei Alexandrescu wrote:

 I'm not surprised in the least. I was just remarking to Walter the other
 day that Unix has become the path of least resistance for doing
 programming-at-large and in particular OSS kind of work,


It definitely seems to be so for for C/C++, and in fact, the native 
compiled languages (Go, D, etc.). But not so for Java work. I use 
Windows just fine for that.
Don't know about other ecosystems.

-- 
Bruno Medeiros - Software Engineer
May 26 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 26.05.2011 18:51, schrieb Bruno Medeiros:

 On 20/05/2011 18:12, Andrei Alexandrescu wrote:

 I'm not surprised in the least. I was just remarking to Walter the other
 day that Unix has become the path of least resistance for doing
 programming-at-large and in particular OSS kind of work,


 
 It definitely seems to be so for for C/C++, and in fact, the native
 compiled languages (Go, D, etc.). But not so for Java work. I use
 Windows just fine for that.
 Don't know about other ecosystems.
 


Why not for Java? Eclipse works well on Linux, as well as Maven etc.

Or did you mean "it's as good on Windows so no reason to change"?
May 26 2011
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 26/05/2011 18:06, Daniel Gibson wrote:

 Am 26.05.2011 18:51, schrieb Bruno Medeiros:

 On 20/05/2011 18:12, Andrei Alexandrescu wrote:

 I'm not surprised in the least. I was just remarking to Walter the other
 day that Unix has become the path of least resistance for doing
 programming-at-large and in particular OSS kind of work,


 It definitely seems to be so for for C/C++, and in fact, the native
 compiled languages (Go, D, etc.). But not so for Java work. I use
 Windows just fine for that.
 Don't know about other ecosystems.


 Why not for Java? Eclipse works well on Linux, as well as Maven etc.

 Or did you mean "it's as good on Windows so no reason to change"?


That's what I meant, yes. The way I said it originally doesn't imply 
Windows is better for working with Java (just that it isn't worse)

-- 
Bruno Medeiros - Software Engineer
Jun 02 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Don" <nospam nospam.com> wrote in message 
news:ir55o4$2lhg$1 digitalmars.com...

 Here's my list of bugs in git for windows which I found in the first fews 
 days of using it:

 1. Windows git's handling of paths is completely screwed.
 If you've checked out your working copy into (say) c:\foo\bar\dmd
 and you rename a parent directory, eg to c:\foo2\bar\dmd, your working 
 copy gets hosed.
 Maybe this happens only after you've performed a git operation; didn't 
 experiment with it much.


That one's kind of funny, actually. Linus himself pretty much considers SVN 
to be total shit, and yet SVN handles that perfectly fine, while his program 
apperently doesn't.
May 20 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 20.05.2011 22:26, schrieb Nick Sabalausky:

 "Don" <nospam nospam.com> wrote in message 
 news:ir55o4$2lhg$1 digitalmars.com...

 Here's my list of bugs in git for windows which I found in the first fews 
 days of using it:

 1. Windows git's handling of paths is completely screwed.
 If you've checked out your working copy into (say) c:\foo\bar\dmd
 and you rename a parent directory, eg to c:\foo2\bar\dmd, your working 
 copy gets hosed.
 Maybe this happens only after you've performed a git operation; didn't 
 experiment with it much.


 
 That one's kind of funny, actually. Linus himself pretty much considers SVN 
 to be total shit, and yet SVN handles that perfectly fine, while his program 
 apperently doesn't.
 
 


You wouldn't really expect that Linus cares about Windows support, would
you? I guess on Linux git works really well (haven't used it much yet).

Microsofts VCS (Visual Sourcesafe or something like that) won't work
properly on Linux either..
May 20 2011
next sibling parent reply so <so so.so> writes:
On Fri, 20 May 2011 23:42:15 +0300, Daniel Gibson <metalcaedes gmail.com>  
wrote:


 Am 20.05.2011 22:26, schrieb Nick Sabalausky:

 "Don" <nospam nospam.com> wrote in message
 news:ir55o4$2lhg$1 digitalmars.com...

 Here's my list of bugs in git for windows which I found in the first  
 fews
 days of using it:

 1. Windows git's handling of paths is completely screwed.
 If you've checked out your working copy into (say) c:\foo\bar\dmd
 and you rename a parent directory, eg to c:\foo2\bar\dmd, your working
 copy gets hosed.
 Maybe this happens only after you've performed a git operation; didn't
 experiment with it much.


 That one's kind of funny, actually. Linus himself pretty much considers  
 SVN
 to be total shit, and yet SVN handles that perfectly fine, while his  
 program
 apperently doesn't.


 You wouldn't really expect that Linus cares about Windows support, would
 you?


Why not?
I fail to understand the motives of taking sides, especially for us  
developers.
Windows is shit because it is not for developers.
Linux is shit because it lacks drivers.
In both cases we are on the wrong end.

We should unite and bitch about both of them and platform dependent  
software!
May 20 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 20.05.2011 23:11, schrieb so:

 On Fri, 20 May 2011 23:42:15 +0300, Daniel Gibson
 <metalcaedes gmail.com> wrote:
 

 Am 20.05.2011 22:26, schrieb Nick Sabalausky:

 "Don" <nospam nospam.com> wrote in message
 news:ir55o4$2lhg$1 digitalmars.com...

 Here's my list of bugs in git for windows which I found in the first
 fews
 days of using it:

 1. Windows git's handling of paths is completely screwed.
 If you've checked out your working copy into (say) c:\foo\bar\dmd
 and you rename a parent directory, eg to c:\foo2\bar\dmd, your working
 copy gets hosed.
 Maybe this happens only after you've performed a git operation; didn't
 experiment with it much.


 That one's kind of funny, actually. Linus himself pretty much
 considers SVN
 to be total shit, and yet SVN handles that perfectly fine, while his
 program
 apperently doesn't.


 You wouldn't really expect that Linus cares about Windows support, would
 you?


 
 Why not?


Linus developed git because he needed a DVCS for Linux kernel
development. I don't think many Linux kernel developers use Windows..
(at least not for Linux kernel development)


 I fail to understand the motives of taking sides, especially for us
 developers.
 Windows is shit because it is not for developers.
 Linux is shit because it lacks drivers.
 In both cases we are on the wrong end.
 
 We should unite and bitch about both of them and platform dependent
 software!


So we need platform independent drivers?

Also note that Linux software tends to be more portable to other systems
than Windows software.
May 20 2011
next sibling parent reply so <so so.so> writes:
On Sat, 21 May 2011 00:18:05 +0300, Daniel Gibson <metalcaedes gmail.com>  
wrote:


 Linus developed git because he needed a DVCS for Linux kernel
 development. I don't think many Linux kernel developers use Windows..
 (at least not for Linux kernel development)


This maybe "was" the reason, but if it still is, what is all the hype  
about its being the new DVCS?
So things changed, it is not only for them.


 So we need platform independent drivers?


Absolutely.


 Also note that Linux software tends to be more portable to other systems
 than Windows software.


Well it is for starters, open :)
May 20 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 20.05.2011 23:32, schrieb so:

 On Sat, 21 May 2011 00:18:05 +0300, Daniel Gibson
 <metalcaedes gmail.com> wrote:
 

 Linus developed git because he needed a DVCS for Linux kernel
 development. I don't think many Linux kernel developers use Windows..
 (at least not for Linux kernel development)


 
 This maybe "was" the reason, but if it still is, what is all the hype
 about its being the new DVCS?
 So things changed, it is not only for them.
 


Seems like it turned out that git is so great that everybody wants to
use it. I don't see how this forces the git team to deliver a (perfect)
Windows version themselves - it's not like they're getting paid to do it
or something.


 So we need platform independent drivers?


 
 Absolutely.
 


That would mean that all OS kernels are the same, or at least similar
enough to provide a uniform interface for drivers. I don't think this
feasible.


 Also note that Linux software tends to be more portable to other systems
 than Windows software.


 
 Well it is for starters, open :)
May 20 2011
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ir6nj9$1he8$5 digitalmars.com...

 Am 20.05.2011 23:32, schrieb so:

 On Sat, 21 May 2011 00:18:05 +0300, Daniel Gibson
 <metalcaedes gmail.com> wrote:


 So we need platform independent drivers?


 Absolutely.


 That would mean that all OS kernels are the same, or at least similar
 enough to provide a uniform interface for drivers. I don't think this
 feasible.


I'd imagine there's a lot in a driver that wouldn't really need porting from 
OS to OS. Sure, the end that talks to the kernel maybe, but the other end, 
everything that talks to the hardware, I'd imagine that would be the same. 
So all you really should need would be a compatible bridge interface to the 
kernel.
May 20 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ir6m1v$1he8$3 digitalmars.com...

 Am 20.05.2011 23:11, schrieb so:

 On Fri, 20 May 2011 23:42:15 +0300, Daniel Gibson
 <metalcaedes gmail.com> wrote:


 You wouldn't really expect that Linus cares about Windows support, would
 you?


 Why not?


 Linus developed git because he needed a DVCS for Linux kernel
 development. I don't think many Linux kernel developers use Windows..
 (at least not for Linux kernel development)


If Git were still exclusively for Linux kernel dev, then that might have 
been a relevent point.


 I fail to understand the motives of taking sides, especially for us
 developers.
 Windows is shit because it is not for developers.
 Linux is shit because it lacks drivers.
 In both cases we are on the wrong end.

 We should unite and bitch about both of them and platform dependent
 software!




You may jest, but that's exactly what I do :)


 Also note that Linux software tends to be more portable to other systems
 than Windows software.


The Windows software *I* write is ported to other OSes *far* more easily 
than anything from, say, GNU for instance.
May 20 2011
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 20/05/2011 21:42, Daniel Gibson wrote:

 Microsofts VCS (Visual Sourcesafe or something like that) won't work
 properly on Linux either..


I wouldn't really compare Visual Sourcesafe to git... It barely 
qualifies as a version control system :3

What, someone else has "checked out" a file, so I can't write a quick 
bugfix in that file until they're done? Pfft.

I wouldn't /want/ that on linux ;p

-- 
Robert
http://octarineparrot.com/
May 20 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 20.05.2011 23:17, schrieb Robert Clipsham:

 On 20/05/2011 21:42, Daniel Gibson wrote:

 Microsofts VCS (Visual Sourcesafe or something like that) won't work
 properly on Linux either..


 
 I wouldn't really compare Visual Sourcesafe to git... It barely
 qualifies as a version control system :3


I think MS doesn't have anything that comes closer to a VCS, so there
was nothing else I could have used that comparison ;)


 
 What, someone else has "checked out" a file, so I can't write a quick
 bugfix in that file until they're done? Pfft.
 
 I wouldn't /want/ that on linux ;p
May 20 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Fri, 2011-05-20 at 23:19 +0200, Daniel Gibson wrote:

 Am 20.05.2011 23:17, schrieb Robert Clipsham:

 On 20/05/2011 21:42, Daniel Gibson wrote:

 Microsofts VCS (Visual Sourcesafe or something like that) won't work
 properly on Linux either..


=20
 I wouldn't really compare Visual Sourcesafe to git... It barely
 qualifies as a version control system :3


=20
 I think MS doesn't have anything that comes closer to a VCS, so there
 was nothing else I could have used that comparison ;)


Not entirely true, they have Team Foundation Server (including Team
Foundation Version Control) which is reputed to work reasonably well,
especially with Visual Studio.  On the other hand I have no first hand
experience as it requires Windows Server, IIS, and SharePoint.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 20 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 08:15, schrieb Russel Winder:

 On Fri, 2011-05-20 at 23:19 +0200, Daniel Gibson wrote:

 Am 20.05.2011 23:17, schrieb Robert Clipsham:

 On 20/05/2011 21:42, Daniel Gibson wrote:

 Microsofts VCS (Visual Sourcesafe or something like that) won't work
 properly on Linux either..


 I wouldn't really compare Visual Sourcesafe to git... It barely
 qualifies as a version control system :3


 I think MS doesn't have anything that comes closer to a VCS, so there
 was nothing else I could have used that comparison ;)


 Not entirely true, they have Team Foundation Server (including Team
 Foundation Version Control) which is reputed to work reasonably well,
 especially with Visual Studio.  On the other hand I have no first hand
 experience as it requires Windows Server, IIS, and SharePoint.


OK, I'm not really familiar with Microsoft tools.
I guess MS doesn't provide a Linux client for that either. ;)
May 21 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Sat, 2011-05-21 at 12:00 +0200, Daniel Gibson wrote:

 Am 21.05.2011 08:15, schrieb Russel Winder:

 On Fri, 2011-05-20 at 23:19 +0200, Daniel Gibson wrote:

 Am 20.05.2011 23:17, schrieb Robert Clipsham:

 On 20/05/2011 21:42, Daniel Gibson wrote:

 Microsofts VCS (Visual Sourcesafe or something like that) won't work
 properly on Linux either..


 I wouldn't really compare Visual Sourcesafe to git... It barely
 qualifies as a version control system :3


 I think MS doesn't have anything that comes closer to a VCS, so there
 was nothing else I could have used that comparison ;)


 Not entirely true, they have Team Foundation Server (including Team
 Foundation Version Control) which is reputed to work reasonably well,
 especially with Visual Studio.  On the other hand I have no first hand
 experience as it requires Windows Server, IIS, and SharePoint.


=20
 OK, I'm not really familiar with Microsoft tools.
 I guess MS doesn't provide a Linux client for that either. ;)


Definitely not -- after all why would Microsoft even contemplate that
you were going to buy anything other than Microsoft product -- but there
are various plug-ins for Eclipse, IntelliJ IDEA, etc. to allow them to
make checkouts of TFS hosted repositories.  It's just web services so no
big deal.  Though the conspiracy theorists will undoubtedly want to
worry about all the hidden checks etc. to hobble non-Microsoft products.

Personally I'll just stick with Bazaar, Mercurial and Git.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 21 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 13:13, schrieb Russel Winder:

 On Sat, 2011-05-21 at 12:00 +0200, Daniel Gibson wrote:

 Am 21.05.2011 08:15, schrieb Russel Winder:

 On Fri, 2011-05-20 at 23:19 +0200, Daniel Gibson wrote:

 Am 20.05.2011 23:17, schrieb Robert Clipsham:

 On 20/05/2011 21:42, Daniel Gibson wrote:

 Microsofts VCS (Visual Sourcesafe or something like that) won't work
 properly on Linux either..


 I wouldn't really compare Visual Sourcesafe to git... It barely
 qualifies as a version control system :3


 I think MS doesn't have anything that comes closer to a VCS, so there
 was nothing else I could have used that comparison ;)


 Not entirely true, they have Team Foundation Server (including Team
 Foundation Version Control) which is reputed to work reasonably well,
 especially with Visual Studio.  On the other hand I have no first hand
 experience as it requires Windows Server, IIS, and SharePoint.


 OK, I'm not really familiar with Microsoft tools.
 I guess MS doesn't provide a Linux client for that either. ;)


 Definitely not -- after all why would Microsoft even contemplate that
 you were going to buy anything other than Microsoft product


that's about my point about git and windows ;)


 -- but there
 are various plug-ins for Eclipse, IntelliJ IDEA, etc. to allow them to
 make checkouts of TFS hosted repositories.


Could be similar for git. In fact JGIT exists and eclipse and netbeans 
plugins that use JGIT.


 It's just web services so no
 big deal.  Though the conspiracy theorists will undoubtedly want to
 worry about all the hidden checks etc. to hobble non-Microsoft products.

 Personally I'll just stick with Bazaar, Mercurial and Git.
May 21 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ir6jup$1he8$1 digitalmars.com...

 Am 20.05.2011 22:26, schrieb Nick Sabalausky:

 "Don" <nospam nospam.com> wrote in message
 news:ir55o4$2lhg$1 digitalmars.com...

 Here's my list of bugs in git for windows which I found in the first 
 fews
 days of using it:

 1. Windows git's handling of paths is completely screwed.
 If you've checked out your working copy into (say) c:\foo\bar\dmd
 and you rename a parent directory, eg to c:\foo2\bar\dmd, your working
 copy gets hosed.
 Maybe this happens only after you've performed a git operation; didn't
 experiment with it much.


 That one's kind of funny, actually. Linus himself pretty much considers 
 SVN
 to be total shit, and yet SVN handles that perfectly fine, while his 
 program
 apperently doesn't.


 You wouldn't really expect that Linus cares about Windows support, would
 you? I guess on Linux git works really well (haven't used it much yet).

 Microsofts VCS (Visual Sourcesafe or something like that) won't work
 properly on Linux either..


Microsoft is a corporation. So by definition, self-interested (Besides, VSS 
is rightfully dead anyway). Linus isn't a corporation and he isn't selling 
Linux. But he is, presumably, a self-respecting software developer and not a 
self-righteous ass that's out to throw his weight around at any whim (or is 
he?). So why not?
May 20 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 00:15, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:ir6jup$1he8$1 digitalmars.com...

 Am 20.05.2011 22:26, schrieb Nick Sabalausky:

 "Don" <nospam nospam.com> wrote in message
 news:ir55o4$2lhg$1 digitalmars.com...

 Here's my list of bugs in git for windows which I found in the first 
 fews
 days of using it:

 1. Windows git's handling of paths is completely screwed.
 If you've checked out your working copy into (say) c:\foo\bar\dmd
 and you rename a parent directory, eg to c:\foo2\bar\dmd, your working
 copy gets hosed.
 Maybe this happens only after you've performed a git operation; didn't
 experiment with it much.


 That one's kind of funny, actually. Linus himself pretty much considers 
 SVN
 to be total shit, and yet SVN handles that perfectly fine, while his 
 program
 apperently doesn't.


 You wouldn't really expect that Linus cares about Windows support, would
 you? I guess on Linux git works really well (haven't used it much yet).

 Microsofts VCS (Visual Sourcesafe or something like that) won't work
 properly on Linux either..


 
 Microsoft is a corporation. So by definition, self-interested (Besides, VSS 
 is rightfully dead anyway). Linus isn't a corporation and he isn't selling 
 Linux. But he is, presumably, a self-respecting software developer and not a 
 self-righteous ass that's out to throw his weight around at any whim (or is 
 he?). So why not?
 


Yeah, Linus is not a corporation, he doesn't get paid to develop git, so
why should he spend his precious time for Windows support that he (and
his targeted userbase, i.e. Linux kernel developers) doesn't need?
May 20 2011
next sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 5/21/11 12:17 AM, Daniel Gibson wrote:

 Yeah, Linus is not a corporation, he doesn't get paid to develop git, so
 why should he spend his precious time for Windows support that he (and
 his targeted userbase, i.e. Linux kernel developers) doesn't need?


As Linus' name has been mentioned in this thread quite a number of 
times, I think it should be noted that he isn't the maintainer of Git 
anymore since more than five years ago…

David
May 20 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 00:26, schrieb David Nadlinger:

 On 5/21/11 12:17 AM, Daniel Gibson wrote:

 Yeah, Linus is not a corporation, he doesn't get paid to develop git, so
 why should he spend his precious time for Windows support that he (and
 his targeted userbase, i.e. Linux kernel developers) doesn't need?


 
 As Linus' name has been mentioned in this thread quite a number of
 times, I think it should be noted that he isn't the maintainer of Git
 anymore since more than five years ago…
 
 David


Yeah, but he invented it and I guess it's his fault that it depends
heavily on bash - which, if I understood correctly, is the main reason
for git being awkward on Windows.
May 20 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ir6ph4$1he8$7 digitalmars.com...

 Am 21.05.2011 00:15, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:ir6jup$1he8$1 digitalmars.com...

 Am 20.05.2011 22:26, schrieb Nick Sabalausky:

 "Don" <nospam nospam.com> wrote in message
 news:ir55o4$2lhg$1 digitalmars.com...

 Here's my list of bugs in git for windows which I found in the first
 fews
 days of using it:

 1. Windows git's handling of paths is completely screwed.
 If you've checked out your working copy into (say) c:\foo\bar\dmd
 and you rename a parent directory, eg to c:\foo2\bar\dmd, your working
 copy gets hosed.
 Maybe this happens only after you've performed a git operation; didn't
 experiment with it much.


 That one's kind of funny, actually. Linus himself pretty much considers
 SVN
 to be total shit, and yet SVN handles that perfectly fine, while his
 program
 apperently doesn't.


 You wouldn't really expect that Linus cares about Windows support, would
 you? I guess on Linux git works really well (haven't used it much yet).

 Microsofts VCS (Visual Sourcesafe or something like that) won't work
 properly on Linux either..


 Microsoft is a corporation. So by definition, self-interested (Besides, 
 VSS
 is rightfully dead anyway). Linus isn't a corporation and he isn't 
 selling
 Linux. But he is, presumably, a self-respecting software developer and 
 not a
 self-righteous ass that's out to throw his weight around at any whim (or 
 is
 he?). So why not?


 Yeah, Linus is not a corporation, he doesn't get paid to develop git, so
 why should he spend his precious time for Windows support that he (and
 his targeted userbase, i.e. Linux kernel developers) doesn't need?


Because it makes it a better product and, presumably, he cares about his 
software being good. And like I said, *I* make damn sure my software is 
sensibly cross-platform, and of all the things I bitch about, sensibly 
supporting another major OS has never been one of them. And the fact that I 
didn't write Windows doesn't invalidate the comparison: If I wrote OSS 
program A that was an alternative to program B, and then I wrote OSS program 
X that interacted with program A, you can be damn sure I'd be interested in 
X being compatible with B, too.
May 20 2011
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Fri, 2011-05-20 at 22:42 +0200, Daniel Gibson wrote:
[ . . . ]

 Microsofts VCS (Visual Sourcesafe or something like that) won't work
 properly on Linux either..


Visual SourceSafe doesn't work on Windows either.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 20 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Russel Winder" <russel russel.org.uk> wrote in message 
news:mailman.301.1305958019.14074.digitalmars-d puremagic.com...

On Fri, 2011-05-20 at 22:42 +0200, Daniel Gibson wrote:
[ . . . ]

 Microsofts VCS (Visual Sourcesafe or something like that) won't work
 properly on Linux either..


Visual SourceSafe doesn't work on Windows either.


Well, I don't know about that, now. Let's not be too hasty... After all, are 
we really *certain* what the primary purpose of VSS is? Sure we all *assume* 
it's a VCS. But if it's really a tool to piss of programmers and make them 
prematurely grow grey hair, then I'd say it works fantastically!
May 20 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/20/2011 11:06 PM, Russel Winder wrote:

 On Fri, 2011-05-20 at 22:42 +0200, Daniel Gibson wrote:
 [ . . . ]

 Microsofts VCS (Visual Sourcesafe or something like that) won't work
 properly on Linux either..


 Visual SourceSafe doesn't work on Windows either.



Ouch!
May 21 2011
prev sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Don Wrote:


 No, fanboyism is evidenced in dismissing a list of bugs. I think that 
 was a darn good list.


 
Based on what you have described it sounds like most of your problems come with
using poorly ported Linux programs and not with the Windows port of Git.

You had symbolic links and mounted files, those don't exist in Windows.
Junctions exist for NTFS, but I doubt that is what you refer.

I happily run git in powershell with assistance from gvim.
May 20 2011
parent reply Don <nospam nospam.com> writes:
Jesse Phillips wrote:

 Don Wrote:
 

 No, fanboyism is evidenced in dismissing a list of bugs. I think that 
 was a darn good list.


  
 Based on what you have described it sounds like most of your problems come
with using poorly ported Linux programs and not with the Windows port of Git.
 
 You had symbolic links and mounted files, those don't exist in Windows.
Junctions exist for NTFS, but I doubt that is what you refer.


They're not symbolic links. Just junctions.
They're the only vaguely unusual thing on my machine.
I've never had any similar problem with anything other than git.


 I happily run git in powershell with assistance from gvim.
May 21 2011
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 21 May 2011 11:31:06 +0300, Don <nospam nospam.com> wrote:


 Jesse Phillips wrote:

 Don Wrote:


 No, fanboyism is evidenced in dismissing a list of bugs. I think that  
 was a darn good list.


  Based on what you have described it sounds like most of your problems  
 come with using poorly ported Linux programs and not with the Windows  
 port of Git.
  You had symbolic links and mounted files, those don't exist in  
 Windows. Junctions exist for NTFS, but I doubt that is what you refer.


 They're not symbolic links. Just junctions.
 They're the only vaguely unusual thing on my machine.
 I've never had any similar problem with anything other than git.


I use junctions a lot. I never had such problems with them. Your problems  
originate elsewhere.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 21 2011