git/Documentation/git-init.txt, branch v2.34.2

init: document `init.defaultBranch` better

2020-12-13T23:53:50Z

Our documentation does not mention any future plan to change 'master' to other value. It is a good idea to document this, though. Initial-patch-by: Junio C Hamano Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

doc: fix the bnf like style of some commands

2020-10-08T21:01:19Z

In command line options, variables are entered between < and > Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

Documentation: mark `--object-format=sha256` as experimental

2020-08-17T17:50:14Z

After eff45daab8 ("repository: enable SHA-256 support by default", 2020-07-29), vanilla builds of Git enable the user to run, e.g., git init --object-format=sha256 and hack away. This can be a good way to gain experience with the SHA-256 world, e.g., to find bugs that GIT_TEST_DEFAULT_HASH=sha256 make test doesn't spot. But it really is a separate world: Such SHA-256 repos will live entirely separate from the (by now fairly large) set of SHA-1 repos. Interacting across the border is possible in principle, e.g., through "diff + apply" (or "format-patch + am"), but even that has its limitations: Applying a SHA-256 diff in a SHA-1 repo works in the simple case, but if you need to resort to `-3`, you're out of luck. Similarly, "push + pull" should work, but you really will be operating mostly offset from the rest of the world. That might be ok by the time you initialize your repository, and it might be ok for several months after that, but there might come a day when you're starting to regret your use of `git init --object-format=sha256` and have dug yourself into a fairly deep hole. There are currently topics in flight to document our data formats and protocols regarding SHA-256 and in some cases (midx and commit-graph), we're considering adjusting how the file formats indicate which object format to use. Wherever `--object-format` is mentioned in our documentation, let's make it clear that using it with "sha256" is experimental. If we later need to explain why we can't handle data we generated back in 2020, we can always point to this paragraph we're adding here. By "include::"-ing a small blurb, we should be able to be consistent throughout the documentation and can eventually gradually tone down the severity of this text. One day, we might even use it to start phasing out `--object-format=sha1`, but let's not get ahead of ourselves... There's also `extensions.objectFormat`, but it's only mentioned three times. Twice where we're adding this new disclaimer and in the third spot we already have a "do not edit" warning. From there, interested readers should eventually find this new one that we're adding here. Because `GIT_DEFAULT_HASH` provides another entry point to this functionality, document the experimental nature of it too. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

init: allow specifying the initial branch name for the new repository

2020-06-24T16:14:21Z

There is a growing number of projects and companies desiring to change the main branch name of their repositories (see e.g. https://twitter.com/mislav/status/1270388510684598272 for background on this). To change that branch name for new repositories, currently the only way to do that automatically is by copying all of Git's template directory, then hard-coding the desired default branch name into the `.git/HEAD` file, and then configuring `init.templateDir` to point to those copied template files. To make this process much less cumbersome, let's introduce a new option: `--initial-branch=`. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

docs: add missing diamond brackets

2020-06-24T16:14:21Z

There were a couple of instances in our manual pages that had an opening diamond bracket without a corresponding closing one. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

builtin/init-db: allow specifying hash algorithm on command line

2020-02-24T17:33:27Z

Allow the user to specify the hash algorithm on the command line by using the --object-format option to git init. Validate that the user is not attempting to reinitialize a repository with a different hash algorithm. Ensure that if we are writing a non-SHA-1 repository that we set the repository version to 1 and write the objectFormat extension. Restrict this option to work only when ENABLE_SHA256 is set until the codebase is in a situation to fully support this. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'km/init-doc-typofix'

2019-02-07T06:05:21Z

Docfix. * km/init-doc-typofix: init docs: correct a punctuation typo

init docs: correct a punctuation typo

2019-01-31T17:47:20Z

Signed-off-by: Kyle Meyer Signed-off-by: Junio C Hamano

Documentation: do not nest open blocks

2018-12-26T23:29:30Z

It appears we try to nest open blocks, but that does not work well with Asciidoctor, which fails to indent the inner blocks. As a result, they do not visually seem to relate (as much) to the preceding paragraph as they should. Drop the outer blocks to fix the rendering of the inner ones. Asciidoc renders identically before and after this patch, both man-pages and html. This also makes Asciidoctor stop rendering a literal '+' before "Under --pretty=oneline ..." in the manuals for git-log and git-rev-list. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

init: document dotfiles exclusion on template copy

2017-02-17T23:57:21Z

Not just . and .., but any path that begins with dot is not copied when copying the template directory to a new repository. You can customize the template directory, copying some dotfiles might make sense, but it's actually a good thing not to, because you would not want to have your git directory copied in every git directory that is created should you decide to put your template directory under version control, for example. Plus, it might be used as a feature by people who would want to exclude some files. Signed-off-by: Grégoire Paris Signed-off-by: Junio C Hamano