threads / patch / 52175

v3, 4 partsDocumentation for common user misconceptions

Subject: [PATCH v3 0/4] Documentation for common user misconceptions

## tl;dr

25 messages between Nov 2, 2019 and Jan 16, 2020. Diffs are folded; open one to read it.

replies: 24people: 6as markdown or json

brian m. carlson· Nov 2, 2019, 19:26 UTC · lore

This series includes four patches that update the documentation to address common user misconceptions.

Changes from v2:
* Move author and committer information to git-commit(1) where people
  will look for it.
* Move guidance on user.name format to git-commit(1) as well and mention
  a shortened form of the advice in the `user.name` description.
* Use a parenthetical to describe a "personal name" without contrasting
  it with a username.
* Offer a potential solution for people who want to ignore tracked
  files by recommending a templating mechanism.
* Be slightly more verbose about why memory is wasted with
  http.postBuffer.
Changes from v1:
* Remove parenthetical which was confusing.
* Add two more patches.
brian m. carlson (4):
  doc: move author and committer information to git-commit(1)
  doc: provide guidance on user.name format
  doc: dissuade users from trying to ignore tracked files
  docs: mention when increasing http.postBuffer is valuable
 Documentation/config/http.txt      |  8 ++++++
 Documentation/config/user.txt      |  7 +++++-
 Documentation/git-commit-tree.txt  | 39 ++++-------------------------
 Documentation/git-commit.txt       | 40 +++++++++++++++++++++++++++---
 Documentation/git-update-index.txt | 16 ++++++++++++
 5 files changed, 72 insertions(+), 38 deletions(-)
Range-diff against v2:
1:  603a9f8f9a < -:  ---------- doc: provide guidance on user.name format
-:  ---------- > 1:  b39b365f54 doc: move author and committer information to git-commit(1)
-:  ---------- > 2:  b7d805427c doc: provide guidance on user.name format
2:  0da41623a5 ! 3:  7644af0b07 doc: dissuade users from trying to ignore tracked files
    @@ Commit message
         pitfalls in the documentation for git update-index so that users know
         they should explore alternate solutions.
     
    +    In additon, let's provide a recommended solution to dealing with the
    +    common case of configuration files, since there are well-known
    +    approaches used successfully in many environments.
    +
         Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
     
      ## Documentation/git-update-index.txt ##
    @@ Documentation/git-update-index.txt: The untracked cache extension can be enabled
     +the index when performing certain operations.  In general, Git does not
     +provide a way to ignore changes to tracked files, so alternate solutions
     +are recommended.
    ++
    ++If the file you want to change is some sort of configuration file (say,
    ++for a build tool, IDE, or editor), a common solution is to use a
    ++templating mechanism, such as Ruby's ERB, to generate the ignored
    ++configuration file from a template stored in the repository and a source
    ++of data using a script or build step.
     +
      SEE ALSO
      --------
3:  89fe11b951 ! 4:  d096763e7a docs: mention when increasing http.postBuffer is valuable
    @@ Documentation/config/http.txt: http.postBuffer::
     +server or a proxy only supports HTTP/1.0 or is noncompliant with the
     +HTTP standard.  Raising this is not, in general, an effective solution
     +for most push problems, but can increase memory consumption
    -+significantly.
    ++significantly since the entire buffer is allocated for even small
    ++pushes.
      
      http.lowSpeedLimit, http.lowSpeedTime::
      	If the HTTP transfer speed is less than 'http.lowSpeedLimit'
brian m. carlson· Nov 2, 2019, 19:26 UTC · re: brian m. carlson · lore

[PATCH v3 2/4] doc: provide guidance on user.name format

It's a frequent misconception that the user.name variable controls authentication in some way, and as a result, beginning users frequently attempt to change it when they're having authentication troubles. Document that the convention is that this variable represents some form of a human's personal name, although that is not required. In addition, address concerns about whether Unicode is supported.

Use the term "personal name" as this is likely to draw the intended contrast, be applicable across cultures which may have different naming conventions, and be easily understandable to people who do not speak English as their first language. Indicate that "some form" is conventionally used, as people may use a nickname or preferred name instead of a full legal name.

Point users who may be confused about authentication to an appropriate configuration option instead. Provide a shortened form of this information in the configuration option description.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 Documentation/config/user.txt | 7 ++++++-
 Documentation/git-commit.txt  | 6 ++++++
 2 files changed, 12 insertions(+), 1 deletion(-)
Show changes to 2 files +12 −1

Documentation/config/user.txt, Documentation/git-commit.txt

diff --git a/Documentation/config/user.txt b/Documentation/config/user.txt
index a1f80e823c..f0edb06329 100644
--- a/Documentation/config/user.txt
+++ b/Documentation/config/user.txt
@@ -13,7 +13,12 @@ committer.email::
 	Also, all of these can be overridden by the `GIT_AUTHOR_NAME`,
 	`GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_NAME`,
 	`GIT_COMMITTER_EMAIL` and `EMAIL` environment variables.
-	See linkgit:git-commit[1] for more information.
++
+Note that the `name` forms of these variables conventionally refer to
+some form of a personal name.
+See linkgit:git-commit[1] for more information on these settings and
+the `credential.username` option if you're looking for authentication
+credentials instead.
 
 user.useConfigOnly::
 	Instruct Git to avoid trying to guess defaults for `user.email`
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index f684f7fdc2..3a69d82d52 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -467,6 +467,12 @@ if set:
 
 (nb "<", ">" and "\n"s are stripped)
 
+The author and committer names are by convention some form of a personal name
+(that is, the name by which other humans refer to you), although Git does not
+enforce or require any particular form. Arbitrary Unicode may be used, subject
+to the constraints listed above. This name has no effect on authentication; for
+that, see the `credential.username` variable in linkgit::git-config[1].
+
 In case (some of) these environment variables are not set, the information
 is taken from the configuration items user.name and user.email, or, if not
 present, the environment variable EMAIL, or, if that is not set,
Jakub Narebski· Nov 3, 2019, 13:13 UTC · re: brian m. carlson · lore

Re: [PATCH v3 2/4] doc: provide guidance on user.name format

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 13 quoted lines
> It's a frequent misconception that the user.name variable controls
> authentication in some way, and as a result, beginning users frequently
> attempt to change it when they're having authentication troubles.
> Document that the convention is that this variable represents some form
> of a human's personal name, although that is not required.  In addition,
> address concerns about whether Unicode is supported.
>
> Use the term "personal name" as this is likely to draw the intended
> contrast, be applicable across cultures which may have different naming
> conventions, and be easily understandable to people who do not speak
> English as their first language.  Indicate that "some form" is
> conventionally used, as people may use a nickname or preferred name
> instead of a full legal name.

This reminds me of "Personal names around the world" by W3C https://www.w3.org/International/questions/qa-personal-names

