From: Sverre Rabbelier Date: Fri, 14 Aug 2009 07:05:05 GMT Subject: Re: [RFC PATCH 1/2] add a --delete option to git push Message-ID: In-Reply-To: <7vab22ubr5.fsf@alter.siamese.dyndns.org> Heya, On Thu, Aug 13, 2009 at 23:53, Junio C Hamano wrote: > 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). Fair enough. > Your "old:new" demonstrates a fuzzy understanding of the underlying > concept.  They are not nor .  They are and > ; with this object, update that destination. Not really, I was responding to Jeff's "you can rename a branch like this", I know that in : the can be anything that locally resolves to an object, and that can be any valid ref on the remote side, but that's quite a mouthful :P. > 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. Agreed, I don't think "git push --delete origin master:master to-be-deleted" is a good idea. > [...] Being able to > say "git push --delete branch1 branch2" matches _a_ mental model (perhaps > Hg inspired one) _very_ naturally.  [...] > > [...] In > git model, you give list of instructions 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. Agreed, would it be enough to ensure that there are refs present (as argument), and that they do not contain a colon? Also, how do I go about making sure the local configuration is ignored, as you mentioned above? -- Cheers, Sverre Rabbelier