Re: [OT] Re: There's new GIT instructions on Github now

[Bruno Medeiros]

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

Re: [OT] Re: There's new GIT instructions on Github now

[Daniel Gibson]

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

Re: [OT] Re: There's new GIT instructions on Github now

[Daniel Gibson]

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 enough on Windows so no reason to change"?

Re: There's new GIT instructions on Github now

[Bruno Medeiros]

On 21/05/2011 11:02, Daniel Gibson wrote:

Am 21.05.2011 11:28, schrieb Don:

Vladimir Panteleev wrote:

On Sat, 21 May 2011 00:47:46 +0300, Don  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 google:

http://www.nishioka.com/blog/2008/01/source-control-with-git-and-cygwin.html



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

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

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

Still not fixed in cygwin in 2011.


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


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

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

I'm amazed anyone disagrees with that.




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

Cheers,
- Daniel


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


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


--
Bruno Medeiros - Software Engineer

Re: [OT] Re: There's new GIT instructions on Github now

[Bruno Medeiros]

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

Re: [OT] Re: There's new GIT instructions on Github now

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

--
Bruno Medeiros - Software Engineer

Re: [OT] Re: There's new GIT instructions on Github now

[Bruno Medeiros]

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

Re: [OT] Re: There's new GIT instructions on Github now

[Bruno Medeiros]

On 21/05/2011 09:43, Vladimir Panteleev wrote:

On Sat, 21 May 2011 08:12:24 +0300, Nick Sabalausky  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

Re: [OT] Re: There's new GIT instructions on Github now

[Kagamin]

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?

Re: There's new GIT instructions on Github now

[Kagamin]

Nick Sabalausky Wrote:

> > What politics? If there's less interoperability between linux and windows, 
> > this hinders adoption of linux.
> 
> If XYZ works on Ubuntu/Linux and not on Windows, that benefits Ubuntu/Linux, 
> not Windows. "If you need XYZ, then you'll just have to use ABC" That's 
> called "exclusivity" and corporations have always tried to use it to 
> gain/keep customers.

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

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

That's a resource management. Because no windows user uses their piece of crap, 
the target audience becomes exclusively linux users. Of course linux users 
support will get higher priority provided absence of windows users.

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

On 5/21/11, Walter Bright  wrote:
> On 5/20/2011 3:05 PM, Andrej Mitrovic wrote:
>> I would also like to know how to uncommit a change which hasn't been
>> pushed yet. So if I locally do:
>> git add someFile.d
>> git commit -m "woops wrong comment"
>>
>> I'd like to just uncommit that message. I couldn't find an easy way to
>> do this.
>
> What I do is rm -rf the entire project directory, then re-clone it from
> github.
> Voila!
>
> (Yes, I suck at git. But I like it anyway.)
>

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

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

No rebase shenanigans or whatever I was recommended.

Re: [OT] Re: There's new GIT instructions on Github now

[Walter Bright]

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.

Re: There's new GIT instructions on Github now

[Russel Winder]

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

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

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.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: [OT] Re: There's new GIT instructions on Github now

[Russel Winder]

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?

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.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: There's new GIT instructions on Github now

[Nick Sabalausky]

"Walter Bright"  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).
>

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

On 5/21/11, Walter Bright  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.

Re: There's new GIT instructions on Github now

[Walter Bright]

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.

Re: [OT] Re: There's new GIT instructions on Github now

[Walter Bright]

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.

Re: There's new GIT instructions on Github now

[Walter Bright]

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.

Re: There's new GIT instructions on Github now

[Walter Bright]

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

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

On 5/21/11, Vladimir Panteleev  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.

Re: There's new GIT instructions on Github now

[Robert Clipsham]

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/

Re: There's new GIT instructions on Github now

[Robert Clipsham]

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/

Re: There's new GIT instructions on Github now

[Vladimir Panteleev]

On Sat, 21 May 2011 18:40:40 +0300, Andrej Mitrovic  
 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,
 Vladimirmailto:vladi...@thecybershadow.net

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

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

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

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.

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

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.

Re: There's new GIT instructions on Github now

[Vladimir Panteleev]

On Sat, 21 May 2011 18:24:31 +0300, Andrej Mitrovic  
 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,
 Vladimirmailto:vladi...@thecybershadow.net

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

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.

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

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

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

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  wrote:
> On 5/21/11, Vladimir Panteleev  wrote:
>> How about this?
>>
>> http://www.prowiki.org/wiki4d/wiki.cgi?PullRequest
>>
>
> That's great.
>
> We should link these from somewhere though as they're free-standing
> pages that have to be search for to be found. Maybe a "Contributing to
> D" section in one of the menus on the left (under About maybe?).
>

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

On 5/21/11, Vladimir Panteleev  wrote:
> How about this?
>
> http://www.prowiki.org/wiki4d/wiki.cgi?PullRequest
>

That's great.

We should link these from somewhere though as they're free-standing
pages that have to be search for to be found. Maybe a "Contributing to
D" section in one of the menus on the left (under About maybe?).

Re: There's new GIT instructions on Github now

[Vladimir Panteleev]

On Sat, 21 May 2011 14:58:55 +0300, Andrej Mitrovic  
 wrote:



On 5/21/11, David Nadlinger  wrote:

snip lots of awesome info


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


How about this?

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

--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: There's new GIT instructions on Github now

[David Nadlinger]

On 5/21/11 2:04 PM, Andrej Mitrovic wrote:

On 5/21/11, Lutger Blijdestijn  wrote:

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


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

Re: There's new GIT instructions on Github now

[Lutger Blijdestijn]

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.

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

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

Re: [OT] Re: There's new GIT instructions on Github now

[Lutger Blijdestijn]

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.

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

On 5/21/11, Lutger Blijdestijn  wrote:
> I recently starting using interactive rebasing which is a tremendous help
> for these kind of situations. This is usually what I do: 

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?).

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

On 5/21/11, David Nadlinger  wrote:
> snip lots of awesome info

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

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

On 5/21/11, Vladimir Panteleev  wrote:
> If you just want to edit the commit message of your last commit, use:
>
> git commit -am "New message"

Super. Thanks.

Re: There's new GIT instructions on Github now

[Lutger Blijdestijn]

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.

Re: There's new GIT instructions on Github now

[Vladimir Panteleev]

On Sat, 21 May 2011 14:14:18 +0300, Lutger Blijdestijn  
 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,
 Vladimirmailto:vladi...@thecybershadow.net

Re: [OT] Re: There's new GIT instructions on Github now

[David Nadlinger]

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

Re: [OT] Re: There's new GIT instructions on Github now

[Daniel Gibson]

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.

Re: There's new GIT instructions on Github now

[Daniel Gibson]

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.

Re: There's new GIT instructions on Github now

[Lutger Blijdestijn]

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/

Re: There's new GIT instructions on Github now

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

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: [OT] Re: There's new GIT instructions on Github now

[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++. '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. 

Re: There's new GIT instructions on Github now

[Daniel Gibson]

Am 21.05.2011 11:28, schrieb Don:

Vladimir Panteleev wrote:

On Sat, 21 May 2011 00:47:46 +0300, Don  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 google:

http://www.nishioka.com/blog/2008/01/source-control-with-git-and-cygwin.html


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

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

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

Still not fixed in cygwin in 2011.


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


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

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

I'm amazed anyone disagrees with that.




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


Cheers,
- Daniel

Re: There's new GIT instructions on Github now

[Daniel Gibson]

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. ;)

Re: [OT] Re: There's new GIT instructions on Github now

[Daniel Gibson]

Am 21.05.2011 07:12, schrieb Nick Sabalausky:

"Daniel Gibson"  wrote in message
news:ir6tel$1he8$1...@digitalmars.com...

Am 21.05.2011 01:18, schrieb Nick Sabalausky:

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

Re: There's new GIT instructions on Github now

[Vladimir Panteleev]

On Sat, 21 May 2011 12:28:04 +0300, Don  wrote:


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


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

My experience is:
* download, standard install.
* As far as I know there is nothing unusual to my Windows setup.
* Running 'git status' corrupts the database.
* Googling for the error message I find other people have encountered  
this before.

* I find many other bugs within a couple of hours of use.
Conclude this is an _extremely_ immature product.

I'm amazed anyone disagrees with that.


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


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


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


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: There's new GIT instructions on Github now

[David Nadlinger]

On 5/21/11 12:05 AM, Andrej Mitrovic wrote:

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


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


git add someFilePreviouslyLeftOut.d
git commit --amend …

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



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


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



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


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


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


David

Re: There's new GIT instructions on Github now

[Don]

Vladimir Panteleev wrote:

On Sat, 21 May 2011 00:47:46 +0300, Don  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 google:


http://www.nishioka.com/blog/2008/01/source-control-with-git-and-cygwin.html 



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


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


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

Still not fixed in cygwin in 2011.


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


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

My experience is:
* download, standard install.
* As far as I know there is nothing unusual to my Windows setup.
* Running 'git status' corrupts the database.
* Googling for the error message I find other people have encountered 
this before.

* I find many other bugs within a couple of hours of use.
Conclude this is an _extremely_ immature product.

I'm amazed anyone disagrees with that.

Re: There's new GIT instructions on Github now

[Vladimir Panteleev]

On Sat, 21 May 2011 01:05:56 +0300, Andrej Mitrovic  
 wrote:



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

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


git reset "HEAD^"

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

