diff options
Diffstat (limited to 'Documentation')
67 files changed, 2829 insertions, 350 deletions
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 32210a4..1169ff6 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -412,6 +412,12 @@ For C programs: must be declared with "extern" in header files. However, function declarations should not use "extern", as that is already the default. + - You can launch gdb around your program using the shorthand GIT_DEBUGGER. + Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or + run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to + use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb" + ./bin-wrappers/git log` (See `wrap-for-bin.sh`.) + For Perl programs: - Most of the C guidelines above apply. diff --git a/Documentation/Makefile b/Documentation/Makefile index dbf5a0f..76f2ecf 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -76,6 +76,7 @@ SP_ARTICLES += howto/maintain-git API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) SP_ARTICLES += $(API_DOCS) +TECH_DOCS += MyFirstContribution TECH_DOCS += SubmittingPatches TECH_DOCS += technical/hash-function-transition TECH_DOCS += technical/http-protocol diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt new file mode 100644 index 0000000..f867037 --- /dev/null +++ b/Documentation/MyFirstContribution.txt @@ -0,0 +1,1134 @@ +My First Contribution to the Git Project +======================================== +:sectanchors: + +[[summary]] +== Summary + +This is a tutorial demonstrating the end-to-end workflow of creating a change to +the Git tree, sending it for review, and making changes based on comments. + +[[prerequisites]] +=== Prerequisites + +This tutorial assumes you're already fairly familiar with using Git to manage +source code. The Git workflow steps will largely remain unexplained. + +[[related-reading]] +=== Related Reading + +This tutorial aims to summarize the following documents, but the reader may find +useful additional context: + +- `Documentation/SubmittingPatches` +- `Documentation/howto/new-command.txt` + +[[getting-started]] +== Getting Started + +[[cloning]] +=== Clone the Git Repository + +Git is mirrored in a number of locations. Clone the repository from one of them; +https://git-scm.com/downloads suggests one of the best places to clone from is +the mirror on GitHub. + +---- +$ git clone https://github.com/git/git git +$ cd git +---- + +[[identify-problem]] +=== Identify Problem to Solve + +//// +Use + to indicate fixed-width here; couldn't get ` to work nicely with the +quotes around "Pony Saying 'Um, Hello'". +//// +In this tutorial, we will add a new command, +git psuh+, short for ``Pony Saying +`Um, Hello''' - a feature which has gone unimplemented despite a high frequency +of invocation during users' typical daily workflow. + +(We've seen some other effort in this space with the implementation of popular +commands such as `sl`.) + +[[setup-workspace]] +=== Set Up Your Workspace + +Let's start by making a development branch to work on our changes. Per +`Documentation/SubmittingPatches`, since a brand new command is a new feature, +it's fine to base your work on `master`. However, in the future for bugfixes, +etc., you should check that document and base it on the appropriate branch. + +For the purposes of this document, we will base all our work on the `master` +branch of the upstream project. Create the `psuh` branch you will use for +development like so: + +---- +$ git checkout -b psuh origin/master +---- + +We'll make a number of commits here in order to demonstrate how to send a topic +with multiple patches up for review simultaneously. + +[[code-it-up]] +== Code It Up! + +NOTE: A reference implementation can be found at +https://github.com/nasamuffin/git/tree/psuh. + +[[add-new-command]] +=== Adding a New Command + +Lots of the subcommands are written as builtins, which means they are +implemented in C and compiled into the main `git` executable. Implementing the +very simple `psuh` command as a built-in will demonstrate the structure of the +codebase, the internal API, and the process of working together as a contributor +with the reviewers and maintainer to integrate this change into the system. + +Built-in subcommands are typically implemented in a function named "cmd_" +followed by the name of the subcommand, in a source file named after the +subcommand and contained within `builtin/`. So it makes sense to implement your +command in `builtin/psuh.c`. Create that file, and within it, write the entry +point for your command in a function matching the style and signature: + +---- +int cmd_psuh(int argc, const char **argv, const char *prefix) +---- + +We'll also need to add the declaration of psuh; open up `builtin.h`, find the +declaration for `cmd_push`, and add a new line for `psuh` immediately before it, +in order to keep the declarations sorted: + +---- +int cmd_psuh(int argc, const char **argv, const char *prefix); +---- + +Be sure to `#include "builtin.h"` in your `psuh.c`. + +Go ahead and add some throwaway printf to that function. This is a decent +starting point as we can now add build rules and register the command. + +NOTE: Your throwaway text, as well as much of the text you will be adding over +the course of this tutorial, is user-facing. That means it needs to be +localizable. Take a look at `po/README` under "Marking strings for translation". +Throughout the tutorial, we will mark strings for translation as necessary; you +should also do so when writing your user-facing commands in the future. + +---- +int cmd_psuh(int argc, const char **argv, const char *prefix) +{ + printf(_("Pony saying hello goes here.\n")); + return 0; +} +---- + +Let's try to build it. Open `Makefile`, find where `builtin/push.o` is added +to `BUILTIN_OBJS`, and add `builtin/psuh.o` in the same way next to it in +alphabetical order. Once you've done so, move to the top-level directory and +build simply with `make`. Also add the `DEVELOPER=1` variable to turn on +some additional warnings: + +---- +$ echo DEVELOPER=1 >config.mak +$ make +---- + +NOTE: When you are developing the Git project, it's preferred that you use the +`DEVELOPER` flag; if there's some reason it doesn't work for you, you can turn +it off, but it's a good idea to mention the problem to the mailing list. + +NOTE: The Git build is parallelizable. `-j#` is not included above but you can +use it as you prefer, here and elsewhere. + +Great, now your new command builds happily on its own. But nobody invokes it. +Let's change that. + +The list of commands lives in `git.c`. We can register a new command by adding +a `cmd_struct` to the `commands[]` array. `struct cmd_struct` takes a string +with the command name, a function pointer to the command implementation, and a +setup option flag. For now, let's keep mimicking `push`. Find the line where +`cmd_push` is registered, copy it, and modify it for `cmd_psuh`, placing the new +line in alphabetical order. + +The options are documented in `builtin.h` under "Adding a new built-in." Since +we hope to print some data about the user's current workspace context later, +we need a Git directory, so choose `RUN_SETUP` as your only option. + +Go ahead and build again. You should see a clean build, so let's kick the tires +and see if it works. There's a binary you can use to test with in the +`bin-wrappers` directory. + +---- +$ ./bin-wrappers/git psuh +---- + +Check it out! You've got a command! Nice work! Let's commit this. + +`git status` reveals modified `Makefile`, `builtin.h`, and `git.c` as well as +untracked `builtin/psuh.c` and `git-psuh`. First, let's take care of the binary, +which should be ignored. Open `.gitignore` in your editor, find `/git-push`, and +add an entry for your new command in alphabetical order: + +---- +... +/git-prune-packed +/git-psuh +/git-pull +/git-push +/git-quiltimport +/git-range-diff +... +---- + +Checking `git status` again should show that `git-psuh` has been removed from +the untracked list and `.gitignore` has been added to the modified list. Now we +can stage and commit: + +---- +$ git add Makefile builtin.h builtin/psuh.c git.c .gitignore +$ git commit -s +---- + +You will be presented with your editor in order to write a commit message. Start +the commit with a 50-column or less subject line, including the name of the +component you're working on, followed by a blank line (always required) and then +the body of your commit message, which should provide the bulk of the context. +Remember to be explicit and provide the "Why" of your change, especially if it +couldn't easily be understood from your diff. When editing your commit message, +don't remove the Signed-off-by line which was added by `-s` above. + +---- +psuh: add a built-in by popular demand + +Internal metrics indicate this is a command many users expect to be +present. So here's an implementation to help drive customer +satisfaction and engagement: a pony which doubtfully greets the user, +or, a Pony Saying "Um, Hello" (PSUH). + +This commit message is intentionally formatted to 72 columns per line, +starts with a single line as "commit message subject" that is written as +if to command the codebase to do something (add this, teach a command +that). The body of the message is designed to add information about the +commit that is not readily deduced from reading the associated diff, +such as answering the question "why?". + +Signed-off-by: A U Thor <author@example.com> +---- + +Go ahead and inspect your new commit with `git show`. "psuh:" indicates you +have modified mainly the `psuh` command. The subject line gives readers an idea +of what you've changed. The sign-off line (`-s`) indicates that you agree to +the Developer's Certificate of Origin 1.1 (see the +`Documentation/SubmittingPatches` +++[[dco]]+++ header). + +For the remainder of the tutorial, the subject line only will be listed for the +sake of brevity. However, fully-fleshed example commit messages are available +on the reference implementation linked at the top of this document. + +[[implementation]] +=== Implementation + +It's probably useful to do at least something besides printing out a string. +Let's start by having a look at everything we get. + +Modify your `cmd_psuh` implementation to dump the args you're passed, keeping +existing `printf()` calls in place: + +---- + int i; + + ... + + printf(Q_("Your args (there is %d):\n", + "Your args (there are %d):\n", + argc), + argc); + for (i = 0; i < argc; i++) + printf("%d: %s\n", i, argv[i]); + + printf(_("Your current working directory:\n<top-level>%s%s\n"), + prefix ? "/" : "", prefix ? prefix : ""); + +---- + +Build and try it. As you may expect, there's pretty much just whatever we give +on the command line, including the name of our command. (If `prefix` is empty +for you, try `cd Documentation/ && ../bin-wrappers/git psuh`). That's not so +helpful. So what other context can we get? + +Add a line to `#include "config.h"`. Then, add the following bits to the +function body: + +---- + const char *cfg_name; + +... + + git_config(git_default_config, NULL); + if (git_config_get_string_const("user.name", &cfg_name) > 0) + printf(_("No name is found in config\n")); + else + printf(_("Your name: %s\n"), cfg_name); +---- + +`git_config()` will grab the configuration from config files known to Git and +apply standard precedence rules. `git_config_get_string_const()` will look up +a specific key ("user.name") and give you the value. There are a number of +single-key lookup functions like this one; you can see them all (and more info +about how to use `git_config()`) in `Documentation/technical/api-config.txt`. + +You should see that the name printed matches the one you see when you run: + +---- +$ git config --get user.name +---- + +Great! Now we know how to check for values in the Git config. Let's commit this +too, so we don't lose our progress. + +---- +$ git add builtin/psuh.c +$ git commit -sm "psuh: show parameters & config opts" +---- + +NOTE: Again, the above is for sake of brevity in this tutorial. In a real change +you should not use `-m` but instead use the editor to write a meaningful +message. + +Still, it'd be nice to know what the user's working context is like. Let's see +if we can print the name of the user's current branch. We can mimic the +`git status` implementation; the printer is located in `wt-status.c` and we can +see that the branch is held in a `struct wt_status`. + +`wt_status_print()` gets invoked by `cmd_status()` in `builtin/commit.c`. +Looking at that implementation we see the status config being populated like so: + +---- +status_init_config(&s, git_status_config); +---- + +But as we drill down, we can find that `status_init_config()` wraps a call +to `git_config()`. Let's modify the code we wrote in the previous commit. + +Be sure to include the header to allow you to use `struct wt_status`: +---- +#include "wt-status.h" +---- + +Then modify your `cmd_psuh` implementation to declare your `struct wt_status`, +prepare it, and print its contents: + +---- + struct wt_status status; + +... + + wt_status_prepare(the_repository, &status); + git_config(git_default_config, &status); + +... + + printf(_("Your current branch: %s\n"), status.branch); +---- + +Run it again. Check it out - here's the (verbose) name of your current branch! + +Let's commit this as well. + +---- +$ git add builtin/psuh.c +$ git commit -sm "psuh: print the current branch" +---- + +Now let's see if we can get some info about a specific commit. + +Luckily, there are some helpers for us here. `commit.h` has a function called +`lookup_commit_reference_by_name` to which we can simply provide a hardcoded +string; `pretty.h` has an extremely handy `pp_commit_easy()` call which doesn't +require a full format object to be passed. + +Add the following includes: + +---- +#include "commit.h" +#include "pretty.h" +---- + +Then, add the following lines within your implementation of `cmd_psuh()` near +the declarations and the logic, respectively. + +---- + struct commit *c = NULL; + struct strbuf commitline = STRBUF_INIT; + +... + + c = lookup_commit_reference_by_name("origin/master"); + + if (c != NULL) { + pp_commit_easy(CMIT_FMT_ONELINE, c, &commitline); + printf(_("Current commit: %s\n"), commitline.buf); + } +---- + +The `struct strbuf` provides some safety belts to your basic `char*`, one of +which is a length member to prevent buffer overruns. It needs to be initialized +nicely with `STRBUF_INIT`. Keep it in mind when you need to pass around `char*`. + +`lookup_commit_reference_by_name` resolves the name you pass it, so you can play +with the value there and see what kind of things you can come up with. + +`pp_commit_easy` is a convenience wrapper in `pretty.h` that takes a single +format enum shorthand, rather than an entire format struct. It then +pretty-prints the commit according to that shorthand. These are similar to the +formats available with `--pretty=FOO` in many Git commands. + +Build it and run, and if you're using the same name in the example, you should +see the subject line of the most recent commit in `origin/master` that you know +about. Neat! Let's commit that as well. + +---- +$ git add builtin/psuh.c +$ git commit -sm "psuh: display the top of origin/master" +---- + +[[add-documentation]] +=== Adding Documentation + +Awesome! You've got a fantastic new command that you're ready to share with the +community. But hang on just a minute - this isn't very user-friendly. Run the +following: + +---- +$ ./bin-wrappers/git help psuh +---- + +Your new command is undocumented! Let's fix that. + +Take a look at `Documentation/git-*.txt`. These are the manpages for the +subcommands that Git knows about. You can open these up and take a look to get +acquainted with the format, but then go ahead and make a new file +`Documentation/git-psuh.txt`. Like with most of the documentation in the Git +project, help pages are written with AsciiDoc (see CodingGuidelines, "Writing +Documentation" section). Use the following template to fill out your own +manpage: + +// Surprisingly difficult to embed AsciiDoc source within AsciiDoc. +[listing] +.... +git-psuh(1) +=========== + +NAME +---- +git-psuh - Delight users' typo with a shy horse + + +SYNOPSIS +-------- +[verse] +'git-psuh [<arg>...]' + +DESCRIPTION +----------- +... + +OPTIONS[[OPTIONS]] +------------------ +... + +OUTPUT +------ +... + +GIT +--- +Part of the linkgit:git[1] suite +.... + +The most important pieces of this to note are the file header, underlined by =, +the NAME section, and the SYNOPSIS, which would normally contain the grammar if +your command took arguments. Try to use well-established manpage headers so your +documentation is consistent with other Git and UNIX manpages; this makes life +easier for your user, who can skip to the section they know contains the +information they need. + +Now that you've written your manpage, you'll need to build it explicitly. We +convert your AsciiDoc to troff which is man-readable like so: + +---- +$ make all doc +$ man Documentation/git-psuh.1 +---- + +or + +---- +$ make -C Documentation/ git-psuh.1 +$ man Documentation/git-psuh.1 +---- + +NOTE: You may need to install the package `asciidoc` to get this to work. + +While this isn't as satisfying as running through `git help`, you can at least +check that your help page looks right. + +You can also check that the documentation coverage is good (that is, the project +sees that your command has been implemented as well as documented) by running +`make check-docs` from the top-level. + +Go ahead and commit your new documentation change. + +[[add-usage]] +=== Adding Usage Text + +Try and run `./bin-wrappers/git psuh -h`. Your command should crash at the end. +That's because `-h` is a special case which your command should handle by +printing usage. + +Take a look at `Documentation/technical/api-parse-options.txt`. This is a handy +tool for pulling out options you need to be able to handle, and it takes a +usage string. + +In order to use it, we'll need to prepare a NULL-terminated array of usage +strings and a `builtin_psuh_options` array. + +Add a line to `#include "parse-options.h"`. + +At global scope, add your array of usage strings: + +---- +static const char * const psuh_usage[] = { + N_("git psuh [<arg>...]"), + NULL, +}; +---- + +Then, within your `cmd_psuh()` implementation, we can declare and populate our +`option` struct. Ours is pretty boring but you can add more to it if you want to +explore `parse_options()` in more detail: + +---- + struct option options[] = { + OPT_END() + }; +---- + +Finally, before you print your args and prefix, add the call to +`parse-options()`: + +---- + argc = parse_options(argc, argv, prefix, options, psuh_usage, 0); +---- + +This call will modify your `argv` parameter. It will strip the options you +specified in `options` from `argv` and the locations pointed to from `options` +entries will be updated. Be sure to replace your `argc` with the result from +`parse_options()`, or you will be confused if you try to parse `argv` later. + +It's worth noting the special argument `--`. As you may be aware, many Unix +commands use `--` to indicate "end of named parameters" - all parameters after +the `--` are interpreted merely as positional arguments. (This can be handy if +you want to pass as a parameter something which would usually be interpreted as +a flag.) `parse_options()` will terminate parsing when it reaches `--` and give +you the rest of the options afterwards, untouched. + +Build again. Now, when you run with `-h`, you should see your usage printed and +your command terminated before anything else interesting happens. Great! + +Go ahead and commit this one, too. + +[[testing]] +== Testing + +It's important to test your code - even for a little toy command like this one. +Moreover, your patch won't be accepted into the Git tree without tests. Your +tests should: + +* Illustrate the current behavior of the feature +* Prove the current behavior matches the expected behavior +* Ensure the externally-visible behavior isn't broken in later changes + +So let's write some tests. + +Related reading: `t/README` + +[[overview-test-structure]] +=== Overview of Testing Structure + +The tests in Git live in `t/` and are named with a 4-digit decimal number using +the schema shown in the Naming Tests section of `t/README`. + +[[write-new-test]] +=== Writing Your Test + +Since this a toy command, let's go ahead and name the test with t9999. However, +as many of the family/subcmd combinations are full, best practice seems to be +to find a command close enough to the one you've added and share its naming +space. + +Create a new file `t/t9999-psuh-tutorial.sh`. Begin with the header as so (see +"Writing Tests" and "Source 'test-lib.sh'" in `t/README`): + +---- +#!/bin/sh + +test_description='git-psuh test + +This test runs git-psuh and makes sure it does not crash.' + +. ./test-lib.sh +---- + +Tests are framed inside of a `test_expect_success` in order to output TAP +formatted results. Let's make sure that `git psuh` doesn't exit poorly and does +mention the right animal somewhere: + +---- +test_expect_success 'runs correctly with no args and good output' ' + git psuh >actual && + test_i18ngrep Pony actual +' +---- + +Indicate that you've run everything you wanted by adding the following at the +bottom of your script: + +---- +test_done +---- + +Make sure you mark your test script executable: + +---- +$ chmod +x t/t9999-psuh-tutorial.sh +---- + +You can get an idea of whether you created your new test script successfully +by running `make -C t test-lint`, which will check for things like test number +uniqueness, executable bit, and so on. + +[[local-test]] +=== Running Locally + +Let's try and run locally: + +---- +$ make +$ cd t/ && prove t9999-psuh-tutorial.sh +---- + +You can run the full test suite and ensure `git-psuh` didn't break anything: + +---- +$ cd t/ +$ prove -j$(nproc) --shuffle t[0-9]*.sh +---- + +NOTE: You can also do this with `make test` or use any testing harness which can +speak TAP. `prove` can run concurrently. `shuffle` randomizes the order the +tests are run in, which makes them resilient against unwanted inter-test +dependencies. `prove` also makes the output nicer. + +Go ahead and commit this change, as well. + +[[ready-to-share]] +== Getting Ready to Share + +You may have noticed already that the Git project performs its code reviews via +emailed patches, which are then applied by the maintainer when they are ready +and approved by the community. The Git project does not accept patches from +pull requests, and the patches emailed for review need to be formatted a +specific way. At this point the tutorial diverges, in order to demonstrate two +different methods of formatting your patchset and getting it reviewed. + +The first method to be covered is GitGitGadget, which is useful for those +already familiar with GitHub's common pull request workflow. This method +requires a GitHub account. + +The second method to be covered is `git send-email`, which can give slightly +more fine-grained control over the emails to be sent. This method requires some +setup which can change depending on your system and will not be covered in this +tutorial. + +Regardless of which method you choose, your engagement with reviewers will be +the same; the review process will be covered after the sections on GitGitGadget +and `git send-email`. + +[[howto-ggg]] +== Sending Patches via GitGitGadget + +One option for sending patches is to follow a typical pull request workflow and +send your patches out via GitGitGadget. GitGitGadget is a tool created by +Johannes Schindelin to make life as a Git contributor easier for those used to +the GitHub PR workflow. It allows contributors to open pull requests against its +mirror of the Git project, and does some magic to turn the PR into a set of +emails and send them out for you. It also runs the Git continuous integration +suite for you. It's documented at http://gitgitgadget.github.io. + +[[create-fork]] +=== Forking `git/git` on GitHub + +Before you can send your patch off to be reviewed using GitGitGadget, you will +need to fork the Git project and upload your changes. First thing - make sure +you have a GitHub account. + +Head to the https://github.com/git/git[GitHub mirror] and look for the Fork +button. Place your fork wherever you deem appropriate and create it. + +[[upload-to-fork]] +=== Uploading to Your Own Fork + +To upload your branch to your own fork, you'll need to add the new fork as a +remote. You can use `git remote -v` to show the remotes you have added already. +From your new fork's page on GitHub, you can press "Clone or download" to get +the URL; then you need to run the following to add, replacing your own URL and +remote name for the examples provided: + +---- +$ git remote add remotename git@github.com:remotename/git.git +---- + +or to use the HTTPS URL: + +---- +$ git remote add remotename https://github.com/remotename/git/.git +---- + +Run `git remote -v` again and you should see the new remote showing up. +`git fetch remotename` (with the real name of your remote replaced) in order to +get ready to push. + +Next, double-check that you've been doing all your development in a new branch +by running `git branch`. If you didn't, now is a good time to move your new +commits to their own branch. + +As mentioned briefly at the beginning of this document, we are basing our work +on `master`, so go ahead and update as shown below, or using your preferred +workflow. + +---- +$ git checkout master +$ git pull -r +$ git rebase master psuh +---- + +Finally, you're ready to push your new topic branch! (Due to our branch and +command name choices, be careful when you type the command below.) + +---- +$ git push remotename psuh +---- + +Now you should be able to go and check out your newly created branch on GitHub. + +[[send-pr-ggg]] +=== Sending a PR to GitGitGadget + +In order to have your code tested and formatted for review, you need to start by +opening a Pull Request against `gitgitgadget/git`. Head to +https://github.com/gitgitgadget/git and open a PR either with the "New pull +request" button or the convenient "Compare & pull request" button that may +appear with the name of your newly pushed branch. + +Review the PR's title and description, as it's used by GitGitGadget as the cover +letter for your change. When you're happy, submit your pull request. + +[[run-ci-ggg]] +=== Running CI and Getting Ready to Send + +If it's your first time using GitGitGadget (which is likely, as you're using +this tutorial) then someone will need to give you permission to use the tool. +As mentioned in the GitGitGadget documentation, you just need someone who +already uses it to comment on your PR with `/allow <username>`. GitGitGadget +will automatically run your PRs through the CI even without the permission given +but you will not be able to `/submit` your changes until someone allows you to +use the tool. + +If the CI fails, you can update your changes with `git rebase -i` and push your +branch again: + +---- +$ git push -f remotename psuh +---- + +In fact, you should continue to make changes this way up until the point when +your patch is accepted into `next`. + +//// +TODO https://github.com/gitgitgadget/gitgitgadget/issues/83 +It'd be nice to be able to verify that the patch looks good before sending it +to everyone on Git mailing list. +[[check-work-ggg]] +=== Check Your Work +//// + +[[send-mail-ggg]] +=== Sending Your Patches + +Now that your CI is passing and someone has granted you permission to use +GitGitGadget with the `/allow` command, sending out for review is as simple as +commenting on your PR with `/submit`. + +[[responding-ggg]] +=== Updating With Comments + +Skip ahead to <<reviewing,Responding to Reviews>> for information on how to +reply to review comments you will receive on the mailing list. + +Once you have your branch again in the shape you want following all review +comments, you can submit again: + +---- +$ git push -f remotename psuh +---- + +Next, go look at your pull request against GitGitGadget; you should see the CI +has been kicked off again. Now while the CI is running is a good time for you +to modify your description at the top of the pull request thread; it will be +used again as the cover letter. You should use this space to describe what +has changed since your previous version, so that your reviewers have some idea +of what they're looking at. When the CI is done running, you can comment once +more with `/submit` - GitGitGadget will automatically add a v2 mark to your +changes. + +[[howto-git-send-email]] +== Sending Patches with `git send-email` + +If you don't want to use GitGitGadget, you can also use Git itself to mail your +patches. Some benefits of using Git this way include finer grained control of +subject line (for example, being able to use the tag [RFC PATCH] in the subject) +and being able to send a ``dry run'' mail to yourself to ensure it all looks +good before going out to the list. + +[[setup-git-send-email]] +=== Prerequisite: Setting Up `git send-email` + +Configuration for `send-email` can vary based on your operating system and email +provider, and so will not be covered in this tutorial, beyond stating that in +many distributions of Linux, `git-send-email` is not packaged alongside the +typical `git` install. You may need to install this additional package; there +are a number of resources online to help you do so. You will also need to +determine the right way to configure it to use your SMTP server; again, as this +configuration can change significantly based on your system and email setup, it +is out of scope for the context of this tutorial. + +[[format-patch]] +=== Preparing Initial Patchset + +Sending emails with Git is a two-part process; before you can prepare the emails +themselves, you'll need to prepare the patches. Luckily, this is pretty simple: + +---- +$ git format-patch --cover-letter -o psuh/ master..psuh +---- + +The `--cover-letter` parameter tells `format-patch` to create a cover letter +template for you. You will need to fill in the template before you're ready +to send - but for now, the template will be next to your other patches. + +The `-o psuh/` parameter tells `format-patch` to place the patch files into a +directory. This is useful because `git send-email` can take a directory and +send out all the patches from there. + +`master..psuh` tells `format-patch` to generate patches for the difference +between `master` and `psuh`. It will make one patch file per commit. After you +run, you can go have a look at each of the patches with your favorite text +editor and make sure everything looks alright; however, it's not recommended to +make code fixups via the patch file. It's a better idea to make the change the +normal way using `git rebase -i` or by adding a new commit than by modifying a +patch. + +NOTE: Optionally, you can also use the `--rfc` flag to prefix your patch subject +with ``[RFC PATCH]'' instead of ``[PATCH]''. RFC stands for ``request for +comments'' and indicates that while your code isn't quite ready for submission, +you'd like to begin the code review process. This can also be used when your +patch is a proposal, but you aren't sure whether the community wants to solve +the problem with that approach or not - to conduct a sort of design review. You +may also see on the list patches marked ``WIP'' - this means they are incomplete +but want reviewers to look at what they have so far. You can add this flag with +`--subject-prefix=WIP`. + +Check and make sure that your patches and cover letter template exist in the +directory you specified - you're nearly ready to send out your review! + +[[cover-letter]] +=== Preparing Email + +In addition to an email per patch, the Git community also expects your patches +to come with a cover letter, typically with a subject line [PATCH 0/x] (where +x is the number of patches you're sending). Since you invoked `format-patch` +with `--cover-letter`, you've already got a template ready. Open it up in your +favorite editor. + +You should see a number of headers present already. Check that your `From:` +header is correct. Then modify your `Subject:` to something which succinctly +covers the purpose of your entire topic branch, for example: + +---- +Subject: [PATCH 0/7] adding the 'psuh' command +---- + +Make sure you retain the ``[PATCH 0/X]'' part; that's what indicates to the Git +community that this email is the beginning of a review, and many reviewers +filter their email for this type of flag. + +You'll need to add some extra parameters when you invoke `git send-email` to add +the cover letter. + +Next you'll have to fill out the body of your cover letter. This is an important +component of change submission as it explains to the community from a high level +what you're trying to do, and why, in a way that's more apparent than just +looking at your diff. Be sure to explain anything your diff doesn't make clear +on its own. + +Here's an example body for `psuh`: + +---- +Our internal metrics indicate widespread interest in the command +git-psuh - that is, many users are trying to use it, but finding it is +unavailable, using some unknown workaround instead. + +The following handful of patches add the psuh command and implement some +handy features on top of it. + +This patchset is part of the MyFirstContribution tutorial and should not +be merged. +---- + +The template created by `git format-patch --cover-letter` includes a diffstat. +This gives reviewers a summary of what they're in for when reviewing your topic. +The one generated for `psuh` from the sample implementation looks like this: + +---- + Documentation/git-psuh.txt | 40 +++++++++++++++++++++ + Makefile | 1 + + builtin.h | 1 + + builtin/psuh.c | 73 ++++++++++++++++++++++++++++++++++++++ + git.c | 1 + + t/t9999-psuh-tutorial.sh | 12 +++++++ + 6 files changed, 128 insertions(+) + create mode 100644 Documentation/git-psuh.txt + create mode 100644 builtin/psuh.c + create mode 100755 t/t9999-psuh-tutorial.sh +---- + +Finally, the letter will include the version of Git used to generate the +patches. You can leave that string alone. + +[[sending-git-send-email]] +=== Sending Email + +At this point you should have a directory `psuh/` which is filled with your +patches and a cover letter. Time to mail it out! You can send it like this: + +---- +$ git send-email --to=target@example.com psuh/*.patch +---- + +NOTE: Check `git help send-email` for some other options which you may find +valuable, such as changing the Reply-to address or adding more CC and BCC lines. + +NOTE: When you are sending a real patch, it will go to git@vger.kernel.org - but +please don't send your patchset from the tutorial to the real mailing list! For +now, you can send it to yourself, to make sure you understand how it will look. + +After you run the command above, you will be presented with an interactive +prompt for each patch that's about to go out. This gives you one last chance to +edit or quit sending something (but again, don't edit code this way). Once you +press `y` or `a` at these prompts your emails will be sent! Congratulations! + +Awesome, now the community will drop everything and review your changes. (Just +kidding - be patient!) + +[[v2-git-send-email]] +=== Sending v2 + +Skip ahead to <<reviewing,Responding to Reviews>> for information on how to +handle comments from reviewers. Continue this section when your topic branch is +shaped the way you want it to look for your patchset v2. + +When you're ready with the next iteration of your patch, the process is fairly +similar. + +First, generate your v2 patches again: + +---- +$ git format-patch -v2 --cover-letter -o psuh/ master..psuh +---- + +This will add your v2 patches, all named like `v2-000n-my-commit-subject.patch`, +to the `psuh/` directory. You may notice that they are sitting alongside the v1 +patches; that's fine, but be careful when you are ready to send them. + +Edit your cover letter again. Now is a good time to mention what's different +between your last version and now, if it's something significant. You do not +need the exact same body in your second cover letter; focus on explaining to +reviewers the changes you've made that may not be as visible. + +You will also need to go and find the Message-Id of your previous cover letter. +You can either note it when you send the first series, from the output of `git +send-email`, or you can look it up on the +https://public-inbox.org/git[mailing list]. Find your cover letter in the +archives, click on it, then click "permalink" or "raw" to reveal the Message-Id +header. It should match: + +---- +Message-Id: <foo.12345.author@example.com> +---- + +Your Message-Id is `<foo.12345.author@example.com>`. This example will be used +below as well; make sure to replace it with the correct Message-Id for your +**previous cover letter** - that is, if you're sending v2, use the Message-Id +from v1; if you're sending v3, use the Message-Id from v2. + +While you're looking at the email, you should also note who is CC'd, as it's +common practice in the mailing list to keep all CCs on a thread. You can add +these CC lines directly to your cover letter with a line like so in the header +(before the Subject line): + +---- +CC: author@example.com, Othe R <other@example.com> +---- + +Now send the emails again, paying close attention to which messages you pass in +to the command: + +---- +$ git send-email --to=target@example.com + --in-reply-to="<foo.12345.author@example.com>" + psuh/v2* +---- + +[[single-patch]] +=== Bonus Chapter: One-Patch Changes + +In some cases, your very small change may consist of only one patch. When that +happens, you only need to send one email. Your commit message should already be +meaningful and explain at a high level the purpose (what is happening and why) +of your patch, but if you need to supply even more context, you can do so below +the `---` in your patch. Take the example below, which was generated with `git +format-patch` on a single commit, and then edited to add the content between +the `---` and the diffstat. + +---- +From 1345bbb3f7ac74abde040c12e737204689a72723 Mon Sep 17 00:00:00 2001 +From: A U Thor <author@example.com> +Date: Thu, 18 Apr 2019 15:11:02 -0700 +Subject: [PATCH] README: change the grammar + +I think it looks better this way. This part of the commit message will +end up in the commit-log. + +Signed-off-by: A U Thor <author@example.com> +--- +Let's have a wild discussion about grammar on the mailing list. This +part of my email will never end up in the commit log. Here is where I +can add additional context to the mailing list about my intent, outside +of the context of the commit log. This section was added after `git +format-patch` was run, by editing the patch file in a text editor. + + README.md | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/README.md b/README.md +index 88f126184c..38da593a60 100644 +--- a/README.md ++++ b/README.md +@@ -3,7 +3,7 @@ + Git - fast, scalable, distributed revision control system + ========================================================= + +-Git is a fast, scalable, distributed revision control system with an ++Git is a fast, scalable, and distributed revision control system with an + unusually rich command set that provides both high-level operations + and full access to internals. + +-- +2.21.0.392.gf8f6787159e-goog +---- + +[[now-what]] +== My Patch Got Emailed - Now What? + +[[reviewing]] +=== Responding to Reviews + +After a few days, you will hopefully receive a reply to your patchset with some +comments. Woohoo! Now you can get back to work. + +It's good manners to reply to each comment, notifying the reviewer that you have +made the change requested, feel the original is better, or that the comment +inspired you to do something a new way which is superior to both the original +and the suggested change. This way reviewers don't need to inspect your v2 to +figure out whether you implemented their comment or not. + +If you are going to push back on a comment, be polite and explain why you feel +your original is better; be prepared that the reviewer may still disagree with +you, and the rest of the community may weigh in on one side or the other. As +with all code reviews, it's important to keep an open mind to doing something a +different way than you originally planned; other reviewers have a different +perspective on the project than you do, and may be thinking of a valid side +effect which had not occurred to you. It is always okay to ask for clarification +if you aren't sure why a change was suggested, or what the reviewer is asking +you to do. + +Make sure your email client has a plaintext email mode and it is turned on; the +Git list rejects HTML email. Please also follow the mailing list etiquette +outlined in the +https://kernel.googlesource.com/pub/scm/git/git/+/todo/MaintNotes[Maintainer's +Note], which are similar to etiquette rules in most open source communities +surrounding bottom-posting and inline replies. + +When you're making changes to your code, it is cleanest - that is, the resulting +commits are easiest to look at - if you use `git rebase -i` (interactive +rebase). Take a look at this +https://www.oreilly.com/library/view/git-pocket-guide/9781449327507/ch10.html[overview] +from O'Reilly. The general idea is to modify each commit which requires changes; +this way, instead of having a patch A with a mistake, a patch B which was fine +and required no upstream reviews in v1, and a patch C which fixes patch A for +v2, you can just ship a v2 with a correct patch A and correct patch B. This is +changing history, but since it's local history which you haven't shared with +anyone, that is okay for now! (Later, it may not make sense to do this; take a +look at the section below this one for some context.) + +[[after-approval]] +=== After Review Approval + +The Git project has four integration branches: `pu`, `next`, `master`, and +`maint`. Your change will be placed into `pu` fairly early on by the maintainer +while it is still in the review process; from there, when it is ready for wider +testing, it will be merged into `next`. Plenty of early testers use `next` and +may report issues. Eventually, changes in `next` will make it to `master`, +which is typically considered stable. Finally, when a new release is cut, +`maint` is used to base bugfixes onto. As mentioned at the beginning of this +document, you can read `Documents/SubmittingPatches` for some more info about +the use of the various integration branches. + +Back to now: your code has been lauded by the upstream reviewers. It is perfect. +It is ready to be accepted. You don't need to do anything else; the maintainer +will merge your topic branch to `next` and life is good. + +However, if you discover it isn't so perfect after this point, you may need to +take some special steps depending on where you are in the process. + +If the maintainer has announced in the "What's cooking in git.git" email that +your topic is marked for `next` - that is, that they plan to merge it to `next` +but have not yet done so - you should send an email asking the maintainer to +wait a little longer: "I've sent v4 of my series and you marked it for `next`, +but I need to change this and that - please wait for v5 before you merge it." + +If the topic has already been merged to `next`, rather than modifying your +patches with `git rebase -i`, you should make further changes incrementally - +that is, with another commit, based on top of the maintainer's topic branch as +detailed in https://github.com/gitster/git. Your work is still in the same topic +but is now incremental, rather than a wholesale rewrite of the topic branch. + +The topic branches in the maintainer's GitHub are mirrored in GitGitGadget, so +if you're sending your reviews out that way, you should be sure to open your PR +against the appropriate GitGitGadget/Git branch. + +If you're using `git send-email`, you can use it the same way as before, but you +should generate your diffs from `<topic>..<mybranch>` and base your work on +`<topic>` instead of `master`. diff --git a/Documentation/RelNotes/2.23.0.txt b/Documentation/RelNotes/2.23.0.txt new file mode 100644 index 0000000..8268355 --- /dev/null +++ b/Documentation/RelNotes/2.23.0.txt @@ -0,0 +1,349 @@ +Git 2.23 Release Notes +====================== + +Updates since v2.22 +------------------- + +Backward compatibility note + + * The "--base" option of "format-patch" computed the patch-ids for + prerequisite patches in an unstable way, which has been updated to + compute in a way that is compatible with "git patch-id --stable". + + +UI, Workflows & Features + + * The "git fast-export/import" pair has been taught to handle commits + with log messages in encoding other than UTF-8 better. + + * In recent versions of Git, per-worktree refs are exposed in + refs/worktrees/<wtname>/ hierarchy, which means that worktree names + must be a valid refname component. The code now sanitizes the names + given to worktrees, to make sure these refs are well-formed. + + * "git merge" learned "--quit" option that cleans up the in-progress + merge while leaving the working tree and the index still in a mess. + + * "git format-patch" learns a configuration to set the default for + its --notes=<ref> option. + + * The code to show args with potential typo that cannot be + interpreted as a commit-ish has been improved. + + * "git clone --recurse-submodules" learned to set up the submodules + to ignore commit object names recorded in the superproject gitlink + and instead use the commits that happen to be at the tip of the + remote-tracking branches from the get-go, by passing the new + "--remote-submodules" option. + + * The pattern "git diff/grep" use to extract funcname and words + boundary for Matlab has been extend to cover Octave, which is more + or less equivalent. + + * "git help git" was hard to discover (well, at least for some + people). + + * The pattern "git diff/grep" use to extract funcname and words + boundary for Rust has been added. + + * "git status" can be told a non-standard default value for the + "--[no-]ahead-behind" option with a new configuration variable + status.aheadBehind. + + * "git fetch" and "git pull" reports when a fetch results in + non-fast-forward updates to let the user notice unusual situation. + The commands learned "--no-shown-forced-updates" option to disable + this safety feature. + + * Two new commands "git switch" and "git restore" are introduced to + split "checking out a branch to work on advancing its history" and + "checking out paths out of the index and/or a tree-ish to work on + advancing the current history" out of the single "git checkout" + command. + + * "git branch --list" learned to always output the detached HEAD as + the first item (when the HEAD is detached, of course), regardless + of the locale. + + * The conditional inclusion mechanism learned to base the choice on + the branch the HEAD currently is on. + + * "git rev-list --objects" learned with "--no-object-names" option to + squelch the path to the object that is used as a grouping hint for + pack-objects. + + * A new tag.gpgSign configuration variable turns "git tag -a" into + "git tag -s". + + * "git multi-pack-index" learned expire and repack subcommands. + + * "git blame" learned to "ignore" commits in the history, whose + effects (as well as their presence) get ignored. + + * "git cherry-pick/revert" learned a new "--skip" action. + + * The tips of refs from the alternate object store can be used as + starting point for reachability computation now. + + * Extra blank lines in "git status" output have been reduced. + + * The commits in a repository can be described by multiple + commit-graph files now, which allows the commit-graph files to be + updated incrementally. + + +Performance, Internal Implementation, Development Support etc. + + * Update supporting parts of "git rebase" to remove code that should + no longer be used. + + * Developer support to emulate unsatisfied prerequisites in tests to + ensure that the remainer of the tests still succeeds when tests + with prerequisites are skipped. + + * "git update-server-info" learned not to rewrite the file with the + same contents. + + * The way of specifying the path to find dynamic libraries at runtime + has been simplified. The old default to pass -R/path/to/dir has been + replaced with the new default to pass -Wl,-rpath,/path/to/dir, + which is the more recent GCC uses. Those who need to build with an + old GCC can still use "CC_LD_DYNPATH=-R" + + * Prepare use of reachability index in topological walker that works + on a range (A..B). + + * A new tutorial targetting specifically aspiring git-core + developers has been added. + + * Auto-detect how to tell HP-UX aCC where to use dynamically linked + libraries from at runtime. + + * "git mergetool" and its tests now spawn fewer subprocesses. + + * Dev support update to help tracing out tests. + + * Support to build with MSVC has been updated. + + * "git fetch" that grabs from a group of remotes learned to run the + auto-gc only once at the very end. + + * A handful of Windows build patches have been upstreamed. + + * The code to read state files used by the sequencer machinery for + "git status" has been made more robust against a corrupt or stale + state files. + + * "git for-each-ref" with multiple patterns have been optimized. + + * The tree-walk API learned to pass an in-core repository + instance throughout more codepaths. + + * When one step in multi step cherry-pick or revert is reset or + committed, the command line prompt script failed to notice the + current status, which has been improved. + + +Fixes since v2.22 +----------------- + + * A relative pathname given to "git init --template=<path> <repo>" + ought to be relative to the directory "git init" gets invoked in, + but it instead was made relative to the repository, which has been + corrected. + (merge e1df7fe43f nd/init-relative-template-fix later to maint). + + * "git worktree add" used to fail when another worktree connected to + the same repository was corrupt, which has been corrected. + (merge 105df73e71 nd/corrupt-worktrees later to maint). + + * The ownership rule for the file descriptor to fast-import remote + backend was mixed up, leading to unrelated file descriptor getting + closed, which has been fixed. + (merge 3203566a71 mh/import-transport-fd-fix later to maint). + + * A "merge -c" instruction during "git rebase --rebase-merges" should + give the user a chance to edit the log message, even when there is + otherwise no need to create a new merge and replace the existing + one (i.e. fast-forward instead), but did not. Which has been + corrected. + + * Code cleanup and futureproof. + (merge 31f5256c82 ds/object-info-for-prefetch-fix later to maint). + + * More parameter validation. + (merge de99eb0c24 es/grep-require-name-when-needed later to maint). + + * "git update-server-info" used to leave stale packfiles in its + output, which has been corrected. + (merge e941c48d49 ew/server-info-remove-crufts later to maint). + + * The server side support for "git fetch" used to show incorrect + value for the HEAD symbolic ref when the namespace feature is in + use, which has been corrected. + (merge 533e088250 jk/HEAD-symref-in-xfer-namespaces later to maint). + + * "git am -i --resolved" segfaulted after trying to see a commit as + if it were a tree, which has been corrected. + (merge 7663e438c5 jk/am-i-resolved-fix later to maint). + + * "git bundle verify" needs to see if prerequisite objects exist in + the receiving repository, but the command did not check if we are + in a repository upfront, which has been corrected. + (merge 3bbbe467f2 js/bundle-verify-require-object-store later to maint). + + * "git merge --squash" is designed to update the working tree and the + index without creating the commit, and this cannot be countermanded + by adding the "--commit" option; the command now refuses to work + when both options are given. + (merge 1d14d0c994 vv/merge-squash-with-explicit-commit later to maint). + + * The data collected by fsmonitor was not properly written back to + the on-disk index file, breaking t7519 tests occasionally, which + has been corrected. + (merge b5a8169752 js/fsmonitor-unflake later to maint). + + * Update to Unicode 12.1 width table. + (merge 5817f9caa3 bb/unicode-12.1-reiwa later to maint). + + * The command line to invoke a "git cat-file" command from inside + "git p4" was not properly quoted to protect a caret and running a + broken command on Windows, which has been corrected. + (merge c3f2358de3 mm/p4-unshelve-windows-fix later to maint). + + * "git request-pull" learned to warn when the ref we ask them to pull + from in the local repository and in the published repository are + different. + (merge 0454220d66 pb/request-pull-verify-remote-ref later to maint). + + * When creating a partial clone, the object filtering criteria is + recorded for the origin of the clone, but this incorrectly used a + hardcoded name "origin" to name that remote; it has been corrected + to honor the "--origin <name>" option. + (merge 1c4a9f9114 xl/record-partial-clone-origin later to maint). + + * "git fetch" into a lazy clone forgot to fetch base objects that are + necessary to complete delta in a thin packfile, which has been + corrected. + (merge 810e19322d jt/partial-clone-missing-ref-delta-base later to maint). + + * The filter_data used in the list-objects-filter (which manages a + lazily sparse clone repository) did not use the dynamic array API + correctly---'nr' is supposed to point at one past the last element + of the array in use. This has been corrected. + (merge 7140600e2e md/list-objects-filter-memfix later to maint). + + * The description about slashes in gitignore patterns (used to + indicate things like "anchored to this level only" and "only + matches directories") has been revamped. + (merge 1a58bad014 an/ignore-doc-update later to maint). + + * The URL decoding code has been updated to avoid going past the end + of the string while parsing %-<hex>-<hex> sequence. + (merge d37dc239a4 md/url-parse-harden later to maint). + + * The list of for-each like macros used by clang-format has been + updated. + (merge fc7e03aace mo/clang-format-for-each-update later to maint). + + * "git branch --list" learned to show branches that are checked out + in other worktrees connected to the same repository prefixed with + '+', similar to the way the currently checked out branch is shown + with '*' in front. + (merge 6e9381469e nb/branch-show-other-worktrees-head later to maint). + + * Code restructuring during 2.20 period broke fetching tags via + "import" based transports. + (merge f80d922355 fc/fetch-with-import-fix later to maint). + + * The commit-graph file is now part of the "files that the runtime + may keep open file descriptors on, all of which would need to be + closed when done with the object store", and the file descriptor to + an existing commit-graph file now is closed before "gc" finalizes a + new instance to replace it. + (merge 2d511cfc0b ds/close-object-store later to maint). + + * "git checkout -p" needs to selectively apply a patch in reverse, + which did not work well. + (merge 2bd69b9024 pw/add-p-recount later to maint). + + * Code clean-up to avoid signed integer wraparounds during binary search. + (merge 568a05c5ec rs/avoid-overflow-in-midpoint-computation later to maint). + + * "git interpret-trailers" always treated '#' as the comment + character, regardless of core.commentChar setting, which has been + corrected. + (merge 29c83fc23f jk/trailers-use-config later to maint). + + * "git stash show 23" used to work, but no more after getting + rewritten in C; this regression has been corrected. + (merge 63b50c8ffe tg/stash-ref-by-index-fix later to maint). + + * "git rebase --abort" used to leave refs/rewritten/ when concluding + "git rebase -r", which has been corrected. + (merge d559f502c5 pw/rebase-abort-clean-rewritten later to maint). + + * An incorrect list of options was cached after command line + completion failed (e.g. trying to complete a command that requires + a repository outside one), which has been corrected. + (merge 69702523af nd/completion-no-cache-failure later to maint). + + * The code to parse scaled numbers out of configuration files has + been made more robust and also easier to follow. + (merge 39c575c969 rs/config-unit-parsing later to maint). + + * The codepath to compute delta islands used to spew progress output + without giving the callers any way to squelch it, which has been + fixed. + (merge bdbdf42f8a jk/delta-islands-progress-fix later to maint). + + * Protocol capabilities that go over wire should never be translated, + but it was incorrectly marked for translation, which has been + corrected. The output of protocol capabilities for debugging has + been tweaked a bit. + + * Use "Erase in Line" CSI sequence that is already used in the editor + support to clear cruft in the progress output. + (merge 5b12e3123b sg/rebase-progress later to maint). + + * "git submodule foreach" did not protect command line options passed + to the command to be run in each submodule correctly, when the + "--recursive" option was in use. + (merge 30db18b148 ms/submodule-foreach-fix later to maint). + + * The configuration variable rebase.rescheduleFailedExec should be + effective only while running an interactive rebase and should not + affect anything when running an non-interactive one, which was not + the case. This has been corrected. + (merge 906b63942a js/rebase-reschedule-applies-only-to-interactive later to maint). + + * The "git clone" documentation refers to command line options in its + description in the short form; they have been replaced with long + forms to make them more recognisable. + (merge bfc8c84ed5 qn/clone-doc-use-long-form later to maint). + + * Generation of pack bitmaps are now disabled when .keep files exist, + as these are mutually exclusive features. + (merge 7328482253 ew/repack-with-bitmaps-by-default later to maint). + + * Other code cleanup, docfix, build fix, etc. + (merge f547101b26 es/git-debugger-doc later to maint). + (merge 7877ac3d7b js/bisect-helper-check-get-oid-return-value later to maint). + (merge 0108f47eb3 sw/git-p4-unshelve-branched-files later to maint). + (merge 9df8f734fd cm/send-email-document-req-modules later to maint). + (merge afc3bf6eb1 ab/hash-object-doc later to maint). + (merge 1fde99cfc7 po/doc-branch later to maint). + (merge 459842e1c2 dl/config-alias-doc later to maint). + (merge 5d137fc2c7 cb/fsmonitor-intfix later to maint). + (merge 921d49be86 rs/copy-array later to maint). + (merge cc8d872e69 js/t3404-typofix later to maint). + (merge 729a9b558b cb/mkstemps-uint-type-fix later to maint). + (merge 9dae4fe79f js/gcc-8-and-9 later to maint). + (merge ed33bd8f30 js/t0001-case-insensitive later to maint). + (merge dfa880e336 jw/gitweb-sample-update later to maint). + (merge e532a90a9f sg/t5551-fetch-smart-error-is-translated later to maint). + (merge 8d45ad8c29 jt/t5551-test-chunked later to maint). + (merge 1a64e07d23 sg/git-C-empty-doc later to maint). + (merge 37a2e35395 sg/ci-brew-gcc-workaround later to maint). + (merge 24df0d49c4 js/trace2-signo-typofix later to maint). + (merge fbec05c210 cc/test-oidmap later to maint). diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt index dc41957..5d122db 100644 --- a/Documentation/blame-options.txt +++ b/Documentation/blame-options.txt @@ -110,5 +110,24 @@ commit. And the default value is 40. If there are more than one `-C` options given, the <num> argument of the last `-C` will take effect. +--ignore-rev <rev>:: + Ignore changes made by the revision when assigning blame, as if the + change never happened. Lines that were changed or added by an ignored + commit will be blamed on the previous commit that changed that line or + nearby lines. This option may be specified multiple times to ignore + more than one revision. If the `blame.markIgnoredLines` config option + is set, then lines that were changed by an ignored commit and attributed to + another commit will be marked with a `?` in the blame output. If the + `blame.markUnblamableLines` config option is set, then those lines touched + by an ignored commit that we could not attribute to another revision are + marked with a '*'. + +--ignore-revs-file <file>:: + Ignore revisions listed in `file`, which must be in the same format as an + `fsck.skipList`. This option may be repeated, and these files will be + processed after any files specified with the `blame.ignoreRevsFile` config + option. An empty file name, `""`, will clear the list of revs from + previously processed files. + -h:: Show help message. diff --git a/Documentation/config.txt b/Documentation/config.txt index 7e2a6f6..e3f5bc3 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -144,6 +144,20 @@ refer to linkgit:gitignore[5] for details. For convenience: This is the same as `gitdir` except that matching is done case-insensitively (e.g. on case-insensitive file sytems) +`onbranch`:: + The data that follows the keyword `onbranch:` is taken to be a + pattern with standard globbing wildcards and two additional + ones, `**/` and `/**`, that can match multiple path components. + If we are in a worktree where the name of the branch that is + currently checked out matches the pattern, the include condition + is met. ++ +If the pattern ends with `/`, `**` will be automatically added. For +example, the pattern `foo/` becomes `foo/**`. In other words, it matches +all branches that begin with `foo/`. This is useful if your branches are +organized hierarchically and you would like to apply a configuration to +all the branches in that hierarchy. + A few more notes on matching via `gitdir` and `gitdir/i`: * Symlinks in `$GIT_DIR` are not resolved before matching. @@ -206,6 +220,11 @@ Example [includeIf "gitdir:/path/to/group/"] path = foo.inc + ; include only if we are in a worktree where foo-branch is + ; currently checked out + [includeIf "onbranch:foo-branch"] + path = foo.inc + Values ~~~~~~ diff --git a/Documentation/config/advice.txt b/Documentation/config/advice.txt index ec4f6ae..6aaa360 100644 --- a/Documentation/config/advice.txt +++ b/Documentation/config/advice.txt @@ -4,6 +4,10 @@ advice.*:: can tell Git that you do not need help by setting these to 'false': + -- + fetchShowForcedUpdates:: + Advice shown when linkgit:git-fetch[1] takes a long time + to calculate forced updates after ref updates, or to warn + that the check is disabled. pushUpdateRejected:: Set this variable to 'false' if you want to disable 'pushNonFFCurrent', @@ -37,12 +41,19 @@ advice.*:: we can still suggest that the user push to either refs/heads/* or refs/tags/* based on the type of the source object. + statusAheadBehind:: + Shown when linkgit:git-status[1] computes the ahead/behind + counts for a local ref compared to its remote tracking ref, + and that calculation takes longer than expected. Will not + appear if `status.aheadBehind` is false or the option + `--no-ahead-behind` is given. statusHints:: Show directions on how to proceed from the current state in the output of linkgit:git-status[1], in the template shown when writing commit messages in linkgit:git-commit[1], and in the help message shown - by linkgit:git-checkout[1] when switching branch. + by linkgit:git-switch[1] or + linkgit:git-checkout[1] when switching branch. statusUoption:: Advise to consider using the `-u` option to linkgit:git-status[1] when the command takes more than 2 seconds to enumerate untracked @@ -57,17 +68,21 @@ advice.*:: resolveConflict:: Advice shown by various commands when conflicts prevent the operation from being performed. + sequencerInUse:: + Advice shown when a sequencer command is already in progress. implicitIdentity:: Advice on how to set your identity configuration when your information is guessed from the system username and domain name. detachedHead:: - Advice shown when you used linkgit:git-checkout[1] to - move to the detach HEAD state, to instruct how to create - a local branch after the fact. + Advice shown when you used + linkgit:git-switch[1] or linkgit:git-checkout[1] + to move to the detach HEAD state, to instruct how to + create a local branch after the fact. checkoutAmbiguousRemoteBranchName:: Advice shown when the argument to - linkgit:git-checkout[1] ambiguously resolves to a + linkgit:git-checkout[1] and linkgit:git-switch[1] + ambiguously resolves to a remote tracking branch on more than one remote in situations where an unambiguous argument would have otherwise caused a remote-tracking branch to be diff --git a/Documentation/config/alias.txt b/Documentation/config/alias.txt index 0b14178..f1ca739 100644 --- a/Documentation/config/alias.txt +++ b/Documentation/config/alias.txt @@ -1,18 +1,28 @@ alias.*:: Command aliases for the linkgit:git[1] command wrapper - e.g. - after defining "alias.last = cat-file commit HEAD", the invocation - "git last" is equivalent to "git cat-file commit HEAD". To avoid + after defining `alias.last = cat-file commit HEAD`, the invocation + `git last` is equivalent to `git cat-file commit HEAD`. To avoid confusion and troubles with script usage, aliases that hide existing Git commands are ignored. Arguments are split by spaces, the usual shell quoting and escaping is supported. A quote pair or a backslash can be used to quote them. + +Note that the first word of an alias does not necessarily have to be a +command. It can be a command-line option that will be passed into the +invocation of `git`. In particular, this is useful when used with `-c` +to pass in one-time configurations or `-p` to force pagination. For example, +`loud-rebase = -c commit.verbose=true rebase` can be defined such that +running `git loud-rebase` would be equivalent to +`git -c commit.verbose=true rebase`. Also, `ps = -p status` would be a +helpful alias since `git ps` would paginate the output of `git status` +where the original command does not. ++ If the alias expansion is prefixed with an exclamation point, it will be treated as a shell command. For example, defining -"alias.new = !gitk --all --not ORIG_HEAD", the invocation -"git new" is equivalent to running the shell command -"gitk --all --not ORIG_HEAD". Note that shell commands will be +`alias.new = !gitk --all --not ORIG_HEAD`, the invocation +`git new` is equivalent to running the shell command +`gitk --all --not ORIG_HEAD`. Note that shell commands will be executed from the top-level directory of a repository, which may not necessarily be the current directory. -`GIT_PREFIX` is set as returned by running 'git rev-parse --show-prefix' +`GIT_PREFIX` is set as returned by running `git rev-parse --show-prefix` from the original current directory. See linkgit:git-rev-parse[1]. diff --git a/Documentation/config/blame.txt b/Documentation/config/blame.txt index 67b5c1d..9468e85 100644 --- a/Documentation/config/blame.txt +++ b/Documentation/config/blame.txt @@ -19,3 +19,19 @@ blame.showEmail:: blame.showRoot:: Do not treat root commits as boundaries in linkgit:git-blame[1]. This option defaults to false. + +blame.ignoreRevsFile:: + Ignore revisions listed in the file, one unabbreviated object name per + line, in linkgit:git-blame[1]. Whitespace and comments beginning with + `#` are ignored. This option may be repeated multiple times. Empty + file names will reset the list of ignored revisions. This option will + be handled before the command line option `--ignore-revs-file`. + +blame.markUnblamables:: + Mark lines that were changed by an ignored revision that we could not + attribute to another commit with a '*' in the output of + linkgit:git-blame[1]. + +blame.markIgnoredLines:: + Mark lines that were changed by an ignored revision that we attributed to + another commit with a '?' in the output of linkgit:git-blame[1]. diff --git a/Documentation/config/branch.txt b/Documentation/config/branch.txt index 8f4b3fa..a592d52 100644 --- a/Documentation/config/branch.txt +++ b/Documentation/config/branch.txt @@ -1,5 +1,5 @@ branch.autoSetupMerge:: - Tells 'git branch' and 'git checkout' to set up new branches + Tells 'git branch', 'git switch' and 'git checkout' to set up new branches so that linkgit:git-pull[1] will appropriately merge from the starting point branch. Note that even if this option is not set, this behavior can be chosen per-branch using the `--track` @@ -11,7 +11,7 @@ branch.autoSetupMerge:: branch. This option defaults to true. branch.autoSetupRebase:: - When a new branch is created with 'git branch' or 'git checkout' + When a new branch is created with 'git branch', 'git switch' or 'git checkout' that tracks another branch, this variable tells Git to set up pull to rebase instead of merge (see "branch.<name>.rebase"). When `never`, rebase is never automatically set to true. diff --git a/Documentation/config/checkout.txt b/Documentation/config/checkout.txt index c4118fa..6b64681 100644 --- a/Documentation/config/checkout.txt +++ b/Documentation/config/checkout.txt @@ -1,5 +1,6 @@ checkout.defaultRemote:: - When you run 'git checkout <something>' and only have one + When you run 'git checkout <something>' + or 'git switch <something>' and only have one remote, it may implicitly fall back on checking out and tracking e.g. 'origin/<something>'. This stops working as soon as you have more than one remote with a '<something>' @@ -8,16 +9,10 @@ checkout.defaultRemote:: disambiguation. The typical use-case is to set this to `origin`. + -Currently this is used by linkgit:git-checkout[1] when 'git checkout -<something>' will checkout the '<something>' branch on another remote, +Currently this is used by linkgit:git-switch[1] and +linkgit:git-checkout[1] when 'git checkout <something>' +or 'git switch <something>' +will checkout the '<something>' branch on another remote, and by linkgit:git-worktree[1] when 'git worktree add' refers to a remote branch. This setting might be used for other checkout-like commands or functionality in the future. - -checkout.optimizeNewBranch:: - Optimizes the performance of "git checkout -b <new_branch>" when - using sparse-checkout. When set to true, git will not update the - repo based on the current sparse-checkout settings. This means it - will not update the skip-worktree bit in the index nor add/remove - files in the working directory to reflect the current sparse checkout - settings nor will it show the local changes. diff --git a/Documentation/config/diff.txt b/Documentation/config/diff.txt index 2c4c9ba..5afb5a2 100644 --- a/Documentation/config/diff.txt +++ b/Documentation/config/diff.txt @@ -78,7 +78,8 @@ diff.external:: diff.ignoreSubmodules:: Sets the default value of --ignore-submodules. Note that this affects only 'git diff' Porcelain, and not lower level 'diff' - commands such as 'git diff-files'. 'git checkout' also honors + commands such as 'git diff-files'. 'git checkout' + and 'git switch' also honor this setting when reporting uncommitted changes. Setting it to 'all' disables the submodule summary normally shown by 'git commit' and 'git status' when `status.submoduleSummary` is set unless it is diff --git a/Documentation/config/fetch.txt b/Documentation/config/fetch.txt index cbfad6c..ba890b5 100644 --- a/Documentation/config/fetch.txt +++ b/Documentation/config/fetch.txt @@ -63,3 +63,8 @@ fetch.negotiationAlgorithm:: Unknown values will cause 'git fetch' to error out. + See also the `--negotiation-tip` option for linkgit:git-fetch[1]. + +fetch.showForcedUpdates:: + Set to false to enable `--no-show-forced-updates` in + linkgit:git-fetch[1] and linkgit:git-pull[1] commands. + Defaults to true. diff --git a/Documentation/config/format.txt b/Documentation/config/format.txt index dc77941..414a5a8 100644 --- a/Documentation/config/format.txt +++ b/Documentation/config/format.txt @@ -85,3 +85,18 @@ format.outputDirectory:: format.useAutoBase:: A boolean value which lets you enable the `--base=auto` option of format-patch by default. + +format.notes:: + Provides the default value for the `--notes` option to + format-patch. Accepts a boolean value, or a ref which specifies + where to get notes. If false, format-patch defaults to + `--no-notes`. If true, format-patch defaults to `--notes`. If + set to a non-boolean value, format-patch defaults to + `--notes=<ref>`, where `ref` is the non-boolean value. Defaults + to false. ++ +If one wishes to use the ref `ref/notes/true`, please use that literal +instead. ++ +This configuration can be specified multiple times in order to allow +multiple notes refs to be included. diff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt index f999f8e..cce2c89 100644 --- a/Documentation/config/gpg.txt +++ b/Documentation/config/gpg.txt @@ -2,7 +2,7 @@ gpg.program:: Use this custom program instead of "`gpg`" found on `$PATH` when making or verifying a PGP signature. The program must support the same command-line interface as GPG, namely, to verify a detached - signature, "`gpg --verify $file - <$signature`" is run, and the + signature, "`gpg --verify $signature - <$file`" is run, and the program is expected to signal a good signature by exiting with code 0, and to generate an ASCII-armored detached signature, the standard input of "`gpg -bsau $key`" is fed with the contents to be diff --git a/Documentation/config/interactive.txt b/Documentation/config/interactive.txt index ad846dd..a2d3c7e 100644 --- a/Documentation/config/interactive.txt +++ b/Documentation/config/interactive.txt @@ -2,7 +2,8 @@ interactive.singleKey:: In interactive commands, allow the user to provide one-letter input with a single key (i.e., without hitting enter). Currently this is used by the `--patch` mode of - linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1], + linkgit:git-add[1], linkgit:git-checkout[1], + linkgit:git-restore[1], linkgit:git-commit[1], linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this setting is silently ignored if portable keystroke input is not available; requires the Perl module Term::ReadKey. diff --git a/Documentation/config/status.txt b/Documentation/config/status.txt index ed72fa7..0fc704a 100644 --- a/Documentation/config/status.txt +++ b/Documentation/config/status.txt @@ -12,6 +12,11 @@ status.branch:: Set to true to enable --branch by default in linkgit:git-status[1]. The option --no-branch takes precedence over this variable. +status.aheadBehind:: + Set to true to enable `--ahead-behind` and false to enable + `--no-ahead-behind` by default in linkgit:git-status[1] for + non-porcelain status formats. Defaults to true. + status.displayCommentPrefix:: If set to true, linkgit:git-status[1] will insert a comment prefix before each output line (starting with diff --git a/Documentation/config/tag.txt b/Documentation/config/tag.txt index 663663b..ef5adb3 100644 --- a/Documentation/config/tag.txt +++ b/Documentation/config/tag.txt @@ -8,6 +8,14 @@ tag.sort:: linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the value of this variable will be used as the default. +tag.gpgSign:: + A boolean to specify whether all tags should be GPG signed. + Use of this option when running in an automated script can + result in a large number of tags being signed. It is therefore + convenient to use an agent to avoid typing your gpg passphrase + several times. Note that this option doesn't affects tag signing + behavior enabled by "-u <keyid>" or "--local-user=<keyid>" options. + tar.umask:: This variable can be used to restrict the permission bits of tar archive entries. The default is 0002, which turns off the diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 91c4775..3c9b4f9 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -88,6 +88,10 @@ ifndef::git-pull[] Allow several <repository> and <group> arguments to be specified. No <refspec>s may be specified. +--[no-]auto-gc:: + Run `git gc --auto` at the end to perform garbage collection + if needed. This is enabled by default. + -p:: --prune:: Before fetching, remove any remote-tracking references that no @@ -221,6 +225,19 @@ endif::git-pull[] When multiple `--server-option=<option>` are given, they are all sent to the other side in the order listed on the command line. +--show-forced-updates:: + By default, git checks if a branch is force-updated during + fetch. This can be disabled through fetch.showForcedUpdates, but + the --show-forced-updates option guarantees this check occurs. + See linkgit:git-config[1]. + +--no-show-forced-updates:: + By default, git checks if a branch is force-updated during + fetch. Pass --no-show-forced-updates or set fetch.showForcedUpdates + to false to skip this check for performance reasons. If used during + 'git-pull' the --ff-only option will still check for forced updates + before attempting a fast-forward update. See linkgit:git-config[1]. + -4:: --ipv4:: Use IPv4 addresses only, ignoring IPv6 addresses. diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index 16323eb..7e81541 100644 --- a/Documentation/git-blame.txt +++ b/Documentation/git-blame.txt @@ -10,6 +10,7 @@ SYNOPSIS [verse] 'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental] [-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>] + [--ignore-rev <rev>] [--ignore-revs-file <file>] [--progress] [--abbrev=<n>] [<rev> | --contents <file> | --reverse <rev>..<rev>] [--] <file> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index 6ebd512..135206f 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -8,12 +8,14 @@ git-branch - List, create, or delete branches SYNOPSIS -------- [verse] -'git branch' [--color[=<when>] | --no-color] [-r | -a] - [--list] [--show-current] [-v [--abbrev=<length> | --no-abbrev]] +'git branch' [--color[=<when>] | --no-color] [--show-current] + [-v [--abbrev=<length> | --no-abbrev]] [--column[=<options>] | --no-column] [--sort=<key>] [(--merged | --no-merged) [<commit>]] [--contains [<commit]] [--no-contains [<commit>]] - [--points-at <object>] [--format=<format>] [<pattern>...] + [--points-at <object>] [--format=<format>] + [(-r | --remotes) | (-a | --all)] + [--list] [<pattern>...] 'git branch' [--track | --no-track] [-f] <branchname> [<start-point>] 'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>] 'git branch' --unset-upstream [<branchname>] @@ -26,13 +28,19 @@ DESCRIPTION ----------- If `--list` is given, or if there are no non-option arguments, existing -branches are listed; the current branch will be highlighted with an -asterisk. Option `-r` causes the remote-tracking branches to be listed, -and option `-a` shows both local and remote branches. If a `<pattern>` +branches are listed; the current branch will be highlighted in green and +marked with an asterisk. Any branches checked out in linked worktrees will +be highlighted in cyan and marked with a plus sign. Option `-r` causes the +remote-tracking branches to be listed, +and option `-a` shows both local and remote branches. + +If a `<pattern>` is given, it is used as a shell wildcard to restrict the output to matching branches. If multiple patterns are given, a branch is shown if -it matches any of the patterns. Note that when providing a -`<pattern>`, you must use `--list`; otherwise the command is interpreted +it matches any of the patterns. + +Note that when providing a +`<pattern>`, you must use `--list`; otherwise the command may be interpreted as branch creation. With `--contains`, shows only the branches that contain the named commit @@ -52,7 +60,7 @@ can leave out at most one of `A` and `B`, in which case it defaults to `HEAD`. Note that this will create the new branch, but it will not switch the -working tree to it; use "git checkout <newbranch>" to switch to the +working tree to it; use "git switch <newbranch>" to switch to the new branch. When a local branch is started off a remote-tracking branch, Git sets up the @@ -153,10 +161,12 @@ This option is only applicable in non-verbose mode. -r:: --remotes:: List or delete (if used with -d) the remote-tracking branches. + Combine with `--list` to match the optional pattern(s). -a:: --all:: List both remote-tracking branches and local branches. + Combine with `--list` to match optional pattern(s). -l:: --list:: @@ -174,8 +184,10 @@ This option is only applicable in non-verbose mode. When in list mode, show sha1 and commit subject line for each head, along with relationship to upstream branch (if any). If given twice, print - the name of the upstream branch, as well (see also `git remote - show <remote>`). + the path of the linked worktree (if any) and the name of the upstream + branch, as well (see also `git remote show <remote>`). Note that the + current worktree's HEAD will not have its path printed (it will always + be your current directory). -q:: --quiet:: @@ -202,7 +214,7 @@ This option is only applicable in non-verbose mode. + This behavior is the default when the start point is a remote-tracking branch. Set the branch.autoSetupMerge configuration variable to `false` if you -want `git checkout` and `git branch` to always behave as if `--no-track` +want `git switch`, `git checkout` and `git branch` to always behave as if `--no-track` were given. Set it to `always` if you want this behavior when the start-point is either a local or remote-tracking branch. @@ -301,7 +313,7 @@ Start development from a known tag:: $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 $ cd my2.6 $ git branch my2.6.14 v2.6.14 <1> -$ git checkout my2.6.14 +$ git switch my2.6.14 ------------ + <1> This step and the next one could be combined into a single step with @@ -322,13 +334,25 @@ $ git branch -D test <2> <2> Delete the "test" branch even if the "master" branch (or whichever branch is currently checked out) does not have all commits from the test branch. +Listing branches from a specific remote:: ++ +------------ +$ git branch -r -l '<remote>/<pattern>' <1> +$ git for-each-ref 'refs/remotes/<remote>/<pattern>' <2> +------------ ++ +<1> Using `-a` would conflate <remote> with any local branches you happen to + have been prefixed with the same <remote> pattern. +<2> `for-each-ref` can take a wide range of options. See linkgit:git-for-each-ref[1] + +Patterns will normally need quoting. NOTES ----- -If you are creating a branch that you want to checkout immediately, it is -easier to use the git checkout command with its `-b` option to create -a branch and check it out with a single command. +If you are creating a branch that you want to switch to immediately, +it is easier to use the "git switch" command with its `-c` option to +do the same thing with a single command. The options `--contains`, `--no-contains`, `--merged` and `--no-merged` serve four related but different purposes: diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt index d9de992..ee6a414 100644 --- a/Documentation/git-check-ref-format.txt +++ b/Documentation/git-check-ref-format.txt @@ -88,7 +88,8 @@ but it is explicitly forbidden at the beginning of a branch name). When run with `--branch` option in a repository, the input is first expanded for the ``previous checkout syntax'' `@{-n}`. For example, `@{-1}` is a way to refer the last thing that -was checked out using "git checkout" operation. This option should be +was checked out using "git switch" or "git checkout" operation. +This option should be used by porcelains to accept this syntax anywhere a branch name is expected, so they can act as if you typed the branch name. As an exception note that, the ``previous checkout operation'' might result diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 964f912..cf3cac0 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -23,31 +23,22 @@ or the specified tree. If no paths are given, 'git checkout' will also update `HEAD` to set the specified branch as the current branch. -'git checkout' <branch>:: - To prepare for working on <branch>, switch to it by updating +'git checkout' [<branch>]:: + To prepare for working on `<branch>`, switch to it by updating the index and the files in the working tree, and by pointing - HEAD at the branch. Local modifications to the files in the + `HEAD` at the branch. Local modifications to the files in the working tree are kept, so that they can be committed to the - <branch>. + `<branch>`. + -If <branch> is not found but there does exist a tracking branch in -exactly one remote (call it <remote>) with a matching name, treat as -equivalent to +If `<branch>` is not found but there does exist a tracking branch in +exactly one remote (call it `<remote>`) with a matching name and +`--no-guess` is not specified, treat as equivalent to + ------------ $ git checkout -b <branch> --track <remote>/<branch> ------------ + -If the branch exists in multiple remotes and one of them is named by -the `checkout.defaultRemote` configuration variable, we'll use that -one for the purposes of disambiguation, even if the `<branch>` isn't -unique across all remotes. Set it to -e.g. `checkout.defaultRemote=origin` to always checkout remote -branches from there if `<branch>` is ambiguous but exists on the -'origin' remote. See also `checkout.defaultRemote` in -linkgit:git-config[1]. -+ -You could omit <branch>, in which case the command degenerates to +You could omit `<branch>`, in which case the command degenerates to "check out the current branch", which is a glorified no-op with rather expensive side-effects to show only the tracking information, if exists, for the current branch. @@ -61,7 +52,7 @@ if exists, for the current branch. `--track` without `-b` implies branch creation; see the description of `--track` below. + -If `-B` is given, <new_branch> is created if it doesn't exist; otherwise, it +If `-B` is given, `<new_branch>` is created if it doesn't exist; otherwise, it is reset. This is the transactional equivalent of + ------------ @@ -75,25 +66,25 @@ successful. 'git checkout' --detach [<branch>]:: 'git checkout' [--detach] <commit>:: - Prepare to work on top of <commit>, by detaching HEAD at it + Prepare to work on top of `<commit>`, by detaching `HEAD` at it (see "DETACHED HEAD" section), and updating the index and the files in the working tree. Local modifications to the files in the working tree are kept, so that the resulting working tree will be the state recorded in the commit plus the local modifications. + -When the <commit> argument is a branch name, the `--detach` option can -be used to detach HEAD at the tip of the branch (`git checkout -<branch>` would check out that branch without detaching HEAD). +When the `<commit>` argument is a branch name, the `--detach` option can +be used to detach `HEAD` at the tip of the branch (`git checkout +<branch>` would check out that branch without detaching `HEAD`). + -Omitting <branch> detaches HEAD at the tip of the current branch. +Omitting `<branch>` detaches `HEAD` at the tip of the current branch. 'git checkout' [<tree-ish>] [--] <pathspec>...:: Overwrite paths in the working tree by replacing with the - contents in the index or in the <tree-ish> (most often a - commit). When a <tree-ish> is given, the paths that - match the <pathspec> are updated both in the index and in + contents in the index or in the `<tree-ish>` (most often a + commit). When a `<tree-ish>` is given, the paths that + match the `<pathspec>` are updated both in the index and in the working tree. + The index may contain unmerged entries because of a previous failed merge. @@ -118,7 +109,8 @@ OPTIONS --quiet:: Quiet, suppress feedback messages. ---[no-]progress:: +--progress:: +--no-progress:: Progress status is reported on the standard error stream by default when it is attached to a terminal, unless `--quiet` is specified. This flag enables progress reporting even if not @@ -127,7 +119,7 @@ OPTIONS -f:: --force:: When switching branches, proceed even if the index or the - working tree differs from HEAD. This is used to throw away + working tree differs from `HEAD`. This is used to throw away local changes. + When checking out paths from the index, do not fail upon unmerged @@ -154,12 +146,12 @@ on your side branch as `theirs` (i.e. "one contributor's work on top of it"). -b <new_branch>:: - Create a new branch named <new_branch> and start it at - <start_point>; see linkgit:git-branch[1] for details. + Create a new branch named `<new_branch>` and start it at + `<start_point>`; see linkgit:git-branch[1] for details. -B <new_branch>:: - Creates the branch <new_branch> and start it at <start_point>; - if it already exists, then reset it to <start_point>. This is + Creates the branch `<new_branch>` and start it at `<start_point>`; + if it already exists, then reset it to `<start_point>`. This is equivalent to running "git branch" with "-f"; see linkgit:git-branch[1] for details. @@ -172,15 +164,36 @@ If no `-b` option is given, the name of the new branch will be derived from the remote-tracking branch, by looking at the local part of the refspec configured for the corresponding remote, and then stripping the initial part up to the "*". -This would tell us to use "hack" as the local branch when branching -off of "origin/hack" (or "remotes/origin/hack", or even -"refs/remotes/origin/hack"). If the given name has no slash, or the above +This would tell us to use `hack` as the local branch when branching +off of `origin/hack` (or `remotes/origin/hack`, or even +`refs/remotes/origin/hack`). If the given name has no slash, or the above guessing results in an empty name, the guessing is aborted. You can explicitly give a name with `-b` in such a case. --no-track:: Do not set up "upstream" configuration, even if the - branch.autoSetupMerge configuration variable is true. + `branch.autoSetupMerge` configuration variable is true. + +--guess:: +--no-guess:: + If `<branch>` is not found but there does exist a tracking + branch in exactly one remote (call it `<remote>`) with a + matching name, treat as equivalent to ++ +------------ +$ git checkout -b <branch> --track <remote>/<branch> +------------ ++ +If the branch exists in multiple remotes and one of them is named by +the `checkout.defaultRemote` configuration variable, we'll use that +one for the purposes of disambiguation, even if the `<branch>` isn't +unique across all remotes. Set it to +e.g. `checkout.defaultRemote=origin` to always checkout remote +branches from there if `<branch>` is ambiguous but exists on the +'origin' remote. See also `checkout.defaultRemote` in +linkgit:git-config[1]. ++ +Use `--no-guess` to disable this. -l:: Create the new branch's reflog; see linkgit:git-branch[1] for @@ -189,21 +202,21 @@ explicitly give a name with `-b` in such a case. --detach:: Rather than checking out a branch to work on it, check out a commit for inspection and discardable experiments. - This is the default behavior of "git checkout <commit>" when - <commit> is not a branch name. See the "DETACHED HEAD" section + This is the default behavior of `git checkout <commit>` when + `<commit>` is not a branch name. See the "DETACHED HEAD" section below for details. --orphan <new_branch>:: - Create a new 'orphan' branch, named <new_branch>, started from - <start_point> and switch to it. The first commit made on this + Create a new 'orphan' branch, named `<new_branch>`, started from + `<start_point>` and switch to it. The first commit made on this new branch will have no parents and it will be the root of a new history totally disconnected from all the other branches and commits. + The index and the working tree are adjusted as if you had previously run -"git checkout <start_point>". This allows you to start a new history -that records a set of paths similar to <start_point> by easily running -"git commit -a" to make the root commit. +`git checkout <start_point>`. This allows you to start a new history +that records a set of paths similar to `<start_point>` by easily running +`git commit -a` to make the root commit. + This can be useful when you want to publish the tree from a commit without exposing its full history. You might want to do this to publish @@ -212,17 +225,17 @@ whose full history contains proprietary or otherwise encumbered bits of code. + If you want to start a disconnected history that records a set of paths -that is totally different from the one of <start_point>, then you should +that is totally different from the one of `<start_point>`, then you should clear the index and the working tree right after creating the orphan -branch by running "git rm -rf ." from the top level of the working tree. +branch by running `git rm -rf .` from the top level of the working tree. Afterwards you will be ready to prepare your new files, repopulating the working tree, by copying them from elsewhere, extracting a tarball, etc. --ignore-skip-worktree-bits:: In sparse checkout mode, `git checkout -- <paths>` would - update only entries matched by <paths> and sparse patterns - in $GIT_DIR/info/sparse-checkout. This option ignores - the sparse patterns and adds back any files in <paths>. + update only entries matched by `<paths>` and sparse patterns + in `$GIT_DIR/info/sparse-checkout`. This option ignores + the sparse patterns and adds back any files in `<paths>`. -m:: --merge:: @@ -246,25 +259,25 @@ the conflicted merge in the specified paths. When switching branches with `--merge`, staged changes may be lost. --conflict=<style>:: - The same as --merge option above, but changes the way the + The same as `--merge` option above, but changes the way the conflicting hunks are presented, overriding the - merge.conflictStyle configuration variable. Possible values are + `merge.conflictStyle` configuration variable. Possible values are "merge" (default) and "diff3" (in addition to what is shown by "merge" style, shows the original contents). -p:: --patch:: Interactively select hunks in the difference between the - <tree-ish> (or the index, if unspecified) and the working + `<tree-ish>` (or the index, if unspecified) and the working tree. The chosen hunks are then applied in reverse to the - working tree (and if a <tree-ish> was specified, the index). + working tree (and if a `<tree-ish>` was specified, the index). + This means that you can use `git checkout -p` to selectively discard edits from your current working tree. See the ``Interactive Mode'' section of linkgit:git-add[1] to learn how to operate the `--patch` mode. + Note that this option uses the no overlay mode by default (see also -`--[no-]overlay`), and currently doesn't support overlay mode. +`--overlay`), and currently doesn't support overlay mode. --ignore-other-worktrees:: `git checkout` refuses when the wanted ref is already checked @@ -272,38 +285,42 @@ Note that this option uses the no overlay mode by default (see also out anyway. In other words, the ref can be held by more than one worktree. ---[no-]recurse-submodules:: - Using --recurse-submodules will update the content of all initialized +--overwrite-ignore:: +--no-overwrite-ignore:: + Silently overwrite ignored files when switching branches. This + is the default behavior. Use `--no-overwrite-ignore` to abort + the operation when the new branch contains ignored files. + +--recurse-submodules:: +--no-recurse-submodules:: + Using `--recurse-submodules` will update the content of all initialized submodules according to the commit recorded in the superproject. If local modifications in a submodule would be overwritten the checkout - will fail unless `-f` is used. If nothing (or --no-recurse-submodules) + will fail unless `-f` is used. If nothing (or `--no-recurse-submodules`) is used, the work trees of submodules will not be updated. - Just like linkgit:git-submodule[1], this will detach the - submodules HEAD. - ---no-guess:: - Do not attempt to create a branch if a remote tracking branch - of the same name exists. + Just like linkgit:git-submodule[1], this will detach `HEAD` of the + submodule. ---[no-]overlay:: +--overlay:: +--no-overlay:: In the default overlay mode, `git checkout` never removes files from the index or the working tree. When specifying `--no-overlay`, files that appear in the index and - working tree, but not in <tree-ish> are removed, to make them - match <tree-ish> exactly. + working tree, but not in `<tree-ish>` are removed, to make them + match `<tree-ish>` exactly. <branch>:: Branch to checkout; if it refers to a branch (i.e., a name that, when prepended with "refs/heads/", is a valid ref), then that branch is checked out. Otherwise, if it refers to a valid - commit, your HEAD becomes "detached" and you are no longer on + commit, your `HEAD` becomes "detached" and you are no longer on any branch (see below for details). + -You can use the `"@{-N}"` syntax to refer to the N-th last +You can use the `@{-N}` syntax to refer to the N-th last branch/commit checked out using "git checkout" operation. You may -also specify `-` which is synonymous to `"@{-1}"`. +also specify `-` which is synonymous to `@{-1}`. + -As a special case, you may use `"A...B"` as a shortcut for the +As a special case, you may use `A...B` as a shortcut for the merge base of `A` and `B` if there is exactly one merge base. You can leave out at most one of `A` and `B`, in which case it defaults to `HEAD`. @@ -312,7 +329,7 @@ leave out at most one of `A` and `B`, in which case it defaults to `HEAD`. <start_point>:: The name of a commit at which to start the new branch; see - linkgit:git-branch[1] for details. Defaults to HEAD. + linkgit:git-branch[1] for details. Defaults to `HEAD`. + As a special case, you may use `"A...B"` as a shortcut for the merge base of `A` and `B` if there is exactly one merge base. You can @@ -326,9 +343,9 @@ leave out at most one of `A` and `B`, in which case it defaults to `HEAD`. DETACHED HEAD ------------- -HEAD normally refers to a named branch (e.g. 'master'). Meanwhile, each +`HEAD` normally refers to a named branch (e.g. `master`). Meanwhile, each branch refers to a specific commit. Let's look at a repo with three -commits, one of them tagged, and with branch 'master' checked out: +commits, one of them tagged, and with branch `master` checked out: ------------ HEAD (refers to branch 'master') @@ -341,10 +358,10 @@ a---b---c branch 'master' (refers to commit 'c') ------------ When a commit is created in this state, the branch is updated to refer to -the new commit. Specifically, 'git commit' creates a new commit 'd', whose -parent is commit 'c', and then updates branch 'master' to refer to new -commit 'd'. HEAD still refers to branch 'master' and so indirectly now refers -to commit 'd': +the new commit. Specifically, 'git commit' creates a new commit `d`, whose +parent is commit `c`, and then updates branch `master` to refer to new +commit `d`. `HEAD` still refers to branch `master` and so indirectly now refers +to commit `d`: ------------ $ edit; git add; git commit @@ -361,7 +378,7 @@ a---b---c---d branch 'master' (refers to commit 'd') It is sometimes useful to be able to checkout a commit that is not at the tip of any named branch, or even to create a new commit that is not referenced by a named branch. Let's look at what happens when we -checkout commit 'b' (here we show two ways this may be done): +checkout commit `b` (here we show two ways this may be done): ------------ $ git checkout v2.0 # or @@ -376,9 +393,9 @@ a---b---c---d branch 'master' (refers to commit 'd') tag 'v2.0' (refers to commit 'b') ------------ -Notice that regardless of which checkout command we use, HEAD now refers -directly to commit 'b'. This is known as being in detached HEAD state. -It means simply that HEAD refers to a specific commit, as opposed to +Notice that regardless of which checkout command we use, `HEAD` now refers +directly to commit `b`. This is known as being in detached `HEAD` state. +It means simply that `HEAD` refers to a specific commit, as opposed to referring to a named branch. Let's see what happens when we create a commit: ------------ @@ -395,7 +412,7 @@ a---b---c---d branch 'master' (refers to commit 'd') tag 'v2.0' (refers to commit 'b') ------------ -There is now a new commit 'e', but it is referenced only by HEAD. We can +There is now a new commit `e`, but it is referenced only by `HEAD`. We can of course add yet another commit in this state: ------------ @@ -413,7 +430,7 @@ a---b---c---d branch 'master' (refers to commit 'd') ------------ In fact, we can perform all the normal Git operations. But, let's look -at what happens when we then checkout master: +at what happens when we then checkout `master`: ------------ $ git checkout master @@ -428,9 +445,9 @@ a---b---c---d branch 'master' (refers to commit 'd') ------------ It is important to realize that at this point nothing refers to commit -'f'. Eventually commit 'f' (and by extension commit 'e') will be deleted +`f`. Eventually commit `f` (and by extension commit `e`) will be deleted by the routine Git garbage collection process, unless we create a reference -before that happens. If we have not yet moved away from commit 'f', +before that happens. If we have not yet moved away from commit `f`, any of these will create a reference to it: ------------ @@ -439,19 +456,19 @@ $ git branch foo <2> $ git tag foo <3> ------------ -<1> creates a new branch 'foo', which refers to commit 'f', and then - updates HEAD to refer to branch 'foo'. In other words, we'll no longer - be in detached HEAD state after this command. +<1> creates a new branch `foo`, which refers to commit `f`, and then + updates `HEAD` to refer to branch `foo`. In other words, we'll no longer + be in detached `HEAD` state after this command. -<2> similarly creates a new branch 'foo', which refers to commit 'f', - but leaves HEAD detached. +<2> similarly creates a new branch `foo`, which refers to commit `f`, + but leaves `HEAD` detached. -<3> creates a new tag 'foo', which refers to commit 'f', - leaving HEAD detached. +<3> creates a new tag `foo`, which refers to commit `f`, + leaving `HEAD` detached. -If we have moved away from commit 'f', then we must first recover its object +If we have moved away from commit `f`, then we must first recover its object name (typically by using git reflog), and then we can create a reference to -it. For example, to see the last two commits to which HEAD referred, we +it. For example, to see the last two commits to which `HEAD` referred, we can use either of these commands: ------------ @@ -462,12 +479,12 @@ $ git log -g -2 HEAD ARGUMENT DISAMBIGUATION ----------------------- -When there is only one argument given and it is not `--` (e.g. "git -checkout abc"), and when the argument is both a valid `<tree-ish>` -(e.g. a branch "abc" exists) and a valid `<pathspec>` (e.g. a file +When there is only one argument given and it is not `--` (e.g. `git +checkout abc`), and when the argument is both a valid `<tree-ish>` +(e.g. a branch `abc` exists) and a valid `<pathspec>` (e.g. a file or a directory whose name is "abc" exists), Git would usually ask you to disambiguate. Because checking out a branch is so common an -operation, however, "git checkout abc" takes "abc" as a `<tree-ish>` +operation, however, `git checkout abc` takes "abc" as a `<tree-ish>` in such a situation. Use `git checkout -- <pathspec>` if you want to checkout these paths out of the index. @@ -475,7 +492,7 @@ EXAMPLES -------- . The following sequence checks out the `master` branch, reverts - the `Makefile` to two revisions back, deletes hello.c by + the `Makefile` to two revisions back, deletes `hello.c` by mistake, and gets it back from the index. + ------------ @@ -487,7 +504,7 @@ $ git checkout hello.c <3> + <1> switch branch <2> take a file out of another commit -<3> restore hello.c from the index +<3> restore `hello.c` from the index + If you want to check out _all_ C source files out of the index, you can say @@ -516,7 +533,7 @@ $ git checkout -- hello.c $ git checkout mytopic ------------ + -However, your "wrong" branch and correct "mytopic" branch may +However, your "wrong" branch and correct `mytopic` branch may differ in files that you have modified locally, in which case the above checkout would fail like this: + @@ -557,6 +574,11 @@ $ edit frotz $ git add frotz ------------ +SEE ALSO +-------- +linkgit:git-switch[1], +linkgit:git-restore[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index 754b16c..83ce51a 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -10,9 +10,7 @@ SYNOPSIS [verse] 'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] [-S[<keyid>]] <commit>... -'git cherry-pick' --continue -'git cherry-pick' --quit -'git cherry-pick' --abort +'git cherry-pick' (--continue | --skip | --abort | --quit) DESCRIPTION ----------- diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt index db876f7..0028ff1 100644 --- a/Documentation/git-clean.txt +++ b/Documentation/git-clean.txt @@ -63,7 +63,7 @@ OPTIONS still use the ignore rules given with `-e` options from the command line. This allows removing all untracked files, including build products. This can be used (possibly in - conjunction with 'git reset') to create a pristine + conjunction with 'git restore' or 'git reset') to create a pristine working directory to test a clean build. -X:: diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index a0f14b5..34011c2 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -15,14 +15,15 @@ SYNOPSIS [--dissociate] [--separate-git-dir <git dir>] [--depth <depth>] [--[no-]single-branch] [--no-tags] [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules] - [--jobs <n>] [--] <repository> [<directory>] + [--[no-]remote-submodules] [--jobs <n>] [--] <repository> + [<directory>] DESCRIPTION ----------- Clones a repository into a newly created directory, creates remote-tracking branches for each branch in the cloned repository -(visible using `git branch -r`), and creates and checks out an +(visible using `git branch --remotes`), and creates and checks out an initial branch that is forked from the cloned repository's currently active branch. @@ -40,8 +41,8 @@ configuration variables. OPTIONS ------- ---local:: -l:: +--local:: When the repository to clone from is on a local machine, this flag bypasses the normal "Git aware" transport mechanism and clones the repository by making a copy of @@ -62,8 +63,8 @@ Git transport instead. directory instead of using hardlinks. This may be desirable if you are trying to make a back-up of your repository. ---shared:: -s:: +--shared:: When the repository to clone is on the local machine, instead of using hard links, automatically setup `.git/objects/info/alternates` to share the objects @@ -80,13 +81,13 @@ which automatically call `git gc --auto`. (See linkgit:git-gc[1].) If these objects are removed and were referenced by the cloned repository, then the cloned repository will become corrupt. + -Note that running `git repack` without the `-l` option in a repository -cloned with `-s` will copy objects from the source repository into a pack -in the cloned repository, removing the disk space savings of `clone -s`. -It is safe, however, to run `git gc`, which uses the `-l` option by +Note that running `git repack` without the `--local` option in a repository +cloned with `--shared` will copy objects from the source repository into a pack +in the cloned repository, removing the disk space savings of `clone --shared`. +It is safe, however, to run `git gc`, which uses the `--local` option by default. + -If you want to break the dependency of a repository cloned with `-s` on +If you want to break the dependency of a repository cloned with `--shared` on its source repository, you can simply run `git repack -a` to copy all objects from the source repository into a pack in the cloned repository. @@ -115,19 +116,19 @@ objects from the source repository into a pack in the cloned repository. same repository, and this option can be used to stop the borrowing. ---quiet:: -q:: +--quiet:: Operate quietly. Progress is not reported to the standard error stream. ---verbose:: -v:: +--verbose:: Run verbosely. Does not affect the reporting of progress status to the standard error stream. --progress:: Progress status is reported on the standard error stream - by default when it is attached to a terminal, unless -q + by default when it is attached to a terminal, unless `--quiet` is specified. This flag forces progress status even if the standard error stream is not directed to a terminal. @@ -139,15 +140,15 @@ objects from the source repository into a pack in the cloned repository. When multiple `--server-option=<option>` are given, they are all sent to the other side in the order listed on the command line. ---no-checkout:: -n:: +--no-checkout:: No checkout of HEAD is performed after the clone is complete. --bare:: Make a 'bare' Git repository. That is, instead of creating `<directory>` and placing the administrative files in `<directory>/.git`, make the `<directory>` - itself the `$GIT_DIR`. This obviously implies the `-n` + itself the `$GIT_DIR`. This obviously implies the `--no-checkout` because there is nowhere to check out the working tree. Also the branch heads at the remote are copied directly to corresponding local branch heads, without mapping @@ -163,13 +164,13 @@ objects from the source repository into a pack in the cloned repository. that all these refs are overwritten by a `git remote update` in the target repository. ---origin <name>:: -o <name>:: +--origin <name>:: Instead of using the remote name `origin` to keep track of the upstream repository, use `<name>`. ---branch <name>:: -b <name>:: +--branch <name>:: Instead of pointing the newly created HEAD to the branch pointed to by the cloned repository's HEAD, point to `<name>` branch instead. In a non-bare repository, this is the branch that will @@ -177,8 +178,8 @@ objects from the source repository into a pack in the cloned repository. `--branch` can also take tags and detaches the HEAD at that commit in the resulting repository. ---upload-pack <upload-pack>:: -u <upload-pack>:: +--upload-pack <upload-pack>:: When given, and the repository to clone from is accessed via ssh, this specifies a non-default path for the command run on the other end. @@ -187,8 +188,8 @@ objects from the source repository into a pack in the cloned repository. Specify the directory from which templates will be used; (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) ---config <key>=<value>:: -c <key>=<value>:: +--config <key>=<value>:: Set a configuration variable in the newly-created repository; this takes effect immediately after the repository is initialized, but before the remote history is fetched or any @@ -260,6 +261,12 @@ or `--mirror` is given) --[no-]shallow-submodules:: All submodules which are cloned will be shallow with a depth of 1. +--[no-]remote-submodules:: + All submodules which are cloned will use the status of the submodule’s + remote-tracking branch to update the submodule, rather than the + superproject’s recorded SHA-1. Equivalent to passing `--remote` to + `git submodule update`. + --separate-git-dir=<git dir>:: Instead of placing the cloned repository where it is supposed to be, place the cloned repository at the specified directory, diff --git a/Documentation/git-commit-graph.txt b/Documentation/git-commit-graph.txt index 624470e..eb5e786 100644 --- a/Documentation/git-commit-graph.txt +++ b/Documentation/git-commit-graph.txt @@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git commit-graph read' [--object-dir <dir>] -'git commit-graph verify' [--object-dir <dir>] +'git commit-graph verify' [--object-dir <dir>] [--shallow] 'git commit-graph write' <options> [--object-dir <dir>] @@ -26,7 +26,7 @@ OPTIONS Use given directory for the location of packfiles and commit-graph file. This parameter exists to specify the location of an alternate that only has the objects directory, not a full `.git` directory. The - commit-graph file is expected to be at `<dir>/info/commit-graph` and + commit-graph file is expected to be in the `<dir>/info` directory and the packfiles are expected to be in `<dir>/pack`. @@ -51,6 +51,25 @@ or `--stdin-packs`.) + With the `--append` option, include all commits that are present in the existing commit-graph file. ++ +With the `--split` option, write the commit-graph as a chain of multiple +commit-graph files stored in `<dir>/info/commit-graphs`. The new commits +not already in the commit-graph are added in a new "tip" file. This file +is merged with the existing file if the following merge conditions are +met: ++ +* If `--size-multiple=<X>` is not specified, let `X` equal 2. If the new +tip file would have `N` commits and the previous tip has `M` commits and +`X` times `N` is greater than `M`, instead merge the two files into a +single file. ++ +* If `--max-commits=<M>` is specified with `M` a positive integer, and the +new tip file would have more than `M` commits, then instead merge the new +tip with the previous tip. ++ +Finally, if `--expire-time=<datetime>` is not specified, let `datetime` +be the current time. After writing the split commit-graph, delete all +unused commit-graph whose modified times are older than `datetime`. 'read':: @@ -61,6 +80,9 @@ Used for debugging purposes. Read the commit-graph file and verify its contents against the object database. Used to check for corrupted data. ++ +With the `--shallow` option, only check the tip commit-graph file in +a chain of split commit-graphs. EXAMPLES diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index a85c2c2..7628193 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -359,7 +359,7 @@ When recording your own work, the contents of modified files in your working tree are temporarily stored to a staging area called the "index" with 'git add'. A file can be reverted back, only in the index but not in the working tree, -to that of the last commit with `git reset HEAD -- <file>`, +to that of the last commit with `git restore --staged <file>`, which effectively reverts 'git add' and prevents the changes to this file from participating in the next commit. After building the state to be committed incrementally with these commands, diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt index 64c01ba..11427ac 100644 --- a/Documentation/git-fast-export.txt +++ b/Documentation/git-fast-export.txt @@ -129,6 +129,13 @@ marks the same across runs. for intermediary filters (e.g. for rewriting commit messages which refer to older commits, or for stripping blobs by id). +--reencode=(yes|no|abort):: + Specify how to handle `encoding` header in commit objects. When + asking to 'abort' (which is the default), this program will die + when encountering such a commit object. With 'yes', the commit + message will be reencoded into UTF-8. With 'no', the original + encoding will be preserved. + --refspec:: Apply the specified refspec to each ref exported. Multiple of them can be specified. diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index d65cdb3..7baf9e4 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -388,6 +388,7 @@ change to the project. original-oid? ('author' (SP <name>)? SP LT <email> GT SP <when> LF)? 'committer' (SP <name>)? SP LT <email> GT SP <when> LF + ('encoding' SP <encoding>)? data ('from' SP <commit-ish> LF)? ('merge' SP <commit-ish> LF)? @@ -455,6 +456,12 @@ that was selected by the --date-format=<fmt> command-line option. See ``Date Formats'' above for the set of supported formats, and their syntax. +`encoding` +^^^^^^^^^^ +The optional `encoding` command indicates the encoding of the commit +message. Most commits are UTF-8 and the encoding is omitted, but this +allows importing commit messages into git without first reencoding them. + `from` ^^^^^^ The `from` command is used to specify the commit to initialize diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 774cecc..6dcd39f 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -214,6 +214,11 @@ symref:: `:lstrip` and `:rstrip` options in the same way as `refname` above. +worktreepath:: + The absolute path to the worktree in which the ref is checked + out, if it is checked out in any linked worktree. Empty string + otherwise. + In addition to the above, for commit and tag objects, the header field names (`tree`, `parent`, `object`, `type`, and `tag`) can be used to specify the value in the header field. diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 1af85d4..b9b97e6 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -22,7 +22,8 @@ SYNOPSIS [--rfc] [--subject-prefix=Subject-Prefix] [(--reroll-count|-v) <n>] [--to=<email>] [--cc=<email>] - [--[no-]cover-letter] [--quiet] [--notes[=<ref>]] + [--[no-]cover-letter] [--quiet] + [--no-notes | --notes[=<ref>]] [--interdiff=<previous>] [--range-diff=<previous> [--creation-factor=<percent>]] [--progress] @@ -263,6 +264,7 @@ material (this may change in the future). for details. --notes[=<ref>]:: +--no-notes:: Append the notes (see linkgit:git-notes[1]) for the commit after the three-dash line. + @@ -273,6 +275,9 @@ these explanations after `format-patch` has run but before sending, keeping them as Git notes allows them to be maintained between versions of the patch series (but see the discussion of the `notes.rewrite` configuration options in linkgit:git-notes[1] to use this workflow). ++ +The default is `--no-notes`, unless the `format.notes` configuration is +set. --[no-]signature=<signature>:: Add a signature to each message produced. Per RFC 3676 the signature @@ -421,8 +426,8 @@ One way to test if your MUA is set up correctly is: * Apply it: $ git fetch <project> master:test-apply - $ git checkout test-apply - $ git reset --hard + $ git switch test-apply + $ git restore --source=HEAD --staged --worktree :/ $ git am a.patch If it does not apply correctly, there can be various reasons. diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt index 814e744..df9e2c5 100644 --- a/Documentation/git-hash-object.txt +++ b/Documentation/git-hash-object.txt @@ -18,9 +18,7 @@ Computes the object ID value for an object with specified type with the contents of the named file (which can be outside of the work tree), and optionally writes the resulting object into the object database. Reports its object ID to its standard output. -This is used by 'git cvsimport' to update the index -without modifying files in the work tree. When <type> is not -specified, it defaults to "blob". +When <type> is not specified, it defaults to "blob". OPTIONS ------- diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt index 9f07f4f..261d5c1 100644 --- a/Documentation/git-merge-base.txt +++ b/Documentation/git-merge-base.txt @@ -149,7 +149,7 @@ instead. Discussion on fork-point mode ----------------------------- -After working on the `topic` branch created with `git checkout -b +After working on the `topic` branch created with `git switch -c topic origin/master`, the history of remote-tracking branch `origin/master` may have been rewound and rebuilt, leading to a history of this shape: diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index 6294dbc..01fd52d 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -13,8 +13,7 @@ SYNOPSIS [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [--[no-]allow-unrelated-histories] [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] [<commit>...] -'git merge' --abort -'git merge' --continue +'git merge' (--continue | --abort | --quit) DESCRIPTION ----------- @@ -88,6 +87,11 @@ will be appended to the specified message. Allow the rerere mechanism to update the index with the result of auto-conflict resolution if possible. +--overwrite-ignore:: +--no-overwrite-ignore:: + Silently overwrite ignored files from the merge result. This + is the default behavior. Use `--no-overwrite-ignore` to abort. + --abort:: Abort the current conflict resolution process, and try to reconstruct the pre-merge state. @@ -100,6 +104,10 @@ commit or stash your changes before running 'git merge'. 'git merge --abort' is equivalent to 'git reset --merge' when `MERGE_HEAD` is present. +--quit:: + Forget about the current merge in progress. Leave the index + and the working tree as-is. + --continue:: After a 'git merge' stops due to conflicts you can conclude the merge by running 'git merge --continue' (see "HOW TO RESOLVE diff --git a/Documentation/git-multi-pack-index.txt b/Documentation/git-multi-pack-index.txt index f7778a2..233b2b7 100644 --- a/Documentation/git-multi-pack-index.txt +++ b/Documentation/git-multi-pack-index.txt @@ -9,7 +9,7 @@ git-multi-pack-index - Write and verify multi-pack-indexes SYNOPSIS -------- [verse] -'git multi-pack-index' [--object-dir=<dir>] <verb> +'git multi-pack-index' [--object-dir=<dir>] <subcommand> DESCRIPTION ----------- @@ -23,13 +23,35 @@ OPTIONS `<dir>/packs/multi-pack-index` for the current MIDX file, and `<dir>/packs` for the pack-files to index. +The following subcommands are available: + write:: - When given as the verb, write a new MIDX file to - `<dir>/packs/multi-pack-index`. + Write a new MIDX file. verify:: - When given as the verb, verify the contents of the MIDX file - at `<dir>/packs/multi-pack-index`. + Verify the contents of the MIDX file. + +expire:: + Delete the pack-files that are tracked by the MIDX file, but + have no objects referenced by the MIDX. Rewrite the MIDX file + afterward to remove all references to these pack-files. + +repack:: + Create a new pack-file containing objects in small pack-files + referenced by the multi-pack-index. If the size given by the + `--batch-size=<size>` argument is zero, then create a pack + containing all objects referenced by the multi-pack-index. For + a non-zero batch size, Select the pack-files by examining packs + from oldest-to-newest, computing the "expected size" by counting + the number of objects in the pack referenced by the + multi-pack-index, then divide by the total number of objects in + the pack and multiply by the pack size. We select packs with + expected size below the batch size until the set of packs have + total expected size at least the batch size. If the total size + does not reach the batch size, then do nothing. If a new pack- + file is created, rewrite the multi-pack-index to reference the + new pack-file. A later run of 'git multi-pack-index expire' will + delete the pack-files that were part of this batch. EXAMPLES diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 5e4e927..6156609 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -12,12 +12,12 @@ SYNOPSIS [<upstream> [<branch>]] 'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] --root [<branch>] -'git rebase' --continue | --skip | --abort | --quit | --edit-todo | --show-current-patch +'git rebase' (--continue | --skip | --abort | --quit | --edit-todo | --show-current-patch) DESCRIPTION ----------- If <branch> is specified, 'git rebase' will perform an automatic -`git checkout <branch>` before doing anything else. Otherwise +`git switch <branch>` before doing anything else. Otherwise it remains on the current branch. If <upstream> is not specified, the upstream configured in diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index 0cad37f..9659abb 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -230,7 +230,7 @@ $ git branch -r staging/master staging/staging-linus staging/staging-next -$ git checkout -b staging staging/master +$ git switch -c staging staging/master ... ------------ diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt index 95763d7..4cfc883 100644 --- a/Documentation/git-rerere.txt +++ b/Documentation/git-rerere.txt @@ -91,7 +91,7 @@ For such a test, you need to merge master and topic somehow. One way to do it is to pull master into the topic branch: ------------ - $ git checkout topic + $ git switch topic $ git merge master o---*---o---+ topic @@ -113,10 +113,10 @@ the upstream might have been advanced since the test merge `+`, in which case the final commit graph would look like this: ------------ - $ git checkout topic + $ git switch topic $ git merge master $ ... work on both topic and master branches - $ git checkout master + $ git switch master $ git merge topic o---*---o---+---o---o topic @@ -136,11 +136,11 @@ merges, you could blow away the test merge, and keep building on top of the tip before the test merge: ------------ - $ git checkout topic + $ git switch topic $ git merge master $ git reset --hard HEAD^ ;# rewind the test merge $ ... work on both topic and master branches - $ git checkout master + $ git switch master $ git merge topic o---*---o-------o---o topic diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index 26e746c..97e0544 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt @@ -25,12 +25,13 @@ The `<tree-ish>`/`<commit>` defaults to `HEAD` in all forms. the current branch.) + This means that `git reset <paths>` is the opposite of `git add -<paths>`. +<paths>`. This command is equivalent to +`git restore [--source=<tree-ish>] --staged <paths>...`. + After running `git reset <paths>` to update the index entry, you can -use linkgit:git-checkout[1] to check the contents out of the index to -the working tree. -Alternatively, using linkgit:git-checkout[1] and specifying a commit, you +use linkgit:git-restore[1] to check the contents out of the index to +the working tree. Alternatively, using linkgit:git-restore[1] +and specifying a commit with `--source`, you can copy the contents of a path out of a commit to the index and to the working tree in one go. @@ -86,8 +87,8 @@ but carries forward unmerged index entries. changes, reset is aborted. -- -If you want to undo a commit other than the latest on a branch, -linkgit:git-revert[1] is your friend. +See "Reset, restore and revert" in linkgit:git[1] for the differences +between the three commands. OPTIONS @@ -149,9 +150,9 @@ See also the `--amend` option to linkgit:git-commit[1]. Undo a commit, making it a topic branch:: + ------------ -$ git branch topic/wip <1> -$ git reset --hard HEAD~3 <2> -$ git checkout topic/wip <3> +$ git branch topic/wip <1> +$ git reset --hard HEAD~3 <2> +$ git switch topic/wip <3> ------------ + <1> You have made some commits, but realize they were premature @@ -232,13 +233,13 @@ working tree are not in any shape to be committed yet, but you need to get to the other branch for a quick bugfix. + ------------ -$ git checkout feature ;# you were working in "feature" branch and -$ work work work ;# got interrupted +$ git switch feature ;# you were working in "feature" branch and +$ work work work ;# got interrupted $ git commit -a -m "snapshot WIP" <1> -$ git checkout master +$ git switch master $ fix fix fix $ git commit ;# commit with real log -$ git checkout feature +$ git switch feature $ git reset --soft HEAD^ ;# go back to WIP state <2> $ git reset <3> ------------ @@ -279,18 +280,18 @@ reset it while keeping the changes in your working tree. + ------------ $ git tag start -$ git checkout -b branch1 +$ git switch -c branch1 $ edit $ git commit ... <1> $ edit -$ git checkout -b branch2 <2> +$ git switch -c branch2 <2> $ git reset --keep start <3> ------------ + <1> This commits your first edits in `branch1`. <2> In the ideal world, you could have realized that the earlier commit did not belong to the new topic when you created and switched - to `branch2` (i.e. `git checkout -b branch2 start`), but nobody is + to `branch2` (i.e. `git switch -c branch2 start`), but nobody is perfect. <3> But you can use `reset --keep` to remove the unwanted commit after you switched to `branch2`. diff --git a/Documentation/git-restore.txt b/Documentation/git-restore.txt new file mode 100644 index 0000000..d90093f --- /dev/null +++ b/Documentation/git-restore.txt @@ -0,0 +1,185 @@ +git-restore(1) +============== + +NAME +---- +git-restore - Restore working tree files + +SYNOPSIS +-------- +[verse] +'git restore' [<options>] [--source=<tree>] [--staged] [--worktree] <pathspec>... +'git restore' (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [<pathspec>...] + +DESCRIPTION +----------- +Restore specified paths in the working tree with some contents from a +restore source. If a path is tracked but does not exist in the restore +source, it will be removed to match the source. + +The command can also be used to restore the content in the index with +`--staged`, or restore both the working tree and the index with +`--staged --worktree`. + +By default, the restore sources for working tree and the index are the +index and `HEAD` respectively. `--source` could be used to specify a +commit as the restore source. + +See "Reset, restore and revert" in linkgit:git[1] for the differences +between the three commands. + +THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. + +OPTIONS +------- +-s <tree>:: +--source=<tree>:: + Restore the working tree files with the content from the given + tree. It is common to specify the source tree by naming a + commit, branch or tag associated with it. ++ +If not specified, the default restore source for the working tree is +the index, and the default restore source for the index index is +`HEAD`. When both `--staged` and `--worktree` are specified, +`--source` must also be specified. + +-p:: +--patch:: + Interactively select hunks in the difference between the + restore source and the restore location. See the ``Interactive + Mode'' section of linkgit:git-add[1] to learn how to operate + the `--patch` mode. ++ +Note that `--patch` can accept no pathspec and will prompt to restore +all modified paths. + +-W:: +--worktree:: +-S:: +--staged:: + Specify the restore location. If neither option is specified, + by default the working tree is restored. Specifying `--staged` + will only restore the index. Specifying both restores both. + +-q:: +--quiet:: + Quiet, suppress feedback messages. Implies `--no-progress`. + +--progress:: +--no-progress:: + Progress status is reported on the standard error stream + by default when it is attached to a terminal, unless `--quiet` + is specified. This flag enables progress reporting even if not + attached to a terminal, regardless of `--quiet`. + +--ours:: +--theirs:: + When restoring files in the working tree from the index, use + stage #2 ('ours') or #3 ('theirs') for unmerged paths. ++ +Note that during `git rebase` and `git pull --rebase`, 'ours' and +'theirs' may appear swapped. See the explanation of the same options +in linkgit:git-checkout[1] for details. + +-m:: +--merge:: + When restoring files on the working tree from the index, + recreate the conflicted merge in the unmerged paths. + +--conflict=<style>:: + The same as `--merge` option above, but changes the way the + conflicting hunks are presented, overriding the + `merge.conflictStyle` configuration variable. Possible values + are "merge" (default) and "diff3" (in addition to what is + shown by "merge" style, shows the original contents). + +--ignore-unmerged:: + When restoring files on the working tree from the index, do + not abort the operation if there are unmerged entries and + neither `--ours`, `--theirs`, `--merge` or `--conflict` is + specified. Unmerged paths on the working tree are left alone. + +--ignore-skip-worktree-bits:: + In sparse checkout mode, by default is to only update entries + matched by `<pathspec>` and sparse patterns in + $GIT_DIR/info/sparse-checkout. This option ignores the sparse + patterns and unconditionally restores any files in + `<pathspec>`. + +--overlay:: +--no-overlay:: + In overlay mode, the command never removes files when + restoring. In no-overlay mode, tracked files that do not + appear in the `--source` tree are removed, to make them match + `<tree>` exactly. The default is no-overlay mode. + +EXAMPLES +-------- + +The following sequence switches to the `master` branch, reverts the +`Makefile` to two revisions back, deletes hello.c by mistake, and gets +it back from the index. + +------------ +$ git switch master +$ git restore --source master~2 Makefile <1> +$ rm -f hello.c +$ git restore hello.c <2> +------------ + +<1> take a file out of another commit +<2> restore hello.c from the index + +If you want to restore _all_ C source files to match the version in +the index, you can say + +------------ +$ git restore '*.c' +------------ + +Note the quotes around `*.c`. The file `hello.c` will also be +restored, even though it is no longer in the working tree, because the +file globbing is used to match entries in the index (not in the +working tree by the shell). + +To restore all files in the current directory + +------------ +$ git restore . +------------ + +or to restore all working tree files with 'top' pathspec magic (see +linkgit:gitglossary[7]) + +------------ +$ git restore :/ +------------ + +To restore a file in the index to match the version in `HEAD` (this is +the same as using linkgit:git-reset[1]) + +------------ +$ git restore --staged hello.c +------------ + +or you can restore both the index and the working tree (this the same +as using linkgit:git-checkout[1]) + +------------ +$ git restore --source=HEAD --staged --worktree hello.c +------------ + +or the short form which is more practical but less readable: + +------------ +$ git restore -s@ -SW hello.c +------------ + +SEE ALSO +-------- +linkgit:git-checkout[1], +linkgit:git-reset[1] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt index 88609ff..9392760 100644 --- a/Documentation/git-rev-list.txt +++ b/Documentation/git-rev-list.txt @@ -48,6 +48,7 @@ SYNOPSIS [ --date=<format>] [ [ --objects | --objects-edge | --objects-edge-aggressive ] [ --unpacked ] + [ --object-names | --no-object-names ] [ --filter=<filter-spec> [ --filter-print-omitted ] ] ] [ --missing=<missing-action> ] [ --pretty | --header ] diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt index 0c82ca5..9d22270 100644 --- a/Documentation/git-revert.txt +++ b/Documentation/git-revert.txt @@ -9,9 +9,7 @@ SYNOPSIS -------- [verse] 'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] [-S[<keyid>]] <commit>... -'git revert' --continue -'git revert' --quit -'git revert' --abort +'git revert' (--continue | --skip | --abort | --quit) DESCRIPTION ----------- @@ -26,10 +24,13 @@ effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see linkgit:git-reset[1], particularly the `--hard` option. If you want to extract specific files as they were in another commit, you -should see linkgit:git-checkout[1], specifically the `git checkout -<commit> -- <filename>` syntax. Take care with these alternatives as +should see linkgit:git-restore[1], specifically the `--source` +option. Take care with these alternatives as both will discard uncommitted changes in your working directory. +See "Reset, restore and revert" in linkgit:git[1] for the differences +between the three commands. + OPTIONS ------- <commit>...:: diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 1afe9fc..d93e5d0 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -278,6 +278,14 @@ must be used for each option. Automating ~~~~~~~~~~ +--no-[to|cc|bcc]:: + Clears any list of "To:", "Cc:", "Bcc:" addresses previously + set via config. + +--no-identity:: + Clears the previously read value of `sendemail.identity` set + via config, if any. + --to-cmd=<command>:: Specify a command to execute once per patch file which should generate patch file specific "To:" entries. @@ -500,8 +508,12 @@ app-specific or your regular password as appropriate. If you have credential helper configured (see linkgit:git-credential[1]), the password will be saved in the credential store so you won't have to type it the next time. -Note: the following perl modules are required - Net::SMTP::SSL, MIME::Base64 and Authen::SASL +Note: the following core Perl modules that may be installed with your +distribution of Perl are required: +MIME::Base64, MIME::QuotedPrint, Net::Domain and Net::SMTP. +These additional Perl modules are also required: +Authen::SASL and Mail::Address. + SEE ALSO -------- diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index e31ea7d..8fbe12c 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -235,12 +235,12 @@ return to your original branch to make the emergency fix, like this: + ---------------------------------------------------------------- # ... hack hack hack ... -$ git checkout -b my_wip +$ git switch -c my_wip $ git commit -a -m "WIP" -$ git checkout master +$ git switch master $ edit emergency fix $ git commit -a -m "Fix in a hurry" -$ git checkout my_wip +$ git switch my_wip $ git reset --soft HEAD^ # ... continue hacking ... ---------------------------------------------------------------- @@ -293,7 +293,8 @@ SEE ALSO linkgit:git-checkout[1], linkgit:git-commit[1], linkgit:git-reflog[1], -linkgit:git-reset[1] +linkgit:git-reset[1], +linkgit:git-switch[1] GIT --- diff --git a/Documentation/git-switch.txt b/Documentation/git-switch.txt new file mode 100644 index 0000000..1979003 --- /dev/null +++ b/Documentation/git-switch.txt @@ -0,0 +1,273 @@ +git-switch(1) +============= + +NAME +---- +git-switch - Switch branches + +SYNOPSIS +-------- +[verse] +'git switch' [<options>] [--no-guess] <branch> +'git switch' [<options>] --detach [<start-point>] +'git switch' [<options>] (-c|-C) <new-branch> [<start-point>] +'git switch' [<options>] --orphan <new-branch> + +DESCRIPTION +----------- +Switch to a specified branch. The working tree and the index are +updated to match the branch. All new commits will be added to the tip +of this branch. + +Optionally a new branch could be created with either `-c`, `-C`, +automatically from a remote branch of same name (see `--guess`), or +detach the working tree from any branch with `--detach`, along with +switching. + +Switching branches does not require a clean index and working tree +(i.e. no differences compared to `HEAD`). The operation is aborted +however if the operation leads to loss of local changes, unless told +otherwise with `--discard-changes` or `--merge`. + +THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. + +OPTIONS +------- +<branch>:: + Branch to switch to. + +<new-branch>:: + Name for the new branch. + +<start-point>:: + The starting point for the new branch. Specifying a + `<start-point>` allows you to create a branch based on some + other point in history than where HEAD currently points. (Or, + in the case of `--detach`, allows you to inspect and detach + from some other point.) ++ +You can use the `@{-N}` syntax to refer to the N-th last +branch/commit switched to using "git switch" or "git checkout" +operation. You may also specify `-` which is synonymous to `@{-1}`. +This is often used to switch quickly between two branches, or to undo +a branch switch by mistake. ++ +As a special case, you may use `A...B` as a shortcut for the merge +base of `A` and `B` if there is exactly one merge base. You can leave +out at most one of `A` and `B`, in which case it defaults to `HEAD`. + +-c <new-branch>:: +--create <new-branch>:: + Create a new branch named `<new-branch>` starting at + `<start-point>` before switching to the branch. This is a + convenient shortcut for: ++ +------------ +$ git branch <new-branch> +$ git switch <new-branch> +------------ + +-C <new-branch>:: +--force-create <new-branch>:: + Similar to `--create` except that if `<new-branch>` already + exists, it will be reset to `<start-point>`. This is a + convenient shortcut for: ++ +------------ +$ git branch -f <new-branch> +$ git switch <new-branch> +------------ + +-d:: +--detach:: + Switch to a commit for inspection and discardable + experiments. See the "DETACHED HEAD" section in + linkgit:git-checkout[1] for details. + +--guess:: +--no-guess:: + If `<branch>` is not found but there does exist a tracking + branch in exactly one remote (call it `<remote>`) with a + matching name, treat as equivalent to ++ +------------ +$ git switch -c <branch> --track <remote>/<branch> +------------ ++ +If the branch exists in multiple remotes and one of them is named by +the `checkout.defaultRemote` configuration variable, we'll use that +one for the purposes of disambiguation, even if the `<branch>` isn't +unique across all remotes. Set it to e.g. `checkout.defaultRemote=origin` +to always checkout remote branches from there if `<branch>` is +ambiguous but exists on the 'origin' remote. See also +`checkout.defaultRemote` in linkgit:git-config[1]. ++ +`--guess` is the default behavior. Use `--no-guess` to disable it. + +-f:: +--force:: + An alias for `--discard-changes`. + +--discard-changes:: + Proceed even if the index or the working tree differs from + `HEAD`. Both the index and working tree are restored to match + the switching target. If `--recurse-submodules` is specified, + submodule content is also restored to match the switching + target. This is used to throw away local changes. + +-m:: +--merge:: + If you have local modifications to one or more files that are + different between the current branch and the branch to which + you are switching, the command refuses to switch branches in + order to preserve your modifications in context. However, + with this option, a three-way merge between the current + branch, your working tree contents, and the new branch is + done, and you will be on the new branch. ++ +When a merge conflict happens, the index entries for conflicting +paths are left unmerged, and you need to resolve the conflicts +and mark the resolved paths with `git add` (or `git rm` if the merge +should result in deletion of the path). + +--conflict=<style>:: + The same as `--merge` option above, but changes the way the + conflicting hunks are presented, overriding the + `merge.conflictStyle` configuration variable. Possible values are + "merge" (default) and "diff3" (in addition to what is shown by + "merge" style, shows the original contents). + +-q:: +--quiet:: + Quiet, suppress feedback messages. + +--progress:: +--no-progress:: + Progress status is reported on the standard error stream + by default when it is attached to a terminal, unless `--quiet` + is specified. This flag enables progress reporting even if not + attached to a terminal, regardless of `--quiet`. + +-t:: +--track:: + When creating a new branch, set up "upstream" configuration. + `-c` is implied. See `--track` in linkgit:git-branch[1] for + details. ++ +If no `-c` option is given, the name of the new branch will be derived +from the remote-tracking branch, by looking at the local part of the +refspec configured for the corresponding remote, and then stripping +the initial part up to the "*". This would tell us to use `hack` as +the local branch when branching off of `origin/hack` (or +`remotes/origin/hack`, or even `refs/remotes/origin/hack`). If the +given name has no slash, or the above guessing results in an empty +name, the guessing is aborted. You can explicitly give a name with +`-c` in such a case. + +--no-track:: + Do not set up "upstream" configuration, even if the + `branch.autoSetupMerge` configuration variable is true. + +--orphan <new-branch>:: + Create a new 'orphan' branch, named `<new-branch>`. All + tracked files are removed. + +--ignore-other-worktrees:: + `git switch` refuses when the wanted ref is already + checked out by another worktree. This option makes it check + the ref out anyway. In other words, the ref can be held by + more than one worktree. + +--recurse-submodules:: +--no-recurse-submodules:: + Using `--recurse-submodules` will update the content of all + initialized submodules according to the commit recorded in the + superproject. If nothing (or `--no-recurse-submodules`) is + used, the work trees of submodules will not be updated. Just + like linkgit:git-submodule[1], this will detach `HEAD` of the + submodules. + +EXAMPLES +-------- + +The following command switches to the "master" branch: + +------------ +$ git switch master +------------ + +After working in the wrong branch, switching to the correct branch +would be done using: + +------------ +$ git switch mytopic +------------ + +However, your "wrong" branch and correct "mytopic" branch may differ +in files that you have modified locally, in which case the above +switch would fail like this: + +------------ +$ git switch mytopic +error: You have local changes to 'frotz'; not switching branches. +------------ + +You can give the `-m` flag to the command, which would try a three-way +merge: + +------------ +$ git switch -m mytopic +Auto-merging frotz +------------ + +After this three-way merge, the local modifications are _not_ +registered in your index file, so `git diff` would show you what +changes you made since the tip of the new branch. + +To switch back to the previous branch before we switched to mytopic +(i.e. "master" branch): + +------------ +$ git switch - +------------ + +You can grow a new branch from any commit. For example, switch to +"HEAD~3" and create branch "fixup": + +------------ +$ git switch -c fixup HEAD~3 +Switched to a new branch 'fixup' +------------ + +If you want to start a new branch from a remote branch of the same +name: + +------------ +$ git switch new-topic +Branch 'new-topic' set up to track remote branch 'new-topic' from 'origin' +Switched to a new branch 'new-topic' +------------ + +To check out commit `HEAD~3` for temporary inspection or experiment +without creating a new branch: + +------------ +$ git switch --detach HEAD~3 +HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits' +------------ + +If it turns out whatever you have done is worth keeping, you can +always create a new name for it (without switching away): + +------------ +$ git switch -c good-surprises +------------ + +SEE ALSO +-------- +linkgit:git-checkout[1], +linkgit:git-branch[1] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index a74e7b9..2e5599a 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -64,6 +64,13 @@ OPTIONS -s:: --sign:: Make a GPG-signed tag, using the default e-mail address's key. + The default behavior of tag GPG-signing is controlled by `tag.gpgSign` + configuration variable if it exists, or disabled oder otherwise. + See linkgit:git-config[1]. + +--no-sign:: + Override `tag.gpgSign` configuration variable that is + set to force each and every tag to be signed. -u <keyid>:: --local-user=<keyid>:: diff --git a/Documentation/git-update-server-info.txt b/Documentation/git-update-server-info.txt index bd0e364..969bb2e 100644 --- a/Documentation/git-update-server-info.txt +++ b/Documentation/git-update-server-info.txt @@ -9,7 +9,7 @@ git-update-server-info - Update auxiliary info file to help dumb servers SYNOPSIS -------- [verse] -'git update-server-info' [--force] +'git update-server-info' DESCRIPTION ----------- @@ -19,15 +19,6 @@ $GIT_OBJECT_DIRECTORY/info directories to help clients discover what references and packs the server has. This command generates such auxiliary files. - -OPTIONS -------- - --f:: ---force:: - Update the info files from scratch. - - OUTPUT ------ diff --git a/Documentation/git.txt b/Documentation/git.txt index 6ddc1e2..9b82564 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -33,7 +33,8 @@ individual Git commands with "git help command". linkgit:gitcli[7] manual page gives you an overview of the command-line command syntax. A formatted and hyperlinked copy of the latest Git documentation -can be viewed at `https://git.github.io/htmldocs/git.html`. +can be viewed at https://git.github.io/htmldocs/git.html +or https://git-scm.com/docs. OPTIONS @@ -56,7 +57,8 @@ help ...`. Run as if git was started in '<path>' instead of the current working directory. When multiple `-C` options are given, each subsequent non-absolute `-C <path>` is interpreted relative to the preceding `-C - <path>`. + <path>`. If '<path>' is present but empty, e.g. `-C ""`, then the + current working directory is left unchanged. + This option affects options that expect path name like `--git-dir` and `--work-tree` in that their interpretations of the path names would be @@ -210,6 +212,26 @@ people via patch over e-mail. include::cmds-foreignscminterface.txt[] +Reset, restore and revert +~~~~~~~~~~~~~~~~~~~~~~~~~ +There are three commands with similar names: `git reset`, +`git restore` and `git revert`. + +* linkgit:git-revert[1] is about making a new commit that reverts the + changes made by other commits. + +* linkgit:git-restore[1] is about restoring files in the working tree + from either the index or another commit. This command does not + update your branch. The command can also be used to restore files in + the index from another commit. + +* linkgit:git-reset[1] is about updating your branch, moving the tip + in order to add or remove commits from the branch. This operation + changes the commit history. ++ +`git reset` can also be used to restore the index, overlapping with +`git restore`. + Low-level commands (plumbing) ----------------------------- diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 4fb20cd..fb1d188 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -112,7 +112,8 @@ Checking-out and checking-in These attributes affect how the contents stored in the repository are copied to the working tree files when commands -such as 'git checkout' and 'git merge' run. They also affect how +such as 'git switch', 'git checkout' and 'git merge' run. +They also affect how Git stores the contents you prepare in the working tree in the repository upon 'git add' and 'git commit'. @@ -819,7 +820,7 @@ patterns are available: - `java` suitable for source code in the Java language. -- `matlab` suitable for source code in the MATLAB language. +- `matlab` suitable for source code in the MATLAB and Octave languages. - `objc` suitable for source code in the Objective-C language. @@ -833,6 +834,8 @@ patterns are available: - `ruby` suitable for source code in the Ruby language. +- `rust` suitable for source code in the Rust language. + - `tex` suitable for source code for LaTeX documents. diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index 592e06d..1ed3ca3 100644 --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -47,8 +47,8 @@ disambiguating `--` at appropriate places. things: + -------------------------------- -$ git checkout -- *.c -$ git checkout -- \*.c +$ git restore *.c +$ git restore \*.c -------------------------------- + The former lets your shell expand the fileglob, and you are asking @@ -209,6 +209,18 @@ See also http://marc.info/?l=git&m=116563135620359 and http://marc.info/?l=git&m=119150393620273 for further information. +Some other commands that also work on files in the working tree and/or +in the index can take `--staged` and/or `--worktree`. + +* `--staged` is exactly like `--cached`, which is used to ask a + command to only work on the index, not the working tree. + +* `--worktree` is the opposite, to ask a command to work on the + working tree only, not the index. + +* The two options can be specified together to ask a command to work + on both the index and the working tree. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index e29a9ef..f880d21 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -741,7 +741,7 @@ used earlier, and create a branch in it. You do that by simply just saying that you want to check out a new branch: ------------ -$ git checkout -b mybranch +$ git switch -c mybranch ------------ will create a new branch based at the current `HEAD` position, and switch @@ -755,7 +755,7 @@ just telling 'git checkout' what the base of the checkout would be. In other words, if you have an earlier tag or branch, you'd just do ------------ -$ git checkout -b mybranch earlier-commit +$ git switch -c mybranch earlier-commit ------------ and it would create the new branch `mybranch` at the earlier commit, @@ -765,7 +765,7 @@ and check out the state at that time. You can always just jump back to your original `master` branch by doing ------------ -$ git checkout master +$ git switch master ------------ (or any other branch-name, for that matter) and if you forget which @@ -794,7 +794,7 @@ $ git branch <branchname> [startingpoint] which will simply _create_ the branch, but will not do anything further. You can then later -- once you decide that you want to actually develop -on that branch -- switch to that branch with a regular 'git checkout' +on that branch -- switch to that branch with a regular 'git switch' with the branchname as the argument. @@ -808,7 +808,7 @@ being the same as the original `master` branch, let's make sure we're in that branch, and do some work there. ------------------------------------------------ -$ git checkout mybranch +$ git switch mybranch $ echo "Work, work, work" >>hello $ git commit -m "Some work." -i hello ------------------------------------------------ @@ -825,7 +825,7 @@ does some work in the original branch, and simulate that by going back to the master branch, and editing the same file differently there: ------------ -$ git checkout master +$ git switch master ------------ Here, take a moment to look at the contents of `hello`, and notice how they @@ -958,7 +958,7 @@ to the `master` branch. Let's go back to `mybranch`, and run 'git merge' to get the "upstream changes" back to your branch. ------------ -$ git checkout mybranch +$ git switch mybranch $ git merge -m "Merge upstream changes." master ------------ @@ -1133,9 +1133,8 @@ Remember, before running 'git merge', our `master` head was at work." commit. ------------ -$ git checkout mybranch -$ git reset --hard master^2 -$ git checkout master +$ git switch -C mybranch master^2 +$ git switch master $ git reset --hard master^ ------------ diff --git a/Documentation/giteveryday.txt b/Documentation/giteveryday.txt index 9f2528f..1bd919f 100644 --- a/Documentation/giteveryday.txt +++ b/Documentation/giteveryday.txt @@ -41,7 +41,7 @@ following commands. * linkgit:git-log[1] to see what happened. - * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch + * linkgit:git-switch[1] and linkgit:git-branch[1] to switch branches. * linkgit:git-add[1] to manage the index file. @@ -51,8 +51,7 @@ following commands. * linkgit:git-commit[1] to advance the current branch. - * linkgit:git-reset[1] and linkgit:git-checkout[1] (with - pathname parameters) to undo changes. + * linkgit:git-restore[1] to undo changes. * linkgit:git-merge[1] to merge between local branches. @@ -80,9 +79,9 @@ $ git tag v2.43 <2> Create a topic branch and develop.:: + ------------ -$ git checkout -b alsa-audio <1> +$ git switch -c alsa-audio <1> $ edit/compile/test -$ git checkout -- curses/ux_audio_oss.c <2> +$ git restore curses/ux_audio_oss.c <2> $ git add curses/ux_audio_alsa.c <3> $ edit/compile/test $ git diff HEAD <4> @@ -90,7 +89,7 @@ $ git commit -a -s <5> $ edit/compile/test $ git diff HEAD^ <6> $ git commit -a --amend <7> -$ git checkout master <8> +$ git switch master <8> $ git merge alsa-audio <9> $ git log --since='3 days ago' <10> $ git log v2.43.. curses/ <11> @@ -148,11 +147,11 @@ Clone the upstream and work on it. Feed changes to upstream.:: ------------ $ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6 $ cd my2.6 -$ git checkout -b mine master <1> +$ git switch -c mine master <1> $ edit/compile/test; git commit -a -s <2> $ git format-patch master <3> $ git send-email --to="person <email@example.com>" 00*.patch <4> -$ git checkout master <5> +$ git switch master <5> $ git pull <6> $ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <7> $ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git <8> @@ -194,7 +193,7 @@ satellite$ edit/compile/test/commit satellite$ git push origin <4> mothership$ cd frotz -mothership$ git checkout master +mothership$ git switch master mothership$ git merge satellite/master <5> ------------ + @@ -216,7 +215,7 @@ machine into the master branch. Branch off of a specific tag.:: + ------------ -$ git checkout -b private2.6.14 v2.6.14 <1> +$ git switch -c private2.6.14 v2.6.14 <1> $ edit/compile/test; git commit -a $ git checkout master $ git cherry-pick v2.6.14..private2.6.14 <2> @@ -274,14 +273,14 @@ $ mailx <3> & s 2 3 4 5 ./+to-apply & s 7 8 ./+hold-linus & q -$ git checkout -b topic/one master +$ git switch -c topic/one master $ git am -3 -i -s ./+to-apply <4> $ compile/test -$ git checkout -b hold/linus && git am -3 -i -s ./+hold-linus <5> -$ git checkout topic/one && git rebase master <6> -$ git checkout pu && git reset --hard next <7> +$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus <5> +$ git switch topic/one && git rebase master <6> +$ git switch -C pu next <7> $ git merge topic/one topic/two && git merge hold/linus <8> -$ git checkout maint +$ git switch maint $ git cherry-pick master~4 <9> $ compile/test $ git tag -s -m "GIT 0.99.9x" v0.99.9x <10> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index 786e778..82cd573 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -165,12 +165,13 @@ rebased, and is not set when rebasing the current branch. post-checkout ~~~~~~~~~~~~~ -This hook is invoked when a linkgit:git-checkout[1] is run after having updated the +This hook is invoked when a linkgit:git-checkout[1] or +linkgit:git-switch[1] is run after having updated the worktree. The hook is given three parameters: the ref of the previous HEAD, the ref of the new HEAD (which may or may not have changed), and a flag indicating whether the checkout was a branch checkout (changing branches, flag=1) or a file checkout (retrieving a file from the index, flag=0). -This hook cannot affect the outcome of `git checkout`. +This hook cannot affect the outcome of `git switch` or `git checkout`. It is also run after linkgit:git-clone[1], unless the `--no-checkout` (`-n`) option is used. The first parameter given to the hook is the null-ref, the second the @@ -406,7 +407,8 @@ exit with a zero status. For example, the hook can simply run `git read-tree -u -m HEAD "$1"` in order to emulate `git fetch` that is run in the reverse direction with `git push`, as the two-tree form of `git read-tree -u -m` is -essentially the same as `git checkout` that switches branches while +essentially the same as `git switch` or `git checkout` +that switches branches while keeping the local changes in the working tree that do not interfere with the difference between the branches. diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index b5bc9db..d47b1ae 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -89,28 +89,28 @@ PATTERN FORMAT Put a backslash ("`\`") in front of the first "`!`" for patterns that begin with a literal "`!`", for example, "`\!important!.txt`". - - If the pattern ends with a slash, it is removed for the - purpose of the following description, but it would only find - a match with a directory. In other words, `foo/` will match a - directory `foo` and paths underneath it, but will not match a - regular file or a symbolic link `foo` (this is consistent - with the way how pathspec works in general in Git). - - - If the pattern does not contain a slash '/', Git treats it as - a shell glob pattern and checks for a match against the - pathname relative to the location of the `.gitignore` file - (relative to the toplevel of the work tree if not from a - `.gitignore` file). - - - Otherwise, Git treats the pattern as a shell glob: "`*`" matches - anything except "`/`", "`?`" matches any one character except "`/`" - and "`[]`" matches one character in a selected range. See - fnmatch(3) and the FNM_PATHNAME flag for a more detailed - description. - - - A leading slash matches the beginning of the pathname. - For example, "/{asterisk}.c" matches "cat-file.c" but not - "mozilla-sha1/sha1.c". + - The slash '/' is used as the directory separator. Separators may + occur at the beginning, middle or end of the `.gitignore` search pattern. + + - If there is a separator at the beginning or middle (or both) of the + pattern, then the pattern is relative to the directory level of the + particular `.gitignore` file itself. Otherwise the pattern may also + match at any level below the `.gitignore` level. + + - If there is a separator at the end of the pattern then the pattern + will only match directories, otherwise the pattern can match both + files and directories. + + - For example, a pattern `doc/frotz/` matches `doc/frotz` directory, + but not `a/doc/frotz` directory; however `frotz/` matches `frotz` + and `a/frotz` that is a directory (all paths are relative from + the `.gitignore` file). + + - An asterisk "`*`" matches anything except a slash. + The character "`?`" matches any one character except "`/`". + The range notation, e.g. `[a-zA-Z]`, can be used to match + one of the characters in a range. See fnmatch(3) and the + FNM_PATHNAME flag for a more detailed description. Two consecutive asterisks ("`**`") in patterns matched against full pathname may have special meaning: @@ -152,6 +152,28 @@ To stop tracking a file that is currently tracked, use EXAMPLES -------- + - The pattern `hello.*` matches any file or folder + whose name begins with `hello`. If one wants to restrict + this only to the directory and not in its subdirectories, + one can prepend the pattern with a slash, i.e. `/hello.*`; + the pattern now matches `hello.txt`, `hello.c` but not + `a/hello.java`. + + - The pattern `foo/` will match a directory `foo` and + paths underneath it, but will not match a regular file + or a symbolic link `foo` (this is consistent with the + way how pathspec works in general in Git) + + - The pattern `doc/frotz` and `/doc/frotz` have the same effect + in any `.gitignore` file. In other words, a leading slash + is not relevant if there is already a middle slash in + the pattern. + + - The pattern "foo/*", matches "foo/test.json" + (a regular file), "foo/bar" (a directory), but it does not match + "foo/bar/hello.c" (a regular file), as the asterisk in the + pattern does not match "bar/hello.c" which has a slash in it. + -------------------------------------------------------------- $ git status [...] diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt index e0976f6..8bdb7d0 100644 --- a/Documentation/gittutorial-2.txt +++ b/Documentation/gittutorial-2.txt @@ -370,13 +370,13 @@ situation: $ git status On branch master Changes to be committed: - (use "git reset HEAD <file>..." to unstage) + (use "git restore --staged <file>..." to unstage) new file: closing.txt Changes not staged for commit: (use "git add <file>..." to update what will be committed) - (use "git checkout -- <file>..." to discard changes in working directory) + (use "git restore <file>..." to discard changes in working directory) modified: file.txt diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index 242de31..59ef5ce 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -110,7 +110,7 @@ $ git status On branch master Changes to be committed: Your branch is up to date with 'origin/master'. - (use "git reset HEAD <file>..." to unstage) + (use "git restore --staged <file>..." to unstage) modified: file1 modified: file2 @@ -207,7 +207,7 @@ automatically. The asterisk marks the branch you are currently on; type ------------------------------------------------ -$ git checkout experimental +$ git switch experimental ------------------------------------------------ to switch to the experimental branch. Now edit a file, commit the @@ -216,7 +216,7 @@ change, and switch back to the master branch: ------------------------------------------------ (edit file) $ git commit -a -$ git checkout master +$ git switch master ------------------------------------------------ Check that the change you made is no longer visible, since it was diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt index c743609..3cc9b03 100644 --- a/Documentation/gitweb.txt +++ b/Documentation/gitweb.txt @@ -28,8 +28,7 @@ Gitweb provides a web interface to Git repositories. Its features include: revisions one at a time, viewing the history of the repository. * Finding commits which commit messages matches given search term. -See http://git.kernel.org/?p=git/git.git;a=tree;f=gitweb[] or -http://repo.or.cz/w/git.git/tree/HEAD:/gitweb/[] for gitweb source code, +See http://repo.or.cz/w/git.git/tree/HEAD:/gitweb/[] for gitweb source code, browsed using gitweb itself. diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt index ca11c7b..abc0dc6 100644 --- a/Documentation/gitworkflows.txt +++ b/Documentation/gitworkflows.txt @@ -301,8 +301,7 @@ topics on 'next': .Rewind and rebuild next [caption="Recipe: "] ===================================== -* `git checkout next` -* `git reset --hard master` +* `git switch -C next master` * `git merge ai/topic_in_next1` * `git merge ai/topic_in_next2` * ... diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index 61876db..79a00d2 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -102,6 +102,8 @@ merge. + With --no-squash perform the merge and commit the result. This option can be used to override --squash. ++ +With --squash, --commit is not allowed, and will fail. -s <strategy>:: --strategy=<strategy>:: diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 71a1fcc..bb1251c 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -182,6 +182,14 @@ explicitly. Pretend as if all objects mentioned by reflogs are listed on the command line as `<commit>`. +--alternate-refs:: + Pretend as if all objects mentioned as ref tips of alternate + repositories were listed on the command line. An alternate + repository is any repository whose object directory is specified + in `objects/info/alternates`. The set of included objects may + be modified by `core.alternateRefsCommand`, etc. See + linkgit:git-config[1]. + --single-worktree:: By default, all working trees will be examined by the following options when there are more than one (see @@ -708,6 +716,16 @@ ifdef::git-rev-list[] Only useful with `--objects`; print the object IDs that are not in packs. +--object-names:: + Only useful with `--objects`; print the names of the object IDs + that are found. This is the default behavior. + +--no-object-names:: + Only useful with `--objects`; does not print the names of the object + IDs that are found. This inverts `--object-names`. This flag allows + the output to be more easily parsed by commands such as + linkgit:git-cat-file[1]. + --filter=<filter-spec>:: Only useful with one of the `--objects*`; omits objects (usually blobs) from the list of printed objects. The '<filter-spec>' diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt index 82c1e57..97f995e 100644 --- a/Documentation/revisions.txt +++ b/Documentation/revisions.txt @@ -115,7 +115,7 @@ Here's an example to make it more clear: ------------------------------ $ git config push.default current $ git config remote.pushdefault myfork -$ git checkout -b mybranch origin/master +$ git switch -c mybranch origin/master $ git rev-parse --symbolic-full-name @{upstream} refs/remotes/origin/master diff --git a/Documentation/sequencer.txt b/Documentation/sequencer.txt index 5a57c4a..3bceb56 100644 --- a/Documentation/sequencer.txt +++ b/Documentation/sequencer.txt @@ -3,6 +3,10 @@ `.git/sequencer`. Can be used to continue after resolving conflicts in a failed cherry-pick or revert. +--skip:: + Skip the current commit and continue with the rest of the + sequence. + --quit:: Forget about the current operation in progress. Can be used to clear the sequencer state after a failed cherry-pick or diff --git a/Documentation/technical/api-trace2.txt b/Documentation/technical/api-trace2.txt index 23c3cc7..71eb081 100644 --- a/Documentation/technical/api-trace2.txt +++ b/Documentation/technical/api-trace2.txt @@ -35,7 +35,7 @@ Format details are given in a later section. === The Normal Format Target The normal format target is a tradition printf format and similar -to GIT_TRACE format. This format is enabled with the `GIT_TR` +to GIT_TRACE format. This format is enabled with the `GIT_TRACE2` environment variable or the `trace2.normalTarget` system or global config setting. @@ -668,7 +668,7 @@ completed.) "event":"signal", ... "t_abs":0.001227, # elapsed time in seconds - "signal":13 # SIGTERM, SIGINT, etc. + "signo":13 # SIGTERM, SIGINT, etc. } ------------ diff --git a/Documentation/technical/commit-graph-format.txt b/Documentation/technical/commit-graph-format.txt index 16452a0..a4f1744 100644 --- a/Documentation/technical/commit-graph-format.txt +++ b/Documentation/technical/commit-graph-format.txt @@ -44,8 +44,9 @@ HEADER: 1-byte number (C) of "chunks" - 1-byte (reserved for later use) - Current clients should ignore this value. + 1-byte number (B) of base commit-graphs + We infer the length (H*B) of the Base Graphs chunk + from this value. CHUNK LOOKUP: @@ -92,6 +93,12 @@ CHUNK DATA: positions for the parents until reaching a value with the most-significant bit on. The other bits correspond to the position of the last parent. + Base Graphs List (ID: {'B', 'A', 'S', 'E'}) [Optional] + This list of H-byte hashes describe a set of B commit-graph files that + form a commit-graph chain. The graph position for the ith commit in this + file's OID Lookup chunk is equal to i plus the number of commits in all + base graphs. If B is non-zero, this chunk must exist. + TRAILER: H-byte HASH-checksum of all of the above. diff --git a/Documentation/technical/commit-graph.txt b/Documentation/technical/commit-graph.txt index 7805b09..729fbcb 100644 --- a/Documentation/technical/commit-graph.txt +++ b/Documentation/technical/commit-graph.txt @@ -127,22 +127,196 @@ Design Details helpful for these clones, anyway. The commit-graph will not be read or written when shallow commits are present. -Future Work ------------ - -- After computing and storing generation numbers, we must make graph - walks aware of generation numbers to gain the performance benefits they - enable. This will mostly be accomplished by swapping a commit-date-ordered - priority queue with one ordered by generation number. The following - operations are important candidates: - - - 'log --topo-order' - - 'tag --merged' - -- A server could provide a commit-graph file as part of the network protocol - to avoid extra calculations by clients. This feature is only of benefit if - the user is willing to trust the file, because verifying the file is correct - is as hard as computing it from scratch. +Commit Graphs Chains +-------------------- + +Typically, repos grow with near-constant velocity (commits per day). Over time, +the number of commits added by a fetch operation is much smaller than the +number of commits in the full history. By creating a "chain" of commit-graphs, +we enable fast writes of new commit data without rewriting the entire commit +history -- at least, most of the time. + +## File Layout + +A commit-graph chain uses multiple files, and we use a fixed naming convention +to organize these files. Each commit-graph file has a name +`$OBJDIR/info/commit-graphs/graph-{hash}.graph` where `{hash}` is the hex- +valued hash stored in the footer of that file (which is a hash of the file's +contents before that hash). For a chain of commit-graph files, a plain-text +file at `$OBJDIR/info/commit-graphs/commit-graph-chain` contains the +hashes for the files in order from "lowest" to "highest". + +For example, if the `commit-graph-chain` file contains the lines + +``` + {hash0} + {hash1} + {hash2} +``` + +then the commit-graph chain looks like the following diagram: + + +-----------------------+ + | graph-{hash2}.graph | + +-----------------------+ + | + +-----------------------+ + | | + | graph-{hash1}.graph | + | | + +-----------------------+ + | + +-----------------------+ + | | + | | + | | + | graph-{hash0}.graph | + | | + | | + | | + +-----------------------+ + +Let X0 be the number of commits in `graph-{hash0}.graph`, X1 be the number of +commits in `graph-{hash1}.graph`, and X2 be the number of commits in +`graph-{hash2}.graph`. If a commit appears in position i in `graph-{hash2}.graph`, +then we interpret this as being the commit in position (X0 + X1 + i), and that +will be used as its "graph position". The commits in `graph-{hash2}.graph` use these +positions to refer to their parents, which may be in `graph-{hash1}.graph` or +`graph-{hash0}.graph`. We can navigate to an arbitrary commit in position j by checking +its containment in the intervals [0, X0), [X0, X0 + X1), [X0 + X1, X0 + X1 + +X2). + +Each commit-graph file (except the base, `graph-{hash0}.graph`) contains data +specifying the hashes of all files in the lower layers. In the above example, +`graph-{hash1}.graph` contains `{hash0}` while `graph-{hash2}.graph` contains +`{hash0}` and `{hash1}`. + +## Merging commit-graph files + +If we only added a new commit-graph file on every write, we would run into a +linear search problem through many commit-graph files. Instead, we use a merge +strategy to decide when the stack should collapse some number of levels. + +The diagram below shows such a collapse. As a set of new commits are added, it +is determined by the merge strategy that the files should collapse to +`graph-{hash1}`. Thus, the new commits, the commits in `graph-{hash2}` and +the commits in `graph-{hash1}` should be combined into a new `graph-{hash3}` +file. + + +---------------------+ + | | + | (new commits) | + | | + +---------------------+ + | | + +-----------------------+ +---------------------+ + | graph-{hash2} |->| | + +-----------------------+ +---------------------+ + | | | + +-----------------------+ +---------------------+ + | | | | + | graph-{hash1} |->| | + | | | | + +-----------------------+ +---------------------+ + | tmp_graphXXX + +-----------------------+ + | | + | | + | | + | graph-{hash0} | + | | + | | + | | + +-----------------------+ + +During this process, the commits to write are combined, sorted and we write the +contents to a temporary file, all while holding a `commit-graph-chain.lock` +lock-file. When the file is flushed, we rename it to `graph-{hash3}` +according to the computed `{hash3}`. Finally, we write the new chain data to +`commit-graph-chain.lock`: + +``` + {hash3} + {hash0} +``` + +We then close the lock-file. + +## Merge Strategy + +When writing a set of commits that do not exist in the commit-graph stack of +height N, we default to creating a new file at level N + 1. We then decide to +merge with the Nth level if one of two conditions hold: + + 1. `--size-multiple=<X>` is specified or X = 2, and the number of commits in + level N is less than X times the number of commits in level N + 1. + + 2. `--max-commits=<C>` is specified with non-zero C and the number of commits + in level N + 1 is more than C commits. + +This decision cascades down the levels: when we merge a level we create a new +set of commits that then compares to the next level. + +The first condition bounds the number of levels to be logarithmic in the total +number of commits. The second condition bounds the total number of commits in +a `graph-{hashN}` file and not in the `commit-graph` file, preventing +significant performance issues when the stack merges and another process only +partially reads the previous stack. + +The merge strategy values (2 for the size multiple, 64,000 for the maximum +number of commits) could be extracted into config settings for full +flexibility. + +## Deleting graph-{hash} files + +After a new tip file is written, some `graph-{hash}` files may no longer +be part of a chain. It is important to remove these files from disk, eventually. +The main reason to delay removal is that another process could read the +`commit-graph-chain` file before it is rewritten, but then look for the +`graph-{hash}` files after they are deleted. + +To allow holding old split commit-graphs for a while after they are unreferenced, +we update the modified times of the files when they become unreferenced. Then, +we scan the `$OBJDIR/info/commit-graphs/` directory for `graph-{hash}` +files whose modified times are older than a given expiry window. This window +defaults to zero, but can be changed using command-line arguments or a config +setting. + +## Chains across multiple object directories + +In a repo with alternates, we look for the `commit-graph-chain` file starting +in the local object directory and then in each alternate. The first file that +exists defines our chain. As we look for the `graph-{hash}` files for +each `{hash}` in the chain file, we follow the same pattern for the host +directories. + +This allows commit-graphs to be split across multiple forks in a fork network. +The typical case is a large "base" repo with many smaller forks. + +As the base repo advances, it will likely update and merge its commit-graph +chain more frequently than the forks. If a fork updates their commit-graph after +the base repo, then it should "reparent" the commit-graph chain onto the new +chain in the base repo. When reading each `graph-{hash}` file, we track +the object directory containing it. During a write of a new commit-graph file, +we check for any changes in the source object directory and read the +`commit-graph-chain` file for that source and create a new file based on those +files. During this "reparent" operation, we necessarily need to collapse all +levels in the fork, as all of the files are invalid against the new base file. + +It is crucial to be careful when cleaning up "unreferenced" `graph-{hash}.graph` +files in this scenario. It falls to the user to define the proper settings for +their custom environment: + + 1. When merging levels in the base repo, the unreferenced files may still be + referenced by chains from fork repos. + + 2. The expiry time should be set to a length of time such that every fork has + time to recompute their commit-graph chain to "reparent" onto the new base + file(s). + + 3. If the commit-graph chain is updated in the base, the fork will not have + access to the new chain until its chain is updated to reference those files. + (This may change in the future [5].) Related Links ------------- @@ -170,3 +344,7 @@ Related Links [4] https://public-inbox.org/git/20180108154822.54829-1-git@jeffhostetler.com/T/#u A patch to remove the ahead-behind calculation from 'status'. + +[5] https://public-inbox.org/git/f27db281-abad-5043-6d71-cbb083b1c877@gmail.com/ + A discussion of a "two-dimensional graph position" that can allow reading + multiple commit-graph chains at the same time. diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index eff7890..8bce75b 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -122,10 +122,10 @@ Tags are expected to always point at the same version of a project, while heads are expected to advance as development progresses. Create a new branch head pointing to one of these versions and check it -out using linkgit:git-checkout[1]: +out using linkgit:git-switch[1]: ------------------------------------------------ -$ git checkout -b new v2.6.13 +$ git switch -c new v2.6.13 ------------------------------------------------ The working directory then reflects the contents that the project had @@ -282,10 +282,10 @@ a summary of the commands: this command will fail with a warning. `git branch -D <branch>`:: delete the branch `<branch>` irrespective of its merged status. -`git checkout <branch>`:: +`git switch <branch>`:: make the current branch `<branch>`, updating the working directory to reflect the version referenced by `<branch>`. -`git checkout -b <new> <start-point>`:: +`git switch -c <new> <start-point>`:: create a new branch `<new>` referencing `<start-point>`, and check it out. @@ -302,22 +302,22 @@ ref: refs/heads/master Examining an old version without creating a new branch ------------------------------------------------------ -The `git checkout` command normally expects a branch head, but will also -accept an arbitrary commit; for example, you can check out the commit -referenced by a tag: +The `git switch` command normally expects a branch head, but will also +accept an arbitrary commit when invoked with --detach; for example, +you can check out the commit referenced by a tag: ------------------------------------------------ -$ git checkout v2.6.17 +$ git switch --detach v2.6.17 Note: checking out 'v2.6.17'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this -state without impacting any branches by performing another checkout. +state without impacting any branches by performing another switch. If you want to create a new branch to retain commits you create, you may -do so (now or later) by using -b with the checkout command again. Example: +do so (now or later) by using -c with the switch command again. Example: - git checkout -b new_branch_name + git switch -c new_branch_name HEAD is now at 427abfa Linux v2.6.17 ------------------------------------------------ @@ -373,7 +373,7 @@ You might want to build on one of these remote-tracking branches on a branch of your own, just as you would for a tag: ------------------------------------------------ -$ git checkout -b my-todo-copy origin/todo +$ git switch -c my-todo-copy origin/todo ------------------------------------------------ You can also check out `origin/todo` directly to examine it or @@ -1408,7 +1408,7 @@ If you get stuck and decide to just give up and throw the whole mess away, you can always return to the pre-merge state with ------------------------------------------------- -$ git reset --hard HEAD +$ git merge --abort ------------------------------------------------- Or, if you've already committed the merge that you want to throw away, @@ -1446,7 +1446,7 @@ mistake, you can return the entire working tree to the last committed state with ------------------------------------------------- -$ git reset --hard HEAD +$ git restore --staged --worktree :/ ------------------------------------------------- If you make a commit that you later wish you hadn't, there are two @@ -1523,12 +1523,10 @@ Checking out an old version of a file In the process of undoing a previous bad change, you may find it useful to check out an older version of a particular file using -linkgit:git-checkout[1]. We've used `git checkout` before to switch -branches, but it has quite different behavior if it is given a path -name: the command +linkgit:git-restore[1]. The command ------------------------------------------------- -$ git checkout HEAD^ path/to/file +$ git restore --source=HEAD^ path/to/file ------------------------------------------------- replaces path/to/file by the contents it had in the commit HEAD^, and @@ -2211,8 +2209,8 @@ $ git branch --track release origin/master These can be easily kept up to date using linkgit:git-pull[1]. ------------------------------------------------- -$ git checkout test && git pull -$ git checkout release && git pull +$ git switch test && git pull +$ git switch release && git pull ------------------------------------------------- Important note! If you have any local changes in these branches, then @@ -2264,7 +2262,7 @@ tested changes 2) help future bug hunters that use `git bisect` to find problems ------------------------------------------------- -$ git checkout -b speed-up-spinlocks v2.6.35 +$ git switch -c speed-up-spinlocks v2.6.35 ------------------------------------------------- Now you apply the patch(es), run some tests, and commit the change(s). If @@ -2279,7 +2277,7 @@ When you are happy with the state of this change, you can merge it into the "test" branch in preparation to make it public: ------------------------------------------------- -$ git checkout test && git merge speed-up-spinlocks +$ git switch test && git merge speed-up-spinlocks ------------------------------------------------- It is unlikely that you would have any conflicts here ... but you might if you @@ -2291,7 +2289,7 @@ see the value of keeping each patch (or patch series) in its own branch. It means that the patches can be moved into the `release` tree in any order. ------------------------------------------------- -$ git checkout release && git merge speed-up-spinlocks +$ git switch release && git merge speed-up-spinlocks ------------------------------------------------- After a while, you will have a number of branches, and despite the @@ -2512,7 +2510,7 @@ Suppose that you create a branch `mywork` on a remote-tracking branch `origin`, and create some commits on top of it: ------------------------------------------------- -$ git checkout -b mywork origin +$ git switch -c mywork origin $ vi file.txt $ git commit $ vi otherfile.txt @@ -2552,7 +2550,7 @@ commits without any merges, you may instead choose to use linkgit:git-rebase[1]: ------------------------------------------------- -$ git checkout mywork +$ git switch mywork $ git rebase origin ------------------------------------------------- @@ -3668,13 +3666,13 @@ change within the submodule, and then update the superproject to reference the new commit: ------------------------------------------------- -$ git checkout master +$ git switch master ------------------------------------------------- or ------------------------------------------------- -$ git checkout -b fix-up +$ git switch -c fix-up ------------------------------------------------- then @@ -3800,8 +3798,8 @@ use linkgit:git-tag[1] for both. The Workflow ------------ -High-level operations such as linkgit:git-commit[1], -linkgit:git-checkout[1] and linkgit:git-reset[1] work by moving data +High-level operations such as linkgit:git-commit[1] and +linkgit:git-restore[1] work by moving data between the working tree, the index, and the object database. Git provides low-level operations which perform each of these steps individually. @@ -4194,7 +4192,7 @@ start. A good place to start is with the contents of the initial commit, with: ---------------------------------------------------- -$ git checkout e83c5163 +$ git switch --detach e83c5163 ---------------------------------------------------- The initial revision lays the foundation for almost everything Git has @@ -4437,10 +4435,10 @@ Managing branches ----------------- ----------------------------------------------- -$ git branch # list all local branches in this repo -$ git checkout test # switch working directory to branch "test" -$ git branch new # create branch "new" starting at current HEAD -$ git branch -d new # delete branch "new" +$ git branch # list all local branches in this repo +$ git switch test # switch working directory to branch "test" +$ git branch new # create branch "new" starting at current HEAD +$ git branch -d new # delete branch "new" ----------------------------------------------- Instead of basing a new branch on current HEAD (the default), use: @@ -4456,7 +4454,7 @@ $ git branch new test~10 # ten commits before tip of branch "test" Create and switch to a new branch at the same time: ----------------------------------------------- -$ git checkout -b new v2.6.15 +$ git switch -c new v2.6.15 ----------------------------------------------- Update and examine branches from the repository you cloned from: @@ -4467,7 +4465,7 @@ $ git branch -r # list origin/master origin/next ... -$ git checkout -b masterwork origin/master +$ git switch -c masterwork origin/master ----------------------------------------------- Fetch a branch from a different repository, and give it a new |