git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: clime <clime7@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: getting pull/push/fetch url
Date: Fri, 17 May 2019 13:02:47 +0200	[thread overview]
Message-ID: <CAGqZTUv7zkgT=GJK5Mo7HCoNcjqvsZoCKb93Pc=_r6LcskAabw@mail.gmail.com> (raw)
In-Reply-To: <CAPig+cQ0MB4F++JDC-RO2SFA4Hv7DiEW4hNJGQs71Wi75pXuOg@mail.gmail.com>

On Fri, 17 May 2019 at 10:10, Eric Sunshine <sunshine@sunshineco.com> wrote:
>
> On Fri, May 17, 2019 at 3:30 AM clime <clime7@gmail.com> 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=<format> <branch>` and `git remote get-url <remote>`
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.<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.<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

  reply	other threads:[~2019-05-17 11:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-17  7:30 getting pull/push/fetch url clime
2019-05-17  8:09 ` Eric Sunshine
2019-05-17 11:02   ` clime [this message]
2019-05-17 11:10     ` clime

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGqZTUv7zkgT=GJK5Mo7HCoNcjqvsZoCKb93Pc=_r6LcskAabw@mail.gmail.com' \
    --to=clime7@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).