patch, 3 partsDocumentation: change "folder" to "directory"

It is my understanding that we prefer "directory" over "folder" when discussing the file system concept. (Whereas "folder" is commonly used for the GUI view of such a directory, or for an IMAP folder.)

I stumbled on a mention of the ".git folder" when going through the doc-diff between v2.33.0 and 9d530dc002 ("The fourteenth batch", 2021-10-18), and started looking around. This series is the outcome.

Based on master.

Martin Ågren (3):
  git-multi-pack-index.txt: change "folder" to "directory"
  gitignore.txt: change "folder" to "directory"
  gitweb.txt: change "folder" to "directory"

 Documentation/git-multi-pack-index.txt | 6 +++---
 Documentation/gitignore.txt            | 2 +-
 Documentation/gitweb.txt               | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

We prefer "directory" over "folder" when discussing the file system concept. In all of our documentation, these are the only spots where we refer to the `.git` directory as a folder. Switch to "directory", and while doing so, add backticks to the ".git" filename to set it in monospace.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
 Documentation/git-multi-pack-index.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

We prefer "directory" over "folder" when discussing the file system concept. Change this instance for consistency -- indeed, even within this paragraph, we already use "directory".

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
 Documentation/gitignore.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

We prefer "directory" over "folder" when discussing the file system concept. Change this instance for consistency.

After this, the only hits for '\<folder\>' in Documentation/ relate to IMAP folders.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
 Documentation/gitweb.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On 25/10/21 00.09, Martin Ågren wrote:

The same logical change over three patches, why aren't they be squashed into single commit?

Hi Bagas,

On Mon, 25 Oct 2021 at 11:19, Bagas Sanjaya <bagasdotme@gmail.com> wrote:

Old habit, I guess. :) I tend to find that having multiple patches aids reviewing. Within reason, obviously. Reviewers don't have to go "I agree with everything except that particular hunk", but can just say "I agree with everything except patch two", making tracking things a bit easier.

Similarly, if the patches are all independent (albeit being about the same topic) and it comes up that a particular patch is not such a good idea after all because reasons, Junio could just decide to apply a subset and leave the rest. In this case, the commit message of the third patch assumes that the first two have already been applied, so they're not completely independent, but that's about the only interdependency there is in these.

I'm happy to go either way.

Martin

Martin Ågren <martin.agren@gmail.com> writes:

In this case, changes to three separate files are presented in three separate patches, which was a quite pleasant read. I do appreciate that you said "within reason" ;-)

On 10/24/2021 1:09 PM, Martin Ågren wrote:

Thanks for these changes, in particular for the ones that I had introduced in git-multi-pack-index.txt.

Thanks, -Stolee

Martin Ågren <martin.agren@gmail.com> writes:

Thanks.  Being consistent is good.

We should have been a bit more careful when we reviewed the changes that introduced these.