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

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

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

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
On 5/20/11 11:47 PM, Don wrote:
Still not fixed in cygwin in 2011.

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.

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.

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.

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
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
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 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
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
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/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 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 commit --amend â€¦

(This will obviously change an existing commit, don't do it if you have

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

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
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
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
Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Andrej Mitrovic wrote:

What the duck has happened to this topic?

Ok anyway, I found out a few things:

I can change $HOME by adding this line into C:\Program Files\Git\etc\profile file: HOME="/d/dev/git/" right *above* this line: HOME="$(cd "$HOME" ; pwd)" This was from someone's blogs post. And then if I want to start git bash from a different initial directory I just change the git bash shortcut "Start In" field to whatever directory. Anyways I've made a bunch of commits to my forked repo of dpl.org, and now have to figure out how to make a pull request. I haven't made any branches or anything because I'm way too new to this. I would also like to know how to uncommit a change which hasn't been pushed yet. So if I locally do: git add someFile.d git commit -m "woops wrong comment" I recently starting using interactive rebasing which is a tremendous help for these kind of situations. This is usually what I do: start a branch for work on feature foo: git checkout -b foo * do a bunch of commits on foo * update master with newest changes: git checkout master git pull when foo is done, rebase it on top of master: git checkout foo git rebase -i master This will popup your editor and let you squash some commits together and edit the message. The text in your editor is fairly self-explanatory. It also 'replays' the commits on top of those from master you have pulled in *after* creating the foo branch. This helps with two things: you can resolve any conflicts inside the foo branch and prevents annoying merge commits. It will look in history like you have starting the foo branch from the latest commit from master. Sometimes this is not what you want, but most of the time it makes sense. From here you can either merge it with master (it will fast-forward) and push to github, or push the foo branch to a foo branch on github. Doing interactive rebasing like this allows you to organize the series of commits and messages *after* you are done developing something, resulting in very nice pull requests. There is one thing you should never do: rebase a branch which you have already pushed to some place other people can see / use / depend on. Then you are taking away the history on which people have build. It is to be used strictly with private branches. I use this workflow to work concurrently on lot's of different topics, each in a seperate branch. Without rebasing the history will be cluttered with merge commits. I also don't have to worry anymore about other people when I commit, since making nice messages and such is postponed to the point of a rebase. This makes life much more pleasant.  May 21 2011 Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes: Andrej Mitrovic wrote: Anywho, I'll start reading this http://progit.org/book/ to get the hang of things. That's a good book. I recommend to read closely chapter 3 and 9, goof around in a test repo and browse the .git/refs directory. Doing that made me understand how simple the core of git really is and then a lot of commands suddenly made much more sense.  May 21 2011 David Nadlinger <see klickverbot.at> writes: On 5/21/11 2:04 PM, Andrej Mitrovic wrote: On 5/21/11, Lutger Blijdestijn<lutger.blijdestijn gmail.com> wrote: I recently starting using interactive rebasing which is a tremendous help for these kind of situations. This is usually what I do:<snip> Ah, this could be quite useful. In one instance I've made a change, committed (locally) and then found a typo in the code and had to make another commit just to fix a typo I've introduced. So I could use rebasing here (like merging two changes into one, I guess I can do that?). Yes: Let's assume you have some commits A, B, C, D, E on your branch. Using Â»git rebase -i/--interactive HEAD~5Â«, you could choose to drop commit A altogether, merge C into B, and stop at commit D for editing. Due to the comments in the generated file and the verbose console messages, Â»git rebase -iÂ« is pretty much self-explanatory, just give it a try! David  May 21 2011 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 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: 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 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 David Nadlinger <see klickverbot.at> writes: On 5/21/11 12:34 AM, Nick Sabalausky wrote: And again, using Wine doesn't count as supporting Linux, so why the hell should the other way around be any different? Because, at least in my eyes, there is a huge difference between telling your users that using Wine they might be able to get your software to work on Linux (which is typically the most you can hope for if you are a Linux user), and using MinGW to make porting your application to Windows easier, which is not necessarily visible to the end user. (Yes, Wine is occasionally used by software vendors themselves as well, like in the form of Transgaming Cider by Riot Games for the Mac version of their League of Legends game, but I hope you'll agree that this is not what one typically thinks about when Wine is mentioned.) David  May 20 2011 "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 Daniel Gibson <metalcaedes gmail.com> writes: Am 21.05.2011 01:34, schrieb Andrej Mitrovic: What's there to configuring visual studio? You just open a solution file and hit compile. If there are any dependencies you usually download the libs and put them in some subfolder. I don't have much experience with visual studio, but I've read that using a project from one version in another (newer) version may not always be painless, e.g. http://twitter.com/#!/ID_AA_Carmack/status/45616436995039232 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 download the libs and put them in some subfolder. I don't have much experience with visual studio, but I've read that using a project from one version in another (newer) version may not always be painless, e.g. http://twitter.com/#!/ID_AA_Carmack/status/45616436995039232 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 download the libs and put them in some subfolder. I don't have much experience with visual studio, but I've read that using a project from one version in another (newer) version may not always be painless, e.g. http://twitter.com/#!/ID_AA_Carmack/status/45616436995039232 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 download the libs and put them in some subfolder. I don't have much experience with visual studio, but I've read that using a project from one version in another (newer) version may not always be painless, e.g. http://twitter.com/#!/ID_AA_Carmack/status/45616436995039232 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 download the libs and put them in some subfolder. I don't have much experience with visual studio, but I've read that using a project from one version in another (newer) version may not always be painless, e.g. http://twitter.com/#!/ID_AA_Carmack/status/45616436995039232 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 David Nadlinger <see klickverbot.at> writes: On 5/21/11 1:09 PM, Lutger Blijdestijn wrote: And how well do projects from a professional version work in the free (Visual Studio Express) version? That should work, the professional version is mostly about extra ide features, the basics and the toolchain is exactly the same. I have encountered quite a few problems though. For example, 64 bit code generation used to be absent by default from Express versions (maybe it still is, haven't checked), which is a sensible marketing decision per se. However, it was implemented in such a way that I couldn't open a solution file from an open source project I was working on with my Express edition installation, just because it contained an x64 targetâ€¦ David  May 21 2011 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 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 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 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". 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. 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 Walter Bright <newshound2 digitalmars.com> writes: On 5/21/2011 1:47 AM, Russel Winder wrote: On Sat, 2011-05-21 at 01:23 -0700, Walter Bright wrote: [ . . . ] I gave up again on using Unix to play music. I got tired of continually having to reboot the machine to get it unhung. Music plays just fine on Linux. It also plays fine on Apple's brand of Unix. I haven't tried on Solaris recently. Rhythmbox, the default music player on Ubuntu, does not. Oh, it'll work for a while, maybe a day or two, and then it'll freeze up. A reboot will revive it for a while, and then it'll corrupt its database, which has to be deleted and rebuilt. Oh, and if you add some files to your shared music directory on your lan, just try to get Rhythmbox to rescan it and add the new files. Just try. Bah.  May 21 2011 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 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 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 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 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 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 "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 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 "Vladimir Panteleev" <vladimir thecybershadow.net> writes: On Fri, 20 May 2011 10:33:31 +0300, Don <nospam nospam.com> wrote: You've really got to be a fanboy to claim that git is supported on Windows. Sure, it "works" -- in the same way that hammering a nail with a rock "works". You've mentioned some fairly untypical usage, so it's not surprising you ran into so many problems. Why would you want to use the interactive bash shell? I found that all git commands work fine from CMD. The only reason to use bash that I can think of is to allow copy-pasting commands with parameters quoted/escaped in a way incompatible to CMD. I'm not sure how vim fits the toolchain at all, I think it's just provided as a bonus in msysgit. If you need a proper *nix-like environment on Windows, have you looked at Cygwin? For a long while, Cygwin was the only supported way to run git on Windows. -- Best regards, Vladimir mailto:vladimir thecybershadow.net  May 20 2011 "Vladimir Panteleev" <vladimir thecybershadow.net> writes: On Fri, 20 May 2011 17:52:53 +0300, Don <nospam nospam.com> wrote: Vladimir Panteleev wrote: On Fri, 20 May 2011 10:33:31 +0300, Don <nospam nospam.com> wrote: You've really got to be a fanboy to claim that git is supported on Windows. Sure, it "works" -- in the same way that hammering a nail with a rock "works". 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, Vladimir mailto:vladimir thecybershadow.net  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 "Vladimir Panteleev" <vladimir thecybershadow.net> writes: On Fri, 20 May 2011 23:12:54 +0300, Nick Sabalausky <a a.a> wrote: "Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message news:op.vvsd4ef3tuzx1w cybershadow.mshome.net... On Fri, 20 May 2011 17:52:53 +0300, Don <nospam nospam.com> wrote: Vladimir Panteleev wrote: On Fri, 20 May 2011 10:33:31 +0300, Don <nospam nospam.com> wrote: You've really got to be a fanboy to claim that git is supported on Windows. Sure, it "works" -- in the same way that hammering a nail with a rock "works". 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, Vladimir mailto:vladimir thecybershadow.net  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 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 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
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
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
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
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
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
Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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
Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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
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
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
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 commit -m "woops wrong comment"

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

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

May 21 2011
Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=

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
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
Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

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

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

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

--
Best regards,

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

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:

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

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

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:
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
Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=

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

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

=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
Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2011-05-21 at 11:00 -0700, Walter Bright wrote:

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

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

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