# getting pull/push/fetch url 4 messages from 2019-05-17 to 2019-05-17. Participants: clime, Eric Sunshine. Thread: https://gitlist.dev/t/51112 ## clime, 2019-05-17 07:30 Subject: getting pull/push/fetch url Message-ID: URL: https://gitlist.dev/e/CAGqZTUvTg5S_-i9JjOwEG75CY%2BxFXJHAwTqh8uLG3SQTa3O0YA%40mail.gmail.com ``` Hello, for my app, i need to be able get remote urls (fetch/pull/push) so that i can derive some information from those, e.g. pull url netloc from which i derive where other custom endpoints (binary file storage) related to the remote git repo is located. This is just one example. I am also using fetch url to store it into the composed package that i generate by the app. ...And I also want to support git down to 1.7.1 (maybe i could live with 1.8.3, not sure now) Now, the problem is that getting those urls (fetch/pull/push) doesn't seem to be an easy task. Currently i have the attached scripts to do that. But i noticed that older gits like 1.7 use origin as a fallback for pull url whereas the newer raise an error. My question is if there is a better way to determine the urls that would be backward compatible and easier than what i am doing right now. I could probably tweak my app to only use fetch url but then i won't support triangle workflow so i would like to know if there is some better option. Thank you clime ``` ## Eric Sunshine, 2019-05-17 08:09 Subject: Re: getting pull/push/fetch url Message-ID: URL: https://gitlist.dev/e/CAPig%2BcQ0MB4F%2B%2BJDC-RO2SFA4Hv7DiEW4hNJGQs71Wi75pXuOg%40mail.gmail.com In-Reply-To: ``` On Fri, May 17, 2019 at 3:30 AM clime wrote: > for my app, i need to be able get remote urls (fetch/pull/push) so > that i can derive some information from those, e.g. pull url netloc > from which i derive where other custom endpoints (binary file storage) > related to the remote git repo is located. This is just one example. I > am also using fetch url to store it into the composed package that i > generate by the app. > > Now, the problem is that getting those urls (fetch/pull/push) doesn't > seem to be an easy task. Currently i have the attached scripts to do > that. But i noticed that older gits like 1.7 use origin as a fallback > for pull url whereas the newer raise an error. > > My question is if there is a better way to determine the urls that > would be backward compatible and easier than what i am doing right > now. Perhaps not a complete answer (and I'm sure people more familiar with the topic can provide better direction), but have you tried querying this information via higher-level commands rather than low-level git-config? For instance, to get the name of the remote for a branch: git branch --list --format='%(upstream:remotename)' $BRANCH and, to get the fetch URL for a remote: git remote get-url $REMOTE or the push URL: git remote get-url --push $REMOTE ``` ## clime, 2019-05-17 11:02 Subject: Re: getting pull/push/fetch url Message-ID: URL: https://gitlist.dev/e/CAGqZTUv7zkgT%3DGJK5Mo7HCoNcjqvsZoCKb93Pc%3D_r6LcskAabw%40mail.gmail.com In-Reply-To: ``` On Fri, 17 May 2019 at 10:10, Eric Sunshine wrote: > > On Fri, May 17, 2019 at 3:30 AM clime wrote: > > for my app, i need to be able get remote urls (fetch/pull/push) so > > that i can derive some information from those, e.g. pull url netloc > > from which i derive where other custom endpoints (binary file storage) > > related to the remote git repo is located. This is just one example. I > > am also using fetch url to store it into the composed package that i > > generate by the app. > > > > Now, the problem is that getting those urls (fetch/pull/push) doesn't > > seem to be an easy task. Currently i have the attached scripts to do > > that. But i noticed that older gits like 1.7 use origin as a fallback > > for pull url whereas the newer raise an error. > > > > My question is if there is a better way to determine the urls that > > would be backward compatible and easier than what i am doing right > > now. > > Perhaps not a complete answer (and I'm sure people more familiar with > the topic can provide better direction), but have you tried querying > this information via higher-level commands rather than low-level > git-config? For instance, to get the name of the remote for a branch: > > git branch --list --format='%(upstream:remotename)' $BRANCH > > and, to get the fetch URL for a remote: > > git remote get-url $REMOTE > > or the push URL: > > git remote get-url --push $REMOTE Right, the problem is that both constructs `git branch --list --format= ` and `git remote get-url ` works only under git v2 (not exactly sure about the minor version) but they do not work under git 1.7.1 and git 1.8.3, it seems. Anyway, i figured i was too fuzzy in what kind of url i actually need. I thought about it a bit more and figured that I probably this function git_branch_remote { branch_remote="$(git -C "$GIT_ROOT" config --get branch."$GIT_BRANCH".pushRemote)" if [ -z "$branch_remote" ]; then branch_remote="$(git -C "$GIT_ROOT" config --get remote.pushDefault)" fi if [ -z "$branch_remote" ]; then branch_remote="$(git -C "$GIT_ROOT" config --get branch."$GIT_BRANCH".remote)" fi if [ -z "$branch_remote" ]; then branch_remote="origin" fi echo "$branch_remote" } Because basically, if some wants to go for triangle workflow, then push url remote should be preferred because that's where user has write access. If not, then there is a fallback to branch..remote and to origin eventually, which is just nice to have cause it makes a minimal setup for my app easier. So basically, it is possible that an effective (where git actually pushes when `git push` is invoked) remote for pushing will be different than what that function returns (e.g. when git 1.7.1. is used which doesn't know about branch..pushRemote and remote.pushDefault) but it doesn't really matter as long as a user is able to make a local configuration where effective push remote and remote returned by the fuction will align. Then i also need 'origin' being returned immediatelly after clean clone but that's the case as well. So when i have this kind of 'abstracted' remote, then i need to take pushUrl on one place and fetch url on another but there should be no problem there. Sorry, i didn't realize i actually kind of this 'hybrid remote' thing. There still might an easier way to write that function (in a compatible way). Not sure about that. Anyway, thanks clime ``` ## clime, 2019-05-17 11:10 Subject: Re: getting pull/push/fetch url Message-ID: URL: https://gitlist.dev/e/CAGqZTUuh5K447ejUTDfnR-5t0oqQ8BpU%3DtKUR%3Ds9APmCja%3Dmhw%40mail.gmail.com In-Reply-To: ``` On Fri, 17 May 2019 at 13:02, clime wrote: > > On Fri, 17 May 2019 at 10:10, Eric Sunshine wrote: > > > > On Fri, May 17, 2019 at 3:30 AM clime wrote: > > > for my app, i need to be able get remote urls (fetch/pull/push) so > > > that i can derive some information from those, e.g. pull url netloc > > > from which i derive where other custom endpoints (binary file storage) > > > related to the remote git repo is located. This is just one example. I > > > am also using fetch url to store it into the composed package that i > > > generate by the app. > > > > > > Now, the problem is that getting those urls (fetch/pull/push) doesn't > > > seem to be an easy task. Currently i have the attached scripts to do > > > that. But i noticed that older gits like 1.7 use origin as a fallback > > > for pull url whereas the newer raise an error. > > > > > > My question is if there is a better way to determine the urls that > > > would be backward compatible and easier than what i am doing right > > > now. > > > > Perhaps not a complete answer (and I'm sure people more familiar with > > the topic can provide better direction), but have you tried querying > > this information via higher-level commands rather than low-level > > git-config? For instance, to get the name of the remote for a branch: > > > > git branch --list --format='%(upstream:remotename)' $BRANCH > > > > and, to get the fetch URL for a remote: > > > > git remote get-url $REMOTE > > > > or the push URL: > > > > git remote get-url --push $REMOTE > > Right, the problem is that both constructs `git branch --list > --format= ` and `git remote get-url ` > works only under git v2 (not exactly sure about the minor version) but > they do not work under git 1.7.1 and git 1.8.3, it > seems. > > Anyway, i figured i was too fuzzy in what kind of url i actually need. > I thought about it a bit more and figured that I probably this > > function git_branch_remote { > branch_remote="$(git -C "$GIT_ROOT" config --get > branch."$GIT_BRANCH".pushRemote)" > > if [ -z "$branch_remote" ]; then > branch_remote="$(git -C "$GIT_ROOT" config --get remote.pushDefault)" > fi > > if [ -z "$branch_remote" ]; then > branch_remote="$(git -C "$GIT_ROOT" config --get > branch."$GIT_BRANCH".remote)" > fi > > if [ -z "$branch_remote" ]; then > branch_remote="origin" > fi > > echo "$branch_remote" > } > > Because basically, if some wants to go for triangle workflow, then > push url remote should be preferred because > that's where user has write access. If not, then there is a fallback > to branch..remote and to origin > eventually, which is just nice to have cause it makes a minimal setup > for my app easier. > > So basically, it is possible that an effective (where git actually > pushes when `git push` is invoked) remote > for pushing will be different than what that function returns (e.g. > when git 1.7.1. is used which doesn't > know about branch..pushRemote and remote.pushDefault) but it > doesn't really matter as long > as a user is able to make a local configuration where effective push > remote and remote returned by > the fuction will align. > > Then i also need 'origin' being returned immediatelly after clean > clone but that's the case as well. > > So when i have this kind of 'abstracted' remote, then i need to take > pushUrl on one place and fetch > url on another but there should be no problem there. > > Sorry, i didn't realize i actually kind of this 'hybrid remote' thing. > There still might an easier way to write > that function (in a compatible way). Not sure about that. > > Anyway, thanks > clime And sry for my previous email being a mess. I rushed too much to write it. ```