Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo

From: Jeff King <peff@peff.net>
Date: Dec 2, 2008, 02:48 UTC
Message-ID: <20081202024837.GB6804@coredump.intra.peff.net>
In-Reply-To: <ee2a733e0812011822r4cef6a44ra68d6e84f9e30a90@mail.gmail.com>

On Mon, Dec 01, 2008 at 09:22:43PM -0500, Leo Razoumov wrote:

> I do not think that having a work-flow different from yours deserves a
> "somewhat insane" label. But let us consider the consequences of

  a) you are responding to a nearly month-old message. Please read the
     rest of the thread where we decide that it is not so insane, and
     that the behavior should be configurable with a default of "warn"
     at least for now.

  b) My comment was not that it is insane simply because it is different
     from mine. It is because it creates a dangerous situation (where
     dangerous implies changes might be silently lost) which requires
     manual intervention to fix, and which the user was given no warning
     whatsoever about. It is a direct response to frequent complaints on
     the list about users getting bit by this.

> (1) Switch target's current branch to something else (prevent a
> conflict) before pushing and then restore it back after the push
> 
> (2) Use git-fetch from the target.

(3) Use git-reset --hard, but set a config variable that says "I know what I'm doing." You don't even have to do it per-repo, you can do it per-user.

(4) Push into a non-current branch and merge from the target.

> Method (2) is even worse, because git-fetch provides no control of
> what branches/tags to fetch, it sucks everything in from all branches.
> "git-push", OTOH, can be instructed to be very selective.

Er, what? git-fetch takes a refspec very similar to the ones used by git-push. The real reason that (2) is not an acceptable solution is that you can't necessarily connect to the source repo (e.g., it is on your workstation with no ssh or git server running).

-Peff