~radicle-link/dev

6 2

gitd and git fetch tag

Details
Message ID
<CAH_DpYRuMq5BmTMWiMosSUcWAAXxRzWOXMziqJYADFxtpa=a+g@mail.gmail.com>
DKIM signature
missing
Download raw message
I'm not sure how to make `git fetch <remote> tag <tag>` work nicely. The
problem is this line from [1]

    tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; it
    requests fetching everything up to the given tag.

This seems to always fetch `refs/tags/<tag>`, regardless of what the
fetchspec for the given remote is set up to do.

This means you can only ever fetch tags which you have created in your
local view of the project in the monorepo.

[1]: https://git-scm.com/docs/git-fetch
Details
Message ID
<CKYH6YJFEC7A.3UOR382D747Z9@haptop>
In-Reply-To
<CAH_DpYRuMq5BmTMWiMosSUcWAAXxRzWOXMziqJYADFxtpa=a+g@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
On Fri Jun 24, 2022 at 4:30 PM IST, Alex Good wrote:
> I'm not sure how to make `git fetch <remote> tag <tag>` work nicely. The
> problem is this line from [1]
>
>     tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; it
>     requests fetching everything up to the given tag.
>
> This seems to always fetch `refs/tags/<tag>`, regardless of what the
> fetchspec for the given remote is set up to do.
>
> This means you can only ever fetch tags which you have created in your
> local view of the project in the monorepo.
>
> [1]: https://git-scm.com/docs/git-fetch

Can't you fetch the tag by `git fetch <remote> <tag>`?
Details
Message ID
<CAH_DpYQ_QU8wcOdL+jzPO06NTY30M8Z47gkaMHmK+Tk_i3qydg@mail.gmail.com>
In-Reply-To
<CKYH6YJFEC7A.3UOR382D747Z9@haptop> (view parent)
DKIM signature
missing
Download raw message
On 24/06/22 04:39pm, Fintan Halpenny wrote:
> On Fri Jun 24, 2022 at 4:30 PM IST, Alex Good wrote:
> > I'm not sure how to make `git fetch <remote> tag <tag>` work nicely. The
> > problem is this line from [1]
> >
> >     tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; it
> >     requests fetching everything up to the given tag.
> >
> > This seems to always fetch `refs/tags/<tag>`, regardless of what the
> > fetchspec for the given remote is set up to do.
> >
> > This means you can only ever fetch tags which you have created in your
> > local view of the project in the monorepo.
> >
> > [1]: https://git-scm.com/docs/git-fetch
>
> Can't you fetch the tag by `git fetch <remote> <tag>`?

No. Given our refspec setup that fetches `refs/remotes/<remote>/heads/<tag>`
but the tag is actually under `refs/remotes/<remote>/tags/<tag>`
Details
Message ID
<CKYHDCMCZ5I2.2UHG7AZYL1P6D@haptop>
In-Reply-To
<CAH_DpYQ_QU8wcOdL+jzPO06NTY30M8Z47gkaMHmK+Tk_i3qydg@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
On Fri Jun 24, 2022 at 4:46 PM IST, Alex Good wrote:
> On 24/06/22 04:39pm, Fintan Halpenny wrote:
> > On Fri Jun 24, 2022 at 4:30 PM IST, Alex Good wrote:
> > > I'm not sure how to make `git fetch <remote> tag <tag>` work nicely. The
> > > problem is this line from [1]
> > >
> > >     tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; it
> > >     requests fetching everything up to the given tag.
> > >
> > > This seems to always fetch `refs/tags/<tag>`, regardless of what the
> > > fetchspec for the given remote is set up to do.
> > >
> > > This means you can only ever fetch tags which you have created in your
> > > local view of the project in the monorepo.
> > >
> > > [1]: https://git-scm.com/docs/git-fetch
> >
> > Can't you fetch the tag by `git fetch <remote> <tag>`?
>
> No. Given our refspec setup that fetches `refs/remotes/<remote>/heads/<tag>`
> but the tag is actually under `refs/remotes/<remote>/tags/<tag>`

