git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Should 'git replace' respect GIT_NAMESPACE?

From
Josh Bleecher Snyder <josharian@gmail.com>
Date
Jan 14, 2025, 22:39 UTC
Message-ID
<CAFAcib9cJOp26J=PxU3XwmLT0hQVqCb8vcS7MdGpFd5TNVfDzw@mail.gmail.com>
In-Reply-To
<CAP8UFD206mL+CYxOUKOPWFj7tX1Y79Moc7UjvH4BsLVLbAk-JA@mail.gmail.com>
Show 23 quoted lines
> > 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.

That is indeed roughly what I had in mind: a bunch of different views of the repo.

Show 39 quoted lines
> > $ 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.
Got it. Thanks.
Do you have suggestions for alternative mechanisms I might use?

I want to be able to easily enable/disable a set of replace directives for the purposes of running other git commands, without globally altering the repository. Otherwise I have to worry about locking, cleanup when something goes wrong, and state visibility and management. All possible to fix, but messy compared with something like namespaces.

-josh
Previous: Christian CouderNext: Christian Couder
Message 3 of 4 in “Should 'git replace' respect GIT_NAMESPACE?”
  1. Josh Bleecher SnyderJan 14, 2025
  2. Christian CouderJan 14, 2025
  3. Josh Bleecher SnyderJan 14, 2025
  4. Christian CouderJan 15, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.