git commit -am "New message"


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

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


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


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: [OT] Re: There's new GIT instructions on Github now

[Russel Winder]

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.

[ . . . ]

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: [OT] Re: There's new GIT instructions on Github now

[Vladimir Panteleev]

On Sat, 21 May 2011 08:12:24 +0300, Nick Sabalausky  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,
 Vladimirmailto:vladi...@thecybershadow.net

Re: There's new GIT instructions on Github now

[Don]

David Nadlinger wrote:

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

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



No, fanboyism is evidenced in dismissing a list of bugs. I think that
was a darn good list.
Honestly, I hardly think so, given that half of the items arent't even 
bugs…


David


Which ones aren't bugs? Yes, there's one which is just a poorly written 
man page (that's my opinion, and is debatable). Do you think any of the 
others aren't valid bugzilla entries?

Re: There's new GIT instructions on Github now

[Vladimir Panteleev]

On Sat, 21 May 2011 11:31:06 +0300, Don  wrote:


Jesse Phillips wrote:

Don Wrote:

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


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


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


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: There's new GIT instructions on Github now

[Don]

Jesse Phillips wrote:

Don Wrote:

No, fanboyism is evidenced in dismissing a list of bugs. I think that 
was a darn good list.
 
Based on what you have described it sounds like most of your problems come with using poorly ported Linux programs and not with the Windows port of Git.


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


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


I happily run git in powershell with assistance from gvim.

Re: There's new GIT instructions on Github now

[Walter Bright]

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!

Re: [OT] Re: There's new GIT instructions on Github now

[Walter Bright]

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.

Re: There's new GIT instructions on Github now

[Walter Bright]

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

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

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


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


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

Re: There's new GIT instructions on Github now

[Walter Bright]

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.

Re: There's new GIT instructions on Github now

[Nick Sabalausky]

"Russel Winder"  wrote in message 
news:mailman.301.1305958019.14074.digitalmar...@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!

Re: There's new GIT instructions on Github now

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

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: There's new GIT instructions on Github now

[Russel Winder]

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.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: [OT] Re: There's new GIT instructions on Github now

[Nick Sabalausky]

"Michel Fortin"  wrote in message 
news:ir6tqm$pbf$1...@digitalmars.com...
> On 2011-05-20 18:13:30 -0400, Daniel Gibson  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.
> 
>

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

Re: [OT] Re: There's new GIT instructions on Github now

[Nick Sabalausky]

"Daniel Gibson"  wrote in message 
news:ir6tel$1he8$1...@digitalmars.com...
> Am 21.05.2011 01:18, schrieb Nick Sabalausky:
>> "David Nadlinger"  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 :)

[Answers Andrej] Re: There's new GIT instructions on Github now

[Jesse Phillips]

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.

Pretty sure you can just add HOME as an environment variable in the system 
settings thing that Windows provides somewhere.

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

Branching is extremely easy in Git and can generally be the first thing you do 
before making any changes.

create new branch (branchName) and checkout (commits go into this branch)
git checkout -b branchName

switch to another branch (master)
git checkout master

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

You can amend a commit which will allow you to add no items or change the 
comment

git commit --amend

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

I actually don't remember the steps but I think it goes something like:

git checkout HEAD^
// Do something with git rebase
git commit

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

Don't do that :P

Re: There's new GIT instructions on Github now

[Jesse Phillips]

Don Wrote:

> No, fanboyism is evidenced in dismissing a list of bugs. I think that 
> was a darn good list.
 
Based on what you have described it sounds like most of your problems come with 
using poorly ported Linux programs and not with the Windows port of Git.

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

I happily run git in powershell with assistance from gvim.

Re: [OT] Re: There's new GIT instructions on Github now

[Daniel Gibson]

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.

Re: [OT] Re: There's new GIT instructions on Github now

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



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/

Re: [OT] Re: There's new GIT instructions on Github now

[Daniel Gibson]

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.

Re: [OT] Re: There's new GIT instructions on Github now

[Michel Fortin]

On 2011-05-20 18:13:30 -0400, Daniel Gibson  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.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: [OT] Re: There's new GIT instructions on Github now

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

At least that's my experience.

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

Re: [OT] Re: There's new GIT instructions on Github now

[Daniel Gibson]

Am 21.05.2011 01:18, schrieb Nick Sabalausky:
> "David Nadlinger"  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.
> 
> 

Re: [OT] Re: There's new GIT instructions on Github now

[Daniel Gibson]

Am 21.05.2011 01:11, schrieb Nick Sabalausky:
> "Daniel Gibson"  wrote in message 
> news:ir6r32$1he8$1...@digitalmars.com...
>> Am 21.05.2011 00:34, schrieb Nick Sabalausky:
>>> "Daniel Gibson"  wrote in message
>>> news:ir6q2j$1he8$8...@digitalmars.com...
 Am 21.05.2011 00:20, schrieb Nick Sabalausky:
