All of lore.kernel.org
 help / color / mirror / Atom feed
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/*

  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.