Re: Git clone sends first an empty authorization header
Hey Bryan, Yes that will happen he will get a prompet for username/password but he already provided them in the URL and it worked before. He could clone. I think this is a little bit confusing. My problem is that the tool I'm trying to build is trying to provide the username used to log in via an environment variable. And due to the fact that the anonymous login is always the first to be tried, even if the user provides an username/password on the URL I'm not able to retrieve it. On Sat, Mar 5, 2016 at 11:20 AM, Bryan Turner <btur...@atlassian.com> wrote: > On Fri, Mar 4, 2016 at 9:51 PM, Guilherme <guibuf...@gmail.com> wrote: >> Hi, >> >> When doing basic authentication using git clone by passing the >> username and password in the url git clone will first send a GET >> request without the authorization header set. >> >> Am i seeing this right? > > I believe this is an intentional behavior in either cURL or how Git > uses it. Credentials aren't sent until the server returns a challenge > for them, even if you include them in your clone URL or elsewhere. So > yes, you're seeing it right. > >> >> This means that if the counterpart allows anonymous cloning but not >> pushing and the user provided a wrong usernam/password, it has two >> options: > > I'm not sure why this would be true. If the remote server allows > anonymous clone/fetch, then you never get prompted for credentials > and, even if they're supplied, they're never sent to the remote > server. If you then try to push, if the server is working correctly it > should detect that anonymous users can't push and it should return a > 401 with a WWW-Authenticate header. When the client receives the 401, > it should send the credentials it has (or prompt for them if it > doesn't have them) and the push should work without issue. > > Perhaps there's an issue with how your server is setup to handle permissions? > >> >> 1. Allow the access and leave the user to figure out why he is not able to >> push. >> >> 2. Reply by setting the WWW-Authentication header and see if a >> password/username is provided. This has the downside that if no >> username and password is provided the user will still get a login >> prompt for password and username. Upon entering twice nothing he will >> still be able to clone. This can be confusing. >> >> Can this behaviour of git clone (and I guess all the other parts that >> do basic auth) be changed to provide the authentication header right >> on the first request? Or am I doing/interpreting it wrong? >> >> Thank you. >> -- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git clone sends first an empty authorization header
Hi, When doing basic authentication using git clone by passing the username and password in the url git clone will first send a GET request without the authorization header set. Am i seeing this right? This means that if the counterpart allows anonymous cloning but not pushing and the user provided a wrong usernam/password, it has two options: 1. Allow the access and leave the user to figure out why he is not able to push. 2. Reply by setting the WWW-Authentication header and see if a password/username is provided. This has the downside that if no username and password is provided the user will still get a login prompt for password and username. Upon entering twice nothing he will still be able to clone. This can be confusing. Can this behaviour of git clone (and I guess all the other parts that do basic auth) be changed to provide the authentication header right on the first request? Or am I doing/interpreting it wrong? Thank you. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git config --get-urlmatch does not set exit code 1 when no match is found
@Peff Thank you for the heads up. I'm trying to find out if there are any credential helpers configured in the system that will be running tests. On the dedicated test machines that is not a problem but the developer machines are. Should I already post a pre-emptive email asking about the corner cases? More importantly for me is if there is a case where get-url would not show a match where git clone would. If git clone skips a configuration that config url-match doesn't then it's not so bad. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git config --get-urlmatch does not set exit code 1 when no match is found
Hello, My current woes are with multi-valued configuration values. More specifically credential.helper The documentation of git config says that when a value is not matched it should return 1. To reproduce make sure that credential.helper is not set. git config --get-urlmatch credential.helper http://somedomain:1234/ echo %ERRORLEVEL% 0 git config --get credential.helper echo %ERRORLEVEL% 1 git config --get credential.http://somedomain:1234/.helper echo %ERRORLEVEL% 1 The documentation says that for credential.helper is not found for a domain it should fall back to credential.helper if it is set. So I think that all those tests above should have returned 0. Am i right? Cheers. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: git clone does not respect command line options
What is the current situation if credential.helper is set twice in the same config file. Either [credential] helper = first helper = second or with [credential] helper = first [credenital] helper = second Will both be used by git clone? How do i remove these from the command line? I tried git config --unset credential.helper but that only gives you a warning and does not remove any. Worse is that if second is the empty string there is no way for one to know there is a second set unless he tries to delete the first one. But one still cannot query the value of the second. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: git clone does not respect command line options
Thanks for the quick reply. Is there any documentation on which variables are muli-valued? git -c credential.helper="store --file=creds" config --get credential.helper only returns one value. How can i even know if there are multiple set. I mean someone might have just created an extra credential.helper in `--system` that I'm not expecting... On Fri, Feb 26, 2016 at 1:04 PM, Jeff King <p...@peff.net> wrote: > On Fri, Feb 26, 2016 at 12:17:49PM +0530, Guilherme wrote: > >> I'm trying to use git in an integration test and i'm having trouble >> with configuration options. >> >> On windows developer machines we use wincred as our credenital helper >> and thus have it set in ~/.gitconfig >> >> For the integration test that is no use as it will make testing >> unauthorized logging in impossible. >> >> Since there is no way of disabling configuration options on the >> command line i tried setting it to store with a file I could delete. >> So in front of every command we insert `-c credential.helper="store >> --file=creds.txt"`. In the end the command line looks like: >> >> git -c credential.helper="store --file=creds.txt" clone >> http://admin:admin@oururl@2/TestRepo.git >> >> I see the file creds.txt being created containing only >> http://admin:admin@oururl@2/TestRepo.git but the credenital at the >> same time appears in the windows credential store. >> >> Can anybody else confirm this? > > That's behaving as expected. Unfortunately, you cannot currently do what > you want easily; there is no way to "unset" a multi-valued config > variable (like credential.helper) with a later one. Git will ask both > configured helpers for the password, and will store a successful result > in both. > > The simplest way I can think of to work around it is to point your $HOME > elsewhere[1] during the integration test, so that it does not read your > regular ~/gitconfig. > > -Peff > > [1] Actually, that is what I would do on a Unix system. I have no idea > how the home directory is determined on Windows. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: git clone does not respect command line options
Hi! I'm trying to use git in an integration test and i'm having trouble with configuration options. On windows developer machines we use wincred as our credenital helper and thus have it set in ~/.gitconfig For the integration test that is no use as it will make testing unauthorized logging in impossible. Since there is no way of disabling configuration options on the command line i tried setting it to store with a file I could delete. So in front of every command we insert `-c credential.helper="store --file=creds.txt"`. In the end the command line looks like: git -c credential.helper="store --file=creds.txt" clone http://admin:admin@oururl@2/TestRepo.git I see the file creds.txt being created containing only http://admin:admin@oururl@2/TestRepo.git but the credenital at the same time appears in the windows credential store. Can anybody else confirm this? Thank you. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Copyright on wildmatch.c
That discussion seems to have just died off. Whom should i write to about making the license change effective? You (Duy Nguyen) seemed to be fine with the license change. Can you, or anyone else, further guide me on the process on making sure i can use the file(s) in TSS? Thank you. On Tue, Feb 24, 2015 at 9:58 AM, Duy Nguyen pclo...@gmail.com wrote: On Tue, Feb 24, 2015 at 3:08 PM, Guilherme guibuf...@gmail.com wrote: Hello, I have already posted this to the users mailing list but i guess it's more appropriate to have it here. Related thread about relicensing wildmatch.c for tss http://thread.gmane.org/gmane.comp.version-control.git/259764/focus=259798 -- Forwarded message -- From: Guilherme guibuf...@gmail.com Date: Tue, Feb 24, 2015 at 9:02 AM Subject: Copyright on wildmatch.c To: git-us...@googlegroups.com git-us...@googlegroups.com Hello, I'm trying to implement support for gitignore files in the_silver_searcher (https://github.com/ggreer/the_silver_searcher). It is a source code optimized version of grep. And it is way faster than ack. The problems at hand is that I'd like to use wildmatch.c and some dependencies (hex.c, some portions of compat-util.h) but it seems that git is GPL whereas tss is Apache2 licensed. Is there any possibility to re-license the files above to Apache2 for the TSS project? If not, is there any c library that provides support gitignore patterns? Thank you very much, Bufolo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Copyright on wildmatch.c
Hello, I have already posted this to the users mailing list but i guess it's more appropriate to have it here. -- Forwarded message -- From: Guilherme guibuf...@gmail.com Date: Tue, Feb 24, 2015 at 9:02 AM Subject: Copyright on wildmatch.c To: git-us...@googlegroups.com git-us...@googlegroups.com Hello, I'm trying to implement support for gitignore files in the_silver_searcher (https://github.com/ggreer/the_silver_searcher). It is a source code optimized version of grep. And it is way faster than ack. The problems at hand is that I'd like to use wildmatch.c and some dependencies (hex.c, some portions of compat-util.h) but it seems that git is GPL whereas tss is Apache2 licensed. Is there any possibility to re-license the files above to Apache2 for the TSS project? If not, is there any c library that provides support gitignore patterns? Thank you very much, Bufolo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Copyright on wildmatch.c
This is just an email to all the people i have written in private about relicensing the files in need in TSS so they can reply to this email and it be recorded in the mailing list. The files are part of ctypes.c hex.c git-compat-util.h. On Tue, Feb 24, 2015 at 1:22 PM, Guilherme guibuf...@gmail.com wrote: Hello, I'm writing to you in regards to the files ctypes.c which you have modified part of in the git project. I'm currently working on integrating gitignore pattern matching into the_sivler_searcher(http://github.com/ggreer/the_silver_searcher). PR https://github.com/ggreer/the_silver_searcher/pull/614 For that i needed wildmatch.c and it's dependencies. That is parts of ctypes.c lines 8 to 31. Unfortunately TSS is Apache licensed wheras git is GPL, those licenses are incompatible and thus i ask if you agree that your portion if the code is also licensed under Apache2 for the use in TSS. You can follow the discussion under http://article.gmane.org/gmane.comp.version-control.git/264312 Thank you very much, Bufolo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Copyright on wildmatch.c
Hello, I'm writing to you in regards to the files ctypes.c which you have modified part of in the git project. I'm currently working on integrating gitignore pattern matching into the_sivler_searcher(http://github.com/ggreer/the_silver_searcher). PR https://github.com/ggreer/the_silver_searcher/pull/614 For that i needed wildmatch.c and it's dependencies. That is parts of ctypes.c lines 8 to 31. Unfortunately TSS is Apache licensed wheras git is GPL, those licenses are incompatible and thus i ask if you agree that your portion if the code is also licensed under Apache2 for the use in TSS. You can follow the discussion under http://article.gmane.org/gmane.comp.version-control.git/264312 Thank you very much, Bufolo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Copyright on wildmatch.c
This is CC to Anthony Ramine. On Tue, Feb 24, 2015 at 1:34 PM, Guilherme guibuf...@gmail.com wrote: This is just an email to all the people i have written in private about relicensing the files in need in TSS so they can reply to this email and it be recorded in the mailing list. The files are part of ctypes.c hex.c git-compat-util.h. On Tue, Feb 24, 2015 at 1:22 PM, Guilherme guibuf...@gmail.com wrote: Hello, I'm writing to you in regards to the files ctypes.c which you have modified part of in the git project. I'm currently working on integrating gitignore pattern matching into the_sivler_searcher(http://github.com/ggreer/the_silver_searcher). PR https://github.com/ggreer/the_silver_searcher/pull/614 For that i needed wildmatch.c and it's dependencies. That is parts of ctypes.c lines 8 to 31. Unfortunately TSS is Apache licensed wheras git is GPL, those licenses are incompatible and thus i ask if you agree that your portion if the code is also licensed under Apache2 for the use in TSS. You can follow the discussion under http://article.gmane.org/gmane.comp.version-control.git/264312 Thank you very much, Bufolo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Copyright on wildmatch.c
I'm not sure on how i would rewrite hex.c it is just an array. From git-compat-util.h i only needed a subset of the file (Lines 699 to 785), as you assumed, but rewriting it also seems pointless as it is only a few defines and 4 very short functions. I have asked everybody who changed anything in those lines for their approval. I hope they all agree. On Tue, Feb 24, 2015 at 10:46 AM, Duy Nguyen pclo...@gmail.com wrote: On Tue, Feb 24, 2015 at 4:29 PM, Guilherme guibuf...@gmail.com wrote: That discussion seems to have just died off. Whom should i write to about making the license change effective? You (Duy Nguyen) seemed to be fine with the license change. Can you, or anyone else, further guide me on the process on making sure i can use the file(s) in TSS? I'm not a lawyer, but I think after you double check - what Jonathan Neider wrote about GPLv3 and Apache2 is true - perhaps check with Anthony Ramine, who is the only person besides me that has made changes in wildmatch.c, in b79c0c3 (wildmatch: properly fold case everywhere - 2013-05-30) then wildmatch.c is good for reuse. You probably need to check with other people who made changes in hex.c and git-compat-util.h. git-shortlog and git-blame could be used to get the email list of these people. But maybe it's just easier to rewrite those, hex.c is not big and I suspect you don't need much of git-compat-util.h. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git add single file and git add list of files behave differentely for ignored files
Hello, I reported this issue on the git-user mailing list and they redirected me here. The problem I have observed is that with a ignored path `git add single file` behaves differently then `git add list of files`. I my git/info/excludes file i have /COM/config !COM/config/Project.gny The file COM/config/Project.gny has already been added to the repository via `git add -f`. When doing git add -- COM/config/Projec.gny git will not complain but when doing git add -- COM/config/Project.gny otherfiles.c it will report: The following paths are ignored by one of your .gitignore files: COM/config Use -f if you really want to add them. fatal: no files added This odd behaviour is also present in `git check-ignore`. Before adding the file `git check-ignore` correctly reports the file as ignored. After having added it via `git add -f` it won't report it as ignored anymore. Even if not a bug this behaviour is inconsistent and might want to be addressed as it makes scripting a little bit harder. Thank you. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git add single file and git add list of files behave differentely for ignored files
I forgot to mention: Environment: Cygwin Git version 2.1.1 On Thu, Dec 4, 2014 at 12:11 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Thu, 4 Dec 2014 10:06:23 +0100 Guilherme guibuf...@gmail.com wrote: I reported this issue on the git-user mailing list and they redirected me here. The problem I have observed is that with a ignored path `git add single file` behaves differently then `git add list of files`. [...] To those who's interested the original thread on git-users is https://groups.google.com/d/topic/git-users/322tole9am8/discussion -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Doing a git add '' will add more files then expected
Hello, I first asked on stackoverflow (http://stackoverflow.com/questions/26933761/python-sh-module-and-git-try-to-add-more-files-then-in-command/26934517#26934517) about this behaviour. Then on the conversation that happened on the git-users mailing list other agreed that this behaviour is probably not as intended. Steps to reproduce: In bash (not sure this is bash specific) do: git add '' (that's to apostrophes, an empty argument) Results same as doing git add . Expected no files added or error about not finding file '' Hope this helps. Guilherme -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
