+1

Documentation/MyFirstContribution.adoc

··· 367 367 to `git_config()`. Let's modify the code we wrote in the previous commit. 368 368 369 369 Be sure to include the header to allow you to use `struct wt_status`: 370 370 + 370 371 ---- 371 372 #include "wt-status.h" 372 373 ----

+2

Documentation/MyFirstObjectWalk.adoc

··· 287 287 ==== 288 288 Instead of using the shorthand `add_head_to_pending()`, you could do 289 289 something like this: 290 290 + 290 291 ---- 291 292 struct setup_revision_opt opt; 292 293 ··· 295 296 opt.revarg_opt = REVARG_COMMITTISH; 296 297 setup_revisions(argc, argv, rev, &opt); 297 298 ---- 299 299 + 298 300 Using a `setup_revision_opt` gives you finer control over your walk's starting 299 301 point. 300 302 ====

+1

Documentation/ToolsForGit.adoc

··· 34 34 35 35 - To follow the rules in CodingGuidelines, it's useful to put the following in 36 36 GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode: 37 37 + 37 38 ---- 38 39 ;; note the first part is useful for C editing, too 39 40 ((nil . ((indent-tabs-mode . t)

+1

Documentation/git-bisect.adoc

··· 495 495 ------------ 496 496 + 497 497 or: 498 498 + + 498 499 ------------ 499 500 $ git bisect start --term-old broken --term-new fixed 500 501 $ git bisect fixed

+2 -2

Documentation/git-cat-file.adoc

··· 322 322 323 323 For example, `--batch` without a custom format would produce: 324 324 325 325 - ------------ 325 325 + ----------- 326 326 <oid> SP <type> SP <size> LF 327 327 <contents> LF 328 328 - ------------ 328 328 + ----------- 329 329 330 330 Whereas `--batch-check='%(objectname) %(objecttype)'` would produce: 331 331

+6

Documentation/git-check-attr.adoc

··· 76 76 -------- 77 77 78 78 In the examples, the following '.gitattributes' file is used: 79 79 + 79 80 --------------- 80 81 *.java diff=java -crlf myAttr 81 82 NoMyAttr.java !myAttr ··· 83 84 --------------- 84 85 85 86 * Listing a single attribute: 87 87 + + 86 88 --------------- 87 89 $ git check-attr diff org/example/MyClass.java 88 90 org/example/MyClass.java: diff: java 89 91 --------------- 90 92 91 93 * Listing multiple attributes for a file: 94 94 + + 92 95 --------------- 93 96 $ git check-attr crlf diff myAttr -- org/example/MyClass.java 94 97 org/example/MyClass.java: crlf: unset ··· 97 100 --------------- 98 101 99 102 * Listing all attributes for a file: 103 103 + + 100 104 --------------- 101 105 $ git check-attr --all -- org/example/MyClass.java 102 106 org/example/MyClass.java: diff: java ··· 104 108 --------------- 105 109 106 110 * Listing an attribute for multiple files: 111 111 + + 107 112 --------------- 108 113 $ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java 109 114 org/example/MyClass.java: myAttr: set ··· 111 116 --------------- 112 117 113 118 * Not all values are equally unambiguous: 119 119 + + 114 120 --------------- 115 121 $ git check-attr caveat README 116 122 README: caveat: unspecified

+3

Documentation/git-column.adoc

··· 50 50 -------- 51 51 52 52 Format data by columns: 53 53 + + 53 54 ------------ 54 55 $ seq 1 24 | git column --mode=column --padding=5 55 56 1 4 7 10 13 16 19 22 ··· 58 59 ------------ 59 60 60 61 Format data by rows: 62 62 + + 61 63 ------------ 62 64 $ seq 1 21 | git column --mode=row --padding=5 63 65 1 2 3 4 5 6 7 ··· 66 68 ------------ 67 69 68 70 List some tags in a table with unequal column widths: 71 71 + + 69 72 ------------ 70 73 $ git tag --list 'v2.4.*' --column=row,dense 71 74 v2.4.0 v2.4.0-rc0 v2.4.0-rc1 v2.4.0-rc2 v2.4.0-rc3

+4

Documentation/git-cvsserver.adoc

