Re: git-push branch confusion caused by user mistake

From: Phil Hord <phil.hord@gmail.com>
Date: Mar 13, 2017, 19:49 UTC
Message-ID: <CABURp0onBt8yo2nJhaxkZk+dujOYDD6dZDeo_a4=dMx867OPvg@mail.gmail.com>
In-Reply-To: <CA+P7+xp1T0-02=NznW0=Xd_K5_bdtg=nVgtTqT74+EJuncYxSw@mail.gmail.com>

On Mon, Mar 13, 2017 at 1:55 AM Jacob Keller <jacob.keller@gmail.com> wrote:

Show 15 quoted lines

> On Fri, Mar 10, 2017 at 2:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Phil Hord <phil.hord@gmail.com> writes:
> >> I think git should be smarter about deducing the dest ref from the
> >> source ref if the source ref is in refs/remotes, but I'm not sure how
> >> far to take it.
> >
> > My knee-jerk reaction is "Don't take it anywhere".
> >
> > Giving a refspec from the command line is an established way to
> > defeat the default behaviour when you do not give any and only the
> > remote, and making it do things behind user's back, you would be
> > robbing the escape hatch from people.
>
> It might be worth having some warning or something happen here? I've
> had several  co-workers at $DAYJOB get confused by this sort of thing.

On one very active project at $work, we have 380,000 commits, 4600 branches in refs/heads and 96 branches in refs/remotes. About half of the refs/remotes (43) are obviously user errors. The other half it's not possible for me to know.

I suggested to our admins to block attempts to push to 'refs/remotes/*' so in the future users don't lose track of commits they think they pushed. But I don't know if that will really happen.

Thanks for the counterexample feedback.