And if we had another fetchspec `refs/remotes/<remote>/tags/*`? We would probably advise to have:

---
[remote "memorythought@hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6"]
  url = rad://hnrkxafojjsz4m55qxbwigh1z8sdt7mai81gy.git
  fetch = +refs/remotes/hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/heads/*:refs/remotes/memorythought@hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/heads/*
  fetch = +refs/remotes/hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/tags/*:refs/tags/memorythought@hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/*
  tagOpt = --no-tags
---

So it would map the remote's tags under our tags category but scoped
by the remote name.
Details
Message ID
<CAH_DpYSz02CLpYLL3XaYPr2HK8eJqZUmPd7eWH58REzRV_VFFQ@mail.gmail.com>
In-Reply-To
<CKYHDCMCZ5I2.2UHG7AZYL1P6D@haptop> (view parent)
DKIM signature
missing
Download raw message
On 24/06/22 04:47pm, Fintan Halpenny wrote:
> On Fri Jun 24, 2022 at 4:46 PM IST, Alex Good wrote:
> > On 24/06/22 04:39pm, Fintan Halpenny wrote:
> > > On Fri Jun 24, 2022 at 4:30 PM IST, Alex Good wrote:
> > > > I'm not sure how to make `git fetch <remote> tag <tag>` work nicely. The
> > > > problem is this line from [1]
> > > >
> > > >     tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; it
> > > >     requests fetching everything up to the given tag.
> > > >
> > > > This seems to always fetch `refs/tags/<tag>`, regardless of what the
> > > > fetchspec for the given remote is set up to do.
> > > >
> > > > This means you can only ever fetch tags which you have created in your
> > > > local view of the project in the monorepo.
> > > >
> > > > [1]: https://git-scm.com/docs/git-fetch
> > >
> > > Can't you fetch the tag by `git fetch <remote> <tag>`?
> >
> > No. Given our refspec setup that fetches `refs/remotes/<remote>/heads/<tag>`
> > but the tag is actually under `refs/remotes/<remote>/tags/<tag>`
>
> And if we had another fetchspec `refs/remotes/<remote>/tags/*`? We would probably advise to have:
>
> ---
> [remote "memorythought@hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6"]
>   url = rad://hnrkxafojjsz4m55qxbwigh1z8sdt7mai81gy.git
>   fetch = +refs/remotes/hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/heads/*:refs/remotes/memorythought@hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/heads/*
>   fetch = +refs/remotes/hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/tags/*:refs/tags/memorythought@hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/*
>   tagOpt = --no-tags
> ---
>
> So it would map the remote's tags under our tags category but scoped
> by the remote name.

This doesn't work for me. I think the problem is this paragraph from the
docs:

    When git fetch is run with explicit branches and/or tags to fetch on
    the command line, e.g. git fetch origin master, the <refspec>s given
    on the command line determine what are to be fetched (e.g. master in
    the example, which is a short-hand for master:, which in turn means
    "fetch the master branch but I do not explicitly say what
    remote-tracking branch to update with it from the command line"),
    and the example command will fetch only the master branch. The
    remote.<repository>.fetch values determine which remote-tracking
    branch, if any, is updated. When used in this way, the
    remote.<repository>.fetch values do not have any effect in deciding
    what gets fetched (i.e. the values are not used as refspecs when the
    command-line lists refspecs); they are only used to decide where the
    refs that are fetched are stored by acting as a mapping.

That is to say `git fetch <remote> <branch>` will actually run a fetch
for `refs/heads/<branch>`. On the other hand, `git fetch` with no
arguments will do the right thing because the fetchspec is then used to
figure out what to actually do.

I'm starting to think that we may need to have a separate URL in the
gitd for each remote and do some ref rewriting in gitd.
Details
Message ID
<CKYHWZJFYR10.1ER4A0HHLG6CM@haptop>
In-Reply-To
<CAH_DpYSz02CLpYLL3XaYPr2HK8eJqZUmPd7eWH58REzRV_VFFQ@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
On Fri Jun 24, 2022 at 5:11 PM IST, Alex Good wrote:
> On 24/06/22 04:47pm, Fintan Halpenny wrote:
> > On Fri Jun 24, 2022 at 4:46 PM IST, Alex Good wrote:
> > > On 24/06/22 04:39pm, Fintan Halpenny wrote:
> > > > On Fri Jun 24, 2022 at 4:30 PM IST, Alex Good wrote:
> > > > > I'm not sure how to make `git fetch <remote> tag <tag>` work nicely. The
> > > > > problem is this line from [1]
> > > > >
> > > > >     tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; it
> > > > >     requests fetching everything up to the given tag.
> > > > >
> > > > > This seems to always fetch `refs/tags/<tag>`, regardless of what the
> > > > > fetchspec for the given remote is set up to do.
> > > > >
> > > > > This means you can only ever fetch tags which you have created in your
> > > > > local view of the project in the monorepo.
> > > > >
> > > > > [1]: https://git-scm.com/docs/git-fetch
> > > >
> > > > Can't you fetch the tag by `git fetch <remote> <tag>`?
> > >
> > > No. Given our refspec setup that fetches `refs/remotes/<remote>/heads/<tag>`
> > > but the tag is actually under `refs/remotes/<remote>/tags/<tag>`
> >
> > And if we had another fetchspec `refs/remotes/<remote>/tags/*`? We would probably advise to have:
> >
> > ---
> > [remote "memorythought@hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6"]
> >   url = rad://hnrkxafojjsz4m55qxbwigh1z8sdt7mai81gy.git
> >   fetch = +refs/remotes/hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/heads/*:refs/remotes/memorythought@hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/heads/*
> >   fetch = +refs/remotes/hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/tags/*:refs/tags/memorythought@hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/*
> >   tagOpt = --no-tags
> > ---
> >
> > So it would map the remote's tags under our tags category but scoped
> > by the remote name.
>
> This doesn't work for me. I think the problem is this paragraph from the
> docs:
>
>     When git fetch is run with explicit branches and/or tags to fetch on
>     the command line, e.g. git fetch origin master, the <refspec>s given
>     on the command line determine what are to be fetched (e.g. master in
>     the example, which is a short-hand for master:, which in turn means
>     "fetch the master branch but I do not explicitly say what
>     remote-tracking branch to update with it from the command line"),
>     and the example command will fetch only the master branch. The
>     remote.<repository>.fetch values determine which remote-tracking
>     branch, if any, is updated. When used in this way, the
>     remote.<repository>.fetch values do not have any effect in deciding
>     what gets fetched (i.e. the values are not used as refspecs when the
>     command-line lists refspecs); they are only used to decide where the
>     refs that are fetched are stored by acting as a mapping.
>
> That is to say `git fetch <remote> <branch>` will actually run a fetch
> for `refs/heads/<branch>`. On the other hand, `git fetch` with no
> arguments will do the right thing because the fetchspec is then used to
> figure out what to actually do.

Goddammmmmmm DWIM...

> I'm starting to think that we may need to have a separate URL in the
> gitd for each remote and do some ref rewriting in gitd.

I'd like to hear more about this :)
Details
Message ID
<CAH_DpYT21z5zLuXFHZYK27Hf++BPY8p01ANCckET4yXL79o15A@mail.gmail.com>
In-Reply-To
<CKYHWZJFYR10.1ER4A0HHLG6CM@haptop> (view parent)
DKIM signature
missing
Download raw message
On 24/06/22 05:13pm, Fintan Halpenny wrote:
> On Fri Jun 24, 2022 at 5:11 PM IST, Alex Good wrote:
> > On 24/06/22 04:47pm, Fintan Halpenny wrote:
> > > On Fri Jun 24, 2022 at 4:46 PM IST, Alex Good wrote:
> > > > On 24/06/22 04:39pm, Fintan Halpenny wrote:
> > > > > On Fri Jun 24, 2022 at 4:30 PM IST, Alex Good wrote:
> > > > > > I'm not sure how to make `git fetch <remote> tag <tag>` work nicely. The
> > > > > > problem is this line from [1]
> > > > > >
> > > > > >     tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; it
> > > > > >     requests fetching everything up to the given tag.
> > > > > >
> > > > > > This seems to always fetch `refs/tags/<tag>`, regardless of what the
> > > > > > fetchspec for the given remote is set up to do.
> > > > > >
> > > > > > This means you can only ever fetch tags which you have created in your
> > > > > > local view of the project in the monorepo.
> > > > > >
> > > > > > [1]: https://git-scm.com/docs/git-fetch
> > > > >
> > > > > Can't you fetch the tag by `git fetch <remote> <tag>`?
> > > >
> > > > No. Given our refspec setup that fetches `refs/remotes/<remote>/heads/<tag>`
> > > > but the tag is actually under `refs/remotes/<remote>/tags/<tag>`
> > >
> > > And if we had another fetchspec `refs/remotes/<remote>/tags/*`? We would probably advise to have:
> > >
> > > ---
> > > [remote "memorythought@hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6"]
> > >   url = rad://hnrkxafojjsz4m55qxbwigh1z8sdt7mai81gy.git
> > >   fetch = +refs/remotes/hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/heads/*:refs/remotes/memorythought@hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/heads/*
> > >   fetch = +refs/remotes/hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/tags/*:refs/tags/memorythought@hydjhd8q9nkoxzkpddhcuue9xzpfr4bn6d44fo1f4q1japwm4brhh6/*
> > >   tagOpt = --no-tags
> > > ---
> > >
> > > So it would map the remote's tags under our tags category but scoped
> > > by the remote name.
> >
> > This doesn't work for me. I think the problem is this paragraph from the
> > docs:
> >
> >     When git fetch is run with explicit branches and/or tags to fetch on
> >     the command line, e.g. git fetch origin master, the <refspec>s given
> >     on the command line determine what are to be fetched (e.g. master in
> >     the example, which is a short-hand for master:, which in turn means
> >     "fetch the master branch but I do not explicitly say what
> >     remote-tracking branch to update with it from the command line"),
> >     and the example command will fetch only the master branch. The
> >     remote.<repository>.fetch values determine which remote-tracking
> >     branch, if any, is updated. When used in this way, the
> >     remote.<repository>.fetch values do not have any effect in deciding
> >     what gets fetched (i.e. the values are not used as refspecs when the
> >     command-line lists refspecs); they are only used to decide where the
> >     refs that are fetched are stored by acting as a mapping.
> >
> > That is to say `git fetch <remote> <branch>` will actually run a fetch
> > for `refs/heads/<branch>`. On the other hand, `git fetch` with no
> > arguments will do the right thing because the fetchspec is then used to
> > figure out what to actually do.
>
> Goddammmmmmm DWIM...
>
> > I'm starting to think that we may need to have a separate URL in the
> > gitd for each remote and do some ref rewriting in gitd.
>
> I'd like to hear more about this :)

What I'm imagining is that we have URLs of the form:

    ssh://<addr>/<peer ID>@<URN>

The idea would be for this remote to be kind of like a nested namespace,
the outer namespace being the URN and the inner namespace being the peer
ID. We had a play with this before. It wasn't useful because we can't tell
git that the peer ID is a kind of namespace (the ref layout would need
to be `refs/namespaces/<URN>/refs/namespaces/<peer ID>` for that to work
I think).

What we could do though is actually intercept the protocol in `gitd` and
rewrite all references to `refs/remotes/<peer id>/* -> *` (on the way
out, and the converse on the way in) and block everything else. This is
more work but gives us complete control over how the remote is seen by
the git client.
Reply to thread Export thread (mbox)