Jonathan Nieder writes:
> [...]
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -1795,7 +1795,8 @@ push.default::
>>+
>>This is currently the default, but Git 2.0 will change the default
>>to `simple`.
>> -* `upstream` - push the current branch to its upstrea
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Junio C Hamano wrote:
>>> For those who
>>> want to _learn_ what possibilities are available to them (i.e. they
>>> are not going from `tracking` to what it means, but going in the
>>> opposite
Junio C Hamano wrote:
> How about doing it this way?
[...]
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1795,7 +1795,8 @@ push.default::
>+
>This is currently the default, but Git 2.0 will change the default
>to `simple`.
> -* `upstream` - push the current br
How about doing it this way? I do not think anything that is
deprecated even deserves a separate section and "do not use it!"
heading.
-- >8 --
When looking at a configuration file edited long time ago, a user
may find 'pull.default = tracking' and wonder what it means.
Instead of not mentioning
Junio C Hamano writes:
> Jonathan Nieder writes:
>
>> Am I really the only one that doesn't see the "--print" change as
>> hiding an option and sees burying "tracking" in the text as
>> qualitatively different?
>
> Sorry, but I do not understand the question.
>
> We are hiding/burying the "--pri
Jonathan Nieder writes:
> Am I really the only one that doesn't see the "--print" change as
> hiding an option and sees burying "tracking" in the text as
> qualitatively different?
Sorry, but I do not understand the question.
We are hiding/burying the "--print" option to make it clear that it
i
From: "Jonathan Nieder"
Sent: Thursday, January 31, 2013 8:04 PM
Junio C Hamano wrote:
For those who
want to _learn_ what possibilities are available to them (i.e. they
are not going from `tracking` to what it means, but going in the
opposit
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> For those who
>> want to _learn_ what possibilities are available to them (i.e. they
>> are not going from `tracking` to what it means, but going in the
>> opposite direction), it should be u
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> That works because, as you mention, the usual way to look up an option
>> in manpages is to search for "--print", including the two minus signs.
>>
>> Unfortunately an analagous approach in gitconfig(5) would be seriously
>> broken, because searc
Jonathan Nieder writes:
> How about the following?
>
> * `nothing` - ...
> * `matching` - ...
> * `upstream` - ...
> * `simple` - ...
> * `current` - ...
>
> For compatibility with ancient config files, the following synonym
> is also supported. Don't use it.
>
> * `t
Junio C Hamano wrote:
> For those who
> want to _learn_ what possibilities are available to them (i.e. they
> are not going from `tracking` to what it means, but going in the
> opposite direction), it should be unmistakingly clear that
> `tracki
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> That is why I tend to prefer how check-ref-format documentation
>> describes --print:
>>
>> --normalize::
>> Normalize 'refname' by removing any leading slash (`/`)
>> characters and collapsing runs of ad
Jonathan Nieder writes:
> Jonathan Nieder wrote:
>
>> Is the problem that "deprecated" is not precise enough? For example,
>> would it make sense to say "deprecated synonym for `upstream`. Will
>> be dropped in git 2.1" or something like that?
>
> Also, if we plan to remove support soon, we sho
Junio C Hamano wrote:
> That is why I tend to prefer how check-ref-format documentation
> describes --print:
>
> --normalize::
> Normalize 'refname' by removing any leading slash (`/`)
> characters and collapsing runs of adjacent slashes between
>
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> Wow, that's a blast from the past.
>>
>> I tend to agree that deprecating and removing are quite different,
>> but a simple "revert" of the change would not be good, either. We
>> still would want to _discourage_ its use.
>
> Hm, I was about t
Jonathan Nieder wrote:
> Is the problem that "deprecated" is not precise enough? For example,
> would it make sense to say "deprecated synonym for `upstream`. Will
> be dropped in git 2.1" or something like that?
Also, if we plan to remove support soon, we should start warning when
this setting
Hi,
Junio C Hamano wrote:
> Wow, that's a blast from the past.
>
> I tend to agree that deprecating and removing are quite different,
> but a simple "revert" of the change would not be good, either. We
> still would want to _discourage_ its use.
Hm, I was about to try adding a line in that vein
Ævar Arnfjörð Bjarmason writes:
> On Mon, Apr 23, 2012 at 10:37 AM, Matthieu Moy wrote:
>> It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011,
>> push.default: Rename 'tracking' to 'upstream'), so it's OK to remove it
>> from documentation (even though it's still supported) to ma
On Mon, Apr 23, 2012 at 10:37 AM, Matthieu Moy wrote:
> It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011,
> push.default: Rename 'tracking' to 'upstream'), so it's OK to remove it
> from documentation (even though it's still supported) to make the
> explanations more readable.
I
19 matches
Mail list logo
