delta/git.git/Documentation/git-var.txt, branch pm/build-persistent-https-with-recent-go

Documentation: the name of the system is 'Git', not 'git'

2013-02-01T21:53:33+00:00

Signed-off-by: Thomas Ackermann 
Signed-off-by: Junio C Hamano

ident: report passwd errors with a more friendly message

2012-05-22T16:08:20+00:00

When getpwuid fails, we give a cute but cryptic message.
While it makes sense if you know that getpwuid or identity
functions are being called, this code is triggered behind
the scenes by quite a few git commands these days (e.g.,
receive-pack on a remote server might use it for a reflog;
the current message is hard to distinguish from an
authentication error).  Let's switch to something that gives
a little more context.

While we're at it, we can factor out all of the
cut-and-pastes of the "you don't exist" message into a
wrapper function. Rather than provide xgetpwuid, let's make
it even more specific to just getting the passwd entry for
the current uid. That's the only way we use getpwuid anyway,
and it lets us make an even more specific error message.

The current message also fails to mention errno. While the
usual cause for getpwuid failing is that the user does not
exist, mentioning errno makes it easier to diagnose these
problems.  Note that POSIX specifies that errno remain
untouched if the passwd entry does not exist (but will be
set on actual errors), whereas some systems will return
ENOENT or similar for a missing entry. We handle both cases
in our wrapper.

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

drop length limitations on gecos-derived names and emails

2012-05-22T16:08:20+00:00

When we pull the user's name from the GECOS field of the
passwd file (or generate an email address based on their
username and hostname), we put the result into a
static buffer. While it's extremely unlikely that anybody
ever hit these limits (after all, in such a case their
parents must have hated them), we still had to deal with the
error cases in our code.

Converting these static buffers to strbufs lets us simplify
the code and drop some error messages from the documentation
that have confused some users.

The conversion is mostly mechanical: replace string copies
with strbuf equivalents, and access the strbuf.buf directly.
There are a few exceptions:

  - copy_gecos and copy_email are the big winners in code
    reduction (since they no longer have to manage the
    string length manually)

  - git_ident_config wants to replace old versions of
    the default name (e.g., if we read the config multiple
    times), so it must reset+add to the strbuf instead of
    just adding

Note that there is still one length limitation: the
gethostname interface requires us to provide a static
buffer, so we arbitrarily choose 1024 bytes for the
hostname.

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

var doc: advertise current DEFAULT_PAGER and DEFAULT_EDITOR settings

2012-04-10T21:50:27+00:00

Document the default pager and editor chosen at compile time in the
git-var(1) manpage so users curious about what command _this_ copy of
git will fall back to when EDITOR, VISUAL, and PAGER are unset can
find the answer quickly.

In builds leaving those settings uncustomized, this patch makes the
manpage continue to say "usually vi" and "usually less" so the
formatted documentation is usable for a wide audience including users
of custom builds that change those settings.  If you would like your
copy of the docs to be less noncommittal, you will need to set
DEFAULT_PAGER=less and DEFAULT_EDITOR=vi explicitly.

Suggested-by: Junio C Hamano 
Signed-off-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

var doc: default editor and pager are configurable at build time

2012-03-31T18:14:26+00:00

Some distributors customize the fallback pager and editor used by git
commands when the user has not indicated a preference via the
core.editor/core.pager configuration or GIT_EDITOR, GIT_PAGER, VISUAL,
EDITOR, and PAGER environment variables, and git's build system
provides DEFAULT_PAGER and DEFAULT_EDITOR makefile settings to help
them with that (see v1.6.6-rc0~24, 2009-11-20).

Unfortunately those compile-time settings do not affect the
documentation, so the uninitiated user who tries to understand git by
reading the git-var(1) manpage can easily be confused when git falls
back to 'nano' and 'more' instead of 'vi' and 'less'.  Even if the
distributor patches the distributed docs to reflect the new default,
the user may read the official documentation from the git-htmldocs
repository online and be confused in the same way.

Add a few words stating that the defaults are customizable at
compile time to make the behavior crystal clear.

Reported-by: Rodrigo Silva (MestreLion) 
Signed-off-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

Documentation: use [verse] for SYNOPSIS sections

2011-07-06T21:26:26+00:00

The SYNOPSIS sections of most commands that span several lines already
use [verse] to retain line breaks. Most commands that don't span
several lines seem not to use [verse]. In the HTML output, [verse]
does not only preserve line breaks, but also makes the section
indented, which causes a slight inconsistency between commands that
use [verse] and those that don't. Use [verse] in all SYNOPSIS sections
for consistency.

Also remove the blank lines from git-fetch.txt and git-rebase.txt to
align with the other man pages. In the case of git-rebase.txt, which
already uses [verse], the blank line makes the [verse] not apply to
the last line, so removing the blank line also makes the formatting
within the document more consistent.

While at it, add single quotes to 'git cvsimport' for consistency with
other commands.

Signed-off-by: Martin von Zweigbergk 
Signed-off-by: Junio C Hamano

doc: drop author/documentation sections from most pages

2011-03-11T15:59:16+00:00

The point of these sections is generally to:

  1. Give credit where it is due.

  2. Give the reader an idea of where to ask questions or
     file bug reports.

But they don't do a good job of either case. For (1), they
are out of date and incomplete. A much more accurate answer
can be gotten through shortlog or blame.  For (2), the
correct contact point is generally git@vger, and even if you
wanted to cc the contact point, the out-of-date and
incomplete fields mean you're likely sending to somebody
useless.

So let's drop the fields entirely from all manpages except
git(1) itself. We already point people to the mailing list
for bug reports there, and we can update the Authors section
to give credit to the major contributors and point to
shortlog and blame for more information.

Each page has a "This is part of git" footer, so people can
follow that to the main git manpage.

Fix 'git var' usage synopsis

2010-02-15T02:23:16+00:00

The parameter to 'git var' is not optional.

Signed-off-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

Documentation: format full commands in typewriter font

2010-01-10T12:01:25+00:00

Use `code snippet` style instead of 'emphasis' for `git cmd ...`
according to the following rules:

* The SYNOPSIS sections are left untouched.

* If the intent is that the user type the command exactly as given, it
  is `code`.
  If the user is only loosely referred to a command and/or option, it
  remains 'emphasised'.

Signed-off-by: Thomas Rast

Teach git var about GIT_PAGER

2009-11-13T20:20:47+00:00

Expose the command found by setup_pager() for scripts to use.
Scripts can use this to avoid repeating the logic to look for a
proper pager in each command.

Signed-off-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano