On Mon, Apr 23, 2012 at 10:37 AM, Matthieu Moy matthieu@imag.fr 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
Ævar Arnfjörð Bjarmason ava...@gmail.com writes:
On Mon, Apr 23, 2012 at 10:37 AM, Matthieu Moy matthieu@imag.fr 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
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, like
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 is
Jonathan Nieder jrnie...@gmail.com 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
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 jrnie...@gmail.com 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,
Jonathan Nieder jrnie...@gmail.com 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
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
`tracking`
Jonathan Nieder jrnie...@gmail.com 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.
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
Jonathan Nieder jrnie...@gmail.com 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
From: Jonathan Nieder jrnie...@gmail.com
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
Jonathan Nieder jrnie...@gmail.com 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
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com 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
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 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 branch to
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
Jonathan Nieder jrnie...@gmail.com 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
19 matches
Mail list logo
