Re: [RFC] [PATCH] remote: add new --fetch option for set-url

From: Jeff King <peff@peff.net>
Date: Nov 25, 2014, 04:08 UTC
Message-ID: <20141125040826.GC19301@peff.net>
In-Reply-To: <283403992.8FOSVk7RPR@al>

On Tue, Nov 25, 2014 at 12:27:31AM +0100, Peter Wu wrote:

Show 30 quoted lines

> On Monday 24 November 2014 17:54:57 Jeff King wrote:
> > On Mon, Nov 24, 2014 at 11:47:30PM +0100, Peter Wu wrote:
> > > I can understand that --fetch sounds a bit weird, what about this
> > > natural translation:
> > > 
> > >     "git remote: set the URL (only the fetch one) for NAME to URL"
> > >     git remote set-url --only=fetch NAME URL
> > > 
> > >     "git remote: set the URL (only the push one) for NAME to URL"
> > >     git remote set-url --only=push NAME URL
> > >     (obsoletes --push)
> > > 
> > >     "git remote: set the URL (both) for NAME to URL"
> > >     git remote set-url --only=both NAME URL
> > >     (it would be nice if --only=both (weird!) can be removed in the
> > >     future such that the option is more natural)
> > > 
> > >     "git remote: set the URL for NAME to URL"
> > >     git remote set-url NAME URL
> > >     (current behavior: YOU git guru knows what I do right?)
> > 
> > Yeah, I think that addresses my concern (because it explicitly leaves
> > no-option as a historical curiosity, and not as an implicit version of
> > "--both").
> 
> Ok, I will make a clear note about the default (without --only) behavior
> having weird behavior for historical reasons. Are you really OK with
> --only=both? It sounds a bit odd (mathematically speaking it is correct
> as fetch and push are both partitions that form the whole set if you
> ignore the historical behavior).

Maybe "--operation={push,fetch,both}" would be less odd (though "--operation" is rather clunky, I could not think of a better word). It is the conjunction of "--only" an "both" that makes little sense.

However, I think what removed the confusion for me in your --only=both proposal was the presence of a "both" option, since it made it more clear that is not what no-option means. So what about just "--push", "--fetch", and "--both"? Explain the current behavior of no-options in the documentation as a historical oddity.

That also gives us an easy path forward for changing the behavior. During the transition period, people should use --push, --fetch, or --both. Using no-options provides a warning. After a settling period, the no-option behavior will switch to one of those (presumably --both), and drop the warning.

You do not have to do the migration path if you don't want to. Adding "--fetch" and "--both" scratches your itch and sets us up to migrate later.

> What about the translations? Should I send a separate patch for that or
> can I update all translations at once?

You do not have to update the translations. When we near a release, the l10n coordinator will run "make pot" to update po/git.pot with the strings marked for translation, and then the translators will write translations for the new strings. You are of course welcome to help with the translation effort at that stage. :)

Details are in po/README.

-Peff