[dmd-internals] [D-Programming-Language/dmd] 10640a: dang, forgot that one, too

Don Clugston dclugston at gmail.com
Wed Nov 7 06:46:30 PST 2012


On 7 November 2012 14:13, David Nadlinger <code at klickverbot.at> wrote:
> On Tue, Nov 6, 2012 at 9:24 PM, Walter Bright <walter at digitalmars.com> wrote:
>> Yeah, I know it's not the
>> usual git workflow, but git sux on Windows, and I don't care for the grief.
>
> Sorry, but I think you are just unnecessarily making life hard for
> yourself. What exactly is so bad about Git on Windows that it
> justifies manually copying the files over to a Linux box, with all the
> additional problems/chaos this entails? We might be able to help. Also
> note that the quality of Git on Windows has been improving a lot
> lately (at least in my experience), so if you have tried it the last
> time a few years ago, you might want to give it another shot.

At least for the git release I've used, which is about a year old. I
would describe its level of maturity as fairly similar to DMD - as
good as DMD, and as bad as DMD.
I was never able to get git to work from the Windows command prompt.
Other people have apparently done that, but I never had any success
with it. But from the git bash shell, it works fine.
So, on Windows I always have a git shell open just for doing commits.

The key thing I found you must NOT do is have cygwin and Msys git both
installed. As far as I can tell, git does no revision checking on its
index files, so if you accidentally mix git versions, you'll corrupt
various files, and get really bizarre symptoms. Some other oddities
I've seen may be because I'm on German Windows -- some apps report
error messages in English, others in German, and I think some scripts
fail when they're expecting a particular language.

Walter -
I never had any problems with Windows git, IF AND ONLY IF I used it
from the git bash shell. It does seem broken elsewhere.
I recommend you use the pull tester, I think it will save you a lot of work.

-Don,



>
> If you don't want to use GitHub for testing your commits before
> pushing them to master, I'd suggest not copying over the files from
> your development box to the other ones where you run the test suite,
> but instead exporting the respective Git repositories as a network
> share and pulling the new commits from them using Git.
>
> This way, you could easily catch missing files and other problems like
> that. Let me emphasize that broken commits are indeed very annoying
> when you are trying to make sense of the history, for example when
> using »git bisect« (yes, there is »git bisect skip«, but it's still
> cumbersome).
>
> David
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals


More information about the dmd-internals mailing list