Re: Fetch-hooks

On 02/20/2018 08:42 AM, Jeff King wrote:>> [...] >> >> Is there a way for “pre-receive” to individually filter [refs]? I was >> under the impression that the only way to do that was to use the >> “update” hook, which was the reason I wanted to model it after “update” >> rather than “pre-receive”

Re: Fetch-hooks

On Mon, Feb 19, 2018 at 11:50:37PM +0100, Leo Gaspard wrote: > On 02/19/2018 10:23 PM, Jeff King wrote: > > [...] > > If you do go this route, please model it after "pre-receive" rather than > > "update". We had "update" originally but found it was too limiting for > > hooks to see only one ref

Re: Fetch-hooks

On Mon, Feb 19, 2018 at 2:50 PM, Leo Gaspard wrote: > On 02/19/2018 10:23 PM, Jeff King wrote: >> [...] >> If you do go this route, please model it after "pre-receive" rather than >> "update". We had "update" originally but found it was too limiting for >> hooks to see only one

Re: Fetch-hooks

On 02/19/2018 10:23 PM, Jeff King wrote: > [...] > If you do go this route, please model it after "pre-receive" rather than > "update". We had "update" originally but found it was too limiting for > hooks to see only one ref at a time. So we introduced pre-receive. The > "update" hook remains for

Re: Fetch-hooks

On Wed, Feb 14, 2018 at 03:02:00AM +0100, Leo Gaspard wrote: > > So does anybody actually want to be able to adjust the refs as they pass > > through? It really sounds like you just want to be able to reject or not > > reject the fetch. And that rejecting would be the uncommon case, so it's > >

Re: Fetch-hooks

On 02/14/2018 02:35 AM, Jeff King wrote: > On Sat, Feb 10, 2018 at 07:36:47PM +0100, Leo Gaspard wrote: >> [...] > I think there may have been some more concrete proposals after that, but > that's what I was able to dig up quickly. Thanks! Though it looks way above my knowledge of git internals

Re: Fetch-hooks

On Sat, Feb 10, 2018 at 4:21 AM, Jeff King wrote: > On Sat, Feb 10, 2018 at 01:37:20AM +0100, Leo Gaspard wrote: > >> > 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:

Re: Fetch-hooks

On Mon, Feb 12, 2018 at 11:23:27AM -0800, Brandon Williams wrote: > Maybe this isn't helpful but you may be able to implement this by using > a remote-helper. The helper could perform any sort of caching it needed > to prevent re-downloading large amounts of data that is potentially > thrown

Re: Fetch-hooks

On Sat, Feb 10, 2018 at 07:36:47PM +0100, Leo Gaspard wrote: > Hmm... would this also drown the remote..fetch map? Also, I think > this behavior could be emulated with fetch and fetchTagsTo, and it would > look like: > [remote "my-remote"] > fetch =

Re: Fetch-hooks

On 02/12/2018 08:23 PM, Brandon Williams wrote:> Maybe this isn't helpful but you may be able to implement this by using > a remote-helper. The helper could perform any sort of caching it needed > to prevent re-downloading large amounts of data that is potentially > thrown away, while only

Re: Fetch-hooks

On 02/10, Leo Gaspard wrote: > On 02/10/2018 01:21 PM, Jeff King wrote: > > On Sat, Feb 10, 2018 at 01:37:20AM +0100, Leo Gaspard wrote: > > > >>> 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 >

Re: Fetch-hooks

On 02/10/2018 01:21 PM, Jeff King wrote: > On Sat, Feb 10, 2018 at 01:37:20AM +0100, Leo Gaspard wrote: > >>> 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

Re: Fetch-hooks

On 02/10/2018 02:33 AM, Leo Gaspard wrote:> I guess the very early part of the discussion you're speaking of is what > I was assuming after reading > https://marc.info/?l=git=132478296309094=2 > > [...] > > So the reason for a post-fetch in my opinion is the same as for a > pre-push /

Re: Fetch-hooks

On Sat, Feb 10, 2018 at 01:37:20AM +0100, Leo Gaspard wrote: > > 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 =

Re: Fetch-hooks

On 02/10/2018 02:08 AM, Junio C Hamano wrote: > Leo Gaspard writes: > >> On 02/10/2018 01:13 AM, Jeff King wrote: >>> On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote: So the changes that are required are: * Adding a notification-only post-fetch hook > >

Re: Fetch-hooks

Leo Gaspard writes: > On 02/10/2018 01:13 AM, Jeff King wrote: >> On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote: >>> So the changes that are required are: >>> * Adding a notification-only post-fetch hook Maybe I missed a very early part of the discussion, but why

Re: Fetch-hooks

On 02/10/2018 01:13 AM, Jeff King wrote: > On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote: >> 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

