git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC PATCH 1/2] add a --delete option to git push

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 14, 2009, 06:53 UTC
Message-ID
<7vab22ubr5.fsf@alter.siamese.dyndns.org>
In-Reply-To
<1250226349-20397-2-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
>     Currently `git push --delete master:master` results in a somewhat
>     cryptic error message. ...

What does "git push --delete name:destination" say? What does "git push --delete :destination" say?

>     ... It seems unlikely however, that those new
>     to git would use the 'old:new' notation,...

I doubt that assumption is warranted. I've seen new people on this list who want to be as specific as possible before they get familiar with the tool (I guess it is in the same spirit that they like to spell out long option names instead of short ones).

And I happen to think it is a good discipline, when learning a new tool, to understand the underlying generic model before advancing to lazy and useful short-hand. That's how I teach in my upcoming book.

Your "old:new" demonstrates a fuzzy understanding of the underlying concept. They are not <old> nor <new>. They are <object name> and <destination>; with this object, update that destination. And you can abbreviate when they are textually spelled the same. I.e. "git push origin master" is equivalent to "git push origin master:master" because both sides are spelled 'm a s t e r' the same way.

Having said all that.

I tend to agree with Jeff that it would probably make sense to limit this new feature to colonless form and error out if you see a refspec with a colon and --delete at the same time. Also --delete should imply not looking at configured refspecs at all. After all, this is incompatible with the way git expresses push with refspecs, and trying to mix these two would lead to confusion.

I do not mean that this new feature is useless nor stupid. Being able to say "git push --delete branch1 branch2" matches _a_ mental model (perhaps Hg inspired one) _very_ naturally. There are branches on the other side, and there is a special operation called 'delete' that you can inflict on them.

But it is a different mental model of how git natively does "push". In git model, you give list of instructions <which branch to update with what commit>, and as a special case "what commit" could be "empty" to signal deletion, and "push" carries out the instructions.

These are both valid models. They just do not mix, so let's avoid confusion by not allowing both at the same time.

Previous: Jeff KingNext: Jeff King
Message 9 of 18 in “add a --delete option to git push”
  1. 0/2 add a --delete option to git pushSverre Rabbelier, Aug 14, 2009
  2. 1/2 add a --delete option to git pushSverre Rabbelier, Aug 14, 2009
  3. 2/2 test that git push --delete deletes the remote refSverre Rabbelier, Aug 14, 2009
  4. Jeff KingAug 14, 2009
  5. Sverre RabbelierAug 14, 2009
  6. Jeff KingAug 14, 2009
  7. Sverre RabbelierAug 14, 2009
  8. Jeff KingAug 14, 2009
  9. Junio C HamanoAug 14, 2009
  10. Jeff KingAug 14, 2009
  11. Jeff KingAug 14, 2009
  12. Sverre RabbelierAug 14, 2009
  13. Junio C HamanoAug 14, 2009
  14. Junio C HamanoAug 15, 2009
  15. Sverre RabbelierAug 16, 2009
  16. Jakub NarebskiAug 16, 2009
  17. Jakub NarebskiAug 14, 2009
  18. Jakub NarebskiAug 14, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.