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
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>`?
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>`
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.
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.
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 :)
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.