Re: Should 'git replace' respect GIT_NAMESPACE?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 14, 2025 at 6:17 AM Josh Bleecher Snyder
<josharian@xxxxxxxxx> wrote:
>
> I was hoping it would, so I could have different replacements in
> different namespaces, but it doesn't look like it does as of ~now:

It might be interesting to know what you wanted to do with different
replacements in different namespaces.

When replace refs were introduced, there were discussions about
extending replace refs to be able to have different sets of replace
refs used at different times, so that it would be possible to have
different "views" of a repository. For example there could be the
following views:

  - the "default" or "canonical" view where no replace refs are used,
  - the "timestamp fixed" view where some replace refs to fix
timestamp issues are used,
  - the "authorship fixed" view where some replace refs to fix
authorship and committership issues are used,
  - the "build fixed" view where some replace refs are used so that
the build work on all commits (which should help with bisecting),
  - the "old history" view where some old history of the code (that
was not imported when Git started to be used) is linked by some
replace refs,
etc.

> $ git version
> git version 2.47.1
>
> $ GIT_NAMESPACE=foo git replace
> 751eeb3b4d23c7fbde919aedde8c091f04f4f819
> a9dfd084086ee4d6bf00a33b0976f28c0997457e
>
> $ git rev-parse refs/replace/751eeb3b4d23c7fbde919aedde8c091f04f4f819
> a9dfd084086ee4d6bf00a33b0976f28c0997457e
>
> $ git rev-parse
> refs/namespaces/foo/refs/replace/751eeb3b4d23c7fbde919aedde8c091f04f4f819
> refs/namespaces/foo/refs/replace/751eeb3b4d23c7fbde919aedde8c091f04f4f819
> fatal: ambiguous argument
> 'refs/namespaces/foo/refs/replace/751eeb3b4d23c7fbde919aedde8c091f04f4f819':
> unknown revision or path not in the working tree.
>
> $ git log -n 1 --oneline 751eeb3b4d23c7fbde919aedde8c091f04f4f819
> 751eeb3 (replaced) add go.mod
>
> $ GIT_NAMESPACE=foo git log -n 1 --oneline
> 751eeb3b4d23c7fbde919aedde8c091f04f4f819
> 751eeb3 (replaced) add go.mod
>
> Is this a bug in which case I might hope for a fix, or is it working
> as intended?

I don't think anyone mentioned using both namespaces and replace refs
together before, so it's hard to say.

I think namespaces are considered a server side thing to avoid
duplicating objects in the common case where different users have
different forks of the same original repo. And namespaces might not
even be used much on the server side as there is the "alternates"
mechanism that can be used for the same purpose. Also on the server
side, you generally want to disable ref replacement entirely as it's
just simpler, and most often what users want, to use the default view
without any replacement. So it might just happen very rarely that
people want to use both namespaces and replace refs together.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux