Re: `seen' datapoint [
- From
- Eric Wong <e@yhbt.net>
- Date
- Jun 29, 2020, 02:04 UTC
- Message-ID
- <20200629020427.GA8153@dcvr>
- In-Reply-To
- <xmqqy2o6fyxl.fsf@gitster.c.googlers.com>
Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> Eric Wong <e@yhbt.net> writes: > > > So I had receive.denyNonFastforwards=true set, and a > > special cases for `pu': > > > > fetch = +refs/heads/pu:refs/remotes/origin/pu > > Hmph. I thought receive.denyNonFastforwards was for pushing into > the repository, so it is a bit puzzling that you bring up "only > updates to fetch into 'pu' is allowed to be forced" like this. > Such an arrangement would let you know when 'next' got rewound, > which is another plus ;-)
Yeah, I can't recall when I started using denyNonFastforwards; but it was probably a paranoid thing to ensure I'd notice if `master' got rewound.
Show 9 quoted lines
> > Which necessitated s/pu/seen/. So I wonder if there's other > > denyNonFastforwards users out there affected. Anyways, just > > a data point... > > I can sort-of see how the special case would work, but what makes > your setting fetch other branches like 'master', 'todo', and 'next'? > > Do you have a separate "fetch" refspec for each of the ones you are > interested in?
Nope, I use the catch-all as you describe below
Show 6 quoted lines
> Or "remote.origin.fetch = refs/heads/*:refs/remotes/origin/*" which > serves as the default catch-all (which overlaps with the "pu can be > fast forwarded" you showed---I don't recall how we designed such a > set-up to work offhand, so I am a bit curious) works as a natural > "require fast-forward in general, but a more specific rule about > 'pu' allows non-fast-forward updates"?
I only have `+' entries for `next' and `seen', the catch-all provides the rest.
fetch = +refs/heads/seen:refs/remotes/origin/seen fetch = +refs/heads/next:refs/remotes/origin/next fetch = refs/heads/*:refs/remotes/origin/*