1

I have a repository that has a remote to azure-devops.

I have to go through a proxy if that matters, but that's setup and working correctly. I don't think this will be an issue for this question.

You can add a token to the remote url (in the form of https://user:pat@dev.azure.com/...), which I do because copy-n-pasting the pat every single time is annoying.

When pushing or pulling, the full url is displayed.

$ git push azure dev
Counting objects: 3, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 279 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: Analyzing objects... (2/2) (163 ms)
remote: Storing packfile... done (177 ms)
remote: Storing index... done (31 ms)
To https://user:mypat@dev.azure.com/user/path/to/repo <<<---
   b20e4fd..b1772a1  dev -> dev

How can I suppress the 'To https...' line?

Edit: This is not a duplicate, because that answer changes authentication protocol to ssh keys. Because I have to use a proxy (see second paragraph) I can't use ssh keys.

harleypig
  • 1,264
  • 8
  • 25
  • What do you mean by suppress? As I’m not letting it be output by git? – evolutionxbox Jul 09 '19 at 18:33
  • Possible duplicate of [How do I avoid the specification of the username and password at every git push?](https://stackoverflow.com/questions/8588768/how-do-i-avoid-the-specification-of-the-username-and-password-at-every-git-push) – blurfus Jul 09 '19 at 18:33
  • Perhaps this answer will help as well: https://serverfault.com/a/912788 – blurfus Jul 09 '19 at 18:36
  • @ochi The OP doesn't ask how to get username/password. The question is about how to hide username/password from public logs. – phd Jul 09 '19 at 22:42
  • @phd never said anything to the contrary. First link indicates that, if using an SSH key, you don't need to enter user/pass credentials (and, thus, avoid showing them on logs) - the other link illustrates how to to use a shell that echos env variables (which contain user/pass) - The poster of this one indicated it does not echo values to screen either. – blurfus Jul 09 '19 at 22:47
  • @ochi I think such links require more explanation than just links. This one is better than nothing, thanks. – phd Jul 09 '19 at 22:49
  • You can't. You need to use a solution which doesn't put credentials in the URL, either by using a credential helper of some sort or by using SSH. – bk2204 Jul 09 '19 at 22:49
  • 1
    @phd the explanations are in the answers themselves. OP can read them as well as any other user - I do not see the need to spoon-feeding or duplicating a well-explained answer (diluted into a comment). Do you? – blurfus Jul 09 '19 at 22:54
  • Edited to explain why I think this isn't a duplicate. @ochi pointed me in the right direction, however, with his second link. I'm creating an answer for this question now. – harleypig Jul 10 '19 at 14:58

1 Answers1

1

@ochi pointed to a comment on another, similar question. The following comment held my answer.

Using .netrc to hold my authentication information works as desired. Make sure to chmod 0600 ~/.netrc or it won't work.

machine dev.azure.com
login user
password personalaccesstoken

This is the output I'm getting now.

$ git push azure test
Counting objects: 3, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 289 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: Analyzing objects... (2/2) (126 ms)
remote: Storing packfile... done (244 ms)
remote: Storing index... done (95 ms)
To https://dev.azure.com/user/path/to/repo <<<---
   24a77ad..5ee5fcb  HEAD -> test

Updated

As pointed out in the comments, this is not a perfect solution. The .netrc file is used by other applications and this information will be available to them. This works in my situation, you should evaluate yours and decide if this is what you want.

blurfus
  • 13,485
  • 8
  • 55
  • 61
harleypig
  • 1,264
  • 8
  • 25
  • 1
    Beware that this solution leaves your user/pass in the `~/.netrc` file - which other systems might be able to read or have access to. This is undesirable in some cases. – blurfus Jul 10 '19 at 15:39
  • Edited to incorporate your warning. Thank you. – harleypig Jul 10 '19 at 15:55