Re: [ITCH] Specify refspec without remote

From: Jeff King <peff@peff.net>
Date: Apr 10, 2013, 22:23 UTC
Message-ID: <20130410222334.GC6930@sigill.intra.peff.net>
In-Reply-To: <CALkWK0=Y-pO3+g21PLCWOxx+M-7fSmp2FedMBtZ68PWU_TOHDw@mail.gmail.com>

On Thu, Apr 11, 2013 at 03:41:33AM +0530, Ramkumar Ramachandra wrote:

Show 6 quoted lines

> Jeff King wrote:
> > It's not that it's not potentially useful. It's that it may be
> > surprising and annoying to users who did not want that.
> 
> Besides, I'm not able to imagine one scenario where this is the wrong
> or annoying thing to do.  Can you provide an example?

To flesh out my earlier example:

  $ git clone https://github.com/upstream/project.git
  $ cd project
  $ hack hack hack; commit commit commit
  $ git tag -m 'something of note' my-tag
  $ git remote add me https://github.com/me/project.git
  $ git config branch.master.remote me
  $ git tag -m 'something of note'
  $ git push master my-tag

My intent there is publish both master and mytag, but my-tag goes to origin. It's obvious if you think carefully about (and know) the rules, and it's user error. But what fault do we take for designing a feature that causes confusion?

Maybe I am the only one who might make that mistake, and it is a non-issue. But I would be much happier if git said "hey, are you sure you wanted to push to two different remotes?". At least by default.

-Peff