Show 6 quoted lines
>
> Point users who may be confused about authentication to an appropriate
> configuration option instead.  Provide a shortened form of this
> information in the configuration option description.
>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
I like this change!  Un-confusing users is always a win.
Show 20 quoted lines
> ---
>  Documentation/config/user.txt | 7 ++++++-
>  Documentation/git-commit.txt  | 6 ++++++
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/config/user.txt b/Documentation/config/user.txt
> index a1f80e823c..f0edb06329 100644
> --- a/Documentation/config/user.txt
> +++ b/Documentation/config/user.txt
> @@ -13,7 +13,12 @@ committer.email::
>  	Also, all of these can be overridden by the `GIT_AUTHOR_NAME`,
>  	`GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_NAME`,
>  	`GIT_COMMITTER_EMAIL` and `EMAIL` environment variables.
> -	See linkgit:git-commit[1] for more information.
> ++
> +Note that the `name` forms of these variables conventionally refer to
> +some form of a personal name.
> +See linkgit:git-commit[1] for more information on these settings and
> +the `credential.username` option if you're looking for authentication
> +credentials instead.

Minor nit: should this be one paragraph or two - the linebreak after "of a personal name." looks a bit strange?

No need for a change: just idly wondering.
Show 16 quoted lines
>  
>  user.useConfigOnly::
>  	Instruct Git to avoid trying to guess defaults for `user.email`
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index f684f7fdc2..3a69d82d52 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -467,6 +467,12 @@ if set:
>  
>  (nb "<", ">" and "\n"s are stripped)
>  
> +The author and committer names are by convention some form of a personal name
> +(that is, the name by which other humans refer to you), although Git does not
> +enforce or require any particular form. Arbitrary Unicode may be used, subject
> +to the constraints listed above. This name has no effect on authentication; for
> +that, see the `credential.username` variable in linkgit::git-config[1].

Just ensuring that I understand it correctly: by "constraints" you mean stripping of "<", ">" and "\n" (and by implication "\0")?

Should we say anything about encoding?
> +
>  In case (some of) these environment variables are not set, the information
>  is taken from the configuration items user.name and user.email, or, if not
>  present, the environment variable EMAIL, or, if that is not set,
Best,
-- 
Jakub Narębski
brian m. carlson· Nov 3, 2019, 19:23 UTC · re: Jakub Narebski · lore

Re: [PATCH v3 2/4] doc: provide guidance on user.name format

On 2019-11-03 at 13:13:57, Jakub Narebski wrote:
> This reminds me of "Personal names around the world" by W3C
> https://www.w3.org/International/questions/qa-personal-names

I hadn't read that document before, but it's definitely the approach I was going for. People all over the world use Git, and we should make it as usable for all of those people as we can.

> Minor nit: should this be one paragraph or two - the linebreak after "of
> a personal name." looks a bit strange?
> 
> No need for a change: just idly wondering.

Good question. I had explained this in my original patch but had to reformat the patch and forgot to include this.

The existing text uses a line break after each sentence, and in AsciiDoc that doesn't introduce a new paragraph; only a blank line does that. I opted to keep this consistent with the rest of the description of this item.

> Just ensuring that I understand it correctly: by "constraints" you mean
> stripping of "<", ">" and "\n" (and by implication "\0")?
Yes, that's correct.
> Should we say anything about encoding?

I don't think it's necessary; since we told people that arbitrary Unicode is permitted, hopefully they will determine that they should use UTF-8, or, for Windows environment variables, UTF-16. Unfortunately, there's not a good way to get UTF-8 environment variables in Windows, so "Unicode" is the best we can do there.

I'm happy to gloss over the fact that they can use something else because (a) while they can, they should not and (b) if they do, they'll know that they're obviously restricted to that subset of Unicode.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
brian m. carlson· Nov 2, 2019, 19:26 UTC · re: brian m. carlson · lore

[PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files

It is quite common for users to want to ignore the changes to a file that Git tracks. Common scenarios for this case are IDE settings and configuration files, which should generally not be tracked and possibly generated from tracked files using a templating mechanism.

However, users learn about the assume-unchanged and skip-worktree bits and try to use them to do this anyway. This is problematic, because when these bits are set, many operations behave as the user expects, but they usually do not help when git checkout needs to replace a file.

There is no sensible behavior in this case, because sometimes the data is precious, such as certain configuration files, and sometimes it is irrelevant data that the user would be happy to discard.

Since this is not a supported configuration and users are prone to misuse the existing features for unintended purposes, causing general sadness and confusion, let's document the existing behavior and the pitfalls in the documentation for git update-index so that users know they should explore alternate solutions.

In additon, let's provide a recommended solution to dealing with the common case of configuration files, since there are well-known approaches used successfully in many environments.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 Documentation/git-update-index.txt | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
Show changes to Documentation/git-update-index.txt +16 −0
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 1c4d146a41..11230376c8 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -543,6 +543,22 @@ The untracked cache extension can be enabled by the
 `core.untrackedCache` configuration variable (see
 linkgit:git-config[1]).
 
+NOTES
+-----
+
+Users often try to use the ``assume unchanged'' and skip-worktree bits
+to tell Git to ignore changes to files that are tracked.  This does not
+work as expected, since Git may still check working tree files against
+the index when performing certain operations.  In general, Git does not
+provide a way to ignore changes to tracked files, so alternate solutions
+are recommended.
+
+If the file you want to change is some sort of configuration file (say,
+for a build tool, IDE, or editor), a common solution is to use a
+templating mechanism, such as Ruby's ERB, to generate the ignored
+configuration file from a template stored in the repository and a source
+of data using a script or build step.
+
 SEE ALSO
 --------
 linkgit:git-config[1],
rsbecker@nexbridge.com· Nov 2, 2019, 20:14 UTC · re: brian m. carlson · lore

RE: [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files

On November 2, 2019 3:26 PM, brian m. carlson wrote:
> It is quite common for users to want to ignore the changes to a file that
Git
Show 11 quoted lines
> tracks.  Common scenarios for this case are IDE settings and configuration
> files, which should generally not be tracked and possibly generated from
> tracked files using a templating mechanism.
> 
> However, users learn about the assume-unchanged and skip-worktree bits
> and try to use them to do this anyway.  This is problematic, because when
> these bits are set, many operations behave as the user expects, but they
> usually do not help when git checkout needs to replace a file.
> 
> There is no sensible behavior in this case, because sometimes the data is
> precious, such as certain configuration files, and sometimes it is
irrelevant
> data that the user would be happy to discard.
> 
> Since this is not a supported configuration and users are prone to misuse
the
Show 8 quoted lines
> existing features for unintended purposes, causing general sadness and
> confusion, let's document the existing behavior and the pitfalls in the
> documentation for git update-index so that users know they should explore
> alternate solutions.
> 
> In additon, let's provide a recommended solution to dealing with the
> common case of configuration files, since there are well-known approaches
> used successfully in many environments.

Just noodling about a potential solution. If we assume the use case that files are modified by an IDE that have no real relevance, but should not interfere with other git operations including checkout...

What if we introduce something like .gitignore.changes, with the same syntax as .gitignore. The difference is files listed in this file will not show in git status (or could show as "changes ignored" with an option to enable that. The only way to have the changes considered would be git add -f, so git add . and git commit -a would not pick up the changes. From checkout's perspective, the file would be considered unmodified so if a change is incoming for that path, checkout replaces it instead of rejecting the checkout, otherwise the file is untouched. Pull would act similarly. Branch switching would be permitted without stashing the files - they would remain unchanged unless the switch modified the files.

OTOH, this is a change that is most relevant to IDE users, so JGit would have to implement it as well to really get any real benefit.

This does have some benefit in post-install situations as well as the IDE use-case, but for that I might want to consider finer granularity, like some way to identify regions of files being ignored. This being a pretty deep rabbit hole we'd end up following.

If this idea seems reasonable, it might make a nice small project for someone, possibly me, if I could unentangle from my current hellish $DAYJOB project.

Just my few coins of thought.
Randall
Jakub Narebski· Nov 3, 2019, 15:46 UTC · re: rsbecker@nexbridge.com · lore

Re: [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files

<rsbecker@nexbridge.com> writes:
Show 10 quoted lines
> On November 2, 2019 3:26 PM, brian m. carlson wrote:
>> It is quite common for users to want to ignore the changes to a file that Git
>> tracks.  Common scenarios for this case are IDE settings and configuration
>> files, which should generally not be tracked and possibly generated from
>> tracked files using a templating mechanism.
>> 
>> However, users learn about the assume-unchanged and skip-worktree bits
>> and try to use them to do this anyway.  This is problematic, because when
>> these bits are set, many operations behave as the user expects, but they
>> usually do not help when git checkout needs to replace a file.
[...]
Show 9 quoted lines
> Just noodling about a potential solution. If we assume the use case that
> files are modified by an IDE that have no real relevance, but should not
> interfere with other git operations including checkout...
>
> What if we introduce something like .gitignore.changes, with the same syntax
> as .gitignore. The difference is files listed in this file will not show in
> `git status` (or could show as "changes ignored" with an option to enable
> that. The only way to have the changes considered would be `git add -f`, so
> `git add .` and `git commit -a` would not pick up the changes.
[...]

I think it would be better and easier to add new attribute and use .gitattributes instead of a new .gitignore.changes (and its per-repository, per-user and system-wide version).

> If this idea seems reasonable, it might make a nice small project for
> someone, possibly me, if I could unentangle from my current hellish $DAYJOB
> project.
I wish you luck.

The fact that it was nod done yet may mean that there are some annoying corner-cases in the concept, or that it is not commonly useful... or maybe that is the problem that needs reframing.

Best,
-- 
Jakub Narębski
Jakub Narebski· Nov 3, 2019, 15:04 UTC · re: brian m. carlson · lore

Re: [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 23 quoted lines
> It is quite common for users to want to ignore the changes to a file
> that Git tracks.  Common scenarios for this case are IDE settings and
> configuration files, which should generally not be tracked and possibly
> generated from tracked files using a templating mechanism.
>
> However, users learn about the assume-unchanged and skip-worktree bits
> and try to use them to do this anyway.  This is problematic, because
> when these bits are set, many operations behave as the user expects, but
> they usually do not help when git checkout needs to replace a file.
>
> There is no sensible behavior in this case, because sometimes the data
> is precious, such as certain configuration files, and sometimes it is
> irrelevant data that the user would be happy to discard.
>
> Since this is not a supported configuration and users are prone to
> misuse the existing features for unintended purposes, causing general
> sadness and confusion, let's document the existing behavior and the
> pitfalls in the documentation for git update-index so that users know
> they should explore alternate solutions.
>
> In additon, let's provide a recommended solution to dealing with the
> common case of configuration files, since there are well-known
> approaches used successfully in many environments.
All right, looks sensible and good thing to have.
Show 17 quoted lines
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
>  Documentation/git-update-index.txt | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
> index 1c4d146a41..11230376c8 100644
> --- a/Documentation/git-update-index.txt
> +++ b/Documentation/git-update-index.txt
> @@ -543,6 +543,22 @@ The untracked cache extension can be enabled by the
>  `core.untrackedCache` configuration variable (see
>  linkgit:git-config[1]).
>  
> +NOTES
> +-----
> +
> +Users often try to use the ``assume unchanged'' and skip-worktree bits

Why the change between formatting '``assume unchanged''' (with double quotes and space separated) and 'skip-worktree' (without quotes, and kebab-cased)? In the commit message you write about assume-unchanged and skip-worktree.

I guess that follows the inconsistency in git-update-index(1) headers, namely we have

  USING ``ASSUME UNCHANGED'' BIT
  ------------------------------
but
  SKIP-WORKTREE BIT
  -----------------

This incconsistency is much more viible when both names are on the same line, however.

This is a minor nit.
Show 5 quoted lines
> +to tell Git to ignore changes to files that are tracked.  This does not
> +work as expected, since Git may still check working tree files against
> +the index when performing certain operations.  In general, Git does not
> +provide a way to ignore changes to tracked files, so alternate solutions
> +are recommended.

I'm not sure if it is a place for it, but the proposed text treats assume-unchanged and skip-worktree as similarly unsuited for intended purpose. However, their failure modes are different: (ab)using the assume-unchanged for "ignore changed to tracked files" may lead to data loss (as changes are overwritten), while with skip-worktree the trouble is that some operations that should succeed (like unstashing) are unnecessarily blocked - but no data loss.

Show 6 quoted lines
> +
> +If the file you want to change is some sort of configuration file (say,
> +for a build tool, IDE, or editor), a common solution is to use a
> +templating mechanism, such as Ruby's ERB, to generate the ignored
> +configuration file from a template stored in the repository and a source
> +of data using a script or build step.

I would really like to see a simple example of such template, so that even people who are unfamiliar with Ruby's ERB can think of equivalent solution for their language or toolchain of choice.

> +
>  SEE ALSO
>  --------
>  linkgit:git-config[1],
Best,
-- 
Jakub Narębski
brian m. carlson· Nov 3, 2019, 18:59 UTC · re: Jakub Narebski · lore

Re: [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files

On 2019-11-03 at 15:04:44, Jakub Narebski wrote:
Show 18 quoted lines
> Why the change between formatting '``assume unchanged''' (with double
> quotes and space separated) and 'skip-worktree' (without quotes, and
> kebab-cased)?  In the commit message you write about assume-unchanged
> and skip-worktree.
> 
> I guess that follows the inconsistency in git-update-index(1) headers,
> namely we have
> 
>   USING ``ASSUME UNCHANGED'' BIT
>   ------------------------------
> 
> but
> 
>   SKIP-WORKTREE BIT
>   -----------------
> 
> This incconsistency is much more viible when both names are on the same
> line, however.

Yeah, I can change them to make them consistent. I did preserve the existing formatting for both, as you mentioned.

Show 7 quoted lines
> I'm not sure if it is a place for it, but the proposed text treats
> assume-unchanged and skip-worktree as similarly unsuited for intended
> purpose.  However, their failure modes are different: (ab)using the
> assume-unchanged for "ignore changed to tracked files" may lead to data
> loss (as changes are overwritten), while with skip-worktree the trouble
> is that some operations that should succeed (like unstashing) are
> unnecessarily blocked - but no data loss.

I agree the failure modes can be different, but from my experience there are people who have seen checkout failures with both bits set independently. I'm not exactly sure what those cases are, but folks do see them on Stack Overflow quite frequently.

Even if there is a difference in failure modes, I'd rather encourage people to just not use this mechanism rather than explain why or in which cases it won't do what you want.

> I would really like to see a simple example of such template, so that
> even people who are unfamiliar with Ruby's ERB can think of equivalent
> solution for their language or toolchain of choice.

I hesitated to mention ERB, but I wasn't sure that folks would know what we meant by a "templating mechanism". The reason I had chosen to mention it is that someone could search for "Ruby ERB" and find out what it looked like and then look for an option in their own language.

My concern with adding such a template is that an example will likely grow this section quite a bit, and it's meant as a short aside to help people avoid making a common mistake and guide them to a proper solution rather than a comprehensive howto. I'm planning on adding a FAQ document in the future that covers a lot of these issues in more detail and helps folks figure out solutions to common problems, and I'd prefer to explain this more in depth there.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Jakub Narebski· Nov 3, 2019, 19:40 UTC · re: brian m. carlson · lore

Re: [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2019-11-03 at 15:04:44, Jakub Narebski wrote:
Show 21 quoted lines
>> Why the change between formatting '``assume unchanged''' (with double
>> quotes and space separated) and 'skip-worktree' (without quotes, and
>> kebab-cased)?  In the commit message you write about assume-unchanged
>> and skip-worktree.
>> 
>> I guess that follows the inconsistency in git-update-index(1) headers,
>> namely we have
>> 
>>   USING ``ASSUME UNCHANGED'' BIT
>>   ------------------------------
>> 
>> but
>> 
>>   SKIP-WORKTREE BIT
>>   -----------------
>> 
>> This inconsistency is much more visible when both names are on the same
>> line, however.
>
> Yeah, I can change them to make them consistent.  I did preserve the
> existing formatting for both, as you mentioned.
Thanks in advance.  This inconsistence just looks strange in one line.
Show 16 quoted lines
>> I'm not sure if it is a place for it, but the proposed text treats
>> assume-unchanged and skip-worktree as similarly unsuited for intended
>> purpose.  However, their failure modes are different: (ab)using the
>> assume-unchanged for "ignore changed to tracked files" may lead to data
>> loss (as changes are overwritten), while with skip-worktree the trouble
>> is that some operations that should succeed (like unstashing) are
>> unnecessarily blocked - but no data loss.
>
> I agree the failure modes can be different, but from my experience there
> are people who have seen checkout failures with both bits set
> independently.  I'm not exactly sure what those cases are, but folks do
> see them on Stack Overflow quite frequently.
>
> Even if there is a difference in failure modes, I'd rather encourage
> people to just not use this mechanism rather than explain why or in
> which cases it won't do what you want.

What I wanted to say here is that if you really, really need to abuse those mechanism for "ignore tracked files changes", it is better to use skip-worktree bit -- at least you wouldn't loose your data (your precious changes).

Nb. I have experimented with both assume-unchanged and skip-worktree, so I know their annoyances, but I have not had a need to use them.

Show 8 quoted lines
>> I would really like to see a simple example of such template, so that
>> even people who are unfamiliar with Ruby's ERB can think of equivalent
>> solution for their language or toolchain of choice.
>
> I hesitated to mention ERB, but I wasn't sure that folks would know what
> we meant by a "templating mechanism".  The reason I had chosen to
> mention it is that someone could search for "Ruby ERB" and find out what
> it looked like and then look for an option in their own language.

I would like to see not an example of template, but example how such template can be used in place of "ignore tracked files change".

Show 7 quoted lines
> My concern with adding such a template is that an example will likely
> grow this section quite a bit, and it's meant as a short aside to help
> people avoid making a common mistake and guide them to a proper solution
> rather than a comprehensive howto.  I'm planning on adding a FAQ
> document in the future that covers a lot of these issues in more detail
> and helps folks figure out solutions to common problems, and I'd prefer
> to explain this more in depth there.
Your proposed change:
  +If the file you want to change is some sort of configuration file (say,
  +for a build tool, IDE, or editor), a common solution is to use a
  +templating mechanism, such as Ruby's ERB, to generate the ignored
  +configuration file from a template stored in the repository and a source
  +of data using a script or build step.

I don't see how such templating mechanism could be used. You have some kind of configuration file with placeholders comitted, and you have a version of this file with local changes -- how templating mechanism could solve this? I would like to see few lines of an example and its use.

Alterantives: ~~~~~~~~~~~~~

In our build system, we have versioned Makefile, and not versioned config.mak (with local configuration), which is included by Makefile.

In many cases using environment variables to provide local changes is recommended, something like e.g.

  AWS::S3::Base.establish_connection!(
    :access_key_id     => ENV['S3_KEY'],
    :secret_access_key => ENV['S3_SECRET']
  )
Best,
-- 
Jakub Narębski
brian m. carlson· Nov 3, 2019, 21:46 UTC · re: Jakub Narebski · lore

Re: [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files

On 2019-11-03 at 19:40:36, Jakub Narebski wrote:
Show 19 quoted lines
> Your proposed change:
> 
>   +If the file you want to change is some sort of configuration file (say,
>   +for a build tool, IDE, or editor), a common solution is to use a
>   +templating mechanism, such as Ruby's ERB, to generate the ignored
>   +configuration file from a template stored in the repository and a source
>   +of data using a script or build step.
> 
> I don't see how such templating mechanism could be used.  You have some
> kind of configuration file with placeholders comitted, and you have a
> version of this file with local changes -- how templating mechanism
> could solve this?  I would like to see few lines of an example and its
> use.
> 
> Alterantives:
> ~~~~~~~~~~~~~
> 
> In our build system, we have versioned Makefile, and not versioned
> config.mak (with local configuration), which is included by Makefile.

Essentially, make and shell support this by themselves, but if, for example, I wanted to adjust my dotfiles to set the email address once and for all, I could create the following files:

.muttrc.erb: ---- my_hdr From: brian m. carlson <<%= data["email"] -%>> ----

.gitconfig.erb: ---- [user] name = brian m. carlson email = <%= data["email"] -%> ----

template.rb: ---- #!/usr/bin/env ruby

require 'erb'
class Template
  def name
    @name ||= 0
    @name += 1
    "name_a#{@name}"
  end
  def data
    ENV.map { |k, v| [k.downcase, v] }.to_h
  end
  def erb(file)
    ERB.new(File.read(file), nil, '-', name).result(binding)
  end
end

puts Template.new.erb(ARGV[0]) ----

and then run:

EMAIL=sandals@crustytoothpaste.net template.rb .muttrc.erb >.muttrc EMAIL=sandals@crustytoothpaste.net template.rb .gitconfig.erb >.gitconfig

The problem that folks tend to have is that they have a single editor or IDE project file, such as an XCode configuration file, that can't be split among multiple files, some of which are checked in and some of which are not. Other situations are generating a configuration file for a web server like nginx in development, which may of course differ depending on where the user has checked out the repository.

Using some sort of file like a config.mak is a fine solution, but many programs don't support that, so it's necessary to create a template for the build process and add a script to generate it. The actual configuration values can come from the environment, the user's gitconfig, a YAML file the user has configured, or anywhere else that makes sense.

As you can see, the example is large and unwieldy, and would not make a good inclusion in the man page. I included that paragraph because Peff stated that it would be nice if we could offer people a solution, but I'd rather drop it if it's too confusing without an example.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Jakub Narebski· Nov 5, 2019, 00:21 UTC · re: brian m. carlson · lore

Re: [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 37 quoted lines
> On 2019-11-03 at 19:40:36, Jakub Narebski wrote:
>>
>> Your proposed change:
>> 
>>   +If the file you want to change is some sort of configuration file (say,
>>   +for a build tool, IDE, or editor), a common solution is to use a
>>   +templating mechanism, such as Ruby's ERB, to generate the ignored
>>   +configuration file from a template stored in the repository and a source
>>   +of data using a script or build step.
>> 
>> I don't see how such templating mechanism could be used.  You have some
>> kind of configuration file with placeholders comitted, and you have a
>> version of this file with local changes -- how templating mechanism
>> could solve this?  I would like to see few lines of an example and its
>> use.
>> 
>> Alternatives:
>> ~~~~~~~~~~~~~
>> 
>> In our build system, we have versioned Makefile, and not versioned
>> config.mak (with local configuration), which is included by Makefile.
>
> Essentially, make and shell support this by themselves, but if, for
> example, I wanted to adjust my dotfiles to set the email address once
> and for all, I could create the following files:
>
> .muttrc.erb:
> ----
> my_hdr From: brian m. carlson <<%= data["email"] -%>>
> ----
>
> .gitconfig.erb:
> ----
> [user]
> name = brian m. carlson
> email = <%= data["email"] -%>
> ----

All right, the above might be useful as an example (well, one of those), but might be not necessary if the description of preferred solution is stated in more detail. I think it is better to start with generics, i.e. track template, and generate untracked file, then provide examples like Ruby's ERB.

Show 24 quoted lines
> template.rb:
> ----
> #!/usr/bin/env ruby
>
> require 'erb'
>
> class Template
>   def name
>     @name ||= 0
>     @name += 1
>     "name_a#{@name}"
>   end
>
>   def data
>     ENV.map { |k, v| [k.downcase, v] }.to_h
>   end
>
>   def erb(file)
>     ERB.new(File.read(file), nil, '-', name).result(binding)
>   end
> end
>
> puts Template.new.erb(ARGV[0])
> ----
This is certainly too much detail.
> and then run:
>
> EMAIL=sandals@crustytoothpaste.net template.rb .muttrc.erb >.muttrc
> EMAIL=sandals@crustytoothpaste.net template.rb .gitconfig.erb >.gitconfig
That could be kept as an example, after simplification.
Show 6 quoted lines
> The problem that folks tend to have is that they have a single editor or
> IDE project file, such as an XCode configuration file, that can't be
> split among multiple files, some of which are checked in and some of
> which are not.  Other situations are generating a configuration file for
> a web server like nginx in development, which may of course differ
> depending on where the user has checked out the repository.
All right.
Show 6 quoted lines
> Using some sort of file like a config.mak is a fine solution, but many
> programs don't support that, so it's necessary to create a template for
> the build process and add a script to generate it.  The actual
> configuration values can come from the environment, the user's
> gitconfig, a YAML file the user has configured, or anywhere else that
> makes sense.

I still think that config.mak (or equivalent) solution might be worth mentioning in passing.

> As you can see, the example is large and unwieldy, and would not make a
> good inclusion in the man page.  I included that paragraph because Peff
> stated that it would be nice if we could offer people a solution, but
> I'd rather drop it if it's too confusing without an example.

I think it can be done even without example, but without example it would need careful crafting of the wording.

Best,
-- 
Jakub Narębski
Jeff King· Nov 4, 2019, 22:24 UTC · re: brian m. carlson · lore

Re: [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files

On Sun, Nov 03, 2019 at 06:59:08PM +0000, brian m. carlson wrote:
Show 8 quoted lines
> > I would really like to see a simple example of such template, so that
> > even people who are unfamiliar with Ruby's ERB can think of equivalent
> > solution for their language or toolchain of choice.
> 
> I hesitated to mention ERB, but I wasn't sure that folks would know what
> we meant by a "templating mechanism".  The reason I had chosen to
> mention it is that someone could search for "Ruby ERB" and find out what
> it looked like and then look for an option in their own language.

I don't mind what is here, but I might even suggest going slightly in the opposite direction. Say something like:

  For example, you the repository can include a sample config file that
  can then be copied into the ignored name and modified.

which points people in the right direction without giving specifics. But if you did want to go further, you can then say:

  The repository can even include a script to treat the sample file as a
  template, modifying and copying it automatically (e.g., a Ruby script
  using an ERB template).
or something.
> My concern with adding such a template is that an example will likely
> grow this section quite a bit, and it's meant as a short aside to help
> people avoid making a common mistake and guide them to a proper solution
> rather than a comprehensive howto.
Yeah. I don't think we should get into best practices for using ERB.
-Peff
brian m. carlson· Nov 4, 2019, 23:52 UTC · re: Jeff King · lore

Re: [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files

On 2019-11-04 at 22:24:16, Jeff King wrote:
Show 25 quoted lines
> On Sun, Nov 03, 2019 at 06:59:08PM +0000, brian m. carlson wrote:
> 
> > > I would really like to see a simple example of such template, so that
> > > even people who are unfamiliar with Ruby's ERB can think of equivalent
> > > solution for their language or toolchain of choice.
> > 
> > I hesitated to mention ERB, but I wasn't sure that folks would know what
> > we meant by a "templating mechanism".  The reason I had chosen to
> > mention it is that someone could search for "Ruby ERB" and find out what
> > it looked like and then look for an option in their own language.
> 
> I don't mind what is here, but I might even suggest going slightly in
> the opposite direction. Say something like:
> 
>   For example, you the repository can include a sample config file that
>   can then be copied into the ignored name and modified.
> 
> which points people in the right direction without giving specifics. But
> if you did want to go further, you can then say:
> 
>   The repository can even include a script to treat the sample file as a
>   template, modifying and copying it automatically (e.g., a Ruby script
>   using an ERB template).
> 
> or something.

I think this is a nice change. It summarizes the proposed solution without needing to be specific.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
brian m. carlson· Nov 2, 2019, 19:26 UTC · re: brian m. carlson · lore

[PATCH v3 4/4] docs: mention when increasing http.postBuffer is valuable

Users in a wide variety of situations find themselves with HTTP push problems. Oftentimes these issues are due to antivirus software, filtering proxies, or other man-in-the-middle situations; other times, they are due to simple unreliability of the network.

However, a common solution to HTTP push problems found online is to increase http.postBuffer. This works for none of the aforementioned situations and is only useful in a small, highly restricted number of cases: essentially, when the connection does not properly support HTTP/1.1.

Document when raising this value is appropriate and what it actually does, and discourage people from using it as a general solution for push problems, since it is not effective there.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 Documentation/config/http.txt | 8 ++++++++
 1 file changed, 8 insertions(+)
Show changes to Documentation/config/http.txt +8 −0
diff --git a/Documentation/config/http.txt b/Documentation/config/http.txt
index 5a32f5b0a5..08b375fe95 100644
--- a/Documentation/config/http.txt
+++ b/Documentation/config/http.txt
@@ -199,6 +199,14 @@ http.postBuffer::
 	Transfer-Encoding: chunked is used to avoid creating a
 	massive pack file locally.  Default is 1 MiB, which is
 	sufficient for most requests.
++
+Note that raising this limit is only effective for disabling chunked
+transfer encoding and therefore should be used only where the remote
+server or a proxy only supports HTTP/1.0 or is noncompliant with the
+HTTP standard.  Raising this is not, in general, an effective solution
+for most push problems, but can increase memory consumption
+significantly since the entire buffer is allocated for even small
+pushes.
 
 http.lowSpeedLimit, http.lowSpeedTime::
 	If the HTTP transfer speed is less than 'http.lowSpeedLimit'
brian m. carlson· Nov 2, 2019, 19:26 UTC · re: brian m. carlson · lore

[PATCH v3 1/4] doc: move author and committer information to git-commit(1)

While at one time it made perfect sense to store information about configuring author and committer information in the documentation for git commit-tree, in modern Git that operation is seldom used. Most users will use git commit and expect to find comprehensive documentation about its use in the manual page for that command.

Considering that there is significant confusion about how one is to use the user.name and user.email variables, let's put as much documentation as possible into an obvious place where users will be more likely to find it.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 Documentation/config/user.txt     |  2 +-
 Documentation/git-commit-tree.txt | 39 ++++---------------------------
 Documentation/git-commit.txt      | 34 ++++++++++++++++++++++++---
 3 files changed, 37 insertions(+), 38 deletions(-)
Show changes to 3 files +37 −37

Documentation/config/user.txt, Documentation/git-commit-tree.txt, Documentation/git-commit.txt

diff --git a/Documentation/config/user.txt b/Documentation/config/user.txt
index 0557cbbceb..a1f80e823c 100644
--- a/Documentation/config/user.txt
+++ b/Documentation/config/user.txt
@@ -13,7 +13,7 @@ committer.email::
 	Also, all of these can be overridden by the `GIT_AUTHOR_NAME`,
 	`GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_NAME`,
 	`GIT_COMMITTER_EMAIL` and `EMAIL` environment variables.
-	See linkgit:git-commit-tree[1] for more information.
+	See linkgit:git-commit[1] for more information.
 
 user.useConfigOnly::
 	Instruct Git to avoid trying to guess defaults for `user.email`
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
index 4b90b9c12a..d518dffce0 100644
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -42,6 +42,10 @@ tend to just write the result to the file that is pointed at by
 `.git/HEAD`, so that we can always see what the last committed
 state was.
 
+A commit comment is read from stdin. If a changelog
+entry is not provided via "<" redirection, 'git commit-tree' will just wait
+for one to be entered and terminated with ^D.
+
 OPTIONS
 -------
 <tree>::
@@ -69,40 +73,6 @@ OPTIONS
 	Do not GPG-sign commit, to countermand a `--gpg-sign` option
 	given earlier on the command line.
 
-
-Commit Information
-------------------
-
-A commit encapsulates:
-
-- all parent object ids
-- author name, email and date
-- committer name and email and the commit time.
-
-While parent object ids are provided on the command line, author and
-committer information is taken from the following environment variables,
-if set:
-
-	GIT_AUTHOR_NAME
-	GIT_AUTHOR_EMAIL
-	GIT_AUTHOR_DATE
-	GIT_COMMITTER_NAME
-	GIT_COMMITTER_EMAIL
-	GIT_COMMITTER_DATE
-
-(nb "<", ">" and "\n"s are stripped)
-
-In case (some of) these environment variables are not set, the information
-is taken from the configuration items user.name and user.email, or, if not
-present, the environment variable EMAIL, or, if that is not set,
-system user name and the hostname used for outgoing mail (taken
-from `/etc/mailname` and falling back to the fully qualified hostname when
-that file does not exist).
-
-A commit comment is read from stdin. If a changelog
-entry is not provided via "<" redirection, 'git commit-tree' will just wait
-for one to be entered and terminated with ^D.
-
 include::date-formats.txt[]
 
 Discussion
@@ -117,6 +87,7 @@ FILES
 SEE ALSO
 --------
 linkgit:git-write-tree[1]
+linkgit:git-commit[1]
 
 GIT
 ---
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index afa7b75a23..f684f7fdc2 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -352,9 +352,6 @@ changes to tracked files.
 	these files are also staged for the next commit on top
 	of what have been staged before.
 
-:git-commit: 1
-include::date-formats.txt[]
-
 EXAMPLES
 --------
 When recording your own work, the contents of modified files in
@@ -448,6 +445,37 @@ alter the order the changes are committed, because the merge
 should be recorded as a single commit.  In fact, the command
 refuses to run when given pathnames (but see `-i` option).
 
+COMMIT INFORMATION
+------------------
+
+A commit encapsulates:
+
+- all parent object ids
+- author name, email and date
+- committer name and email and the commit time.
+
+While parent object ids are provided on the command line, author and
+committer information is taken from the following environment variables,
+if set:
+
+	GIT_AUTHOR_NAME
+	GIT_AUTHOR_EMAIL
+	GIT_AUTHOR_DATE
+	GIT_COMMITTER_NAME
+	GIT_COMMITTER_EMAIL
+	GIT_COMMITTER_DATE
+
+(nb "<", ">" and "\n"s are stripped)
+
+In case (some of) these environment variables are not set, the information
+is taken from the configuration items user.name and user.email, or, if not
+present, the environment variable EMAIL, or, if that is not set,
+system user name and the hostname used for outgoing mail (taken
+from `/etc/mailname` and falling back to the fully qualified hostname when
+that file does not exist).
+
+:git-commit: 1
+include::date-formats.txt[]
 
 DISCUSSION
 ----------
Jakub Narebski· Nov 3, 2019, 11:13 UTC · re: brian m. carlson · lore

Re: [PATCH v3 1/4] doc: move author and committer information to git-commit(1)

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 28 quoted lines
> While at one time it made perfect sense to store information about
> configuring author and committer information in the documentation for
> git commit-tree, in modern Git that operation is seldom used.  Most
> users will use git commit and expect to find comprehensive documentation
> about its use in the manual page for that command.
>
> Considering that there is significant confusion about how one is to use
> the user.name and user.email variables, let's put as much documentation
> as possible into an obvious place where users will be more likely to
> find it.
>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
>  Documentation/config/user.txt     |  2 +-
>  Documentation/git-commit-tree.txt | 39 ++++---------------------------
>  Documentation/git-commit.txt      | 34 ++++++++++++++++++++++++---
>  3 files changed, 37 insertions(+), 38 deletions(-)
>
> diff --git a/Documentation/config/user.txt b/Documentation/config/user.txt
> index 0557cbbceb..a1f80e823c 100644
> --- a/Documentation/config/user.txt
> +++ b/Documentation/config/user.txt
> @@ -13,7 +13,7 @@ committer.email::
>  	Also, all of these can be overridden by the `GIT_AUTHOR_NAME`,
>  	`GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_NAME`,
>  	`GIT_COMMITTER_EMAIL` and `EMAIL` environment variables.
> -	See linkgit:git-commit-tree[1] for more information.
> +	See linkgit:git-commit[1] for more information.
O.K., lets refer users to the command they actually use.
Show 14 quoted lines
>  user.useConfigOnly::
>  	Instruct Git to avoid trying to guess defaults for `user.email`
> diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
> index 4b90b9c12a..d518dffce0 100644
> --- a/Documentation/git-commit-tree.txt
> +++ b/Documentation/git-commit-tree.txt
> @@ -42,6 +42,10 @@ tend to just write the result to the file that is pointed at by
>  `.git/HEAD`, so that we can always see what the last committed
>  state was.
>  
> +A commit comment is read from stdin. If a changelog
> +entry is not provided via "<" redirection, 'git commit-tree' will just wait
> +for one to be entered and terminated with ^D.
> +

I understand this is what is extracted from the removed part (moved to git-commit documentation). But I think it is not enough to understand how to actually use this command; this change makes reference documentation not self contained.

Show 16 quoted lines
>  OPTIONS
>  -------
>  <tree>::
> @@ -69,40 +73,6 @@ OPTIONS
>  	Do not GPG-sign commit, to countermand a `--gpg-sign` option
>  	given earlier on the command line.
>  
> -
> -Commit Information
> -------------------
> -
> -A commit encapsulates:
> -
> -- all parent object ids
> -- author name, email and date
> -- committer name and email and the commit time.

O.K., I can understand moving this information to a better place (nb. what about gitglossry?).

Show 20 quoted lines
> -
> -While parent object ids are provided on the command line, author and
> -committer information is taken from the following environment variables,
> -if set:
> -
> -	GIT_AUTHOR_NAME
> -	GIT_AUTHOR_EMAIL
> -	GIT_AUTHOR_DATE
> -	GIT_COMMITTER_NAME
> -	GIT_COMMITTER_EMAIL
> -	GIT_COMMITTER_DATE
> -
> -(nb "<", ">" and "\n"s are stripped)
> -
> -In case (some of) these environment variables are not set, the information
> -is taken from the configuration items user.name and user.email, or, if not
> -present, the environment variable EMAIL, or, if that is not set,
> -system user name and the hostname used for outgoing mail (taken
> -from `/etc/mailname` and falling back to the fully qualified hostname when
> -that file does not exist).

I'm not sure if this should not be left here, perhaps extracted into separate fragment file to be included in both git-commit-tree.txt and in git-commit.txt

I see that we are missing the ebvious information that if GIT_*_DATE environment variables are not set, Git will use current date and time. Is there a place where we say what format GIT_*_DATE needs to be in?

Show 13 quoted lines
> -
> -A commit comment is read from stdin. If a changelog
> -entry is not provided via "<" redirection, 'git commit-tree' will just wait
> -for one to be entered and terminated with ^D.
> -
>  include::date-formats.txt[]
>  
>  Discussion
> @@ -117,6 +87,7 @@ FILES
>  SEE ALSO
>  --------
>  linkgit:git-write-tree[1]
> +linkgit:git-commit[1]
All right.
Show 14 quoted lines
>  
>  GIT
>  ---
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index afa7b75a23..f684f7fdc2 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -352,9 +352,6 @@ changes to tracked files.
>  	these files are also staged for the next commit on top
>  	of what have been staged before.
>  
> -:git-commit: 1
> -include::date-formats.txt[]
> -
All right, it is moved down, not removed.
Show 17 quoted lines
>  EXAMPLES
>  --------
>  When recording your own work, the contents of modified files in
> @@ -448,6 +445,37 @@ alter the order the changes are committed, because the merge
>  should be recorded as a single commit.  In fact, the command
>  refuses to run when given pathnames (but see `-i` option).
>  
> +COMMIT INFORMATION
> +------------------
> +
> +A commit encapsulates:
> +
> +- all parent object ids
> +- author name, email and date
> +- committer name and email and the commit time.
> +
> +While parent object ids are provided on the command line,
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This was true for `git commit-tree`, with the following synopsis
  git commit-tree <tree> [(-p <parent>)…​]
  git commit-tree [(-p <parent>)…​] [-S[<keyid>]] [(-m <message>)…​]
  		  [(-F <file>)…​] <tree>
This is decidely *NOT true* for `git commit`:
  git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
  	   [--dry-run] [(-c | -C | --fixup | --squash) <commit>]
  	   [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
  	   [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
  	   [--date=<date>] [--cleanup=<mode>] [--[no-]status]
  	   [-i | -o] [-S[<keyid>]] [--] [<file>…​]
Parent ids are *not* provided on the command line.
Show 19 quoted lines
>                                                            author and
> +committer information is taken from the following environment variables,
> +if set:
> +
> +	GIT_AUTHOR_NAME
> +	GIT_AUTHOR_EMAIL
> +	GIT_AUTHOR_DATE
> +	GIT_COMMITTER_NAME
> +	GIT_COMMITTER_EMAIL
> +	GIT_COMMITTER_DATE
> +
> +(nb "<", ">" and "\n"s are stripped)
> +
> +In case (some of) these environment variables are not set, the information
> +is taken from the configuration items user.name and user.email, or, if not
> +present, the environment variable EMAIL, or, if that is not set,
> +system user name and the hostname used for outgoing mail (taken
> +from `/etc/mailname` and falling back to the fully qualified hostname when
> +that file does not exist).

I think that this description, while perfectly fine for plumbing command `git commit-tree`, might be needlesly confusing for `git commit` users, as it describes less often common used way of providing committer and author information first.

Also in `git commit` there are *options* specifically for adjusting how committer and author information is handled: `--reuse-message=<commit>` and `--reedit-message=<commit>`, `--reset-author` (doesn't make sense alone), `--author=<author>` and `--date=<date>`.

Maybe describe usual way first, then describe the various options and their priority?

Show 6 quoted lines
> +
> +:git-commit: 1
> +include::date-formats.txt[]
>  
>  DISCUSSION
>  ----------
Best,
-- 
Jakub Narębski
Jeff King· Nov 4, 2019, 22:18 UTC · re: brian m. carlson · lore

Re: [PATCH v3 1/4] doc: move author and committer information to git-commit(1)

On Sat, Nov 02, 2019 at 07:26:12PM +0000, brian m. carlson wrote:
Show 10 quoted lines
> While at one time it made perfect sense to store information about
> configuring author and committer information in the documentation for
> git commit-tree, in modern Git that operation is seldom used.  Most
> users will use git commit and expect to find comprehensive documentation
> about its use in the manual page for that command.
> 
> Considering that there is significant confusion about how one is to use
> the user.name and user.email variables, let's put as much documentation
> as possible into an obvious place where users will be more likely to
> find it.

I think we might want to keep documentation that gets too low-level out of git-commit(1).

So for instance, this part that got moved from commit-tree:
Show 6 quoted lines
> +A commit encapsulates:
> +
> +- all parent object ids
> +- author name, email and date
> +- committer name and email and the commit time.
> +
I think could just stay there.
The part just below that:
Show 12 quoted lines
> +While parent object ids are provided on the command line, author and
> +committer information is taken from the following environment variables,
> +if set:
> +
> +	GIT_AUTHOR_NAME
> +	GIT_AUTHOR_EMAIL
> +	GIT_AUTHOR_DATE
> +	GIT_COMMITTER_NAME
> +	GIT_COMMITTER_EMAIL
> +	GIT_COMMITTER_DATE
> +
> +(nb "<", ">" and "\n"s are stripped)

would be appropriate in git-commit. Though possibly they should just be broken out into an ENVIRONMENT VARIABLES section.

I thought we already did so in git.txt, but it looks like it just refers to commit-tree (and if we don't do anything more drastic, I think you'd probably want to update that reference). Since these do affect multiple commands, I wonder if it would make sense to define them there in git.txt, giving a more user-facing description. Something like:

  GIT_COMMITTER_NAME::
	The human-readable name used in the committer identity when
	creating commit or tags objects, or when writing reflogs.
	Overrides the user.name config.
and so forth for COMMITTER_EMAIL, AUTHOR_NAME, etc.
-Peff
Junio C Hamano· Nov 6, 2019, 01:55 UTC · re: Jeff King · lore

Re: [PATCH v3 1/4] doc: move author and committer information to git-commit(1)

Jeff King <peff@peff.net> writes:
Show 13 quoted lines
> I think we might want to keep documentation that gets too low-level out
> of git-commit(1).
>
> So for instance, this part that got moved from commit-tree:
>
>> +A commit encapsulates:
>> +
>> +- all parent object ids
>> +- author name, email and date
>> +- committer name and email and the commit time.
>> +
>
> I think could just stay there.
Me too ;-)
Show 9 quoted lines
> ... I wonder if it would make sense to define them there in
> git.txt, giving a more user-facing description. Something like:
>
>   GIT_COMMITTER_NAME::
> 	The human-readable name used in the committer identity when
> 	creating commit or tags objects, or when writing reflogs.
> 	Overrides the user.name config.
>
> and so forth for COMMITTER_EMAIL, AUTHOR_NAME, etc.

Yup, I like that. Then either commit-tree, commit etc. can refer to the environment variables section of linkgit:git[1], or perhaps assume that the readers know that anything common across all subcommands are there in linkgit:git[1] (I prefer the former).

Thanks.
Jeff King· Nov 4, 2019, 22:26 UTC · re: brian m. carlson · lore

Re: [PATCH v3 0/4] Documentation for common user misconceptions

On Sat, Nov 02, 2019 at 07:26:11PM +0000, brian m. carlson wrote:
Show 14 quoted lines
> This series includes four patches that update the documentation to
> address common user misconceptions.
> 
> Changes from v2:
> * Move author and committer information to git-commit(1) where people
>   will look for it.
> * Move guidance on user.name format to git-commit(1) as well and mention
>   a shortened form of the advice in the `user.name` description.
> * Use a parenthetical to describe a "personal name" without contrasting
>   it with a username.
> * Offer a potential solution for people who want to ignore tracked
>   files by recommending a templating mechanism.
> * Be slightly more verbose about why memory is wasted with
>   http.postBuffer.

Thanks. I think this is an improvement over v1, but I'm still a little iffy on some of the other movement in the first patch.

TBH, I don't think it's making anything _worse_, but I think it highlights how some of our documentation is a mish-mash of low-level and high-level details. ;) So it might be a good opportunity to at least clean up the documentation around ident environment variables.

-Peff
Junio C Hamano· Nov 6, 2019, 01:58 UTC · re: Jeff King · lore

Re: [PATCH v3 0/4] Documentation for common user misconceptions

Jeff King <peff@peff.net> writes:
Show 7 quoted lines
> Thanks. I think this is an improvement over v1, but I'm still a little
> iffy on some of the other movement in the first patch.
>
> TBH, I don't think it's making anything _worse_, but I think it
> highlights how some of our documentation is a mish-mash of low-level and
> high-level details. ;) So it might be a good opportunity to at least
> clean up the documentation around ident environment variables.

Yeah, I hate to suggest another round, but agree with your comments on 1/4 wrt the way how and the place where the environment variables are explained, which invalidates the changes in 2/4. Fortunately 3/4 and 4/4 are unaffected ;-)

Thanks.
brian m. carlson· Nov 6, 2019, 02:19 UTC · re: Junio C Hamano · lore

Re: [PATCH v3 0/4] Documentation for common user misconceptions

On 2019-11-06 at 01:58:33, Junio C Hamano wrote:
Show 14 quoted lines
> Jeff King <peff@peff.net> writes:
> 
> > Thanks. I think this is an improvement over v1, but I'm still a little
> > iffy on some of the other movement in the first patch.
> >
> > TBH, I don't think it's making anything _worse_, but I think it
> > highlights how some of our documentation is a mish-mash of low-level and
> > high-level details. ;) So it might be a good opportunity to at least
> > clean up the documentation around ident environment variables.
> 
> Yeah, I hate to suggest another round, but agree with your comments
> on 1/4 wrt the way how and the place where the environment variables
> are explained, which invalidates the changes in 2/4.  Fortunately
> 3/4 and 4/4 are unaffected ;-)

Yeah, I agree another round is warranted, and it's not the end of the world: it'll get into 2.25 either way. I'll try to get a reroll out in the next few days.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Junio C Hamano· Nov 6, 2019, 03:15 UTC · re: brian m. carlson · lore

Re: [PATCH v3 0/4] Documentation for common user misconceptions

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 19 quoted lines
> On 2019-11-06 at 01:58:33, Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>> 
>> > Thanks. I think this is an improvement over v1, but I'm still a little
>> > iffy on some of the other movement in the first patch.
>> >
>> > TBH, I don't think it's making anything _worse_, but I think it
>> > highlights how some of our documentation is a mish-mash of low-level and
>> > high-level details. ;) So it might be a good opportunity to at least
>> > clean up the documentation around ident environment variables.
>> 
>> Yeah, I hate to suggest another round, but agree with your comments
>> on 1/4 wrt the way how and the place where the environment variables
>> are explained, which invalidates the changes in 2/4.  Fortunately
>> 3/4 and 4/4 are unaffected ;-)
>
> Yeah, I agree another round is warranted, and it's not the end of the
> world: it'll get into 2.25 either way.  I'll try to get a reroll out in
> the next few days.

Thanks. I also agree with what Peff and you said on 3/4 wrt the addition of "ship template, tweak it into an untracked config that gets used".

Emily Shaffer· Jan 16, 2020, 21:08 UTC · re: brian m. carlson · lore

Re: [PATCH v3 0/4] Documentation for common user misconceptions

On Sat, Nov 02, 2019 at 07:26:11PM +0000, brian m. carlson wrote:
> This series includes four patches that update the documentation to
> address common user misconceptions.

Hm, is this still waiting for a reroll? Someone just ran into the user.name/username confusion in #git-devel today: https://colabti.org/irclogger/irclogger_log/git-devel?date=2020-01-16#l79

 - Emily
brian m. carlson· Jan 16, 2020, 23:35 UTC · re: Emily Shaffer · lore

Re: [PATCH v3 0/4] Documentation for common user misconceptions

On 2020-01-16 at 21:08:57, Emily Shaffer wrote:
Show 7 quoted lines
> On Sat, Nov 02, 2019 at 07:26:11PM +0000, brian m. carlson wrote:
> > This series includes four patches that update the documentation to
> > address common user misconceptions.
> 
> Hm, is this still waiting for a reroll? Someone just ran into the
> user.name/username confusion in #git-devel today:
> https://colabti.org/irclogger/irclogger_log/git-devel?date=2020-01-16#l79

Yeah, it is. I have one, but haven't sent it out. I'll plan to do so this weekend.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

← back to recent threads