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

• Andrej Mitrovic (4/4) May 19 2011 I'm not sure when these came out, but the last time I've tried using git...
• Nick Sabalausky (16/27) May 19 2011 I came across some instructions somewhere that involved using something
• Robert Clipsham (9/13) May 19 2011 Mercurial has rebase too, just as an extension. Rebase is incredibly
• Trass3r (3/8) May 19 2011 Yeah, unfortunately most people don't even seem to know about rebase.
• Nick Sabalausky (5/9) May 19 2011 Heh, I just noticed that the guy who keeps insisting that a breaking bug...
• Kagamin (2/14) May 20 2011 What politics? If there's less interoperability between linux and window...
• Nick Sabalausky (9/25) May 20 2011 If XYZ works on Ubuntu/Linux and not on Windows, that benefits Ubuntu/Li...
• Kagamin (3/14) May 23 2011 That's a resource management. Because no windows user uses their piece o...
• Jacob Carlborg (5/35) May 19 2011 If it's possible, I would recommend using git via Linux, Mac OS X or
• Don (34/62) May 20 2011 Here's my list of bugs in git for windows which I found in the first
• Vladimir Panteleev (13/16) May 20 2011 You've mentioned some fairly untypical usage, so it's not surprising you...
• Kagamin (2/3) May 20 2011 I wonder, whether stock portablegit has useless bonuses.
• Don (28/46) May 20 2011 Because it has slightly fewer bugs than the other alternatives.
• David Nadlinger (3/5) May 20 2011 Are you maybe using an older Git version from the regular command line?
• Vladimir Panteleev (24/45) May 20 2011 You wouldn't consider using msysgit's bash shell and utilities on an AD ...
• Nick Sabalausky (16/37) May 20 2011 Half of github's "setting up on windows" instructions (
• Vladimir Panteleev (16/64) May 20 2011 Good point (one can argue why Github chose to instruct users to use bash...
• Don (30/82) May 20 2011 Yeah, I would have thought so. I wouldn't expect to find the root cause
• Andrej Mitrovic (24/24) May 20 2011 What the duck has happened to this topic?
• Walter Bright (4/10) May 21 2011 What I do is rm -rf the entire project directory, then re-clone it from ...
• Andrej Mitrovic (8/20) May 22 2011 Turns out all I had to do after I commited was edit the file I messed
• David Nadlinger (18/24) May 21 2011 If you just want to modify the commit, e.g. because you made a typo in
• Andrej Mitrovic (4/5) May 21 2011 These are great, thanks. In fact, all of these tips deserve to be put
• Andrej Mitrovic (5/7) May 21 2011 That's great.
• Andrej Mitrovic (4/13) May 21 2011 Nevermind, it's already linked from
• Andrej Mitrovic (5/5) May 21 2011 Ok so apparently the reason why ~ would be added on delete is because
• Andrej Mitrovic (5/5) May 21 2011 Well setting up the diff tool was a bitch. msysgit/git doesn't like
• Vladimir Panteleev (7/12) May 21 2011 Do you mean a custom diff tool, or perhaps a merge tool? git comes with ...
• Andrej Mitrovic (5/5) May 21 2011 So I did "git log --stat" on one of my test repos to view my logs,
• Andrej Mitrovic (2/2) May 21 2011 Yeah it comes with a diff command, I was trying to set up a custom one
• Andrej Mitrovic (1/1) May 21 2011 It was 'q'. I had to hit q. Well who would have thought.
• Walter Bright (4/5) May 21 2011 I was reading an article about older folks having problems setting the a...
• Andrej Mitrovic (7/14) May 21 2011 I took a look at the man-page (btw. for those not in the know, it's
• Lutger Blijdestijn (4/6) May 21 2011 I like git cola for gui. I has some nice features such as picking the li...
• Vladimir Panteleev (10/16) May 21 2011 git gui can do that too (right-click on a line, select "stage line for
• Lutger Blijdestijn (34/57) May 21 2011 I recently starting using interactive rebasing which is a tremendous hel...
• Andrej Mitrovic (6/8) May 21 2011 Ah, this could be quite useful. In one instance I've made a change,
• David Nadlinger (8/16) May 21 2011 Yes: Let's assume you have some commits A, B, C, D, E on your branch.
• Andrej Mitrovic (2/2) May 21 2011 Anywho, I'll start reading this http://progit.org/book/ to get the
• Lutger Blijdestijn (5/7) May 21 2011 That's a good book. I recommend to read closely chapter 3 and 9, goof ar...
• Vladimir Panteleev (20/37) May 20 2011 Sorry, but did you read the bug report and the whole comment you linked ...
• Andrej Mitrovic (9/9) May 20 2011 I think all I have to do is actually click the "Pull Request" button.
• David Nadlinger (7/10) May 20 2011 You should give it a sensible title, because that's what appears in the
• Don (12/43) May 21 2011 I don't even know what a text mount is. (That's a quote from the page).
• Vladimir Panteleev (14/26) May 21 2011 Well, there you have the main point of our argument: your experience wit...
• Daniel Gibson (6/50) May 21 2011 By the way: Have you ever tried JGIT? http://www.eclipse.org/jgit/
• Bruno Medeiros (13/69) May 26 2011 Yeah, it's a pure Java implementation, and thus much more portable. From...
• David Nadlinger (5/8) May 20 2011 So, just to make this clear, you are using Git via Cygwin instead of
• Don (4/15) May 21 2011 Which ones aren't bugs? Yes, there's one which is just a poorly written
• Walter Bright (5/7) May 21 2011 Reminds me of when I tried to run Latex on Windows. What a disaster.
• Robert Clipsham (7/15) May 21 2011 The install instructions mentioned eariler that started this whole
• Walter Bright (15/18) May 21 2011 There seem to be at least 6 ways of dealing with this on git. The docume...
• Robert Clipsham (8/16) May 21 2011 Also, doesn't your editor leave line endings in tact? Every editor I've
• Walter Bright (6/9) May 21 2011 My editor sets the line endings to match the default of the OS it is run...
• Nick Sabalausky (8/20) May 21 2011 I'm becoming convinced that just using Unix-style \n even on Windows is
• Russel Winder (15/18) May 21 2011 at you,=20
• Robert Clipsham (6/11) May 20 2011 Have you reported any of these issues?
• Jesse Phillips (14/48) May 20 2011 May have done this without thinking about it, but I'd remember if I'd ru...
• bearophile (4/6) May 20 2011 Have you reported those bugs to the devs, or are they known bugs?
• Andrei Alexandrescu (14/17) May 20 2011 Fanboyism for Windows or git? :o)
• Nick Sabalausky (17/33) May 20 2011 I realize you're not actually accusing him of Windows fanboyism, but tha...
• Daniel Gibson (20/61) May 20 2011 It's the same when it's the other way round. "You can't properly view
• Nick Sabalausky (31/97) May 20 2011 Yea, but 99.9% those are just moron office drones who barely even know h...
• Daniel Gibson (16/125) May 20 2011 Isn't mingw just a port of GCC, GDB etc? I don't think using it to build
• Nick Sabalausky (6/22) May 20 2011 *shrug* All I know is that I've dealt with stuff that required it before...
• Daniel Gibson (8/36) May 20 2011 Why? MSYS and mingw are available on Windows and mingw is even available
• Nick Sabalausky (8/26) May 20 2011 The way I see it, msys and mingw are total pains in the ass that should
• Andrej Mitrovic (4/4) May 20 2011 I'm ok with msysgit simulating a linux shell, it's not too hard to use
• Daniel Gibson (7/37) May 20 2011 Come on, that comparison is BS.
• Nick Sabalausky (4/43) May 20 2011 In other words, Wine does even *more* to make windows programs work on
• Daniel Gibson (11/57) May 20 2011 Of course, because more is needed, because they're less portable.
• Andrej Mitrovic (3/3) May 20 2011 Okie, the pull is here:
• David Nadlinger (11/13) May 20 2011 Because, at least in my eyes, there is a huge difference between telling...
• Nick Sabalausky (11/23) May 20 2011 OSS programs, which most Linux programs are, are expected to be compilab...
• Daniel Gibson (6/37) May 20 2011 Compiling on Windows always sucks and is generally not done by the end
• Andrej Mitrovic (6/6) May 20 2011 What's there to configuring visual studio? You just open a solution
• Daniel Gibson (7/15) May 20 2011 I don't have much experience with visual studio, but I've read that
• Robert Clipsham (7/22) May 20 2011 Each version contains a migration tool, which has worked reasonably well...
• Lutger Blijdestijn (15/31) May 21 2011 Going from one version of a *solution* to the next usually just works. I...
• Daniel Gibson (11/41) May 21 2011 Probably that was the problem.
• David Nadlinger (8/12) May 21 2011 I have encountered quite a few problems though. For example, 64 bit code...
• Lutger Blijdestijn (2/17) May 21 2011 ouch, that sucks. Wikipedia suggests this works now for 2010 though.
• Nick Sabalausky (6/34) May 20 2011 My experience has been the other way around. Besides, a *lot* of windows...
• Vladimir Panteleev (7/11) May 21 2011 I frequently hear that Visual Studio is the all-round best IDE for C/C++...
• Bruno Medeiros (5/13) May 26 2011 For programs intended to run on Windows, sure. But for example, for
• Daniel Gibson (6/42) May 21 2011 So how do you compile C/C++ code on windows? DMC? Fine for your code but...
• Kagamin (2/6) May 24 2011 Didn't use msys, but stock mingw+make work just fine for me (I've made s...
• Michel Fortin (10/15) May 20 2011 Sometime wanting to get to every platform at first try puts
• Nick Sabalausky (15/26) May 20 2011 I guess for all I know that might be the case for some people in some
• Don (6/68) May 20 2011 For me, the issue is not that it doesn't work. I actually don't mind
• Daniel Gibson (9/16) May 20 2011 OK, I totally agree that one should be honest about bugs and the general
• Bruno Medeiros (4/9) May 26 2011 Well said.
• Walter Bright (5/8) May 21 2011 I gave up again on using Unix to play music. I got tired of continually ...
• Bruno Medeiros (7/10) May 26 2011 It definitely seems to be so for for C/C++, and in fact, the native
• Daniel Gibson (3/13) May 26 2011 Why not for Java? Eclipse works well on Linux, as well as Maven etc.
• Bruno Medeiros (5/18) Jun 02 2011 That's what I meant, yes. The way I said it originally doesn't imply
• Nick Sabalausky (5/13) May 20 2011 That one's kind of funny, actually. Linus himself pretty much considers ...
• Daniel Gibson (5/23) May 20 2011 You wouldn't really expect that Linus cares about Windows support, would
• so (10/34) May 20 2011 Why not?
• Daniel Gibson (7/45) May 20 2011 Linus developed git because he needed a DVCS for Linux kernel
• so (7/13) May 20 2011 This maybe "was" the reason, but if it still is, what is all the hype
• Daniel Gibson (8/27) May 20 2011 Seems like it turned out that git is so great that everybody wants to
• Nick Sabalausky (7/18) May 20 2011 I'd imagine there's a lot in a driver that wouldn't really need porting ...
• Nick Sabalausky (7/29) May 20 2011 If Git were still exclusively for Linux kernel dev, then that might have...
• Robert Clipsham (9/11) May 20 2011 I wouldn't really compare Visual Sourcesafe to git... It barely
• Daniel Gibson (3/15) May 20 2011 I think MS doesn't have anything that comes closer to a VCS, so there
• Russel Winder (15/25) May 20 2011 Not entirely true, they have Team Foundation Server (including Team
• Daniel Gibson (3/18) May 21 2011 OK, I'm not really familiar with Microsoft tools.
• Russel Winder (18/39) May 21 2011 Definitely not -- after all why would Microsoft even contemplate that
• Daniel Gibson (4/35) May 21 2011 Could be similar for git. In fact JGIT exists and eclipse and netbeans
• Nick Sabalausky (7/33) May 20 2011 Microsoft is a corporation. So by definition, self-interested (Besides, ...
• Daniel Gibson (4/41) May 20 2011 Yeah, Linus is not a corporation, he doesn't get paid to develop git, so
• David Nadlinger (5/8) May 20 2011 As Linus' name has been mentioned in this thread quite a number of
• Daniel Gibson (4/14) May 20 2011 Yeah, but he invented it and I guess it's his fault that it depends
• Nick Sabalausky (10/55) May 20 2011 Because it makes it a better product and, presumably, he cares about his...
• Russel Winder (13/15) May 20 2011 Visual SourceSafe doesn't work on Windows either.
• Nick Sabalausky (6/11) May 20 2011 Well, I don't know about that, now. Let's not be too hasty... After all,...
• Walter Bright (2/7) May 21 2011 Ouch!
• Jesse Phillips (5/7) May 20 2011
• Don (4/13) May 21 2011 They're not symbolic links. Just junctions.
• Vladimir Panteleev (6/19) May 21 2011 I use junctions a lot. I never had such problems with them. Your problem...
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
"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:

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:
able to start using hg-git/TortoiseHg instead of putting up with the
convoluted mess that git is...(Rebase? Seriously?!)

May 19 2011
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:
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
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
"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
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
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
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

May 20 2011
"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
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,

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
Kagamin <spam here.lot> writes:
Nick Sabalausky Wrote:

What politics? If there's less interoperability between linux and windows,

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
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:

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:
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
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:

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
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,

May 20 2011
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
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*
encountered severe data corruption (similar to bug #1 on my list).
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
# On branch ctfe5966
# Untracked files:
....<etc, this bit works OK>
#       test/runnable/xtest46.obj
#       test/test_results/
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
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
On Fri, 20 May 2011 17:52:53 +0300, Don <nospam nospam.com> 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.

Problems #6 and #7 on your list, maybe even #1 and #2 are msys problems.
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,

May 20 2011
"Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message
On Fri, 20 May 2011 17:52:53 +0300, Don <nospam nospam.com> 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.

Problems #6 and #7 on your list, maybe even #1 and #2 are msys problems.
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
On Fri, 20 May 2011 23:12:54 +0300, Nick Sabalausky <a a.a> wrote:

On Fri, 20 May 2011 17:52:53 +0300, Don <nospam nospam.com> 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.

Problems #6 and #7 on your list, maybe even #1 and #2 are msys problems.
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,

May 20 2011
Don <nospam nospam.com> writes:
Vladimir Panteleev wrote:
On Fri, 20 May 2011 17:52:53 +0300, Don <nospam nospam.com> 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.

Problems #6 and #7 on your list, maybe even #1 and #2 are msys problems.
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
first described as bug #21, yes TWENTY ONE in the msysgit database.

---
"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
----
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
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 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 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 "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 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 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 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 "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 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 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 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 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 "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 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 "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 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 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 Andrej Mitrovic <andrej.mitrovich gmail.com> writes: It was 'q'. I had to hit q. Well who would have thought.  May 21 2011 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 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 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 "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 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 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 *

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
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
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
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
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

May 21 2011
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
first described as bug #21, yes TWENTY ONE in the msysgit 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
----
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.

(with my own observations and suggestions), but that would have definitely
landed me a "fanboy" label...

--
Best regards,

May 20 2011
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
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
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
cause first described as bug #21, yes TWENTY ONE in the msysgit 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
----
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:
* 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
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:
* 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,

May 21 2011
Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.05.2011 11:28, schrieb Don:
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 first described as bug #21, yes TWENTY ONE in the msysgit
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
----
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:
* 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
Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 21/05/2011 11:02, Daniel Gibson wrote:
Am 21.05.2011 11:28, schrieb Don:
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 first described as bug #21, yes TWENTY ONE in the msysgit
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
----
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:
* 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
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
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
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
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
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
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
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
"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
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).

Any Sh/Bash/Csh script with a #! line with CRLF on the end fails
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
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
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
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
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
"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
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
"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
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
"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
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
"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
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
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
"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
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
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
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
"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
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
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

At least that's my experience.

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

May 20 2011
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

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
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

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
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

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
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

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
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

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
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
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
"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
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,

May 21 2011
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
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
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
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
"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
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
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
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
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
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
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.

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

May 21 2011
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

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 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 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 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 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 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 "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 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 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 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 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 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 "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 "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 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 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 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 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 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 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 "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 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 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 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 "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
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
"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
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
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
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
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.
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,