diff --git a/Documentation/git-contacts.txt b/Documentation/git-contacts.txt new file mode 100644 index 0000000..dd914d1 --- /dev/null +++ b/Documentation/git-contacts.txt @@ -0,0 +1,94 @@ +git-contacts(1) +=============== + +NAME +---- +git-contacts - List people who might be interested in a set of changes + + +SYNOPSIS +-------- +[verse] +'git contacts' (||)... + + +DESCRIPTION +----------- + +Given a set of changes, specified as patch files or revisions, determine people +who might be interested in those changes. This is done by consulting the +history of each patch or revision hunk to find people mentioned by commits +which touched the lines of files under consideration. + +Input consists of one or more patch files or revision arguments. A revision +argument can be a range or a single `` which is interpreted as +`..HEAD`, thus the same revision arguments are accepted as for +linkgit:git-format-patch[1]. Patch files and revision arguments can be combined +in the same invocation. + +This command can be useful for determining the list of people with whom to +discuss proposed changes, or for finding the list of recipients to Cc: when +submitting a patch series via `git send-email`. For the latter case, `git +contacts` can be used as the argument to `git send-email`'s `--cc-cmd` option. + + +DISCUSSION +---------- + +`git blame` is invoked for each hunk in a patch file or revision. For each +commit mentioned by `git blame`, the commit message is consulted for people who +authored, reviewed, signed, acknowledged, or were Cc:'d. Once the list of +participants is known, each person's relevance is computed by considering how +many commits mentioned that person compared with the total number of commits +under consideration. The final output consists only of participants who exceed +a minimum threshold of participation. + + +OUTPUT +------ + +For each person of interest, a single line is output, terminated by a newline. +If the person's name is known, ``Name $$$$'' is printed; otherwise +only ``$$$$'' is printed. + + +EXAMPLES +-------- + +* Consult patch files: ++ +------------ +$ git contacts feature/*.patch +------------ + +* Revision range: ++ +------------ +$ git contacts R1..R2 +------------ + +* From a single revision to `HEAD`: ++ +------------ +$ git contacts origin +------------ + +* Helper for `git send-email`: ++ +------------ +$ git send-email --cc-cmd='git contacts' feature/*.patch +------------ + + +LIMITATIONS +----------- + +Several conditions controlling a person's significance are currently +hard-coded, such as minimum participation level (10%), blame date-limiting (5 +years), and `-C` level for detecting moved and copied lines (a single `-C`). In +the future, these conditions may become configurable. + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-subtree.txt b/Documentation/git-subtree.txt new file mode 100644 index 0000000..352deda --- /dev/null +++ b/Documentation/git-subtree.txt @@ -0,0 +1,351 @@ +git-subtree(1) +============== + +NAME +---- +git-subtree - Merge subtrees together and split repository into subtrees + + +SYNOPSIS +-------- +[verse] +'git subtree' add -P +'git subtree' add -P +'git subtree' pull -P +'git subtree' push -P +'git subtree' merge -P +'git subtree' split -P [OPTIONS] [] + + +DESCRIPTION +----------- +Subtrees allow subprojects to be included within a subdirectory +of the main project, optionally including the subproject's +entire history. + +For example, you could include the source code for a library +as a subdirectory of your application. + +Subtrees are not to be confused with submodules, which are meant for +the same task. Unlike submodules, subtrees do not need any special +constructions (like .gitmodules files or gitlinks) be present in +your repository, and do not force end-users of your +repository to do anything special or to understand how subtrees +work. A subtree is just a subdirectory that can be +committed to, branched, and merged along with your project in +any way you want. + +They are also not to be confused with using the subtree merge +strategy. The main difference is that, besides merging +the other project as a subdirectory, you can also extract the +entire history of a subdirectory from your project and make it +into a standalone project. Unlike the subtree merge strategy +you can alternate back and forth between these +two operations. If the standalone library gets updated, you can +automatically merge the changes into your project; if you +update the library inside your project, you can "split" the +changes back out again and merge them back into the library +project. + +For example, if a library you made for one application ends up being +useful elsewhere, you can extract its entire history and publish +that as its own git repository, without accidentally +intermingling the history of your application project. + +[TIP] +In order to keep your commit messages clean, we recommend that +people split their commits between the subtrees and the main +project as much as possible. That is, if you make a change that +affects both the library and the main application, commit it in +two pieces. That way, when you split the library commits out +later, their descriptions will still make sense. But if this +isn't important to you, it's not *necessary*. git subtree will +simply leave out the non-library-related parts of the commit +when it splits it out into the subproject later. + + +COMMANDS +-------- +add:: + Create the subtree by importing its contents + from the given or and remote . + A new commit is created automatically, joining the imported + project's history with your own. With '--squash', imports + only a single commit from the subproject, rather than its + entire history. + +merge:: + Merge recent changes up to into the + subtree. As with normal 'git merge', this doesn't + remove your own local changes; it just merges those + changes into the latest . With '--squash', + creates only one commit that contains all the changes, + rather than merging in the entire history. ++ +If you use '--squash', the merge direction doesn't always have to be +forward; you can use this command to go back in time from v2.5 to v2.4, +for example. If your merge introduces a conflict, you can resolve it in +the usual ways. + +pull:: + Exactly like 'merge', but parallels 'git pull' in that + it fetches the given ref from the specified remote + repository. + +push:: + Does a 'split' (see below) using the supplied + and then does a 'git push' to push the result to the + repository and ref. This can be used to push your + subtree to different branches of the remote repository. + +split:: + Extract a new, synthetic project history from the + history of the subtree. The new history + includes only the commits (including merges) that + affected , and each of those commits now has the + contents of at the root of the project instead + of in a subdirectory. Thus, the newly created history + is suitable for export as a separate git repository. ++ +After splitting successfully, a single commit id is printed to stdout. +This corresponds to the HEAD of the newly created tree, which you can +manipulate however you want. ++ +Repeated splits of exactly the same history are guaranteed to be +identical (i.e. to produce the same commit ids). Because of this, if +you add new commits and then re-split, the new commits will be attached +as commits on top of the history you generated last time, so 'git merge' +and friends will work as expected. ++ +Note that if you use '--squash' when you merge, you should usually not +just '--rejoin' when you split. + + +OPTIONS +------- +-q:: +--quiet:: + Suppress unnecessary output messages on stderr. + +-d:: +--debug:: + Produce even more unnecessary output messages on stderr. + +-P :: +--prefix=:: + Specify the path in the repository to the subtree you + want to manipulate. This option is mandatory + for all commands. + +-m :: +--message=:: + This option is only valid for add, merge and pull (unsure). + Specify as the commit message for the merge commit. + + +OPTIONS FOR add, merge, push, pull +---------------------------------- +--squash:: + This option is only valid for add, merge, and pull + commands. ++ +Instead of merging the entire history from the subtree project, produce +only a single commit that contains all the differences you want to +merge, and then merge that new commit into your project. ++ +Using this option helps to reduce log clutter. People rarely want to see +every change that happened between v1.0 and v1.1 of the library they're +using, since none of the interim versions were ever included in their +application. ++ +Using '--squash' also helps avoid problems when the same subproject is +included multiple times in the same project, or is removed and then +re-added. In such a case, it doesn't make sense to combine the +histories anyway, since it's unclear which part of the history belongs +to which subtree. ++ +Furthermore, with '--squash', you can switch back and forth between +different versions of a subtree, rather than strictly forward. 'git +subtree merge --squash' always adjusts the subtree to match the exactly +specified commit, even if getting to that commit would require undoing +some changes that were added earlier. ++ +Whether or not you use '--squash', changes made in your local repository +remain intact and can be later split and send upstream to the +subproject. + + +OPTIONS FOR split +----------------- +--annotate=:: + This option is only valid for the split command. ++ +When generating synthetic history, add as a prefix to each +commit message. Since we're creating new commits with the same commit +message, but possibly different content, from the original commits, this +can help to differentiate them and avoid confusion. ++ +Whenever you split, you need to use the same , or else you +don't have a guarantee that the new re-created history will be identical +to the old one. That will prevent merging from working correctly. git +subtree tries to make it work anyway, particularly if you use --rejoin, +but it may not always be effective. + +-b :: +--branch=:: + This option is only valid for the split command. ++ +After generating the synthetic history, create a new branch called + that contains the new history. This is suitable for immediate +pushing upstream. must not already exist. + +--ignore-joins:: + This option is only valid for the split command. ++ +If you use '--rejoin', git subtree attempts to optimize its history +reconstruction to generate only the new commits since the last +'--rejoin'. '--ignore-join' disables this behaviour, forcing it to +regenerate the entire history. In a large project, this can take a long +time. + +--onto=:: + This option is only valid for the split command. ++ +If your subtree was originally imported using something other than git +subtree, its history may not match what git subtree is expecting. In +that case, you can specify the commit id that corresponds to the +first revision of the subproject's history that was imported into your +project, and git subtree will attempt to build its history from there. ++ +If you used 'git subtree add', you should never need this option. + +--rejoin:: + This option is only valid for the split command. ++ +After splitting, merge the newly created synthetic history back into +your main project. That way, future splits can search only the part of +history that has been added since the most recent --rejoin. ++ +If your split commits end up merged into the upstream subproject, and +then you want to get the latest upstream version, this will allow git's +merge algorithm to more intelligently avoid conflicts (since it knows +these synthetic commits are already part of the upstream repository). ++ +Unfortunately, using this option results in 'git log' showing an extra +copy of every new commit that was created (the original, and the +synthetic one). ++ +If you do all your merges with '--squash', don't use '--rejoin' when you +split, because you don't want the subproject's history to be part of +your project anyway. + + +EXAMPLE 1. Add command +---------------------- +Let's assume that you have a local repository that you would like +to add an external vendor library to. In this case we will add the +git-subtree repository as a subdirectory of your already existing +git-extensions repository in ~/git-extensions/: + + $ git subtree add --prefix=git-subtree --squash \ + git://github.com/apenwarr/git-subtree.git master + +'master' needs to be a valid remote ref and can be a different branch +name + +You can omit the --squash flag, but doing so will increase the number +of commits that are included in your local repository. + +We now have a ~/git-extensions/git-subtree directory containing code +from the master branch of git://github.com/apenwarr/git-subtree.git +in our git-extensions repository. + +EXAMPLE 2. Extract a subtree using commit, merge and pull +--------------------------------------------------------- +Let's use the repository for the git source code as an example. +First, get your own copy of the git.git repository: + + $ git clone git://git.kernel.org/pub/scm/git/git.git test-git + $ cd test-git + +gitweb (commit 1130ef3) was merged into git as of commit +0a8f4f0, after which it was no longer maintained separately. +But imagine it had been maintained separately, and we wanted to +extract git's changes to gitweb since that time, to share with +the upstream. You could do this: + + $ git subtree split --prefix=gitweb --annotate='(split) ' \ + 0a8f4f0^.. --onto=1130ef3 --rejoin \ + --branch gitweb-latest + $ gitk gitweb-latest + $ git push git@github.com:whatever/gitweb.git gitweb-latest:master + +(We use '0a8f4f0^..' because that means "all the changes from +0a8f4f0 to the current version, including 0a8f4f0 itself.") + +If gitweb had originally been merged using 'git subtree add' (or +a previous split had already been done with --rejoin specified) +then you can do all your splits without having to remember any +weird commit ids: + + $ git subtree split --prefix=gitweb --annotate='(split) ' --rejoin \ + --branch gitweb-latest2 + +And you can merge changes back in from the upstream project just +as easily: + + $ git subtree pull --prefix=gitweb \ + git@github.com:whatever/gitweb.git master + +Or, using '--squash', you can actually rewind to an earlier +version of gitweb: + + $ git subtree merge --prefix=gitweb --squash gitweb-latest~10 + +Then make some changes: + + $ date >gitweb/myfile + $ git add gitweb/myfile + $ git commit -m 'created myfile' + +And fast forward again: + + $ git subtree merge --prefix=gitweb --squash gitweb-latest + +And notice that your change is still intact: + + $ ls -l gitweb/myfile + +And you can split it out and look at your changes versus +the standard gitweb: + + git log gitweb-latest..$(git subtree split --prefix=gitweb) + +EXAMPLE 3. Extract a subtree using branch +----------------------------------------- +Suppose you have a source directory with many files and +subdirectories, and you want to extract the lib directory to its own +git project. Here's a short way to do it: + +First, make the new repository wherever you want: + + $ + $ git init --bare + +Back in your original directory: + + $ git subtree split --prefix=lib --annotate="(split)" -b split + +Then push the new branch onto the new empty repository: + + $ git push split:master + + +AUTHOR +------ +Written by Avery Pennarun + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/command-list.txt b/command-list.txt index cbb960c..857e92b 100644 --- a/command-list.txt +++ b/command-list.txt @@ -49,7 +49,6 @@ git-add mainporcelain worktree git-am mainporcelain git-annotate ancillaryinterrogators git-apply plumbingmanipulators complete -git-archimport foreignscminterface git-archive mainporcelain git-bisect mainporcelain info git-blame ancillaryinterrogators complete @@ -77,9 +76,6 @@ git-count-objects ancillaryinterrogators git-credential purehelpers git-credential-cache purehelpers git-credential-store purehelpers -git-cvsexportcommit foreignscminterface -git-cvsimport foreignscminterface -git-cvsserver foreignscminterface git-daemon synchingrepositories git-describe mainporcelain git-diff mainporcelain info @@ -130,7 +126,6 @@ git-mktree plumbingmanipulators git-mv mainporcelain worktree git-name-rev plumbinginterrogators git-notes mainporcelain -git-p4 foreignscminterface git-pack-objects plumbingmanipulators git-pack-redundant plumbinginterrogators git-pack-refs ancillarymanipulators diff --git a/config.mak b/config.mak new file mode 100644 index 0000000..df7fe57 --- /dev/null +++ b/config.mak @@ -0,0 +1,22 @@ +V = 1 +CFLAGS = -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection +LDFLAGS = -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld +NEEDS_CRYPTO_WITH_SSL = 1 +USE_LIBPCRE = 1 +ETC_GITCONFIG = /etc/gitconfig +INSTALL_SYMLINKS = 1 +GITWEB_PROJECTROOT = /var/lib/git +GNU_ROFF = 1 +NO_PERL_CPAN_FALLBACKS = 1 +NO_PYTHON = 1 +# endif with python2 +# endif with asciidoctor +htmldir = /usr/share/doc/git +prefix = /usr +perllibdir = /usr/share/perl5/vendor_perl +gitwebdir = /var/www/git + +# Test options +DEFAULT_TEST_TARGET = prove +GIT_PROVE_OPTS = --verbose --normalize -j64 --formatter=TAP::Formatter::File +GIT_TEST_OPTS = -x --verbose-log diff --git a/contrib/contacts/git-contacts.txt b/contrib/contacts/git-contacts.txt deleted file mode 100644 index dd914d1..0000000 --- a/contrib/contacts/git-contacts.txt +++ /dev/null @@ -1,94 +0,0 @@ -git-contacts(1) -=============== - -NAME ----- -git-contacts - List people who might be interested in a set of changes - - -SYNOPSIS --------- -[verse] -'git contacts' (||)... - - -DESCRIPTION ------------ - -Given a set of changes, specified as patch files or revisions, determine people -who might be interested in those changes. This is done by consulting the -history of each patch or revision hunk to find people mentioned by commits -which touched the lines of files under consideration. - -Input consists of one or more patch files or revision arguments. A revision -argument can be a range or a single `` which is interpreted as -`..HEAD`, thus the same revision arguments are accepted as for -linkgit:git-format-patch[1]. Patch files and revision arguments can be combined -in the same invocation. - -This command can be useful for determining the list of people with whom to -discuss proposed changes, or for finding the list of recipients to Cc: when -submitting a patch series via `git send-email`. For the latter case, `git -contacts` can be used as the argument to `git send-email`'s `--cc-cmd` option. - - -DISCUSSION ----------- - -`git blame` is invoked for each hunk in a patch file or revision. For each -commit mentioned by `git blame`, the commit message is consulted for people who -authored, reviewed, signed, acknowledged, or were Cc:'d. Once the list of -participants is known, each person's relevance is computed by considering how -many commits mentioned that person compared with the total number of commits -under consideration. The final output consists only of participants who exceed -a minimum threshold of participation. - - -OUTPUT ------- - -For each person of interest, a single line is output, terminated by a newline. -If the person's name is known, ``Name $$$$'' is printed; otherwise -only ``$$$$'' is printed. - - -EXAMPLES --------- - -* Consult patch files: -+ ------------- -$ git contacts feature/*.patch ------------- - -* Revision range: -+ ------------- -$ git contacts R1..R2 ------------- - -* From a single revision to `HEAD`: -+ ------------- -$ git contacts origin ------------- - -* Helper for `git send-email`: -+ ------------- -$ git send-email --cc-cmd='git contacts' feature/*.patch ------------- - - -LIMITATIONS ------------ - -Several conditions controlling a person's significance are currently -hard-coded, such as minimum participation level (10%), blame date-limiting (5 -years), and `-C` level for detecting moved and copied lines (a single `-C`). In -the future, these conditions may become configurable. - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt deleted file mode 100644 index 352deda..0000000 --- a/contrib/subtree/git-subtree.txt +++ /dev/null @@ -1,351 +0,0 @@ -git-subtree(1) -============== - -NAME ----- -git-subtree - Merge subtrees together and split repository into subtrees - - -SYNOPSIS --------- -[verse] -'git subtree' add -P -'git subtree' add -P -'git subtree' pull -P -'git subtree' push -P -'git subtree' merge -P -'git subtree' split -P [OPTIONS] [] - - -DESCRIPTION ------------ -Subtrees allow subprojects to be included within a subdirectory -of the main project, optionally including the subproject's -entire history. - -For example, you could include the source code for a library -as a subdirectory of your application. - -Subtrees are not to be confused with submodules, which are meant for -the same task. Unlike submodules, subtrees do not need any special -constructions (like .gitmodules files or gitlinks) be present in -your repository, and do not force end-users of your -repository to do anything special or to understand how subtrees -work. A subtree is just a subdirectory that can be -committed to, branched, and merged along with your project in -any way you want. - -They are also not to be confused with using the subtree merge -strategy. The main difference is that, besides merging -the other project as a subdirectory, you can also extract the -entire history of a subdirectory from your project and make it -into a standalone project. Unlike the subtree merge strategy -you can alternate back and forth between these -two operations. If the standalone library gets updated, you can -automatically merge the changes into your project; if you -update the library inside your project, you can "split" the -changes back out again and merge them back into the library -project. - -For example, if a library you made for one application ends up being -useful elsewhere, you can extract its entire history and publish -that as its own git repository, without accidentally -intermingling the history of your application project. - -[TIP] -In order to keep your commit messages clean, we recommend that -people split their commits between the subtrees and the main -project as much as possible. That is, if you make a change that -affects both the library and the main application, commit it in -two pieces. That way, when you split the library commits out -later, their descriptions will still make sense. But if this -isn't important to you, it's not *necessary*. git subtree will -simply leave out the non-library-related parts of the commit -when it splits it out into the subproject later. - - -COMMANDS --------- -add:: - Create the subtree by importing its contents - from the given or and remote . - A new commit is created automatically, joining the imported - project's history with your own. With '--squash', imports - only a single commit from the subproject, rather than its - entire history. - -merge:: - Merge recent changes up to into the - subtree. As with normal 'git merge', this doesn't - remove your own local changes; it just merges those - changes into the latest . With '--squash', - creates only one commit that contains all the changes, - rather than merging in the entire history. -+ -If you use '--squash', the merge direction doesn't always have to be -forward; you can use this command to go back in time from v2.5 to v2.4, -for example. If your merge introduces a conflict, you can resolve it in -the usual ways. - -pull:: - Exactly like 'merge', but parallels 'git pull' in that - it fetches the given ref from the specified remote - repository. - -push:: - Does a 'split' (see below) using the supplied - and then does a 'git push' to push the result to the - repository and ref. This can be used to push your - subtree to different branches of the remote repository. - -split:: - Extract a new, synthetic project history from the - history of the subtree. The new history - includes only the commits (including merges) that - affected , and each of those commits now has the - contents of at the root of the project instead - of in a subdirectory. Thus, the newly created history - is suitable for export as a separate git repository. -+ -After splitting successfully, a single commit id is printed to stdout. -This corresponds to the HEAD of the newly created tree, which you can -manipulate however you want. -+ -Repeated splits of exactly the same history are guaranteed to be -identical (i.e. to produce the same commit ids). Because of this, if -you add new commits and then re-split, the new commits will be attached -as commits on top of the history you generated last time, so 'git merge' -and friends will work as expected. -+ -Note that if you use '--squash' when you merge, you should usually not -just '--rejoin' when you split. - - -OPTIONS -------- --q:: ---quiet:: - Suppress unnecessary output messages on stderr. - --d:: ---debug:: - Produce even more unnecessary output messages on stderr. - --P :: ---prefix=:: - Specify the path in the repository to the subtree you - want to manipulate. This option is mandatory - for all commands. - --m :: ---message=:: - This option is only valid for add, merge and pull (unsure). - Specify as the commit message for the merge commit. - - -OPTIONS FOR add, merge, push, pull ----------------------------------- ---squash:: - This option is only valid for add, merge, and pull - commands. -+ -Instead of merging the entire history from the subtree project, produce -only a single commit that contains all the differences you want to -merge, and then merge that new commit into your project. -+ -Using this option helps to reduce log clutter. People rarely want to see -every change that happened between v1.0 and v1.1 of the library they're -using, since none of the interim versions were ever included in their -application. -+ -Using '--squash' also helps avoid problems when the same subproject is -included multiple times in the same project, or is removed and then -re-added. In such a case, it doesn't make sense to combine the -histories anyway, since it's unclear which part of the history belongs -to which subtree. -+ -Furthermore, with '--squash', you can switch back and forth between -different versions of a subtree, rather than strictly forward. 'git -subtree merge --squash' always adjusts the subtree to match the exactly -specified commit, even if getting to that commit would require undoing -some changes that were added earlier. -+ -Whether or not you use '--squash', changes made in your local repository -remain intact and can be later split and send upstream to the -subproject. - - -OPTIONS FOR split ------------------ ---annotate=:: - This option is only valid for the split command. -+ -When generating synthetic history, add as a prefix to each -commit message. Since we're creating new commits with the same commit -message, but possibly different content, from the original commits, this -can help to differentiate them and avoid confusion. -+ -Whenever you split, you need to use the same , or else you -don't have a guarantee that the new re-created history will be identical -to the old one. That will prevent merging from working correctly. git -subtree tries to make it work anyway, particularly if you use --rejoin, -but it may not always be effective. - --b :: ---branch=:: - This option is only valid for the split command. -+ -After generating the synthetic history, create a new branch called - that contains the new history. This is suitable for immediate -pushing upstream. must not already exist. - ---ignore-joins:: - This option is only valid for the split command. -+ -If you use '--rejoin', git subtree attempts to optimize its history -reconstruction to generate only the new commits since the last -'--rejoin'. '--ignore-join' disables this behaviour, forcing it to -regenerate the entire history. In a large project, this can take a long -time. - ---onto=:: - This option is only valid for the split command. -+ -If your subtree was originally imported using something other than git -subtree, its history may not match what git subtree is expecting. In -that case, you can specify the commit id that corresponds to the -first revision of the subproject's history that was imported into your -project, and git subtree will attempt to build its history from there. -+ -If you used 'git subtree add', you should never need this option. - ---rejoin:: - This option is only valid for the split command. -+ -After splitting, merge the newly created synthetic history back into -your main project. That way, future splits can search only the part of -history that has been added since the most recent --rejoin. -+ -If your split commits end up merged into the upstream subproject, and -then you want to get the latest upstream version, this will allow git's -merge algorithm to more intelligently avoid conflicts (since it knows -these synthetic commits are already part of the upstream repository). -+ -Unfortunately, using this option results in 'git log' showing an extra -copy of every new commit that was created (the original, and the -synthetic one). -+ -If you do all your merges with '--squash', don't use '--rejoin' when you -split, because you don't want the subproject's history to be part of -your project anyway. - - -EXAMPLE 1. Add command ----------------------- -Let's assume that you have a local repository that you would like -to add an external vendor library to. In this case we will add the -git-subtree repository as a subdirectory of your already existing -git-extensions repository in ~/git-extensions/: - - $ git subtree add --prefix=git-subtree --squash \ - git://github.com/apenwarr/git-subtree.git master - -'master' needs to be a valid remote ref and can be a different branch -name - -You can omit the --squash flag, but doing so will increase the number -of commits that are included in your local repository. - -We now have a ~/git-extensions/git-subtree directory containing code -from the master branch of git://github.com/apenwarr/git-subtree.git -in our git-extensions repository. - -EXAMPLE 2. Extract a subtree using commit, merge and pull ---------------------------------------------------------- -Let's use the repository for the git source code as an example. -First, get your own copy of the git.git repository: - - $ git clone git://git.kernel.org/pub/scm/git/git.git test-git - $ cd test-git - -gitweb (commit 1130ef3) was merged into git as of commit -0a8f4f0, after which it was no longer maintained separately. -But imagine it had been maintained separately, and we wanted to -extract git's changes to gitweb since that time, to share with -the upstream. You could do this: - - $ git subtree split --prefix=gitweb --annotate='(split) ' \ - 0a8f4f0^.. --onto=1130ef3 --rejoin \ - --branch gitweb-latest - $ gitk gitweb-latest - $ git push git@github.com:whatever/gitweb.git gitweb-latest:master - -(We use '0a8f4f0^..' because that means "all the changes from -0a8f4f0 to the current version, including 0a8f4f0 itself.") - -If gitweb had originally been merged using 'git subtree add' (or -a previous split had already been done with --rejoin specified) -then you can do all your splits without having to remember any -weird commit ids: - - $ git subtree split --prefix=gitweb --annotate='(split) ' --rejoin \ - --branch gitweb-latest2 - -And you can merge changes back in from the upstream project just -as easily: - - $ git subtree pull --prefix=gitweb \ - git@github.com:whatever/gitweb.git master - -Or, using '--squash', you can actually rewind to an earlier -version of gitweb: - - $ git subtree merge --prefix=gitweb --squash gitweb-latest~10 - -Then make some changes: - - $ date >gitweb/myfile - $ git add gitweb/myfile - $ git commit -m 'created myfile' - -And fast forward again: - - $ git subtree merge --prefix=gitweb --squash gitweb-latest - -And notice that your change is still intact: - - $ ls -l gitweb/myfile - -And you can split it out and look at your changes versus -the standard gitweb: - - git log gitweb-latest..$(git subtree split --prefix=gitweb) - -EXAMPLE 3. Extract a subtree using branch ------------------------------------------ -Suppose you have a source directory with many files and -subdirectories, and you want to extract the lib directory to its own -git project. Here's a short way to do it: - -First, make the new repository wherever you want: - - $ - $ git init --bare - -Back in your original directory: - - $ git subtree split --prefix=lib --annotate="(split)" -b split - -Then push the new branch onto the new empty repository: - - $ git push split:master - - -AUTHOR ------- -Written by Avery Pennarun - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/git-send-email.perl b/git-send-email.perl index dc95656..8bc0904 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -26,13 +26,13 @@ use Text::ParseWords; use Term::ANSIColor; use File::Temp qw/ tempdir tempfile /; use File::Spec::Functions qw(catdir catfile); -use Git::LoadCPAN::Error qw(:try); +use Error qw(:try); use Cwd qw(abs_path cwd); use Git; use Git::I18N; use Net::Domain (); use Net::SMTP (); -use Git::LoadCPAN::Mail::Address; +use Mail::Address; Getopt::Long::Configure qw/ pass_through /; diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index 0959a78..842aeef 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -91,7 +91,7 @@ our $projectroot = "++GITWEB_PROJECTROOT++"; our $project_maxdepth = "++GITWEB_PROJECT_MAXDEPTH++"; # string of the home link on top of all pages -our $home_link_str = "++GITWEB_HOME_LINK_STR++"; +our $home_link_str = $ENV{"SERVER_NAME"} ? "git://" . $ENV{"SERVER_NAME"} : "projects"; # extra breadcrumbs preceding the home link our @extra_breadcrumbs = (); diff --git a/perl/Git.pm b/perl/Git.pm index 54c9ed0..ca2b186 100644 --- a/perl/Git.pm +++ b/perl/Git.pm @@ -104,7 +104,7 @@ increase notwithstanding). use Carp qw(carp croak); # but croak is bad - throw instead -use Git::LoadCPAN::Error qw(:try); +use Error qw(:try); use Cwd qw(abs_path cwd); use IPC::Open2 qw(open2); use Fcntl qw(SEEK_SET SEEK_CUR); diff --git a/perl/Git/LoadCPAN.pm b/perl/Git/LoadCPAN.pm deleted file mode 100644 index e5585e7..0000000 --- a/perl/Git/LoadCPAN.pm +++ /dev/null @@ -1,104 +0,0 @@ -package Git::LoadCPAN; -use 5.008; -use strict; -use warnings; - -=head1 NAME - -Git::LoadCPAN - Wrapper for loading modules from the CPAN (OS) or Git's own copy - -=head1 DESCRIPTION - -The Perl code in Git depends on some modules from the CPAN, but we -don't want to make those a hard requirement for anyone building from -source. - -Therefore the L namespace shipped with Git contains -wrapper modules like C that will first -attempt to load C from the OS, and if that doesn't work -will fall back on C shipped with Git itself. - -Usually distributors will not ship with Git's Git::FromCPAN tree at -all via the C option, preferring to use their -own packaging of CPAN modules instead. - -This module is only intended to be used for code shipping in the -C repository. Use it for anything else at your peril! - -=cut - -# NO_PERL_CPAN_FALLBACKS_STR evades the sed search-replace from the -# Makefile, and allows for detecting whether the module is loaded from -# perl/Git as opposed to perl/build/Git, which is useful for one-off -# testing without having Error.pm et al installed. -use constant NO_PERL_CPAN_FALLBACKS_STR => '@@' . 'NO_PERL_CPAN_FALLBACKS' . '@@'; -use constant NO_PERL_CPAN_FALLBACKS => ( - q[@@NO_PERL_CPAN_FALLBACKS@@] ne '' - and - q[@@NO_PERL_CPAN_FALLBACKS@@] ne NO_PERL_CPAN_FALLBACKS_STR -); - -sub import { - shift; - my $caller = caller; - my %args = @_; - my $module = exists $args{module} ? delete $args{module} : die "BUG: Expected 'module' parameter!"; - my $import = exists $args{import} ? delete $args{import} : die "BUG: Expected 'import' parameter!"; - die "BUG: Too many arguments!" if keys %args; - - # Foo::Bar to Foo/Bar.pm - my $package_pm = $module; - $package_pm =~ s[::][/]g; - $package_pm .= '.pm'; - - eval { - require $package_pm; - 1; - } or do { - my $error = $@ || "Zombie Error"; - - if (NO_PERL_CPAN_FALLBACKS) { - chomp(my $error = sprintf <<'THEY_PROMISED', $module); -BUG: The '%s' module is not here, but NO_PERL_CPAN_FALLBACKS was set! - -Git needs this Perl module from the CPAN, and will by default ship -with a copy of it. This Git was built with NO_PERL_CPAN_FALLBACKS, -meaning that whoever built it promised to provide this module. - -You're seeing this error because they broke that promise, and we can't -load our fallback version, since we were asked not to install it. - -If you're seeing this error and didn't package Git yourself the -package you're using is broken, or your system is broken. This error -won't appear if Git is built without NO_PERL_CPAN_FALLBACKS (instead -we'll use our fallback version of the module). -THEY_PROMISED - die $error; - } - - my $Git_LoadCPAN_pm_path = $INC{"Git/LoadCPAN.pm"} || die "BUG: Should have our own path from %INC!"; - - require File::Basename; - my $Git_LoadCPAN_pm_root = File::Basename::dirname($Git_LoadCPAN_pm_path) || die "BUG: Can't figure out lib/Git dirname from '$Git_LoadCPAN_pm_path'!"; - - require File::Spec; - my $Git_pm_FromCPAN_root = File::Spec->catdir($Git_LoadCPAN_pm_root, '..', 'FromCPAN'); - die "BUG: '$Git_pm_FromCPAN_root' should be a directory!" unless -d $Git_pm_FromCPAN_root; - - local @INC = ($Git_pm_FromCPAN_root, @INC); - require $package_pm; - }; - - if ($import) { - no strict 'refs'; - *{"${caller}::import"} = sub { - shift; - use strict 'refs'; - unshift @_, $module; - goto &{"${module}::import"}; - }; - use strict 'refs'; - } -} - -1; diff --git a/perl/Git/LoadCPAN/Error.pm b/perl/Git/LoadCPAN/Error.pm deleted file mode 100644 index c6d2c45..0000000 --- a/perl/Git/LoadCPAN/Error.pm +++ /dev/null @@ -1,10 +0,0 @@ -package Git::LoadCPAN::Error; -use 5.008; -use strict; -use warnings; -use Git::LoadCPAN ( - module => 'Error', - import => 1, -); - -1; diff --git a/perl/Git/LoadCPAN/Mail/Address.pm b/perl/Git/LoadCPAN/Mail/Address.pm deleted file mode 100644 index f70a4f0..0000000 --- a/perl/Git/LoadCPAN/Mail/Address.pm +++ /dev/null @@ -1,10 +0,0 @@ -package Git::LoadCPAN::Mail::Address; -use 5.008; -use strict; -use warnings; -use Git::LoadCPAN ( - module => 'Mail::Address', - import => 0, -); - -1; diff --git a/print-failed-test-output b/print-failed-test-output new file mode 100755 index 0000000..68fa9ee --- /dev/null +++ b/print-failed-test-output @@ -0,0 +1,13 @@ +#!/bin/bash + +shopt -s failglob + +# Print output from failing tests +dashes=$(printf "%80s" '' | tr ' ' '-') +for exit_file in t/test-results/*.exit; do + [ "$(cat "$exit_file")" -eq 0 ] && continue + out_file="${exit_file%exit}out" + printf '\n%s\n%s\n%s\n' "$dashes" "$out_file" "$dashes" + cat "$out_file" +done +exit 1