From 4523dc8624cf3d494fcc3643a85b8dbb69858e07 Mon Sep 17 00:00:00 2001 From: Ævar Arnfjörð Bjarmason Date: Thu, 22 Jul 2021 14:11:23 +0200 Subject: SubmittingPatches: move discussion of Signed-off-by above "send" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Move the section discussing the addition of a SOB trailer above the section that discusses generating the patch itself. This makes sense as we don't want someone to go through the process of "git format-patch", only to realize late that they should have used "git commit -s" or equivalent. This is a move-only change, no lines here are being altered, only moved around. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano --- Documentation/SubmittingPatches | 158 ++++++++++++++++++++-------------------- 1 file changed, 79 insertions(+), 79 deletions(-) (limited to 'Documentation') diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 3e215f4d80..07e2073155 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -167,6 +167,85 @@ or, on an older version of Git without support for --pretty=reference: git show -s --date=short --pretty='format:%h (%s, %ad)' .... +[[sign-off]] +=== Certify your work by adding your `Signed-off-by` trailer + +To improve tracking of who did what, we ask you to certify that you +wrote the patch or have the right to pass it on under the same license +as ours, by "signing off" your patch. Without sign-off, we cannot +accept your patches. + +If (and only if) you certify the below D-C-O: + +[[dco]] +.Developer's Certificate of Origin 1.1 +____ +By making a contribution to this project, I certify that: + +a. The contribution was created in whole or in part by me and I + have the right to submit it under the open source license + indicated in the file; or + +b. The contribution is based upon previous work that, to the best + of my knowledge, is covered under an appropriate open source + license and I have the right under that license to submit that + work with modifications, whether created in whole or in part + by me, under the same open source license (unless I am + permitted to submit under a different license), as indicated + in the file; or + +c. The contribution was provided directly to me by some other + person who certified (a), (b) or (c) and I have not modified + it. + +d. I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. +____ + +you add a "Signed-off-by" trailer to your commit, that looks like +this: + +.... + Signed-off-by: Random J Developer +.... + +This line can be added by Git if you run the git-commit command with +the -s option. + +Notice that you can place your own `Signed-off-by` trailer when +forwarding somebody else's patch with the above rules for +D-C-O. Indeed you are encouraged to do so. Do not forget to +place an in-body "From: " line at the beginning to properly attribute +the change to its true author (see (2) above). + +This procedure originally came from the Linux kernel project, so our +rule is quite similar to theirs, but what exactly it means to sign-off +your patch differs from project to project, so it may be different +from that of the project you are accustomed to. + +[[real-name]] +Also notice that a real name is used in the `Signed-off-by` trailer. Please +don't hide your real name. + +[[commit-trailers]] +If you like, you can put extra tags at the end: + +. `Reported-by:` is used to credit someone who found the bug that + the patch attempts to fix. +. `Acked-by:` says that the person who is more familiar with the area + the patch attempts to modify liked the patch. +. `Reviewed-by:`, unlike the other tags, can only be offered by the + reviewers themselves when they are completely satisfied with the + patch after a detailed analysis. +. `Tested-by:` is used to indicate that the person applied the patch + and found it to have the desired effect. + +You can also create your own tag or use one that's in common usage +such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:". + [[git-tools]] === Generate your patch using Git tools out of your commits. @@ -302,85 +381,6 @@ Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and `Tested-by:` lines as necessary to credit people who helped your patch, and "cc:" them when sending such a final version for inclusion. -[[sign-off]] -=== Certify your work by adding your `Signed-off-by` trailer - -To improve tracking of who did what, we ask you to certify that you -wrote the patch or have the right to pass it on under the same license -as ours, by "signing off" your patch. Without sign-off, we cannot -accept your patches. - -If (and only if) you certify the below D-C-O: - -[[dco]] -.Developer's Certificate of Origin 1.1 -____ -By making a contribution to this project, I certify that: - -a. The contribution was created in whole or in part by me and I - have the right to submit it under the open source license - indicated in the file; or - -b. The contribution is based upon previous work that, to the best - of my knowledge, is covered under an appropriate open source - license and I have the right under that license to submit that - work with modifications, whether created in whole or in part - by me, under the same open source license (unless I am - permitted to submit under a different license), as indicated - in the file; or - -c. The contribution was provided directly to me by some other - person who certified (a), (b) or (c) and I have not modified - it. - -d. I understand and agree that this project and the contribution - are public and that a record of the contribution (including all - personal information I submit with it, including my sign-off) is - maintained indefinitely and may be redistributed consistent with - this project or the open source license(s) involved. -____ - -you add a "Signed-off-by" trailer to your commit, that looks like -this: - -.... - Signed-off-by: Random J Developer -.... - -This line can be added by Git if you run the git-commit command with -the -s option. - -Notice that you can place your own `Signed-off-by` trailer when -forwarding somebody else's patch with the above rules for -D-C-O. Indeed you are encouraged to do so. Do not forget to -place an in-body "From: " line at the beginning to properly attribute -the change to its true author (see (2) above). - -This procedure originally came from the Linux kernel project, so our -rule is quite similar to theirs, but what exactly it means to sign-off -your patch differs from project to project, so it may be different -from that of the project you are accustomed to. - -[[real-name]] -Also notice that a real name is used in the `Signed-off-by` trailer. Please -don't hide your real name. - -[[commit-trailers]] -If you like, you can put extra tags at the end: - -. `Reported-by:` is used to credit someone who found the bug that - the patch attempts to fix. -. `Acked-by:` says that the person who is more familiar with the area - the patch attempts to modify liked the patch. -. `Reviewed-by:`, unlike the other tags, can only be offered by the - reviewers themselves when they are completely satisfied with the - patch after a detailed analysis. -. `Tested-by:` is used to indicate that the person applied the patch - and found it to have the desired effect. - -You can also create your own tag or use one that's in common usage -such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:". - == Subsystems with dedicated maintainers Some parts of the system have dedicated maintainers with their own -- cgit v1.3-5-g9baa From f003a91f5c5695a44a94efe9171bc905fbfa27ce Mon Sep 17 00:00:00 2001 From: Ævar Arnfjörð Bjarmason Date: Thu, 22 Jul 2021 14:11:24 +0200 Subject: SubmittingPatches: replace discussion of Travis with GitHub Actions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace the discussion of Travis CI added in 0e5d028a7a0 (Documentation: add setup instructions for Travis CI, 2016-05-02) with something that covers the GitHub Actions added in 889cacb6897 (ci: configure GitHub Actions for CI/PR, 2020-04-11). The setup is trivial compared to using Travis, and it even works on Windows (that "hopefully soon" comment was probably out-of-date on Travis as well). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano --- Documentation/SubmittingPatches | 49 ++++++++++++++--------------------------- 1 file changed, 17 insertions(+), 32 deletions(-) (limited to 'Documentation') diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 07e2073155..e409022d93 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -74,10 +74,9 @@ the feature triggers the new behavior when it should, and to show the feature does not trigger when it shouldn't. After any code change, make sure that the entire test suite passes. -If you have an account at GitHub (and you can get one for free to work -on open source projects), you can use their Travis CI integration to -test your changes on Linux, Mac (and hopefully soon Windows). See -GitHub-Travis CI hints section for details. +Pushing to a fork of https://github.com/git/git will use their CI +integration to test your changes on Linux, Mac and Windows. See the +<> section for details. Do not forget to update the documentation to describe the updated behavior and make sure that the resulting documentation set formats @@ -449,13 +448,12 @@ their trees themselves. entitled "What's cooking in git.git" and "What's in git.git" giving the status of various proposed changes. -[[travis]] -== GitHub-Travis CI hints +== GitHub CI[[GHCI]]] -With an account at GitHub (you can get one for free to work on open -source projects), you can use Travis CI to test your changes on Linux, -Mac (and hopefully soon Windows). You can find a successful example -test build here: https://travis-ci.org/git/git/builds/120473209 +With an account at GitHub, you can use GitHub CI to test your changes +on Linux, Mac and Windows. See +https://github.com/git/git/actions/workflows/main.yml for examples of +recent CI runs. Follow these steps for the initial setup: @@ -463,31 +461,18 @@ Follow these steps for the initial setup: You can find detailed instructions how to fork here: https://help.github.com/articles/fork-a-repo/ -. Open the Travis CI website: https://travis-ci.org - -. Press the "Sign in with GitHub" button. - -. Grant Travis CI permissions to access your GitHub account. - You can find more information about the required permissions here: - https://docs.travis-ci.com/user/github-oauth-scopes - -. Open your Travis CI profile page: https://travis-ci.org/profile - -. Enable Travis CI builds for your Git fork. - -After the initial setup, Travis CI will run whenever you push new changes +After the initial setup, CI will run whenever you push new changes to your fork of Git on GitHub. You can monitor the test state of all your -branches here: https://travis-ci.org/____/git/branches +branches here: https://github.com//git/actions/workflows/main.yml If a branch did not pass all test cases then it is marked with a red -cross. In that case you can click on the failing Travis CI job and -scroll all the way down in the log. Find the line "<-- Click here to see -detailed test output!" and click on the triangle next to the log line -number to expand the detailed test output. Here is such a failing -example: https://travis-ci.org/git/git/jobs/122676187 - -Fix the problem and push your fix to your Git fork. This will trigger -a new Travis CI build to ensure all tests pass. +cross. In that case you can click on the failing job and navigate to +"ci/run-build-and-tests.sh" and/or "ci/print-test-failures.sh". You +can also download "Artifacts" which are tarred (or zipped) archives +with test data relevant for debugging. + +Then fix the problem and push your fix to your GitHub fork. This will +trigger a new CI build to ensure all tests pass. [[mua]] == MUA specific hints -- cgit v1.3-5-g9baa From fd441eb612b28e2b0f512ad6d98859c9e82a2cbd Mon Sep 17 00:00:00 2001 From: Philippe Blain Date: Fri, 23 Jul 2021 12:14:28 +0000 Subject: Documentation: define 'MERGE_AUTOSTASH' The documentation for 'git merge --abort' and 'git merge --quit' both mention the special ref 'MERGE_AUTOSTASH', but this ref is not formally defined anywhere. Mention it in the description of the '--autostash' option for 'git merge'. Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano --- Documentation/merge-options.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index eb0aabd396..52565014c1 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -154,7 +154,8 @@ endif::git-pull[] --autostash:: --no-autostash:: Automatically create a temporary stash entry before the operation - begins, and apply it after the operation ends. This means + begins, record it in the special ref `MERGE_AUTOSTASH` + and apply it after the operation ends. This means that you can run the operation on a dirty worktree. However, use with care: the final stash application after a successful merge might result in non-trivial conflicts. -- cgit v1.3-5-g9baa From f0b922473e246f4288669c2ed20a0b4b5d6dec13 Mon Sep 17 00:00:00 2001 From: Andrei Rybak Date: Thu, 29 Jul 2021 13:02:52 +0200 Subject: Documentation: render special characters correctly MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Three hyphens are rendered verbatim, so "--" has to be used to produce a dash. There is no double arrow ("<->" is rendered as "<→"), so a left and right arrow "<-->" have to be combined for that. So fix asciidoc output for special characters. This is similar to fixes in commit de82095a95 (doc hash-function-transition: fix asciidoc output, 2021-02-05). Signed-off-by: Andrei Rybak Acked-by: Jeff King Signed-off-by: Junio C Hamano --- Documentation/git-fetch.txt | 2 +- Documentation/gittutorial.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index 9067c2079e..550c16ca61 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -133,7 +133,7 @@ remember to run that, set `fetch.prune` globally, or linkgit:git-config[1]. Here's where things get tricky and more specific. The pruning feature -doesn't actually care about branches, instead it'll prune local <-> +doesn't actually care about branches, instead it'll prune local <--> remote-references as a function of the refspec of the remote (see `` and <> above). diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index 59ef5cef1f..0e0b863105 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -322,7 +322,7 @@ initiating this "pull". If Bob's work conflicts with what Alice did since their histories forked, Alice will use her working tree and the index to resolve conflicts, and existing local changes will interfere with the conflict resolution process (Git will still perform the fetch but will -refuse to merge --- Alice will have to get rid of her local changes in +refuse to merge -- Alice will have to get rid of her local changes in some way and pull again when this happens). Alice can peek at what Bob did without merging first, using the "fetch" -- cgit v1.3-5-g9baa From e5a14ddd2d93da4d951fd63d4f78fe2410debe68 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 4 Aug 2021 13:09:13 -0700 Subject: The eighth batch Signed-off-by: Junio C Hamano --- Documentation/RelNotes/2.33.0.txt | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/RelNotes/2.33.0.txt b/Documentation/RelNotes/2.33.0.txt index 7960c4f7ab..09cab31e7a 100644 --- a/Documentation/RelNotes/2.33.0.txt +++ b/Documentation/RelNotes/2.33.0.txt @@ -48,7 +48,7 @@ Performance, Internal Implementation, Development Support etc. reduce code duplication. * Repeated rename detections in a sequence of mergy operations have - been optimize out. + been optimized out for the 'ort' merge strategy. * Preliminary clean-up of tests before the main reftable changes hits the codebase. @@ -98,6 +98,11 @@ Performance, Internal Implementation, Development Support etc. * "git read-tree" had a codepath where blobs are fetched one-by-one from the promisor remote, which has been corrected to fetch in bulk. + * Rewrite of "git submodule" in C continues. + + * "git checkout" and "git commit" learn to work without unnecessarily + expanding sparse indexes. + Fixes since v2.32 ----------------- @@ -237,6 +242,14 @@ Fixes since v2.32 * A race between repacking and using pack bitmaps has been corrected. (merge dc1daacdcc jk/check-pack-valid-before-opening-bitmap later to maint). + * The local changes stashed by "git merge --autostash" were lost when + the merge failed in certain ways, which has been corrected. + + * Windows rmdir() equivalent behaves differently from POSIX ones in + that when used on a symbolic link that points at a directory, the + target directory gets removed, which has been corrected. + (merge 3e7d4888e5 tb/mingw-rmdir-symlink-to-directory later to maint). + * Other code cleanup, docfix, build fix, etc. (merge bfe35a6165 ah/doc-describe later to maint). (merge f302c1e4aa jc/clarify-revision-range later to maint). @@ -278,3 +291,5 @@ Fixes since v2.32 (merge ddcb189d9d tb/bitmap-type-filter-comment-fix later to maint). (merge 878b399734 pb/submodule-recurse-doc later to maint). (merge 734283855f jk/config-env-doc later to maint). + (merge 482e1488a9 ab/getcwd-test later to maint). + (merge f0b922473e ar/doc-markup-fix later to maint). -- cgit v1.3-5-g9baa From 6a38e33331560c3e84123c567f95de72d1cfa506 Mon Sep 17 00:00:00 2001 From: Jonathan Nieder Date: Thu, 5 Aug 2021 18:45:23 -0700 Subject: Revert 'diff-merges: let "-m" imply "-p"' This reverts commit f5bfcc823ba242a46e20fb6f71c9fbf7ebb222fe, which made "git log -m" imply "--patch" by default. The logic was that "-m", which makes diff generation for merges perform a diff against each parent, has no use unless I am viewing the diff, so we could save the user some typing by turning on display of the resulting diff automatically. That wasn't expected to adversely affect scripts because scripts would either be using a command like "git diff-tree" that already emits diffs by default or would be combining -m with a diff generation option such as --name-status. By saving typing for interactive use without adversely affecting scripts in the wild, it would be a pure improvement. The problem is that although diff generation options are only relevant for the displayed diff, a script author can imagine them affecting path limiting. For example, I might run git log -w --format=%H -- README hoping to list commits that edited README, excluding whitespace-only changes. In fact, a whitespace-only change is not TREESAME so the use of -w here has no effect (since we don't apply these diff generation flags to the diff_options struct rev_info::pruning used for this purpose), but the documentation suggests that it should work Suppose you specified foo as the . We shall call commits that modify foo !TREESAME, and the rest TREESAME. (In a diff filtered for foo, they look different and equal, respectively.) and a script author who has not tested whitespace-only changes wouldn't notice. Similarly, a script author could include git log -m --first-parent --format=%H -- README to filter the first-parent history for commits that modified README. The -m is a no-op but it reflects the script author's intent. For example, until 1e20a407fe2 (stash list: stop passing "-m" to "git log", 2021-05-21), "git stash list" did this. As a result, we can't safely change "-m" to imply "-p" without fear of breaking such scripts. Restore the previous behavior. Noticed because Rust's src/bootstrap/bootstrap.py made use of this same construct: https://github.com/rust-lang/rust/pull/87513. That script has been updated to omit the unnecessary "-m" option, but we can expect other scripts in the wild to have similar expectations. Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano --- Documentation/diff-options.txt | 8 ++++---- diff-merges.c | 1 - t/t4013-diff-various.sh | 4 ++-- 3 files changed, 6 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 2825783049..6d968b9012 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -49,9 +49,10 @@ ifdef::git-log[] --diff-merges=m::: -m::: This option makes diff output for merge commits to be shown in - the default format. The default format could be changed using + the default format. `-m` will produce the output only if `-p` + is given as well. The default format could be changed using `log.diffMerges` configuration parameter, which default value - is `separate`. `-m` implies `-p`. + is `separate`. + --diff-merges=first-parent::: --diff-merges=1::: @@ -61,8 +62,7 @@ ifdef::git-log[] --diff-merges=separate::: This makes merge commits show the full diff with respect to each of the parents. Separate log entry and diff is generated - for each parent. This is the format that `-m` produced - historically. + for each parent. + --diff-merges=combined::: --diff-merges=c::: diff --git a/diff-merges.c b/diff-merges.c index 0dfcaa1b11..d897fd8a29 100644 --- a/diff-merges.c +++ b/diff-merges.c @@ -107,7 +107,6 @@ int diff_merges_parse_opts(struct rev_info *revs, const char **argv) if (!strcmp(arg, "-m")) { set_to_default(revs); - revs->merges_imply_patch = 1; } else if (!strcmp(arg, "-c")) { set_combined(revs); revs->merges_imply_patch = 1; diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh index 7fadc985cc..e561a8e485 100755 --- a/t/t4013-diff-various.sh +++ b/t/t4013-diff-various.sh @@ -455,8 +455,8 @@ diff-tree --stat --compact-summary initial mode diff-tree -R --stat --compact-summary initial mode EOF -test_expect_success 'log -m matches log -m -p' ' - git log -m -p master >result && +test_expect_success 'log -m matches pure log' ' + git log master >result && process_diffs result >expected && git log -m >result && process_diffs result >actual && -- cgit v1.3-5-g9baa From 5d213e46bb7b880238ff5ea3914e940a50ae9369 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 11 Aug 2021 11:54:03 -0700 Subject: Git 2.33-rc2 Signed-off-by: Junio C Hamano --- Documentation/RelNotes/2.33.0.txt | 12 ------------ GIT-VERSION-GEN | 2 +- 2 files changed, 1 insertion(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RelNotes/2.33.0.txt b/Documentation/RelNotes/2.33.0.txt index 09cab31e7a..afa2663809 100644 --- a/Documentation/RelNotes/2.33.0.txt +++ b/Documentation/RelNotes/2.33.0.txt @@ -1,18 +1,6 @@ Git 2.33 Release Notes ====================== -Backward compatibility notes ----------------------------- - - * The "-m" option in "git log -m" that does not specify which format, - if any, of diff is desired did not have any visible effect; it now - implies some form of diff (by default "--patch") is produced. - - You can disable the diff output with "git log -m --no-patch", but - then there probably isn't much point in passing "-m" in the first - place ;-). - - Updates since Git 2.32 ---------------------- diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN index 504de6536b..98be1eb261 100755 --- a/GIT-VERSION-GEN +++ b/GIT-VERSION-GEN @@ -1,7 +1,7 @@ #!/bin/sh GVF=GIT-VERSION-FILE -DEF_VER=v2.33.0-rc1 +DEF_VER=v2.33.0-rc2 LF=' ' -- cgit v1.3-5-g9baa