Open jsbain opened 10 years ago
Totally agree. I think the remote information is stored in the .git folder, but I have to investigate whether Gittle/Dulwich supports this.
Ok, looked at this for a bit. Currently, dulwich clone does not add the remote section to .git/config, but it will read it. User info is stored in ~/.gitconfig, however, in pythonista we can only write to ~/Documents. Shellista sets HOME internally to that folder, but if we want dulwich to find the file, we will have to set os.environ['HOME'] to point to Documents. Not sure if we want to do that, as it could affect other people, though I suppose we could wrap the calls to gittle setting environment, then set it back...
I was actually looking at the same thing last night. I added code to git clone
that saves the origin url in .git/config when a repo is cloned, which seems to work fine. I also changed git push
, so that you don't have to enter the URL (it will try the origin URL first), and you can enter your credentials with the -u <username[:password]>
option. If you opt not to specify the password, you will be prompted with a secure prompt.
git remote
should show you the origin URL after you have cloned a new repo.
I'm planning on adding a .gitconfig file to save the username and e-mail address-- this seems to be pretty trivial as far as I can tell. Dulwich provides a ConfigFile class that should provide the necessary info. My idea was that, if there was not a ~/.gitconfig, it would prompt the user for name and email the first time they used a git function, and then use these for subsequent commits.
Would you be willing to test the latest version? Everything is merged into master.
Also, I haven't looked into saving the credentials. I don't know anything about the pythonista keychain-- is that something you would be wiling to investigate, and perhaps come up with code? I'm not sure where this code should go, though, because potentially, you could use the same credentials in git clone, too (say for a private repo).
P.S. did you notice if Dulwich/gittle attempted to use the .gitconfig file for anything? My understanding was that it did not... if that is the case, then we shouldn't need to mess with os.environ. we should just be able to implement the functionality directly with the ConfigFile class, and choose whatever file we want to load (we can ignore the HOME env var). Or i might be not thinking straight, which is quite possible.
Dulwich will read global config in do_commit, if author is blank. But, that can just as well be stored in local .git/config, as far as I can tell... I like your idea about prompting. We could also monkey patch the part that checks the default location, to check somewhere else.
By the way, we probably need to add git pull, since that's the other case where you'd want to use origin.
Keychain is pretty simple. It stores a pass based on a service (I.e hostname prepended with something like shellista.git) and username. Then for push, store user/pass if specified, and try to use what is in keychain if not. Then secure prompt if keychain is empty, or pass fails...I assume gittle or dulwich throws something catchable for auth fail?
I'll make a stab at something if you'd like.
I got this working, but screwed up the pull... I pushed your changes into my fork rather than pulling.
Improving this would be killer. I use 2FA with my GitHub account so typing out a 40 character application password is a bit unfriendly.
@terinjokes... will try to get this fixed ASAP
I'm not that familiar with git, so don't know if this makes sense or not... But it would be nice to save the master address that we push and pull from . Not sure if this is stored inside the .git folder? The git push or git pull would use last server.
Likewise, we should use the pythonista keychain to save github credentials.
Thoughts?