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

From: Peter Wu <[email-masked]>
Date: Tue, 25 Nov 2014 12:36:43 +0100

On Monday 24 November 2014 23:08:26 Jeff King wrote:
> 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.

Ok, this sounds even better. I have dropped the --only part and made the
options --push, --fetch and --both disjoint (overriding each other). A
patch will follow soon. Maybe it should warn when you try to specify
both options though.

> 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.

I have documented the historic behavior and mentioned that it is
/possible/ that the option --both becomes default in the future.

> > 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.

Well, it is not necessary the translations, but the format of them. The
format
"git remote set-url --delete <name> <url>" has changed to
"git remote set-url [--both | --fetch | --push] --delete <name> <url>"
for example. The old strings are still usable, so I wonder whether I can
make it easier for the i10n maintainer to recognize this change?
-- 
Kind regards,
Peter
https://lekensteyn.nl