diff options
Diffstat (limited to 'Documentation/howto')
| -rw-r--r-- | Documentation/howto/maintain-git.txt | 353 | ||||
| -rw-r--r-- | Documentation/howto/new-command.txt | 22 | ||||
| -rw-r--r-- | Documentation/howto/rebase-from-internal-branch.txt | 6 | ||||
| -rw-r--r-- | Documentation/howto/rebuild-from-update-hook.txt | 8 | ||||
| -rw-r--r-- | Documentation/howto/recover-corrupted-blob-object.txt | 10 | ||||
| -rw-r--r-- | Documentation/howto/recover-corrupted-object-harder.txt | 242 | ||||
| -rw-r--r-- | Documentation/howto/revert-a-faulty-merge.txt | 10 | ||||
| -rw-r--r-- | Documentation/howto/revert-branch-rebase.txt | 6 | ||||
| -rw-r--r-- | Documentation/howto/setup-git-server-over-http.txt | 26 | ||||
| -rw-r--r-- | Documentation/howto/use-git-daemon.txt | 2 | ||||
| -rw-r--r-- | Documentation/howto/using-signed-tag-in-pull-request.txt | 4 |
11 files changed, 550 insertions, 139 deletions
diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt index ea6e4a52c9..33ae69c11f 100644 --- a/Documentation/howto/maintain-git.txt +++ b/Documentation/howto/maintain-git.txt @@ -1,7 +1,7 @@ From: Junio C Hamano <gitster@pobox.com> Date: Wed, 21 Nov 2007 16:32:55 -0800 Subject: Addendum to "MaintNotes" -Abstract: Imagine that git development is racing along as usual, when our friendly +Abstract: Imagine that Git development is racing along as usual, when our friendly neighborhood maintainer is struck down by a wayward bus. Out of the hordes of suckers (loyal developers), you have been tricked (chosen) to step up as the new maintainer. This howto will show you "how to" do it. @@ -10,35 +10,42 @@ Content-type: text/asciidoc How to maintain Git =================== -The maintainer's git time is spent on three activities. +Activities +---------- - - Communication (60%) +The maintainer's Git time is spent on three activities. + + - Communication (45%) Mailing list discussions on general design, fielding user questions, diagnosing bug reports; reviewing, commenting on, suggesting alternatives to, and rejecting patches. - - Integration (30%) + - Integration (50%) Applying new patches from the contributors while spotting and correcting minor mistakes, shuffling the integration and testing branches, pushing the results out, cutting the releases, and making announcements. - - Own development (10%) + - Own development (5%) Scratching my own itch and sending proposed patch series out. +The Policy +---------- + The policy on Integration is informally mentioned in "A Note from the maintainer" message, which is periodically posted to this mailing list after each feature release is made. -The policy. - - Feature releases are numbered as vX.Y.Z and are meant to contain bugfixes and enhancements in any area, including functionality, performance and usability, without regression. + - One release cycle for a feature release is expected to last for + eight to ten weeks. + - Maintenance releases are numbered as vX.Y.Z.W and are meant to contain only bugfixes for the corresponding vX.Y.Z feature release and earlier maintenance releases vX.Y.Z.V (V < W). @@ -62,12 +69,15 @@ The policy. - 'pu' branch is used to publish other proposed changes that do not yet pass the criteria set for 'next'. - - The tips of 'master', 'maint' and 'next' branches will always - fast-forward, to allow people to build their own - customization on top of them. + - The tips of 'master' and 'maint' branches will not be rewound to + allow people to build their own customization on top of them. + Early in a new development cycle, 'next' is rewound to the tip of + 'master' once, but otherwise it will not be rewound until the end + of the cycle. - - Usually 'master' contains all of 'maint', 'next' contains all - of 'master' and 'pu' contains all of 'next'. + - Usually 'master' contains all of 'maint' and 'next' contains all + of 'master'. 'pu' contains all the topics merged to 'next', but + is rebuilt directly on 'master'. - The tip of 'master' is meant to be more stable than any tagged releases, and the users are encouraged to follow it. @@ -77,14 +87,22 @@ The policy. are found before new topics are merged to 'master'. -A typical git day for the maintainer implements the above policy +A Typical Git Day +----------------- + +A typical Git day for the maintainer implements the above policy by doing the following: - - Scan mailing list and #git channel log. Respond with review - comments, suggestions etc. Kibitz. Collect potentially - usable patches from the mailing list. Patches about a single - topic go to one mailbox (I read my mail in Gnus, and type - \C-o to save/append messages in files in mbox format). + - Scan mailing list. Respond with review comments, suggestions + etc. Kibitz. Collect potentially usable patches from the + mailing list. Patches about a single topic go to one mailbox (I + read my mail in Gnus, and type \C-o to save/append messages in + files in mbox format). + + - Write his own patches to address issues raised on the list but + nobody has stepped up solving. Send it out just like other + contributors do, and pick them up just like patches from other + contributors (see above). - Review the patches in the saved mailboxes. Edit proposed log message for typofixes and clarifications, and add Acks @@ -100,40 +118,32 @@ by doing the following: - Obviously correct fixes that pertain to the tip of 'master' are directly applied to 'master'. + - Other topics are not handled in this step. + This step is done with "git am". $ git checkout master ;# or "git checkout maint" - $ git am -3 -s mailbox + $ git am -sc3 mailbox $ make test - - Merge downwards (maint->master): - - $ git checkout master - $ git merge maint - $ make test + In practice, almost no patch directly goes to 'master' or + 'maint'. - Review the last issue of "What's cooking" message, review the - topics scheduled for merging upwards (topic->master and - topic->maint), and merge. + topics ready for merging (topic->master and topic->maint). Use + "Meta/cook -w" script (where Meta/ contains a checkout of the + 'todo' branch) to aid this step. + + And perform the merge. Use "Meta/Reintegrate -e" script (see + later) to aid this step. + + $ Meta/cook -w last-issue-of-whats-cooking.mbox $ git checkout master ;# or "git checkout maint" - $ git merge ai/topic ;# or "git merge ai/maint-topic" + $ echo ai/topic | Meta/Reintegrate -e ;# "git merge ai/topic" $ git log -p ORIG_HEAD.. ;# final review $ git diff ORIG_HEAD.. ;# final review $ make test ;# final review - $ git branch -d ai/topic ;# or "git branch -d ai/maint-topic" - - - Merge downwards (maint->master) if needed: - - $ git checkout master - $ git merge maint - $ make test - - - Merge downwards (master->next) if needed: - - $ git checkout next - $ git merge master - $ make test - Handle the remaining patches: @@ -142,9 +152,9 @@ by doing the following: and not in 'master') is applied to a new topic branch that is forked from the tip of 'master'. This includes both enhancements and unobvious fixes to 'master'. A topic - branch is named as ai/topic where "ai" is typically - author's initial and "topic" is a descriptive name of the - topic (in other words, "what's the series is about"). + branch is named as ai/topic where "ai" is two-letter string + named after author's initial and "topic" is a descriptive name + of the topic (in other words, "what's the series is about"). - An unobvious fix meant for 'maint' is applied to a new topic branch that is forked from the tip of 'maint'. The @@ -162,7 +172,8 @@ by doing the following: The above except the "replacement" are all done with: - $ git am -3 -s mailbox + $ git checkout ai/topic ;# or "git checkout -b ai/topic master" + $ git am -sc3 mailbox while patch replacement is often done by: @@ -170,93 +181,170 @@ by doing the following: then replace some parts with the new patch, and reapplying: + $ git checkout ai/topic $ git reset --hard ai/topic~$n - $ git am -3 -s 000*.txt + $ git am -sc3 -s 000*.txt The full test suite is always run for 'maint' and 'master' after patch application; for topic branches the tests are run as time permits. - - Update "What's cooking" message to review the updates to - existing topics, newly added topics and graduated topics. + - Merge maint to master as needed: - This step is helped with Meta/cook script (where Meta/ contains - a checkout of the 'todo' branch). - - - Merge topics to 'next'. For each branch whose tip is not - merged to 'next', one of three things can happen: + $ git checkout master + $ git merge maint + $ make test - - The commits are all next-worthy; merge the topic to next: + - Merge master to next as needed: $ git checkout next - $ git merge ai/topic ;# or "git merge ai/maint-topic" + $ git merge master $ make test + - Review the last issue of "What's cooking" again and see if topics + that are ready to be merged to 'next' are still in good shape + (e.g. has there any new issue identified on the list with the + series?) + + - Prepare 'jch' branch, which is used to represent somewhere + between 'master' and 'pu' and often is slightly ahead of 'next'. + + $ Meta/Reintegrate master..pu >Meta/redo-jch.sh + + The result is a script that lists topics to be merged in order to + rebuild 'pu' as the input to Meta/Reintegrate script. Remove + later topics that should not be in 'jch' yet. Add a line that + consists of '### match next' before the name of the first topic + in the output that should be in 'jch' but not in 'next' yet. + + - Now we are ready to start merging topics to 'next'. For each + branch whose tip is not merged to 'next', one of three things can + happen: + + - The commits are all next-worthy; merge the topic to next; - The new parts are of mixed quality, but earlier ones are - next-worthy; merge the early parts to next: + next-worthy; merge the early parts to next; + - Nothing is next-worthy; do not do anything. + + This step is aided with Meta/redo-jch.sh script created earlier. + If a topic that was already in 'next' gained a patch, the script + would list it as "ai/topic~1". To include the new patch to the + updated 'next', drop the "~1" part; to keep it excluded, do not + touch the line. If a topic that was not in 'next' should be + merged to 'next', add it at the end of the list. Then: + + $ git checkout -B jch master + $ Meta/redo-jch.sh -c1 + + to rebuild the 'jch' branch from scratch. "-c1" tells the script + to stop merging at the first line that begins with '###' + (i.e. the "### match next" line you added earlier). + + At this point, build-test the result. It may reveal semantic + conflicts (e.g. a topic renamed a variable, another added a new + reference to the variable under its old name), in which case + prepare an appropriate merge-fix first (see appendix), and + rebuild the 'jch' branch from scratch, starting at the tip of + 'master'. + + Then do the same to 'next' $ git checkout next - $ git merge ai/topic~2 ;# the tip two are dubious - $ make test + $ sh Meta/redo-jch.sh -c1 -e - - Nothing is next-worthy; do not do anything. + The "-e" option allows the merge message that comes from the + history of the topic and the comments in the "What's cooking" to + be edited. The resulting tree should match 'jch' as the same set + of topics are merged on 'master'; otherwise there is a mismerge. + Investigate why and do not proceed until the mismerge is found + and rectified. - - [** OBSOLETE **] Optionally rebase topics that do not have any commit - in next yet, when they can take advantage of low-level framework - change that is merged to 'master' already. + $ git diff jch next - $ git rebase master ai/topic + When all is well, clean up the redo-jch.sh script with - This step is helped with Meta/git-topic.perl script to - identify which topic is rebaseable. There also is a - pre-rebase hook to make sure that topics that are already in - 'next' are not rebased beyond the merged commit. + $ sh Meta/redo-jch.sh -u - - [** OBSOLETE **] Rebuild "pu" to merge the tips of topics not in 'next'. + This removes topics listed in the script that have already been + merged to 'master'. This may lose '### match next' marker; + add it again to the appropriate place when it happens. - $ git checkout pu - $ git reset --hard next - $ git merge ai/topic ;# repeat for all remaining topics - $ make test + - Rebuild 'pu'. - This step is helped with Meta/PU script + $ Meta/Reintegrate master..pu >Meta/redo-pu.sh - - Push four integration branches to a private repository at - k.org and run "make test" on all of them. + Edit the result by adding new topics that are not still in 'pu' + in the script. Then - - Push four integration branches to /pub/scm/git/git.git at - k.org. This triggers its post-update hook which: + $ git checkout -B pu jch + $ sh Meta/redo-pu.sh - (1) runs "git pull" in $HOME/git-doc/ repository to pull - 'master' just pushed out; + When all is well, clean up the redo-pu.sh script with - (2) runs "make doc" in $HOME/git-doc/, install the generated - documentation in staging areas, which are separate - repositories that have html and man branches checked - out. + $ sh Meta/redo-pu.sh -u - (3) runs "git commit" in the staging areas, and run "git - push" back to /pub/scm/git/git.git/ to update the html - and man branches. + Double check by running - (4) installs generated documentation to /pub/software/scm/git/docs/ - to be viewed from http://www.kernel.org/ + $ git branch --no-merged pu - - Fetch html and man branches back from k.org, and push four - integration branches and the two documentation branches to - repo.or.cz and other mirrors. + to see there is no unexpected leftover topics. + At this point, build-test the result for semantic conflicts, and + if there are, prepare an appropriate merge-fix first (see + appendix), and rebuild the 'pu' branch from scratch, starting at + the tip of 'jch'. + + - Update "What's cooking" message to review the updates to + existing topics, newly added topics and graduated topics. + + This step is helped with Meta/cook script. + + $ Meta/cook + + This script inspects the history between master..pu, finds tips + of topic branches, compares what it found with the current + contents in Meta/whats-cooking.txt, and updates that file. + Topics not listed in the file but are found in master..pu are + added to the "New topics" section, topics listed in the file that + are no longer found in master..pu are moved to the "Graduated to + master" section, and topics whose commits changed their states + (e.g. used to be only in 'pu', now merged to 'next') are updated + with change markers "<<" and ">>". + + Look for lines enclosed in "<<" and ">>"; they hold contents from + old file that are replaced by this integration round. After + verifying them, remove the old part. Review the description for + each topic and update its doneness and plan as needed. To review + the updated plan, run + + $ Meta/cook -w + + which will pick up comments given to the topics, such as "Will + merge to 'next'", etc. (see Meta/cook script to learn what kind + of phrases are supported). + + - Compile, test and install all four (five) integration branches; + Meta/Dothem script may aid this step. + + - Format documentation if the 'master' branch was updated; + Meta/dodoc.sh script may aid this step. + + - Push the integration branches out to public places; Meta/pushall + script may aid this step. + +Observations +------------ Some observations to be made. - * Each topic is tested individually, and also together with - other topics cooking in 'next'. Until it matures, none part - of it is merged to 'master'. + * Each topic is tested individually, and also together with other + topics cooking first in 'pu', then in 'jch' and then in 'next'. + Until it matures, no part of it is merged to 'master'. * A topic already in 'next' can get fixes while still in 'next'. Such a topic will have many merges to 'next' (in other words, "git log --first-parent next" will show many - "Merge ai/topic to next" for the same topic. + "Merge branch 'ai/topic' to next" for the same topic. * An unobvious fix for 'maint' is cooked in 'next' and then merged to 'master' to make extra sure it is Ok and then @@ -278,3 +366,80 @@ Some observations to be made. * Being in the 'next' branch is not a guarantee for a topic to be included in the next feature release. Being in the 'master' branch typically is. + + +Appendix +-------- + +Preparing a "merge-fix" +~~~~~~~~~~~~~~~~~~~~~~~ + +A merge of two topics may not textually conflict but still have +conflict at the semantic level. A classic example is for one topic +to rename an variable and all its uses, while another topic adds a +new use of the variable under its old name. When these two topics +are merged together, the reference to the variable newly added by +the latter topic will still use the old name in the result. + +The Meta/Reintegrate script that is used by redo-jch and redo-pu +scripts implements a crude but usable way to work this issue around. +When the script merges branch $X, it checks if "refs/merge-fix/$X" +exists, and if so, the effect of it is squashed into the result of +the mechanical merge. In other words, + + $ echo $X | Meta/Reintegrate + +is roughly equivalent to this sequence: + + $ git merge --rerere-autoupdate $X + $ git commit + $ git cherry-pick -n refs/merge-fix/$X + $ git commit --amend + +The goal of this "prepare a merge-fix" step is to come up with a +commit that can be squashed into a result of mechanical merge to +correct semantic conflicts. + +After finding that the result of merging branch "ai/topic" to an +integration branch had such a semantic conflict, say pu~4, check the +problematic merge out on a detached HEAD, edit the working tree to +fix the semantic conflict, and make a separate commit to record the +fix-up: + + $ git checkout pu~4 + $ git show -s --pretty=%s ;# double check + Merge branch 'ai/topic' to pu + $ edit + $ git commit -m 'merge-fix/ai/topic' -a + +Then make a reference "refs/merge-fix/ai/topic" to point at this +result: + + $ git update-ref refs/merge-fix/ai/topic HEAD + +Then double check the result by asking Meta/Reintegrate to redo the +merge: + + $ git checkout pu~5 ;# the parent of the problem merge + $ echo ai/topic | Meta/Reintegrate + $ git diff pu~4 + +This time, because you prepared refs/merge-fix/ai/topic, the +resulting merge should have been tweaked to include the fix for the +semantic conflict. + +Note that this assumes that the order in which conflicting branches +are merged does not change. If the reason why merging ai/topic +branch needs this merge-fix is because another branch merged earlier +to the integration branch changed the underlying assumption ai/topic +branch made (e.g. ai/topic branch added a site to refer to a +variable, while the other branch renamed that variable and adjusted +existing use sites), and if you changed redo-jch (or redo-pu) script +to merge ai/topic branch before the other branch, then the above +merge-fix should not be applied while merging ai/topic, but should +instead be applied while merging the other branch. You would need +to move the fix to apply to the other branch, perhaps like this: + + $ mf=refs/merge-fix + $ git update-ref $mf/$the_other_branch $mf/ai/topic + $ git update-ref -d $mf/ai/topic diff --git a/Documentation/howto/new-command.txt b/Documentation/howto/new-command.txt index 36502f6718..d7de5a3e9e 100644 --- a/Documentation/howto/new-command.txt +++ b/Documentation/howto/new-command.txt @@ -1,25 +1,25 @@ From: Eric S. Raymond <esr@thyrsus.com> Abstract: This is how-to documentation for people who want to add extension - commands to git. It should be read alongside api-builtin.txt. + commands to Git. It should be read alongside api-builtin.txt. Content-type: text/asciidoc How to integrate new subcommands ================================ This is how-to documentation for people who want to add extension -commands to git. It should be read alongside api-builtin.txt. +commands to Git. It should be read alongside api-builtin.txt. Runtime environment ------------------- -git subcommands are standalone executables that live in the git exec +Git subcommands are standalone executables that live in the Git exec path, normally /usr/lib/git-core. The git executable itself is a thin wrapper that knows where the subcommands live, and runs them by passing command-line arguments to them. -(If "git foo" is not found in the git exec path, the wrapper +(If "git foo" is not found in the Git exec path, the wrapper will look in the rest of your $PATH for it. Thus, it's possible -to write local git extensions that don't live in system space.) +to write local Git extensions that don't live in system space.) Implementation languages ------------------------ @@ -30,13 +30,13 @@ Perl. While we strongly encourage coding in portable C for portability, these specific scripting languages are also acceptable. We won't accept more without a very strong technical case, as we don't want -to broaden the git suite's required dependencies. Import utilities, +to broaden the Git suite's required dependencies. Import utilities, surgical tools, remote helpers and other code at the edges of the -git suite are more lenient and we allow Python (and even Tcl/tk), +Git suite are more lenient and we allow Python (and even Tcl/tk), but they should not be used for core functions. This may change in the future. Especially Python is not allowed in -core because we need better Python integration in the git Windows +core because we need better Python integration in the Git Windows installer before we can be confident people in that environment won't experience an unacceptably large loss of capability. @@ -54,7 +54,7 @@ functions available to built-in commands written in C. What every extension command needs ---------------------------------- -You must have a man page, written in asciidoc (this is what git help +You must have a man page, written in asciidoc (this is what Git help followed by your subcommand name will display). Be aware that there is a local asciidoc configuration and macros which you should use. It's often helpful to start by cloning an existing page and replacing the @@ -74,7 +74,7 @@ Integrating a command --------------------- Here are the things you need to do when you want to merge a new -subcommand into the git tree. +subcommand into the Git tree. 1. Don't forget to sign off your patch! @@ -94,7 +94,7 @@ your language, document it in the INSTALL file. 6. There is a file command-list.txt in the distribution main directory that categorizes commands by type, so they can be listed in appropriate subsections in the documentation's summary command list. Add an entry -for yours. To understand the categories, look at git-cmmands.txt +for yours. To understand the categories, look at git-commands.txt in the main directory. 7. Give the maintainer one paragraph to include in the RelNotes file diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt index 4627ee47f2..19ab604f1f 100644 --- a/Documentation/howto/rebase-from-internal-branch.txt +++ b/Documentation/howto/rebase-from-internal-branch.txt @@ -4,7 +4,7 @@ Cc: Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org> Subject: Re: sending changesets from the middle of a git tree Date: Sun, 14 Aug 2005 18:37:39 -0700 Abstract: In this article, JC talks about how he rebases the - public "pu" branch using the core GIT tools when he updates + public "pu" branch using the core Git tools when he updates the "master" branch, and how "rebase" works. Also discussed is how this applies to individual developers who sends patches upstream. @@ -31,7 +31,7 @@ up. With its basing philosophical ancestry on quilt, this is the kind of task StGIT is designed to do. I just have done a simpler one, this time using only the core -GIT tools. +Git tools. I had a handful of commits that were ahead of master in pu, and I wanted to add some documentation bypassing my usual habit of @@ -96,7 +96,7 @@ you ran fsck-cache, which is normal. After testing "pu", you can run "git prune" to get rid of those original three commits. While I am talking about "git rebase", I should talk about how -to do cherrypicking using only the core GIT tools. +to do cherrypicking using only the core Git tools. Let's go back to the earlier picture, with different labels. diff --git a/Documentation/howto/rebuild-from-update-hook.txt b/Documentation/howto/rebuild-from-update-hook.txt index 00c1b45b79..25378f68d3 100644 --- a/Documentation/howto/rebuild-from-update-hook.txt +++ b/Documentation/howto/rebuild-from-update-hook.txt @@ -3,7 +3,7 @@ Message-ID: <7vy86o6usx.fsf@assigned-by-dhcp.cox.net> From: Junio C Hamano <gitster@pobox.com> Date: Fri, 26 Aug 2005 18:19:10 -0700 Abstract: In this how-to article, JC talks about how he - uses the post-update hook to automate git documentation page + uses the post-update hook to automate Git documentation page shown at http://www.kernel.org/pub/software/scm/git/docs/. Content-type: text/asciidoc @@ -15,11 +15,11 @@ are built from Documentation/ directory of the git.git project and needed to be kept up-to-date. The www.kernel.org/ servers are mirrored and I was told that the origin of the mirror is on the machine $some.kernel.org, on which I was given an account -when I took over git maintainership from Linus. +when I took over Git maintainership from Linus. The directories relevant to this how-to are these two: - /pub/scm/git/git.git/ The public git repository. + /pub/scm/git/git.git/ The public Git repository. /pub/software/scm/git/docs/ The HTML documentation page. So I made a repository to generate the documentation under my @@ -46,7 +46,7 @@ script: EOF Initially I used to run this by hand whenever I push into the -public git repository. Then I did a cron job that ran twice a +public Git repository. Then I did a cron job that ran twice a day. The current round uses the post-update hook mechanism, like this: diff --git a/Documentation/howto/recover-corrupted-blob-object.txt b/Documentation/howto/recover-corrupted-blob-object.txt index 7484735320..1b3b188d3c 100644 --- a/Documentation/howto/recover-corrupted-blob-object.txt +++ b/Documentation/howto/recover-corrupted-blob-object.txt @@ -15,12 +15,12 @@ On Fri, 9 Nov 2007, Yossi Leybovich wrote: > Any one know how can I track this object and understand which file is it ----------------------------------------------------------- -So exactly *because* the SHA1 hash is cryptographically secure, the hash +So exactly *because* the SHA-1 hash is cryptographically secure, the hash itself doesn't actually tell you anything, in order to fix a corrupt object you basically have to find the "original source" for it. The easiest way to do that is almost always to have backups, and find the -same object somewhere else. Backups really are a good idea, and git makes +same object somewhere else. Backups really are a good idea, and Git makes it pretty easy (if nothing else, just clone the repository somewhere else, and make sure that you do *not* use a hard-linked clone, and preferably not the same disk/machine). @@ -44,7 +44,7 @@ So: ----------------------------------------------------------- This is the right thing to do, although it's usually best to save it under -it's full SHA1 name (you just dropped the "4b" from the result ;). +it's full SHA-1 name (you just dropped the "4b" from the result ;). Let's see what that tells us: @@ -89,7 +89,7 @@ working tree, in which case fixing this problem is really simple, just do git hash-object -w my-magic-file -again, and if it outputs the missing SHA1 (4b945..) you're now all done! +again, and if it outputs the missing SHA-1 (4b945..) you're now all done! But that's the really lucky case, so let's assume that it was some older version that was broken. How do you tell which version it was? @@ -134,7 +134,7 @@ and your repository is good again! git log --raw --all and just looked for the sha of the missing object (4b9458b..) in that -whole thing. It's up to you - git does *have* a lot of information, it is +whole thing. It's up to you - Git does *have* a lot of information, it is just missing one particular blob version. Trying to recreate trees and especially commits is *much* harder. So you diff --git a/Documentation/howto/recover-corrupted-object-harder.txt b/Documentation/howto/recover-corrupted-object-harder.txt new file mode 100644 index 0000000000..6f33dac0e0 --- /dev/null +++ b/Documentation/howto/recover-corrupted-object-harder.txt @@ -0,0 +1,242 @@ +Date: Wed, 16 Oct 2013 04:34:01 -0400 +From: Jeff King <peff@peff.net> +Subject: pack corruption post-mortem +Abstract: Recovering a corrupted object when no good copy is available. +Content-type: text/asciidoc + +How to recover an object from scratch +===================================== + +I was recently presented with a repository with a corrupted packfile, +and was asked if the data was recoverable. This post-mortem describes +the steps I took to investigate and fix the problem. I thought others +might find the process interesting, and it might help somebody in the +same situation. + +******************************** +Note: In this case, no good copy of the repository was available. For +the much easier case where you can get the corrupted object from +elsewhere, see link:recover-corrupted-blob-object.html[this howto]. +******************************** + +I started with an fsck, which found a problem with exactly one object +(I've used $pack and $obj below to keep the output readable, and also +because I'll refer to them later): + +----------- + $ git fsck + error: $pack SHA1 checksum mismatch + error: index CRC mismatch for object $obj from $pack at offset 51653873 + error: inflate: data stream error (incorrect data check) + error: cannot unpack $obj from $pack at offset 51653873 +----------- + +The pack checksum failing means a byte is munged somewhere, and it is +presumably in the object mentioned (since both the index checksum and +zlib were failing). + +Reading the zlib source code, I found that "incorrect data check" means +that the adler-32 checksum at the end of the zlib data did not match the +inflated data. So stepping the data through zlib would not help, as it +did not fail until the very end, when we realize the crc does not match. +The problematic bytes could be anywhere in the object data. + +The first thing I did was pull the broken data out of the packfile. I +needed to know how big the object was, which I found out with: + +------------ + $ git show-index <$idx | cut -d' ' -f1 | sort -n | grep -A1 51653873 + 51653873 + 51664736 +------------ + +Show-index gives us the list of objects and their offsets. We throw away +everything but the offsets, and then sort them so that our interesting +offset (which we got from the fsck output above) is followed immediately +by the offset of the next object. Now we know that the object data is +10863 bytes long, and we can grab it with: + +------------ + dd if=$pack of=object bs=1 skip=51653873 count=10863 +------------ + +I inspected a hexdump of the data, looking for any obvious bogosity +(e.g., a 4K run of zeroes would be a good sign of filesystem +corruption). But everything looked pretty reasonable. + +Note that the "object" file isn't fit for feeding straight to zlib; it +has the git packed object header, which is variable-length. We want to +strip that off so we can start playing with the zlib data directly. You +can either work your way through it manually (the format is described in +link:../technical/pack-format.html[Documentation/technical/pack-format.txt]), +or you can walk through it in a debugger. I did the latter, creating a +valid pack like: + +------------ + # pack magic and version + printf 'PACK\0\0\0\2' >tmp.pack + # pack has one object + printf '\0\0\0\1' >>tmp.pack + # now add our object data + cat object >>tmp.pack + # and then append the pack trailer + /path/to/git.git/test-sha1 -b <tmp.pack >trailer + cat trailer >>tmp.pack +------------ + +and then running "git index-pack tmp.pack" in the debugger (stop at +unpack_raw_entry). Doing this, I found that there were 3 bytes of header +(and the header itself had a sane type and size). So I stripped those +off with: + +------------ + dd if=object of=zlib bs=1 skip=3 +------------ + +I ran the result through zlib's inflate using a custom C program. And +while it did report the error, I did get the right number of output +bytes (i.e., it matched git's size header that we decoded above). But +feeding the result back to "git hash-object" didn't produce the same +sha1. So there were some wrong bytes, but I didn't know which. The file +happened to be C source code, so I hoped I could notice something +obviously wrong with it, but I didn't. I even got it to compile! + +I also tried comparing it to other versions of the same path in the +repository, hoping that there would be some part of the diff that didn't +make sense. Unfortunately, this happened to be the only revision of this +particular file in the repository, so I had nothing to compare against. + +So I took a different approach. Working under the guess that the +corruption was limited to a single byte, I wrote a program to munge each +byte individually, and try inflating the result. Since the object was +only 10K compressed, that worked out to about 2.5M attempts, which took +a few minutes. + +The program I used is here: + +---------------------------------------------- +#include <stdio.h> +#include <unistd.h> +#include <string.h> +#include <signal.h> +#include <zlib.h> + +static int try_zlib(unsigned char *buf, int len) +{ + /* make this absurdly large so we don't have to loop */ + static unsigned char out[1024*1024]; + z_stream z; + int ret; + + memset(&z, 0, sizeof(z)); + inflateInit(&z); + + z.next_in = buf; + z.avail_in = len; + z.next_out = out; + z.avail_out = sizeof(out); + + ret = inflate(&z, 0); + inflateEnd(&z); + return ret >= 0; +} + +/* eye candy */ +static int counter = 0; +static void progress(int sig) +{ + fprintf(stderr, "\r%d", counter); + alarm(1); +} + +int main(void) +{ + /* oversized so we can read the whole buffer in */ + unsigned char buf[1024*1024]; + int len; + unsigned i, j; + + signal(SIGALRM, progress); + alarm(1); + + len = read(0, buf, sizeof(buf)); + for (i = 0; i < len; i++) { + unsigned char c = buf[i]; + for (j = 0; j <= 0xff; j++) { + buf[i] = j; + + counter++; + if (try_zlib(buf, len)) + printf("i=%d, j=%x\n", i, j); + } + buf[i] = c; + } + + alarm(0); + fprintf(stderr, "\n"); + return 0; +} +---------------------------------------------- + +I compiled and ran with: + +------- + gcc -Wall -Werror -O3 munge.c -o munge -lz + ./munge <zlib +------- + + +There were a few false positives early on (if you write "no data" in the +zlib header, zlib thinks it's just fine :) ). But I got a hit about +halfway through: + +------- + i=5642, j=c7 +------- + +I let it run to completion, and got a few more hits at the end (where it +was munging the crc to match our broken data). So there was a good +chance this middle hit was the source of the problem. + +I confirmed by tweaking the byte in a hex editor, zlib inflating the +result (no errors!), and then piping the output into "git hash-object", +which reported the sha1 of the broken object. Success! + +I fixed the packfile itself with: + +------- + chmod +w $pack + printf '\xc7' | dd of=$pack bs=1 seek=51659518 conv=notrunc + chmod -w $pack +------- + +The `\xc7` comes from the replacement byte our "munge" program found. +The offset 51659518 is derived by taking the original object offset +(51653873), adding the replacement offset found by "munge" (5642), and +then adding back in the 3 bytes of git header we stripped. + +After that, "git fsck" ran clean. + +As for the corruption itself, I was lucky that it was indeed a single +byte. In fact, it turned out to be a single bit. The byte 0xc7 was +corrupted to 0xc5. So presumably it was caused by faulty hardware, or a +cosmic ray. + +And the aborted attempt to look at the inflated output to see what was +wrong? I could have looked forever and never found it. Here's the diff +between what the corrupted data inflates to, versus the real data: + +-------------- + - cp = strtok (arg, "+"); + + cp = strtok (arg, "."); +-------------- + +It tweaked one byte and still ended up as valid, readable C that just +happened to do something totally different! One takeaway is that on a +less unlucky day, looking at the zlib output might have actually been +helpful, as most random changes would actually break the C code. + +But more importantly, git's hashing and checksumming noticed a problem +that easily could have gone undetected in another system. The result +still compiled, but would have caused an interesting bug (that would +have been blamed on some random commit). diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt index 8a685483f4..acf3e477e5 100644 --- a/Documentation/howto/revert-a-faulty-merge.txt +++ b/Documentation/howto/revert-a-faulty-merge.txt @@ -37,7 +37,7 @@ where A and B are on the side development that was not so good, M is the merge that brings these premature changes into the mainline, x are changes unrelated to what the side branch did and already made on the mainline, and W is the "revert of the merge M" (doesn't W look M upside down?). -IOW, "diff W^..W" is similar to "diff -R M^..M". +IOW, `"diff W^..W"` is similar to `"diff -R M^..M"`. Such a "revert" of a merge can be made with: @@ -121,9 +121,9 @@ If you reverted the revert in such a case as in the previous example: ---A---B A'--B'--C' where Y is the revert of W, A' and B' are rerolled A and B, and there may -also be a further fix-up C' on the side branch. "diff Y^..Y" is similar -to "diff -R W^..W" (which in turn means it is similar to "diff M^..M"), -and "diff A'^..C'" by definition would be similar but different from that, +also be a further fix-up C' on the side branch. `"diff Y^..Y"` is similar +to `"diff -R W^..W"` (which in turn means it is similar to `"diff M^..M"`), +and `"diff A'^..C'"` by definition would be similar but different from that, because it is a rerolled series of the earlier change. There will be a lot of overlapping changes that result in conflicts. So do not do "revert of revert" blindly without thinking.. @@ -164,7 +164,7 @@ merged. So it's debugging hell, because now you don't have lots of small changes that you can try to pinpoint which _part_ of it changes. But does it all work? Sure it does. You can revert a merge, and from a -purely technical angle, git did it very naturally and had no real +purely technical angle, Git did it very naturally and had no real troubles. It just considered it a change from "state before merge" to "state after merge", and that was it. Nothing complicated, nothing odd, nothing really dangerous. Git will do it without even thinking about it. diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt index a59ced8d04..85f69dbac9 100644 --- a/Documentation/howto/revert-branch-rebase.txt +++ b/Documentation/howto/revert-branch-rebase.txt @@ -12,10 +12,10 @@ How to revert an existing commit ================================ One of the changes I pulled into the 'master' branch turns out to -break building GIT with GCC 2.95. While they were well intentioned +break building Git with GCC 2.95. While they were well-intentioned portability fixes, keeping things working with gcc-2.95 was also important. Here is what I did to revert the change in the 'master' -branch and to adjust the 'pu' branch, using core GIT tools and +branch and to adjust the 'pu' branch, using core Git tools and barebone Porcelain. First, prepare a throw-away branch in case I screw things up. @@ -154,7 +154,7 @@ $ git pull . master Packing 0 objects Unpacking 0 objects -* committish: e3a693c... refs/heads/master from . +* commit-ish: e3a693c... refs/heads/master from . Trying to merge e3a693c... into 8c1f5f0... using 10d781b... Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f cache.h | 8 ++++---- diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt index a695f01f0e..6de4f3c487 100644 --- a/Documentation/howto/setup-git-server-over-http.txt +++ b/Documentation/howto/setup-git-server-over-http.txt @@ -1,11 +1,15 @@ From: Rutger Nijlunsing <rutger@nospam.com> -Subject: Setting up a git repository which can be pushed into and pulled from over HTTP(S). +Subject: Setting up a Git repository which can be pushed into and pulled from over HTTP(S). Date: Thu, 10 Aug 2006 22:00:26 +0200 Content-type: text/asciidoc -How to setup git server over http +How to setup Git server over http ================================= +NOTE: This document is from 2006. A lot has happened since then, and this +document is now relevant mainly if your web host is not CGI capable. +Almost everyone else should instead look at linkgit:git-http-backend[1]. + Since Apache is one of those packages people like to compile themselves while others prefer the bureaucrat's dream Debian, it is impossible to give guidelines which will work for everyone. Just send @@ -44,20 +48,20 @@ What's needed: - have permissions to chown a directory -- have git installed on the client, and +- have Git installed on the client, and -- either have git installed on the server or have a webdav client on +- either have Git installed on the server or have a webdav client on the client. In effect, this means you're going to be root, or that you're using a preconfigured WebDAV server. -Step 1: setup a bare GIT repository +Step 1: setup a bare Git repository ----------------------------------- -At the time of writing, git-http-push cannot remotely create a GIT -repository. So we have to do that at the server side with git. Another +At the time of writing, git-http-push cannot remotely create a Git +repository. So we have to do that at the server side with Git. Another option is to generate an empty bare repository at the client and copy it to the server with a WebDAV client (which is the only option if Git is not installed on the server). @@ -81,8 +85,8 @@ Initialize a bare repository $ git --bare init -Change the ownership to your web-server's credentials. Use "grep ^User -httpd.conf" and "grep ^Group httpd.conf" to find out: +Change the ownership to your web-server's credentials. Use `"grep ^User +httpd.conf"` and `"grep ^Group httpd.conf"` to find out: $ chown -R www.www . @@ -189,7 +193,7 @@ http://<servername>/my-new-repo.git [x] Open as webfolder -> login . Step 3: setup the client ------------------------ -Make sure that you have HTTP support, i.e. your git was built with +Make sure that you have HTTP support, i.e. your Git was built with libcurl (version more recent than 7.10). The command 'git http-push' with no argument should display a usage message. @@ -268,7 +272,7 @@ Reading /usr/local/apache2/logs/error_log is often helpful. On Debian: Read /var/log/apache2/error.log instead. -If you access HTTPS locations, git may fail verifying the SSL +If you access HTTPS locations, Git may fail verifying the SSL certificate (this is return code 60). Setting http.sslVerify=false can help diagnosing the problem, but removes security checks. diff --git a/Documentation/howto/use-git-daemon.txt b/Documentation/howto/use-git-daemon.txt index 23cdf35435..7af2e52cf3 100644 --- a/Documentation/howto/use-git-daemon.txt +++ b/Documentation/howto/use-git-daemon.txt @@ -4,7 +4,7 @@ How to use git-daemon ===================== Git can be run in inetd mode and in stand alone mode. But all you want is -let a coworker pull from you, and therefore need to set up a git server +let a coworker pull from you, and therefore need to set up a Git server real quick, right? Note that git-daemon is not really chatty at the moment, especially when diff --git a/Documentation/howto/using-signed-tag-in-pull-request.txt b/Documentation/howto/using-signed-tag-in-pull-request.txt index 00f693bde8..bbf040eda8 100644 --- a/Documentation/howto/using-signed-tag-in-pull-request.txt +++ b/Documentation/howto/using-signed-tag-in-pull-request.txt @@ -23,7 +23,7 @@ Earlier, a typical pull request may have started like this: Froboz 3.2 (2011-09-30 14:20:57 -0700) - are available in the git repository at: + are available in the Git repository at: example.com:/git/froboz.git for-xyzzy ------------ @@ -107,7 +107,7 @@ The resulting msg.txt file begins like so: Froboz 3.2 (2011-09-30 14:20:57 -0700) - are available in the git repository at: + are available in the Git repository at: example.com:/git/froboz.git tags/frotz-for-xyzzy |