> "Daniel Gibson"  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).

Re: [OT] Re: There's new GIT instructions on Github now

[Nick Sabalausky]

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

Re: [OT] Re: There's new GIT instructions on Github now

[Nick Sabalausky]

"Daniel Gibson"  wrote in message 
news:ir6r32$1he8$1...@digitalmars.com...
> Am 21.05.2011 00:34, schrieb Nick Sabalausky:
>> "Daniel Gibson"  wrote in message
>> news:ir6q2j$1he8$8...@digitalmars.com...
>>> Am 21.05.2011 00:20, schrieb Nick Sabalausky:
 "Daniel Gibson"  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...

Re: [OT] Re: There's new GIT instructions on Github now

[David Nadlinger]

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

Re: [OT] Re: There's new GIT instructions on Github now

[Daniel Gibson]

Am 21.05.2011 00:34, schrieb Nick Sabalausky:
> "Daniel Gibson"  wrote in message 
> news:ir6q2j$1he8$8...@digitalmars.com...
>> Am 21.05.2011 00:20, schrieb Nick Sabalausky:
>>> "Daniel Gibson"  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.

Re: [OT] Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

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

Re: [OT] Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

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.

Re: There's new GIT instructions on Github now

[David Nadlinger]

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

Re: [OT] Re: There's new GIT instructions on Github now

[Daniel Gibson]

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.

Re: There's new GIT instructions on Github now

[David Nadlinger]

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

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



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

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

David

Re: [OT] Re: There's new GIT instructions on Github now

[Nick Sabalausky]

"Daniel Gibson"  wrote in message 
news:ir6q2j$1he8$8...@digitalmars.com...
> Am 21.05.2011 00:20, schrieb Nick Sabalausky:
>> "Daniel Gibson"  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?

Re: There's new GIT instructions on Github now

[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

Re: There's new GIT instructions on Github now

[Nick Sabalausky]

"Daniel Gibson"  wrote in message 
news:ir6ph4$1he8$7...@digitalmars.com...
> Am 21.05.2011 00:15, schrieb Nick Sabalausky:
>> "Daniel Gibson"  wrote in message
>> news:ir6jup$1he8$1...@digitalmars.com...
>>> Am 20.05.2011 22:26, schrieb Nick Sabalausky:
 "Don"  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.

Re: There's new GIT instructions on Github now

[Daniel Gibson]

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.

Re: [OT] Re: There's new GIT instructions on Github now

[Daniel Gibson]

Am 21.05.2011 00:20, schrieb Nick Sabalausky:
> "Daniel Gibson"  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..

Re: There's new GIT instructions on Github now

[Andrej Mitrovic]

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

Re: There's new GIT instructions on Github now

[Vladimir Panteleev]

On Sat, 21 May 2011 00:47:46 +0300, Don  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  
google:


http://www.nishioka.com/blog/2008/01/source-control-with-git-and-cygwin.html

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


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


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

Still not fixed in cygwin in 2011.


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

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


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


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


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


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


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: [OT] Re: There's new GIT instructions on Github now

[Nick Sabalausky]

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

Re: There's new GIT instructions on Github now

[Daniel Gibson]

Am 21.05.2011 00:15, schrieb Nick Sabalausky:
> "Daniel Gibson"  wrote in message 
> news:ir6jup$1he8$1...@digitalmars.com...
>> Am 20.05.2011 22:26, schrieb Nick Sabalausky:
>>> "Don"  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?

Re: There's new GIT instructions on Github now

[Nick Sabalausky]

"Daniel Gibson"  wrote in message 
news:ir6jup$1he8$1...@digitalmars.com...
> Am 20.05.2011 22:26, schrieb Nick Sabalausky:
>> "Don"  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?

Re: [OT] Re: There's new GIT instructions on Github now

[Daniel Gibson]

Am 20.05.2011 23:55, schrieb Nick Sabalausky:
> "Daniel Gibson"  wrote in message 
> news:ir6l0q$1he8$2...@digitalmars.com...
>> Am 20.05.2011 22:41, schrieb Nick Sabalausky:
>>> "Andrei Alexandrescu"  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

Re: There's new GIT instructions on Github now

[Nick Sabalausky]

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

Re: [OT] Re: There's new GIT instructions on Github now

[Don]

Daniel Gibson wrote:

Am 20.05.2011 22:41, schrieb Nick Sabalausky:
"Andrei Alexandrescu"  wrote in message 
news:ir67mk$2jfi$1...@digitalmars.com...

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

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

Fanboyism for Windows or git? :o)

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


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


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


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




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

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




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

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

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


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


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