I got flamed a month ago  for noting how difficult it is to get up and running on GitHub in the Windows world, where things like generating SSH keys aren't exactly part of the daily routine. Glad to hear that they were listening.
The ssh setup is a barrier to entry for a great deal of Windows users, simply because they don't have to deal with such things on a daily basis. Whether they all should know these things is debatable.
I personally couldn't give shit how 'it' works, as long as I don't have to waste my precious time having to learn something I don't need to. I don't want to have to learn machine code for the same reason. We abstract to become more productive. We build on the shoulders of giants. We don't re-invent the wheel. I could go on...
The bottom line is that the previous installation for Windows was manageable, but still it was a drag. Luckily there were enough good resources on the web to help you through it. However, it was time consuming and that barrier has now been removed.
In my opinion that's great. It follows Dieter Rams' principles of good design, namely:
Good design is as little design as possible.
Less, but better – because it concentrates on the essential aspects,
and the products are not burdened with non-essentials.
Let's remember that Git is a distributed source control mechanism. It needs to move versioned code around. That is its pure purpose. When the security setup takes more effort than the source control you're doing it wrong.
That being said, the common language of the Git world will remain the command line. The vast majority of examples you will find on the web when you are learning how to use Git will be executed via the command line. That fact in itself means that you should still learn the basic commands and get familiar with git bash.
EDIT: I hope this gives a fairly balanced opinion from a typical Windows Git user. I appreciate that this topic is a heated one.
By all means switch to using the GUI after.
The method I chose in Windows was to use pageant (part of Putty) to load the keys. Not sure if I missed this option but you can't autoload keys so when you restart pageant you have to readd the keys (which is not terrible bad, just annoying).
Haven't tried Github For Windows yet but if it fixes the hassle of using ssh keys then I'll probably use it as my main git client for Windows.
Then, by all means, use Cygwin or anything that helps you, even if it doesn't come with Windows, if it isn't provided by Microsoft, doesn't look familiar and if it doesn't play well with Visual Studio. If you code for Windows you are coding against an insanely complicated set of APIs.
Compare this with Mercurial, which runs great from the command line on multiple platforms. I actually prefer the command line for SCM work, but git makes it hard.
I understand Cygwin is a layer of Linux on top of the Windows kernel, but didn't Windows have some POSIX support built in?
This seems pretty friendly to me. Is there something I'm missing?
For my team, which consists of designers and developers, this will make the learning curve of my designers a lot easier.
Saying that because you don't know how to use SSH keys on a windows machine means you can't write secure code is just silly. It is a slippery slope to say that. If the majority of senior guys actually believed it then we wouldn't have a use for higher level languages (ruby, php, etc), frameworks like .net, etc.
GitHub doesn't take any more setup than a standard Git setup takes (well, outside of signing up, a very short process anyhow). Install the Git client via the Windows installer, (point and click, a minute, tops). Generate an SSH key. Upload the id_rsa.pub. Done. I mean, it would be one thing if they left users in the dark about this, but I'm fairly sure that the "Thanks for signing up page" links directly to the OS-specific meticulous step-by-step instructions of generating the key.
I'm not sure you understand what it means to be flamed. Every one of the comments is specific about your misconceptions and why signing up for a GitHub account is as trivially easy as signing up for a Twitter account. (Using GitHub as an oAuth account does not require actually uploading a public key)
None of us want to understand every single domain of knowledge from set theory or quantum physics up to cosmology or social psychology.
I personally have been forced to learn more low-level Unixy things than I ever wanted to. I want to write simple and elegant front and back end code quickly so I can spend my spare time honing UX and other human-facing aspects of my work.
I resent being flamed because I don't fully understand the subtleties of zsh or nginx or or whatever other shiny toy someone else happens to find essential knowledge. Your world might not necessarily be mine.
Speak for yourself. All of those are fascinating.
What do you people want? Seriously? Yes, I'd love to have a big red easy button. It could autoconfigure MySQL, and write init scripts, configure deploy environments because apache conf files are too complicated to learn. Hell, it could even write my backend code and then commit it for me too!
I'm done with this ludicrous conversation. I've never seen such an ignorant-excusing entitled discussion in a "technical" community before. Downvote me because you can't follow steps or can't be bothered to learn how to use one of your most important development tools, I've lost interest.
One of the reasons why I recommend using Linux on the desktop if you develop software for anything non-Windows: it's handy to have more exposure to the environment your code will run on. If you run Eclipse to develop Java code that'll run under Tomcat on Linux, you have a lot to gain by moving to Linux yourself.
If, for some reason, I end up writing Windows-specific code once again, I'll probably develop it on a Windows box. Visual Studio is a great IDE if you want to write programs for Windows.
What the hell are you so angry about, seriously? People have less expertise than you, and that makes you upset?
So to all of you that actually know the difference between merge and rebase and what the difference between origin and local branches are :hattip:
That was in the post I replied to. It's insulting because it's accusing me of things that I didn't do. I merely am just a bit floored by the notion that following these instructions, http://help.github.com/win-set-up-git/, is asking too much of someone who is going to be using Git regularly.
I guess I expect too much and seem to be wasting my energy. I apologize.
Using git on Windows has historically not been super fun. The CLI installer mostly works, but it's pretty clunky. Cygwin works fine too, but it's also not especially elegant. At the very least, known of these solutions conform to the expectations of people of the platform. The GUI clients on Windows last I looked (a year ago) were pretty terrible, especially compared to TortoiseSVN, which isn't bad. OS X, on the other hand, had several very nice GUI clients even before the official Github client came out.
There is TortoiseGit, which is basically TortoiseSVN over git. It looks much the same.
You can regard it as a good place to start with git, or as something that stops you learning what makes git special.
As for "CLI installer" (I presume you mean the installer for the CLI git client), and Cygwin, I'm not sure what to say. I've used the Git installer dozens of times without problem, there aren't exactly tons of places for it to go wrong. Are there specific or particular issues you have with it?
I do indeed forget that some programmers manage to make it far resisting learning to use the command line. Even with step-by-step instructions. I guess at some people I'm willing to fault the developer rather than tools that are powerful that come with good documentation.
Obviously GitHub believe there are people who will benefit from using Git who can't be bothered understanding setting up ssh.
Seems reasonable to me.
Haha, maybe another of way of putting things from my perspective, I found keys to be the least of my concerns once I got into projects that really used Git and I have a hard time seeing people be successful with Git if the keygen steps throws them off.
I hope that explains things from a different perspective :)
The level of discourse and use the downvote just amazes me anymore. Seriously, how can you be that much of a douche after I made very basic, undisputed points?
So what if it takes 4 minutes? Why not save all the people who might use your tool 4 minutes of clicking 'OK' through a half dozen boxes you assure them they should just ignore? Particularly if github (as seems clear) want to get more people to pay them money.
Is this an honest question, or are you alluding to the idea that someone who doesn't understand PKI should not use distributed source control?
Last I checked they[GitHub] made you perform a bunch of scary crypto stuff on your local machine before they'd let you in.
If performing `ssh-keygen` and entering in an (optional) password from a command line constitutes "scary crypto", then maybe Git and GitHub isn't for everyone. Not that anyone needs to know how PKI works, but they might be better off knowing that `ssh-keygen` generates an ssh key pair, a pretty essential component of the `git` workflow.
Maybe that's why SVN is so strong in older development shops. Outside of the effort required to convert an SVN repo to a Git repo, all those developers already have all the tools necessary on their machines (Windows is high on that list) and in many cases inside a VPN like my division we just use WebDAV anyways, completely bypassing the need for SSH Keys in favor of ActiveDirectory.
Everything you've said in this thread has been bang-on, and the replies you're getting are deeply depressing.
I find this shows the necessary respect when dealing with security related tasks, since they are HARD.
I'm not talking about developing crypto related software, but just setting up a "safe" environment where you can store your SSH Keys in a way that doesn't defeat the purpose of using them in the first place is non-trivial, even for people with degrees.
IT Security is a complex field of its own and if a user is afraid of making the wrong choice it only shows that he understands the basics of it.
"ssh-keygen -t rsa", set a passcode on it, upload the id_rsa.pub and you're done.
Demonstrating a lack of understanding of that was worrisome for myself and other users that commented on his post a few weeks ago.
We set up VPNs to our servers and access them via network paths or directly using Remote Desktop. One can go one's entire career without ever typing ssh-keygen into a terminal window. It's certainly not a step involved in setting up a client to talk to version control.
You don't have to believe me on this. You can read the article we're talking about here and see this same sentiment expressed by the GitHub team themselves.
Thanks to that team, folks in our side of the dev world now have an easy path into Git and GitHub, and can go about our merry way building things without ever having to parse what it was that you did in your second paragraph.
... except when github messes up, forces you to do a SSH key audit and then you're back to needing to know "scary crypto stuff".
... or when you try and use git outside of github
I don't want to have to do it all command-line, I don't want to have to copy and paste from their blog, I don't want to have to do it by hand. I'm not a competent developer (and I reject your assertion that you need to be a competent developer to use version control), I'm not setting up a server, I'm not deploying to Heroku. I want this script backed up and I want it version controlled. No reason why it should be hard.
No reason why it should be hard, because the whole goal of technology is to make life easier. I'm scared by the thought of a lot of stuff inside my computer and OS, but luckily there wasn't someone with your mindset and now anyone can easily get a computer from bare metal to running Angry Birds in Chrome. I'm not a developer although I write scripts sometimes, and the barrier to entry should not be set higher than absolutely necessary. If that means GUI, then so be it.
I'd bet my right hand the more than 25% of "competent developers" that are "managing servers" will have made security mistakes while storing their ssh keys on a level with storing the password in plaintext on a .txt file on the desktop.
Thats whats scary about "crypto stuff", not that it isn't easy to use the tools, its hard to be really sure how to put them to good use when you are no expert on IT security.
That having been said, I'm certainly not a security expert. Are there other common things to look out for to ensure my private key(s) are safe?
Seriously guys, you're not even trying. Here are the instructions everyone is freaking out about, they contain an explanation of this very issue.
I'd hate to say it but if you're introducing someone in Windows land to source control then NONE of the items on that list are part of their skill set.
If you're a dev, source control is one of your tools. Learn it or find a tool that holds your hand more. I don't know how it gets more hand-holdy than step by step instructions that take 4 minutes to carry out.
Is anyone going to actually reply, or should I continue taking downvotes as "I disagree or I deserve more hand-holding"?
Mm disclaimer: I'm a windows dev by day. I introduced git into that shop I'm working at, the rogue 'I set it up, would you technical guys like to work with it' way. This happened 1.5 years earlier, today it's the blessed and only source control in play (ignoring one sad division having to deal with tfs.. Oh the agony).
So, I a) was the driving force pushing git and b) work in an environment where unix/linux knowledge is rare and ssh is a weird thing.
You are, again and again in this thread, missing the point and just plain insulting. Take it from this guy that types this message from his linux box and has a linux to windows box ratio of 5:1..: The git toolset sucks. It's crap for people that are used to windows only. You can mock people for them being uncomfortable with putty-gen (more likely, btw) or ssh-keygen, but the fact is that it's arcane and unintuitive to do that, if you have no clue what ssh is in the first place.
It doesn't help that git really doesn't _need_ ssh. It's just one (well, _the_ one) protocol you can use. I've coworkers that generated their key and didn't keep it afterwards. They thought it's kind of like a registration or that the client will keep this 'stuff' around somewhere. Most 'git doesn't work' errors are related to crappy windows clients being not helpful if the ssh key isn't available (ssh-agent/pageant not running or key not loaded).
SSH, in the company I work at, is 'that git stuff'. You consider that funny? Well.. Go ahead. My totally socially awkward inner geek might agree with you, but to the real world you're laughing about a weird kind of a maths joke right now. Most people don't get it, you're mocking things no one cares about and in the end you just look out of place.
Don't be that guy and show some understanding.
If that's insulting, then I'm going to have to learn to live with being a cruel, mean person.
Also, it's GitHub's fault that they use an existing secure method of transferring source code instead of writing a new protocol that's easier for you to use. Because 4 step-by-step instructions are too hard to follow. OK.
I'm not even asking that you understand it, but simply be able to follow very, very simple instructions.
(It's perfectly reasonable to not like Git's toolset. There are dozens of other source control utilities out there. The only ones I know of that are more 'usable' are SVN and TFS, and the tradeoffs there are pretty stark in my humble opinion)
"Also, it's GitHub's fault that they use an existing secure method of transferring source code instead of writing a new protocol that's easier for you to use. Because 4 step-by-step instructions are too hard to follow. OK."
"I'm not even asking that you understand it, but simply be able to follow very, very simple instructions."
"If you're a dev, source control is one of your tools. Learn it or find a tool that holds your hand more. I don't know how it gets more hand-holdy than step by step instructions that take 4 minutes to carry out."
Let's imagine a company creates some form of hardware widget that requires some form of setup before it can be used. Initially the setup involves four steps that the company feels is "simple". Now, let's say a number of their customers have trouble with those simple instructions for different reasons. What's the proper response from that company?
A: Maybe we should think over the instructions to identify some problem spots as to why people are having trouble? Maybe we should ask some of these people what part are they having trouble with? Maybe we should consider a more in-depth explanation to people who have never used a similar device before?
B: If people aren't smart enough to figure out our simple instructions then they're too stupid to use our product. We could just ignore them but instead we'll insult them because they just don't get it. After all, if they're in our industry then they should already know how to do this.
I'm not saying that everyone should use response A, since most likely the problem has been answered somewhere. But too many people go with response B with absolutely no benefit to anyone in any way.
If you don't want to do that, you now have the option not to.
Please, bring me someone who actually had trouble with those instructions, and not because they freaked out at the first sign of a command line. They must have actually read them, including the expandable bits, made a serious effort to follow them, and failed.
So in all the rules, the one place that isn't just "press OK, press OK, press OK", tells you to do something probably dangerous, depending on your setup.
More fundamentally, you had SSH keys and no understanding of what they were for? Sorry, but this is exactly what I'm talking about. You are choosing to use systems you have no understanding of, and taking no time at all to learn about them. You are dangerous.
I agree that everyone should be able to follow that list. And now you have someone with ssh keys and no idea what they are.
I think it's dangerous to mock people that are scared of these things (defined as opaque instructions that install various products and ask you to copy paste commands in a terminal) and afterwards mocking people that potentially DID follow that list, succeeded and now use a system they have no understanding of.
I love git. Git on Windows feels out of place for every Windows only guy I showed it to. Why is that something to argue about - and why does it lead to borderline insulting comments? It's interface is.. different and UIs are bolted on only and it packs a lot of mental dependencies (learn about ssh, different newlines) that aren't really related to your ability to write (Windows) code.
That Github link is perfectly correct and still full of WTF material for people that never left Visual Studio. I work with those, and I have a couple dozen anecdotal evidences available..
Secondly, you just said you wanted "A single person actually who had trouble with these rules". I presented you with such a person (indirectly).
While it isn't dangerous, it was annoying, because it took some time to figure out why various tools where no longer working correctly.
To be honest, you seem to be getting surprisingly angry that there at people who might want to use this shiny thing called github, on which many projects they use might reside, without fulling understanding every detail of git, ssh, etc.
I know some mathematicans who can write amazing algorithms, who I would want involved in projects I work on. However, they use windows and don't really care about the finer workings of unix. Personally, I think it's good if such people has the easiest access possible to making a quick push request, on their own machine in their comfort zone.
I truly, TRULY have no problem with making key generation push-button. I really don't. I have a very BIG problem with people who don't understand it pushing that button.
But you're right, I give up. All I can do is ensure that these people who demand of themselves nothing but the most disgusting of human characteristics -- willful ignorance -- do not come anywhere near my systems or projects.
It's isn't "wilful ignorance" to not try and learn everything, ever, about everything. Particularly things which you don't want to learn, and probably aren't going to help you. We all specialise to one degree or another. I work with mathematicians who have spent years learning and refining their craft, who certainly know more maths than I could ever learn. I accept that there are things they know, and things I know. I want them to continue doing amazing maths, so I don't want to pile on them a bunch of things they don't want to learn. Despite the fact I did a maths degree, I know there are things they commonly discuss I don't really understand, which would be their equivalent of ssh keys. Things everyone knows. I've learnt some of them for work. I've learnt some of them for fun. But I don't have the time to learn all of them, and that's fine.
Now, these people do still learn. They learn about all kinds of fields, and all kinds of areas. They learnt CVS, but they didn't enjoy it.
Also, I find it very productive, and fun, to work with people whose skill sets are almost entirely disjoint from mine. It does make working together a bit tricky, but some of my most productive times have risen from such situations.
I've read through the instructions and they do seem straight-forward enough. In fact, they are actually quite nice. But that still does not mean that some people will not have problems along the way. Not that I have any evidence to back this up but I can think of a few possibilities of why people may have problems:
1: The installer keeps failing for some unexplainable reason. Maybe they don't have the user rights, maybe the IT department is blocking it, whatever other possible install problems. You can't assume that everyone will understand why the installer is having issues on their particular computer as compared to another. We're already seeing reports like this for the new installer just released, I guess those people can't follow the simplest instructions of double-clicking an exe installer correctly. Right?
2: When they get to the line ending conversions part; what if they don't understand the options and abandon the process? Remember, some of these people are new to Git and without some hand-holding they may feel lost. In the screenshot I see there's no recommended option. So it's up to the user to pick the one they need without knowing what they need. Unless there's someone to point it out. And considering some people's attitudes about noobs doing the "wrong" thing then options like that are rather important to consider properly. Do you want to bet whether someone has complained about someone else picking the Windows-style checkout?
3: Even though the instructions are nicely laid out, not everyone is accustomed to the command line. I bet there's a huge number of Windows users who have never used the command line. Even with simple instructions there's the possibility for mistakes. There's even an extra section just for SSH that clearly shows that some people have issues with that part, even Github is trying to address it right there. But they can't possibly cover every conceivable issue.
Notice that most of my examples have nothing to do with the instructions themselves, but unforeseen problems that we have to deal with simply because so many people have different computers with different configurations with different networks with different IT departments with their different mandates. The attitude that it's simple for me therefore it must be simple for you is a bad one. The new installer worked for me on the first try, I don't dismiss the ones that did have a problem for some reason.
But to further prove my point about my two responses from before, Github decided to go with response A. How do we know? The release of the even simpler all-in-one application that started this whole conversation. Even with the "simple" instructions that have been pointed out, Github decided to listen about problems with the process and have responded with an even easier method to accomplish the same task. Even go above and beyond.
That is the mark of a good software developer/company/project. These are people trying to be inclusive, not exclusive.
Sadly, too many people in this thread decided to go with response B. Thankfully, Github disagrees with that attitude.
Not a problem following the instructions -- such a failure is clearly outside their scope.
You also conveniently ignore the reality that if they don't have permissions to install it... They're not supposed to be installing it in the first place. Report them to their corporate IT department, you'll be doing everyone a favor.
> When they get to the line ending conversions part; what if they don't understand the options and abandon the process?
Purely hypothetical. But if they give up that easily, yes, I consider it PEBKAC. People must take responsibility for their own ignorance and laziness.
> Even though the instructions are nicely laid out, not everyone is accustomed to the command line.
It. Is. Text. Read it. We read every day, we type every day. This is not difficult. Fear of the command line is irrational, which is exactly why I excluded it.
I tried to make it quite clear that it was all hypothetical and outside the scope of the instructions, maybe I failed. But they are indeed possible problems that people can have during the install process. Whether the people are correctly identifying their problems is a different discussion. You are making my point for me, it is simple for you therefore it should be simple for everyone else. I'm just saying that it is quite possibly not so simple for other people, for various reasons. Nothing more.
Is both correct? Or would you agree that 5min to learn how ssh works, even for a broad overview, is not exactly helping / changing anything.
It should take five minutes for them to learn the basics of public key crypto so that their eyes don't glaze over when you say "public key", "private key", "fingerprint", or "RSA". I consider this basic knowledge absolutely essential for anyone using these concepts, even indirectly. Without it, you're dangerous.
Once those concepts are in place, it shouldn't even take five minutes for them to understand what SSH is doing, because SSH is a very simple and obvious application of the concepts. It should be self-evident from the brief discussions in github's instructions what is going on.
And once you've taken the five minutes to understand the concepts, not being dangerous is likewise simple and obvious:
* Put a good passphrase on your key.
* Don't share your key with others.
* Don't type in the passphrase for your key on any computer you don't trust at least as much as your own.
Notice how these aren't fundamentally different from protecting a password.
We are talking about inherently intelligent people with a good capacity for learning. It is mind-boggling to me that anyone would argue that these people should not have to spend five minutes to understand at even the most basic, limited level, how critical tools they want to use work.
They really resent having to learn about other things.
I don't get it. But that's probably why I am employed as a tools engineer... because I like learning.
When seeing other people who have problems and difficulties - one group only feels righteous indignation; while another group sees a business opportunity.
SSH is one of the easiest security tools to use safely that has ever existed. I would say it is second in usability only to HTTPS in browsers, while having a much better actual security record, and is infinitely more powerful, while keeping basic operation so simple I once taught my mother to use it.
I am 100% confident that anyone competently engaged in development or systems administration can understand the basic concepts and operations of SSH in five minutes. Any fear of it is irrational. It is not hard, it was specifically designed not to be hard.
I'm equally confident you've not taken the five minutes to understand these relevant concepts, because your statement about setting up a "safe" environment makes no sense in the context of OpenSSH. The defaults are inherently safe, as they should be. You must take specific actions to make the system unsafe.
He didn't say he was incapable of understanding it.
> SSH is one of the easiest security tools to use safely that has ever existed. I would say it is second in usability only to HTTPS in browsers
Perhaps that's true, but I suggest testing it would show a massive discrepancy between ease of HTTPS use and SSH use.
In short: I think this is a UX issue, not a PEBCAK one.
nknight@unassigned-hostname:~$ ssh-keygen -t rsa -C "firstname.lastname@example.org"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/nknight/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nknight/.ssh/id_rsa.
Your public key has been saved in /home/nknight/.ssh/id_rsa.pub.
The key fingerprint is:
The key's randomart image is:
+--[ RSA 2048]----+
| . |
| o o |
| = |
| . o |
| . S . . |
| o o. . + |
| . . o.o + = |
| E. . o.+ + .|
| .o. .+.. |
Get over your irrational fear and you will have no more trouble than you would reading a technical book.
Most people aren't going to change where the file is saved, or care. They don't know, or care what a fingerprint is. I still have no idea what the 'randomart' images are about.
I don't see any benefit to all of that over having a button marked "make keys" which just gets me set up so I can use github.
Of course, you could force people to care about what files are placed where, and their permissions. Then you should probably remove the default values of course.
Then they cannot use the system safely and should walk away.
> I still have no idea what the 'randomart' images are about.
First result for "ssh randomart" in Google:
So long as you're unwilling to learn, very simple things will forever elude you.
> I don't see any benefit to all of that over having a button marked "make keys" which just gets me set up so I can use github.
It's not that the form has any strong benefit in itself, it's that if you understand what is going on, which is required for security, the text form is in no way mysterious, complicated, or intimidating. The GUI isn't fixing anything, it's just masking a serious problem with the user.
I also like being told where semi-automated processes are placing critical files on my filesystem. I'm surprised that annoys you.
> I also like being told where semi-automated processes are placing critical files on my filesystem. I'm surprised that annoys you.
No, it really doesn't annoy me. I'm very happy for you to use git from the command line. I use git from the command line and don't intend to use this new GUI. It would be no good to me anyway, as I use linux.
However, I get the feeling that you are annoyed that other people might want to have a full automated process, and not care where the critical files are being placed.
As time goes by I feel one of the most important things is to reduce the amount of work it takes for people to get started with something, particular because I have wasted so much time on it. Did I waste the time I spent getting started with git? vim? python? Not at all.
Did I waste the time I spent getting started with emacs? ruby on rails? mercurial? FreeBSD? Arch Linux? screen? To be honest yes. Each of these things, in their own way, had an annoying and non-user friendly setup and start, and I've since stopped using them and don't believe the skills were transferable. While I enjoy learning things, sometimes I just want to get started. Also, sometimes I want to get many collegues, who are less computer literate but still experts in their own fields, started.
One can perform the act of driving a car without any understanding of what the engine does, but if you lack any understanding of what it does, you're going to park it in a closed garage, leave it running, and kill yourself or someone else because you were too afraid of scary mechanical stuff to learn.
If you can't be bothered to learn about public key crypto, someone's going to social engineer your key out of you without you having any clue what happened.
One downside, not entirely obvious how one's supposed to clone a repo with this?
Edit: They've mentioned the toolkits used at the bottom of the page. Apparently this is written in C#.
Edit for spelling
> Apparently this is written in C#.
You sound surprised. To me it looks like a quite slick WPF app, which aims for a metro-ish look. But I've seen nothing in the UI that is particularly challenging for WPF. WPF is very, very flexible.
I assumed that doing any sort of integration with Git would require C-level bridging. Didn't realize there was any sort of decent C# bindings for Git.
Also, I have not seen very many Windows apps with slick UIs like this that were written in C#. Even the WPF ones that I've seen were quite clunky.
Short of re-writing git in c#, it does require bridging. That's what unsafe code is for - calling out to dlls written in c.
> Didn't realise there was any sort of decent C# bindings for Git.
I kind of just assumed that there was. There usually is. The licences page lists "libgit2", so it's probably this one: https://github.com/libgit2/libgit2sharp#readme (edit yep, LibGit2Sharp is mentioned later on in the licences)
The file LibGit2Sharp/Core/NativeMethods.cs seems to do a lot of the bindings.
> the WPF ones that I've seen were quite clunky
I said that WPF was flexible, I didn't say simple or easy :P Also, to get good design, you usually need the help of a designer. Most coders will produce "clunky" UIs. I would. Somehow, the Windows desktop space has been very slow to deal with this.
I don't claim to be a design guru, but it looks like somebody was going for minimalism, but used a nuke instead of a scalpel. My eyes don't know what to focus on, there's limited indication of what things are, and in places it's hard to tell at a glance where one component ends and the next begins.
It's not so much ugly as it is intensely vague and somewhat undiscoverable.
Edit: Just to be clear, I don't want this to be seen as a criticism of this app or its developers specifically, I'm operating under the impression I'm getting from other commenters that this is very Windows 8-ish in general, so take this as bewilderment at the Windows 8 style.
When I browse to my downloads folder, the most frustrating thing in the world is trying to figure out where 'setup.exe' came from.
I expect this will drive up the adoption of GitHub by a measurable amount.
I've been doing a lot of Windows development lately and I've missed a good git tool. I'm very happy about this.
One single powerful window instead of explorer right-click menus, feels more productive for me. Great support for PuTTY (needs some tricks with KiTTY) but also works with openssh.
I think it is better for TortoiseGit to match the semantics of git rather than match the semantics of TortoiseSVN. It causes some confusion coming from SVN for sure, but once you start using git, you should learn its dialect. It would be worse if TortoiseGit did not match git's vocabulary.
One thing that is great about github.com and other websites is that it feels the same across multiple environments. Furthermore web browsers try to emulate their own style not that of the host operating system. If I use chrome or firefox in mac or windows they feel basically the same.
I wonder if more applications will go in the direction of trying to match the feel of the host operating system over the feel of there application as a whole.
From that perspective, I think they're doing the right thing.
It's nice to know GitHub made the effort.
Actually there are pros and cons to adapting an application to the platform instead of adapting the platform to the application. You're also conflating the OS with the window manager.
but since this is using your framework, xpaulbettsx, is the source for this going to be available? I always love seeing open source functional applications that use a certain framework or toolkit I'm considering. Makes the divide between reading code/documentation and the end product just seem that whole much closer.
That's one I stumbled upon a while back.
Just the fact that it doesn't have keyboard shortcuts is a dealbreaker.
I'm glad Github decided on a core feature set, and made those very easy to access.
Like the Mac app, GitHub for Win doesn't support every single git feature but it makes the ones it does support intuitive and accessible. Props.
It's a first iteration / release. I'm sure with more feedback they'll release more often. I'm unlikely to use this much - because I favour the cli - but I really hope this makes git more accesible to some Windows shops.
Will this tool be able to work with non-github git repositories?
"GitHub for Windows is a 100% native application"
"The application is written in C#"
CefSharp (.NET Bindings): https://github.com/ataranto/CefSharp
I use ClickOnce for several of my applications, and I'd say the users who dislike it the most have the highest technical aptitude (which, I'd guess, is a large part of GitHub's user base).
Unfortunately, there doesn't seem to be an obvious way to mass update ClickOnce applications apt-get style.
I think maybe ClickOnce's drawbacks are less of a sticking point when the application you're installing is one that needs Internet connectivity to be fully functional anyway.
- Why can't I find the installation directory? (ClickOnce doesn't use the standard C:/Program Files/ location, it stores program files in C:/Users/<your username>/AppData/Local/Apps/2.0 for security reasons.)
- Why does the installer need a network connection? (ClickOnce downloads the required setup files from the internet.)
The lack of a standard Program Files/.exe deployment also makes it difficult to map filetype associations, which is also a frequent complaint.
I'll likely be going with non-ClickOnce deployments for the future. ClickOnce is great for deploying production software at work, but for a consumer audience, it isn't quite perfect.
(Personally, I really like ClickOnce.)
Considering that Paul has been working on it and yet choose to go with ClickOnce, I am guessing it's not ready for prime time but it might be worth looking into anyway.
NSync is my ongoing (not finished yet!) project to recreate ClickOnce
How much of an overlap do NSync and NAppUpdate (https://github.com/synhershko/NAppUpdate) share? Would love to see some type of collaboration between the two.
BTW is there a way to submit tickets other than email for GitHub for Windows? Maybe a GitHub repo? Would make it rather easy to submit and track issues while also limiting the number of duplicates.
Granted, this 60/40 blame security software/clickonce, but it was a complaint nonetheless.
For someone that has one foot in both Worlds (UNIX & Windows) this is a welcome addition to my toolset.
14:32:19.309 (unrecognized proxy protocol) connection from 127.0.0.1:3743 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
Considering how MS are not really pushing a competitor, I don't understand why they refuse to add such a simple thing. RDP is a completely different tool, and anyway it's not really something you'd expose on the internet, so I don't understand why they can't just integrate OpenSSH -- it's not even GPL!
One problem that is rendering it unusable for me atm though is that it tells me that files contain changes that have not been touched and if I try to discard those changes it actually has no effect. Wanted to report it but found no way to do so on the GitHub for Windows page.
I already had msys installed, so I'm concerned that GitHub may have tried to install it again, causing conflicts.
How many people were on the team? Did you let Phil write any Xaml?
Would it have been that hard to just use Qt and build a cross platform tool? Or is that not hipster-friendly enough?
I guess it's cool to profit, not that cool to give back. I wouldn't use their tool anyway but I think they're assholes on this one.