From: David Turner <firstname.lastname@example.org> To: Kaushik Srenevasan <email@example.com>, firstname.lastname@example.org Subject: Re: [RFC] Extending git-replace Date: Tue, 14 Jan 2020 13:19:50 -0500 Message-ID: <email@example.com> (raw) In-Reply-To: <CAN_uzpK1m42J19Xi8oc3Dwmhk9qF1n4hFrBVqD+0RHZuZ_15Jw@mail.gmail.com> On Mon, 2020-01-13 at 21:33 -0800, Kaushik Srenevasan wrote: > A feature that allowed such permanent replacement (say a > `git-blacklist` or a `git-replace --blacklist`) might work as > follows: > 1. Blacklisted objects are stored as references under a new namespace > -- `refs/blacklist`. > 2. The object loader unconditionally translates a blacklisted OID > into > the OID it’s been replaced with. > 3. The `+refs/blacklist/*:refs/blacklist/*` refspec is implicitly > always a part of fetch and push transactions. There are definitely some security implications here. I assume that there's a config on the client to trust the server's refs/blacklist/*, and that the documentation for this explains that it allows your repo to be messed with in quite dangerous ways. And on the server, I would expect that only privileged users could push to refs/blacklist/* To Elijah's point that this is related to partial clones and promisors, I think Kaushik's idea is subtly different in that it involves replacements, while promisors try to offer a seamless experience. I wonder whether Kaushik actually needs the replacement functionality? That is, would it be sufficient if every replaced file were replaced with the exact text "me caga en la leche" instead of a custom hand- crafted replacement? I guess it's a bit complicated because while that's a reasonable blob, it's not a valid commit. So maybe this mechanism would be limited to blobs. I thought about whether we could a different flavor of replacement for commits, but those generally have to be custom because they each have different parents. And if that would be sufficient, could promisors be used for this? I don't know how those interact with fsck and the other commands that you're worried about. Basically, the idea would be to use most of the existing promisor code, and then have a mode where instead of visiting the promisor, we just always return "me caga en la leche" (and this does not have its SHA checked, of course). This could work together with some sort refs/blacklist mechanism to enable the server to choose which objects the client replaces.
next prev parent reply index Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-14 5:33 Kaushik Srenevasan 2020-01-14 6:55 ` Elijah Newren 2020-01-14 19:11 ` Jonathan Tan 2020-01-16 3:30 ` Kaushik Srenevasan 2020-01-14 18:19 ` David Turner [this message] 2020-01-14 19:03 ` Jonathan Tan 2020-01-14 20:39 ` Elijah Newren 2020-01-14 21:57 ` Jonathan Tan 2020-01-14 22:46 ` Elijah Newren
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
firstname.lastname@example.org list mirror (unofficial, one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Example config snippet for mirrors Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.io/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/public-inbox.git