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
>                 name components into a single slash.  Iff the normalized
>                 refname is valid then print it to standard output and exit
>                 with a status of 0.  (`--print` is a deprecated way to spell
>                 `--normalize`.)

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 searching for "tracking" (no minus signs) is going to
hit many false positives.  I do not think such a change would be an
improvement.

Meanwhile I believe the prominent words "deprecated synonym" already
make it completely obvious that when I write a new config file, I should
use the modern option, unless I am trying to write a config file that
also works with older versions of git.  In the latter case (which
unfortunately is not too uncommon), hiding the option is not going to
make my life easier.  What would allow me to make an informed choice
is mentioning what version of git *introduced* the new name of the
option:

        - `tracking` - deprecated old name for `upstream`, used by git
          versions before 1.7.4.2.  Don't use this.

Also I do not think anyone claimed we are removing "tracking" from the
documentation in order to stop people from using it.  The rationale
when the patch was proposed is that it makes the documentation easier
to read.  I agree with that rationale, with the caveat Avar mentioned.
There is a simple fix: just simplify the behavior being explained as
well, by biting the bullet and dropping the "tracking" synonym after a
suitable period in which it produces a warning.

In the meantime, the documentation is valuable, and pretending that
"tracking" does not exist for everyone who does not confusedly reread
the docs a few times is just a way to lie to ourselves and make users'
lives more difficult.  Is that really the intent?

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to