On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote: > > I tend to agree with the direction of thinking you outlined: you're > > generally better off completing the fetch to a local namespace that > > tracks the other side completely, and then manipulating the local refs > > as you see fit (e.g., fetching into refs/quarantine, and then migrating > > "good" refs over to refs/remotes/origin). > > Hmm... so do I understand it correctly when I say the process you're > thinking about works like this? > * User installs hook for my-remote by running [something] > * User runs git fetch > * git fetch fetches remote refs/heads/* to local refs/quarantine/* (so > I guess [something] changes the remote.my-remote.fetch refmap) > * When this is done `git fetch` runs a notification-only post-fetch > hook (that would need to be added) > * The post-fetch hook then performs whatever it wants and updates the > references in refs/remotes/my-remote/* Yeah, that was roughly my thinking. > So the changes that are required are: > * Adding a notification-only post-fetch hook > * For handling tags, there is a need to have a refmap for tags. Maybe > adding a remote.my-remote.fetchTags refmap, that would be used when > running with --tags, and having it default to “refs/tags/*:refs/tags/*” > to keep the current behavior by default? Yeah, tag-following may be a little tricky, because it usually wants to write to refs/tags/. One workaround would be to have your config look like this: [remote "origin"] fetch = +refs/heads/*:refs/quarantine/origin/heads/* fetch = +refs/tags/*:refs/quarantine/origin/tags/* tagOpt = --no-tags That's not exactly the same thing, because it would fetch all tags, not just those that point to the history on the branches. But in most repositories and workflows the distinction doesn't matter. (By the way, the I specifically chose the name "refs/quarantine" instead of anything in "refs/remotes" because we'd want to make sure that the "git checkout" DWIM behavior cannot accidentally pull from quarantine). > The only remaining issue I can think of is: How do we avoid the issue > of the > trigger-only-hook-inciting-bad-behavior-by-hook-authors-who-really-want-modification > raised in the side-thread that Junio wrote in [1]? Maybe just writing > in the documentation that the hook should use a quarantine-like > approach if it wants modification would be enough to not have hook > authors try to modify the ref in the post-fetch hook? I don't have a silver bullet there. Documenting the "right" way at least seems like a good first step. -Peff