··· 125 125 pwhash in NetBSD) and paste it in the right location. 126 126 127 127 Then provide your password via the pserver method, for example: 128 128 + 128 129 ------ 129 130 cvs -d:pserver:someuser:somepassword@server:/path/repo.git co <HEAD_name> 130 131 ------ 132 132 + 131 133 No special setup is needed for SSH access, other than having Git tools 132 134 in the PATH. If you have clients that do not accept the CVS_SERVER 133 135 environment variable, you can rename 'git-cvsserver' to `cvs`. ··· 138 140 ------ 139 141 cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name> 140 142 ------ 143 143 + 141 144 This has the advantage that it will be saved in your 'CVS/Root' files and 142 145 you don't need to worry about always setting the correct environment 143 146 variable. SSH users restricted to 'git-shell' don't need to override the default ··· 168 171 access. Valid method names are "ext" (for SSH access) and "pserver". The 169 172 following example configuration would disable pserver access while still 170 173 allowing access over SSH. 174 174 + 171 175 ------ 172 176 [gitcvs] 173 177 enabled=0

+2

Documentation/git-for-each-ref.adoc

··· 441 441 442 442 A simple example showing the use of shell eval on the output, 443 443 demonstrating the use of --shell. List the prefixes of all heads: 444 444 + 444 445 ------------ 445 446 #!/bin/sh 446 447 ··· 455 456 456 457 A bit more elaborate report on tags, demonstrating that the format 457 458 may be an entire script: 459 459 + 458 460 ------------ 459 461 #!/bin/sh 460 462

+14

Documentation/git-p4.adoc

··· 80 80 81 81 To reproduce the entire p4 history in Git, use the '@all' modifier on 82 82 the depot path: 83 83 + 83 84 ------------ 84 85 $ git p4 clone //depot/path/project@all 85 86 ------------ ··· 89 90 ~~~~ 90 91 As development continues in the p4 repository, those changes can 91 92 be included in the Git repository using: 93 93 + 92 94 ------------ 93 95 $ git p4 sync 94 96 ------------ 97 97 + 95 98 This command finds new changes in p4 and imports them as Git commits. 96 99 97 100 P4 repositories can be added to an existing Git repository using 98 101 'git p4 sync' too: 102 102 + 99 103 ------------ 100 104 $ mkdir repo-git 101 105 $ cd repo-git 102 106 $ git init 103 107 $ git p4 sync //path/in/your/perforce/depot 104 108 ------------ 109 109 + 105 110 This imports the specified depot into 106 111 'refs/remotes/p4/master' in an existing Git repository. The 107 112 `--branch` option can be used to specify a different branch to ··· 125 130 is the ultimate location for all code, thus a rebase workflow makes 126 131 sense. This command does 'git p4 sync' followed by 'git rebase' to move 127 132 local commits on top of updated p4 changes. 133 133 + 128 134 ------------ 129 135 $ git p4 rebase 130 136 ------------ ··· 140 146 141 147 To submit all changes that are in the current Git branch but not in 142 148 the 'p4/master' branch, use: 149 149 + 143 150 ------------ 144 151 $ git p4 submit 145 152 ------------ 146 153 147 154 To specify a branch other than the current one, use: 155 155 + 148 156 ------------ 149 157 $ git p4 submit topicbranch 150 158 ------------ 151 159 152 160 To specify a single commit or a range of commits, use: 161 161 + 153 162 ------------ 154 163 $ git p4 submit --commit <sha1> 155 164 $ git p4 submit --commit <sha1..sha1> ··· 510 519 subdirectories in p4, and to generate these as branches in Git. 511 520 512 521 For example, if the P4 repository structure is: 522 522 + 513 523 ---- 514 524 //depot/main/... 515 525 //depot/branch1/... 516 526 ---- 517 527 518 528 And "p4 branch -o branch1" shows a View line that looks like: 529 529 + 519 530 ---- 520 531 //depot/main/... //depot/branch1/... 521 532 ---- 522 533 523 534 Then this 'git p4 clone' command: 535 535 + 524 536 ---- 525 537 git p4 clone --detect-branches //depot@all 526 538 ---- 539 539 + 527 540 produces a separate branch in 'refs/remotes/p4/' for //depot/main, 528 541 called 'master', and one for //depot/branch1 called 'depot/branch1'. 529 542 ··· 536 549 the path elements in the p4 repository. The example above relied on the 537 550 presence of the p4 branch. Without p4 branches, the same result will 538 551 occur with: 552 552 + 539 553 ---- 540 554 git init depot 541 555 cd depot

+3

Documentation/git-rebase.adoc

