Credentials on Linux

[archer884]

First tried this extension on Windows 8.1 because why not and I was absolutely blown away, so i thought, "Hey, I have got to put this on my Linux machine..." Unfortunately, without the credential helper I've got installed on Windows, the plugin is somewhat less useful. It's not a big deal, but it does mean that once every 90 minutes or so I'm going to have to update my credentials the hard way... And I realize this may be entirely me and nothing to do with git-control at all, too.

1. Is there a chance you can fix that?

2. Is there a way I can work around it?

Still a little new to the whole git-on-linux thing.

[SerenadeX]

Are you using an ssh-key? I am running on a mac and do all of my clones over ssh and I never have a problem

[archer884]

No, I wasn't. Right after I posted this, it occurred to me that I might be able to avoid that problem entirely by using ssh auth instead of using my password. It works like a charm.

I didn't close this issue because I figure every other windows guy on earth is going to run into the same problem at some point. (Because who could resist installing this on their toy linux install and playing with it, right?)

edit: Not that I have a problem with someone else closing it at all!

[SerenadeX]

I can't stand using http for my git stuff. Even if I'm on windows I'll generate an ssh key just so I don't have to worry about username/password

[SerenadeX]

Granted it would be nice to get this working with http and ssh...

[hellerbarde]

For the record:

• On Windows, there is https://gitcredentialstore.codeplex.com/ for saving git creds on https:// repos
• For Linux, there are multiple credential stores. It depends on your Desktop Environment.
  • For Gnome, use gnome-keyring, here are git integration instructions
  • For KDE use Kwallet, here are git integration instructions

I think this issue can be closed, because saving the credentials in Atom would be a "bad idea (tm)"

[MarcelMue]

I agree that credentials being saved in git-control are a bad idea. Unfortunately the question pops up quite alot as users that are new to git aren't familiar with the way credentials work.

[archer884]

OK, I've seen a lot of replies about storing credentials, but, if I am
remembering correctly, the problem was that I had to go enter the
credentials at the command line (which I should have said instead of "the
hard way") because, at least when I opened this, there was no way to do it
from within git-control.

On Sat, Jul 18, 2015, 3:32 AM Bricktop notifications@github.com wrote:

I agree that credentials being saved in git-control are a bad idea.
Unfortunately the question pops up quite alot as users that are new to git
aren't familiar with the way credentials work.

—
Reply to this email directly or view it on GitHub
#42 (comment)
.

[hellerbarde]

@MarcelMue yes, git-control should be able to enter the credentials. Which currently it isn't able to, right? But it shouldn't store them. Maybe as soon as we can enter credentials, there should be a note next to the form that mentions setting up proper git credential storage. What do you think?

@archer884 You are correct. The real bug is that we can't even enter any credentials for HTTPS. And that does indeed need to be addressed. I think there was something about the library used for calling git that made this hard. but I don't exactly remember the details..

[MarcelMue]

Yes, sorry I just skimmed this thread again when writing my earlier response and misunderstood the problem. I think the problem was that the credentials are entered in a console something like this:

And the npm package (git-promise) used in git-control does not support comands that don't start with "git" IIRC.
I think the credentials can be applied directly to the command but I am not sure about it as I have a keystore set up myself :(
Any pull requests about this whole console issue are very welcome, I looked at other atom packages and using a buffered process ( see https://github.com/akonwi/git-plus/blob/master/lib/git.coffee for reference ) looks way superior to the way git-control does it currently.
I personally don't have the time to do major changes ( even though I tried multiple times ) because of real life obligations. I mainly support others that want to contribute or have issues with git-control currently. I (or someone else) will hopefully get around to implementing the switch to a buffered process some time.

So the bottom line is contributions are welcome :D