Re: Fetch-hooks

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

Re: Fetch-hooks

On 02/09/2018 11:30 PM, Jeff King wrote: > On Fri, Feb 09, 2018 at 11:04:17PM +0100, Ævar Arnfjörð Bjarmason wrote: >> One thing that's not discussed yet, and I know just enough about for it >> to tingle my spidey sense, but not enough to say for sure (CC'd Jeff & >> Brandon who know more) is that

Re: Fetch-hooks

On Fri, Feb 09 2018, Leo Gaspard jotted: > On 02/09/2018 11:04 PM, Ævar Arnfjörð Bjarmason wrote:>>> You could also > have some intermediate step between these two, where e.g. your refspec for "origin" is "+refs/heads/*:refs/remotes/origin-untrusted/*" instead of the default

Re: Fetch-hooks

Jeff King writes: > The negotiation for future fetches uses the existing refs as the > starting point. And if we don't know that we have the objects because > there are no refs pointing at them, they're going to get transferred > again. That's extra load no the server, and extra

Re: Fetch-hooks

On Fri, Feb 09, 2018 at 11:04:17PM +0100, Ævar Arnfjörð Bjarmason wrote: > One thing that's not discussed yet, and I know just enough about for it > to tingle my spidey sense, but not enough to say for sure (CC'd Jeff & > Brandon who know more) is that this feature once shipped might cause >

Re: Fetch-hooks

On 02/09/2018 11:04 PM, Ævar Arnfjörð Bjarmason wrote:>>> You could also have some intermediate step between these two, where >>> e.g. your refspec for "origin" is >>> "+refs/heads/*:refs/remotes/origin-untrusted/*" instead of the default >>> "+refs/heads/*:refs/remotes/origin/*", you fetch all

Re: Fetch-hooks

On Thu, Feb 08 2018, Leo Gaspard jotted: > On 02/08/2018 10:06 PM, Ævar Arnfjörð Bjarmason wrote:>> Hmm, OK, so I > guess I'll try to update the patch when I get some time to >>> delve into git's internals, as my use case (forbidding some fetches) >>> couldn't afaik be covered by a wrapper hook.

Re: Fetch-hooks

Leo Gaspard wrote: > I just wanted to check, you did not put the Signed-off-by line in > patches in https://marc.info/?l=git=132491485901482=2 > > Could you confirm that the patches you sent are “covered under an > appropriate open source license and I have the right under that license > to

Re: Fetch-hooks

On 02/08/2018 06:02 PM, Leo Gaspard wrote: > On 02/08/2018 04:30 PM, Joey Hess wrote: >> [...] > > Hmm, OK, so I guess I'll try to update the patch when I get some time to > delve into git's internals, as my use case (forbidding some fetches) > couldn't afaik be covered by a wrapper hook. Joey,

Re: Fetch-hooks

On 02/08/2018 10:06 PM, Ævar Arnfjörð Bjarmason wrote:>> Hmm, OK, so I guess I'll try to update the patch when I get some time to >> delve into git's internals, as my use case (forbidding some fetches) >> couldn't afaik be covered by a wrapper hook. > > Per my reading of >

Re: Fetch-hooks

On Thu, Feb 08 2018, Leo Gaspard jotted: > On 02/08/2018 04:30 PM, Joey Hess wrote: >> Leo Gaspard wrote: >>> That said, I just came upon [1] (esp. the description [2] and the patch >>> [3]), and wondered: it looks like the patch was abandoned midway in >>> favor of a hook refactoring. Would you

Re: Fetch-hooks

On 02/08/2018 04:30 PM, Joey Hess wrote: > Leo Gaspard wrote: >> That said, I just came upon [1] (esp. the description [2] and the patch >> [3]), and wondered: it looks like the patch was abandoned midway in >> favor of a hook refactoring. Would you happen to know whether the hook >> refactoring

Re: Fetch-hooks

Leo Gaspard wrote: > That said, I just came upon [1] (esp. the description [2] and the patch > [3]), and wondered: it looks like the patch was abandoned midway in > favor of a hook refactoring. Would you happen to know whether the hook > refactoring eventually took place, and/or whether this patch

Re: Fetch-hooks

On 02/07/2018 11:51 PM, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Feb 07 2018, Leo Gaspard jotted: > >> Hello, >> >> tl;dr: Is there currently a way to have fetch hooks, and if not do you >> think it could be a nice feature? >> >> I was in the process of implementing hooks for git that ensure

Re: Fetch-hooks

On Wed, Feb 07 2018, Leo Gaspard jotted: > Hello, > > tl;dr: Is there currently a way to have fetch hooks, and if not do you > think it could be a nice feature? > > I was in the process of implementing hooks for git that ensure the > repository is always cleanly signed by someone allowed to by