··· 1107 1107 changes that are already present in the new upstream (unless 1108 1108 `--reapply-cherry-picks` is given). So if you say 1109 1109 (assuming you're on 'topic') 1110 1110 + 1110 1111 ------------ 1111 1112 $ git rebase subsystem 1112 1113 ------------ 1113 1114 you will end up with the fixed history 1115 1115 + 1114 1116 ------------ 1115 1117 o---o---o---o---o---o---o---o master 1116 1118 \ ··· 1145 1147 1146 1148 You can then transplant the old `subsystem..topic` to the new tip by 1147 1149 saying (for the reflog case, and assuming you are on 'topic' already): 1150 1150 + 1148 1151 ------------ 1149 1152 $ git rebase --onto subsystem subsystem@{1} 1150 1153 ------------

+16 -8

Documentation/gitattributes.adoc

··· 531 531 final flush packet. Also note that the "value" of a "key=value" pair 532 532 can contain the "=" character whereas the key would never contain 533 533 that character. 534 534 - ------------------------ 534 534 + 535 535 + ----------------------- 535 536 packet: git> command=smudge 536 537 packet: git> pathname=path/testfile.dat 537 538 packet: git> 0000 538 539 packet: git> CONTENT 539 540 packet: git> 0000 540 540 - ------------------------ 541 541 + ----------------------- 541 542 542 543 The filter is expected to respond with a list of "key=value" pairs 543 544 terminated with a flush packet. If the filter does not experience ··· 559 560 560 561 If the result content is empty then the filter is expected to respond 561 562 with a "success" status and a flush packet to signal the empty content. 563 563 + 562 564 ------------------------ 563 565 packet: git< status=success 564 566 packet: git< 0000 ··· 568 570 569 571 In case the filter cannot or does not want to process the content, 570 572 it is expected to respond with an "error" status. 571 571 - ------------------------ 573 573 + 574 574 + ----------------------- 572 575 packet: git< status=error 573 576 packet: git< 0000 574 574 - ------------------------ 577 577 + ----------------------- 575 578 576 579 If the filter experiences an error during processing, then it can 577 580 send the status "error" after the content was (partially or 578 581 completely) sent. 582 582 + 579 583 ------------------------ 580 584 packet: git< status=success 581 585 packet: git< 0000 ··· 589 593 as well as any future content for the lifetime of the Git process, 590 594 then it is expected to respond with an "abort" status at any point 591 595 in the protocol. 592 592 - ------------------------ 596 596 + 597 597 + ----------------------- 593 598 packet: git< status=abort 594 599 packet: git< 0000 595 595 - ------------------------ 600 600 + ----------------------- 596 601 597 602 Git neither stops nor restarts the filter process in case the 598 603 "error"/"abort" status is set. However, Git sets its exit code ··· 613 618 denotes that the filter can delay filtering the current blob (e.g. to 614 619 compensate network latencies) by responding with no content but with 615 620 the status "delayed" and a flush packet. 616 616 - ------------------------ 621 621 + 622 622 + ----------------------- 617 623 packet: git> command=smudge 618 624 packet: git> pathname=path/testfile.dat 619 625 packet: git> can-delay=1 ··· 622 628 packet: git> 0000 623 629 packet: git< status=delayed 624 630 packet: git< 0000 625 625 - ------------------------ 631 631 + ----------------------- 626 632 627 633 If the filter supports the "delay" capability then it must support the 628 634 "list_available_blobs" command. If Git sends this command, then the ··· 647 653 packet: git< 0000 648 654 ------------------------ 649 655 656 656 + 650 657 After Git received the pathnames, it will request the corresponding 651 658 blobs again. These requests contain a pathname and an empty content 652 659 section. The filter is expected to respond with the smudged content 653 660 in the usual way as explained above. 661 661 + 654 662 ------------------------ 655 663 packet: git> command=smudge 656 664 packet: git> pathname=path/testfile.dat

+1 -1

Documentation/gitcli.adoc

··· 209 209 210 210 However, this is *NOT* allowed for switches with an optional value, where the 211 211 'stuck' form must be used: 212 212 + 212 213 ---------------------------- 213 214 $ git describe --abbrev HEAD # correct 214 215 $ git describe --abbrev=10 HEAD # correct 215 216 $ git describe --abbrev 10 HEAD # NOT WHAT YOU MEANT 216 217 ---------------------------- 217 217 - 218 218 219 219 NOTES ON FREQUENTLY CONFUSED OPTIONS 220 220 ------------------------------------

+2

Documentation/gitprotocol-common.adoc

··· 21 21 22 22 ABNF notation as described by RFC 5234 is used within the protocol documents, 23 23 except the following replacement core rules are used: 24 24 + 24 25 ---- 25 26 HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 26 27 ---- 27 28 28 29 We also define the following common rules: 30 30 + 29 31 ---- 30 32 NUL = %x00 31 33 zero-id = 40*"0"

+11

Documentation/gitweb.adoc

··· 103 103 "Generating projects list using gitweb" section below. 104 104 105 105 Example contents: 106 106 + 106 107 ----------------------------------------------------------------------- 107 108 foo.git Joe+R+Hacker+<joe@example.com> 108 109 foo/bar.git O+W+Ner+<owner@example.org> ··· 124 125 125 126 We assume that GITWEB_CONFIG has its default Makefile value, namely 126 127 'gitweb_config.perl'. Put the following in 'gitweb_make_index.perl' file: 128 128 + 127 129 ---------------------------------------------------------------------------- 128 130 read_config_file("gitweb_config.perl"); 129 131 $projects_list = $projectroot; ··· 518 520 If you use the rewrite rules from the example you *might* also need 519 521 something like the following in your gitweb configuration file 520 522 (`/etc/gitweb.conf` following example): 523 523 + 521 524 ---------------------------------------------------------------------------- 522 525 @stylesheets = ("/some/absolute/path/gitweb.css"); 523 526 $my_uri = "/"; 524 527 $home_link = "/"; 525 528 $per_request_config = 1; 526 529 ---------------------------------------------------------------------------- 530 530 + 527 531 Nowadays though gitweb should create HTML base tag when needed (to set base 528 532 URI for relative links), so it should work automatically. 529 533 ··· 535 539 536 540 The virtual host configuration (in Apache configuration file) should look 537 541 like this: 542 542 + 538 543 -------------------------------------------------------------------------- 539 544 <VirtualHost *:80> 540 545 ServerName git.example.org ··· 575 580 Here actual project root is passed to gitweb via `GITWEB_PROJECT_ROOT` 576 581 environment variable from a web server, so you need to put the following 577 582 line in gitweb configuration file (`/etc/gitweb.conf` in above example): 583 583 + 578 584 -------------------------------------------------------------------------- 579 585 $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/pub/git"; 580 586 -------------------------------------------------------------------------- 587 587 + 581 588 *Note* that this requires to be set for each request, so either 582 589 `$per_request_config` must be false, or the above must be put in code 583 590 referenced by `$per_request_config`; ··· 604 611 PATH_INFO usage 605 612 ~~~~~~~~~~~~~~~ 606 613 If you enable PATH_INFO usage in gitweb by putting 614 614 + 607 615 ---------------------------------------------------------------------------- 608 616 $feature{'pathinfo'}{'default'} = [1]; 609 617 ---------------------------------------------------------------------------- 618 618 + 610 619 in your gitweb configuration file, it is possible to set up your server so 611 620 that it consumes and produces URLs in the form 612 621 ··· 636 645 </Directory> 637 646 </VirtualHost> 638 647 ---------------------------------------------------------------------------- 648 648 + 639 649 The rewrite rule guarantees that existing static files will be properly 640 650 served, whereas any other URL will be passed to gitweb as PATH_INFO 641 651 parameter. ··· 647 657 following: in your project root dir (e.g. `/pub/git`) have the projects 648 658 named *without* a .git extension (e.g. `/pub/git/project` instead of 649 659 `/pub/git/project.git`) and configure Apache as follows: 660 660 + 650 661 ---------------------------------------------------------------------------- 651 662 <VirtualHost *:80> 652 663 ServerAlias git.example.com

+2

Documentation/gitweb.conf.adoc

··· 603 603 604 604 Each `%feature` hash element is a hash reference and has the following 605 605 structure: 606 606 + 606 607 ---------------------------------------------------------------------- 607 608 "<feature-name>" => { 608 609 "sub" => <feature-sub-(subroutine)>, ··· 613 614 Some features cannot be overridden per project. For those 614 615 features the structure of appropriate `%feature` hash element has a simpler 615 616 form: 617 617 + 616 618 ---------------------------------------------------------------------- 617 619 "<feature-name>" => { 618 620 "override" => 0,

+2

Documentation/rev-list-options.adoc

··· 429 429 In the following, we will always refer to the same example history to 430 430 illustrate the differences between simplification settings. We assume 431 431 that you are filtering for a file `foo` in this commit graph: 432 432 + 432 433 ----------------------------------------------------------------------- 433 434 .-A---M---N---O---P---Q 434 435 / / / / / / ··· 436 437 \ / / / / / 437 438 `-------------' X 438 439 ----------------------------------------------------------------------- 440 440 + 439 441 The horizontal line of history A---Q is taken to be the first parent of 440 442 each merge. The commits are: 441 443