From: Eric Wong <e@yhbt.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: `seen' datapoint [
Date: Mon, 29 Jun 2020 02:04:27 +0000 [thread overview]
Message-ID: <20200629020427.GA8153@dcvr> (raw)
In-Reply-To: <xmqqy2o6fyxl.fsf@gitster.c.googlers.com>
Junio C Hamano <gitster@pobox.com> wrote:
> 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.
> > 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
> 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/*
next prev parent reply other threads:[~2020-06-29 2:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-23 0:54 What's cooking in git.git (Jun 2020, #04; Mon, 22) Junio C Hamano
2020-06-23 10:00 ` Jeff King
2020-06-23 12:46 ` Johannes Schindelin
2020-06-23 19:16 ` Junio C Hamano
2020-06-28 19:22 ` `seen' datapoint [was: What's cooking in git.git (Jun 2020, #04; Mon, 22)] Eric Wong
2020-06-29 1:22 ` `seen' datapoint [ Junio C Hamano
2020-06-29 2:04 ` Eric Wong [this message]
2020-06-29 18:45 ` Jeff King
2020-06-29 19:03 ` Eric Wong
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200629020427.GA8153@dcvr \
--to=e@yhbt.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.