diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/RelNotes-1.7.0.4.txt | 12 | ||||
| -rw-r--r-- | Documentation/RelNotes-1.7.1.txt | 34 | ||||
| -rw-r--r-- | Documentation/everyday.txt | 51 | ||||
| -rw-r--r-- | Documentation/git-http-backend.txt | 2 | ||||
| -rw-r--r-- | Documentation/git-imap-send.txt | 10 | ||||
| -rw-r--r-- | Documentation/git-rebase.txt | 23 | ||||
| -rw-r--r-- | Documentation/git-show-ref.txt | 2 | ||||
| -rw-r--r-- | Documentation/git.txt | 3 | ||||
| -rw-r--r-- | Documentation/howto/revert-a-faulty-merge.txt | 90 | ||||
| -rw-r--r-- | Documentation/technical/api-string-list.txt | 6 | ||||
| -rw-r--r-- | Documentation/technical/pack-protocol.txt | 10 |
11 files changed, 166 insertions, 77 deletions
diff --git a/Documentation/RelNotes-1.7.0.4.txt b/Documentation/RelNotes-1.7.0.4.txt index cbc94a2f08..cf7f60e60d 100644 --- a/Documentation/RelNotes-1.7.0.4.txt +++ b/Documentation/RelNotes-1.7.0.4.txt @@ -1,9 +1,11 @@ -Git v1.7.0.4 Release Notes (draft) -================================== +Git v1.7.0.4 Release Notes +========================== Fixes since v1.7.0.3 -------------------- + * Optimized ntohl/htonl on big-endian machines were broken. + * Color values given to "color.<cmd>.<slot>" configuration can now have more than one attributes (e.g. "bold ul"). @@ -16,4 +18,10 @@ Fixes since v1.7.0.3 * "git fast-export" didn't check error status and stop when marks file cannot be opened. + * "git format-patch --ignore-if-in-upstream" gave unwarranted errors + when the range was empty, instead of silently finishing. + + * "git remote prune" did not detect remote tracking refs that became + dangling correctly. + And other minor fixes and documentation updates. diff --git a/Documentation/RelNotes-1.7.1.txt b/Documentation/RelNotes-1.7.1.txt index 19aeef5eff..58cf113a90 100644 --- a/Documentation/RelNotes-1.7.1.txt +++ b/Documentation/RelNotes-1.7.1.txt @@ -4,16 +4,25 @@ Git v1.7.1 Release Notes (draft) Updates since v1.7.0 -------------------- + * Eric Raymond is the maintainer of updated CIAbot scripts, in contrib/. + * Some commands (e.g. svn and http interfaces) that interactively ask - password can be told to use an external program given via GIT_ASKPASS. + for a password can be told to use an external program given via + GIT_ASKPASS. + + * Conflict markers that lead the common ancestor in diff3-style output + now have a label, which hopefully would help third-party tools that + expect one. + + * Comes with an updated bash-completion script. * "git am" learned "--keep-cr" option to handle inputs that are - mixture of changes to files with and without CRLF line endings. + a mixture of changes to files with and without CRLF line endings. * "git cvsimport" learned -R option to leave revision mapping between CVS revisions and resulting git commits. - * "git diff --submodule" notices and descries dirty submodules. + * "git diff --submodule" notices and describes dirty submodules. * "git for-each-ref" learned %(symref), %(symref:short) and %(flag) tokens. @@ -34,12 +43,11 @@ Updates since v1.7.0 * "git log -p --first-parent -m" shows one-parent diff for merge commits, instead of showing combined diff. - * "git merge-file" learned to use custom conflict marker size and also use - the "union merge" behaviour. + * "git merge-file" learned to use custom conflict marker size and also + to use the "union merge" behaviour. - * "git notes" command has been rewritten in C and learned quite a - many commands and features to help you carry notes forward across - rebases and amends. + * "git notes" command has been rewritten in C and learned many commands + and features to help you carry notes forward across rebases and amends. * "git request-pull" identifies the commit the request is relative to in a more readable way. @@ -48,7 +56,7 @@ Updates since v1.7.0 near the tip while preserving your local changes in a way similar to how "git checkout branch" does. - * "git status" notices and descries dirty submodules. + * "git status" notices and describes dirty submodules. * "git svn" should work better when interacting with repositories with CRLF line endings. @@ -64,8 +72,14 @@ release, unless otherwise noted. * "git add frotz/nitfol" did not complain when the entire frotz/ directory was ignored. + * "git rev-list --pretty=oneline" didn't terminate a record with LF for + commits without any message. + + * "git rev-list --abbrev-commit" defaulted to 40-byte abbreviations, unlike + newer tools in the git toolset. + --- exec >/var/tmp/1 echo O=$(git describe) -O=v1.7.0.3-310-g99f5b08 +O=v1.7.0.4-382-gb807c52 git shortlog --no-merges ^maint $O.. diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt index 9310b650d3..e0ba8cc075 100644 --- a/Documentation/everyday.txt +++ b/Documentation/everyday.txt @@ -1,13 +1,8 @@ Everyday GIT With 20 Commands Or So =================================== -<<Basic Repository>> commands are needed by people who have a -repository --- that is everybody, because every working tree of -git is a repository. - -In addition, <<Individual Developer (Standalone)>> commands are -essential for anybody who makes a commit, even for somebody who -works alone. +<<Individual Developer (Standalone)>> commands are essential for +anybody who makes a commit, even for somebody who works alone. If you work with other people, you will need commands listed in the <<Individual Developer (Participant)>> section as well. @@ -20,46 +15,6 @@ administrators who are responsible for the care and feeding of git repositories. -Basic Repository[[Basic Repository]] ------------------------------------- - -Everybody uses these commands to maintain git repositories. - - * linkgit:git-init[1] or linkgit:git-clone[1] to create a - new repository. - - * linkgit:git-fsck[1] to check the repository for errors. - - * linkgit:git-gc[1] to do common housekeeping tasks such as - repack and prune. - -Examples -~~~~~~~~ - -Check health and remove cruft.:: -+ ------------- -$ git fsck <1> -$ git count-objects <2> -$ git gc <3> ------------- -+ -<1> running without `\--full` is usually cheap and assures the -repository health reasonably well. -<2> check how many loose objects there are and how much -disk space is wasted by not repacking. -<3> repacks the local repository and performs other housekeeping tasks. - -Repack a small project into single pack.:: -+ ------------- -$ git gc <1> ------------- -+ -<1> pack all the objects reachable from the refs into one pack, -then remove the other packs. - - Individual Developer (Standalone)[[Individual Developer (Standalone)]] ---------------------------------------------------------------------- @@ -67,6 +22,8 @@ A standalone individual developer does not exchange patches with other people, and works alone in a single repository, using the following commands. + * linkgit:git-init[1] to create a new repository. + * linkgit:git-show-branch[1] to see where you are. * linkgit:git-log[1] to see what happened. diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt index 5238820657..277d9e141b 100644 --- a/Documentation/git-http-backend.txt +++ b/Documentation/git-http-backend.txt @@ -35,7 +35,7 @@ These services can be enabled/disabled using the per-repository configuration file: http.getanyfile:: - This serves older Git clients which are unable to use the + This serves Git clients older than version 1.6.6 that are unable to use the upload pack service. When enabled, clients are able to read any file within the repository, including objects that are no longer reachable from a branch but are still present. diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt index 6cafbe2ec1..57aba42e66 100644 --- a/Documentation/git-imap-send.txt +++ b/Documentation/git-imap-send.txt @@ -16,7 +16,9 @@ DESCRIPTION This command uploads a mailbox generated with 'git format-patch' into an IMAP drafts folder. This allows patches to be sent as other email is when using mail clients that cannot read mailbox -files directly. +files directly. The command also works with any general mailbox +in which emails have the fields "From", "Date", and "Subject" in +that order. Typical usage is something like: @@ -122,12 +124,6 @@ Thunderbird in particular is known to be problematic. Thunderbird users may wish to visit this web page for more information: http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email - -BUGS ----- -Doesn't handle lines starting with "From " in the message body. - - Author ------ Derived from isync 1.0.1 by Mike McCormack. diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 823f2a4638..0d07b1b207 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -274,9 +274,16 @@ which makes little sense. -f:: --force-rebase:: Force the rebase even if the current branch is a descendant - of the commit you are rebasing onto. Normally the command will + of the commit you are rebasing onto. Normally non-interactive rebase will exit with the message "Current branch is up to date" in such a situation. + Incompatible with the --interactive option. ++ +You may find this (or --no-ff with an interactive rebase) helpful after +reverting a topic branch merge, as this option recreates the topic branch with +fresh commits so it can be remerged successfully without needing to "revert +the reversion" (see the +link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details). --ignore-whitespace:: --whitespace=<option>:: @@ -316,7 +323,19 @@ which makes little sense. commit to be modified, and change the action of the moved commit from `pick` to `squash` (or `fixup`). + -This option is only valid when '--interactive' option is used. +This option is only valid when the '--interactive' option is used. + +--no-ff:: + With --interactive, cherry-pick all rebased commits instead of + fast-forwarding over the unchanged ones. This ensures that the + entire history of the rebased branch is composed of new commits. ++ +Without --interactive, this is a synonym for --force-rebase. ++ +You may find this helpful after reverting a topic branch merge, as this option +recreates the topic branch with fresh commits so it can be remerged +successfully without needing to "revert the reversion" (see the +link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details). include::merge-strategies.txt[] diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt index df17d49b87..3f9d9c6db3 100644 --- a/Documentation/git-show-ref.txt +++ b/Documentation/git-show-ref.txt @@ -10,7 +10,7 @@ SYNOPSIS [verse] 'git show-ref' [-q|--quiet] [--verify] [--head] [-d|--dereference] [-s|--hash[=<n>]] [--abbrev[=<n>]] [--tags] - [--heads] [--] <pattern>... + [--heads] [--] [<pattern>...] 'git show-ref' --exclude-existing[=<pattern>] < ref-list DESCRIPTION diff --git a/Documentation/git.txt b/Documentation/git.txt index 4e00b315ff..657eac831c 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -43,9 +43,10 @@ unreleased) version of git, that is available from 'master' branch of the `git.git` repository. Documentation for older releases are available here: -* link:v1.7.0.3/git.html[documentation for release 1.7.0.3] +* link:v1.7.0.4/git.html[documentation for release 1.7.0.4] * release notes for + link:RelNotes-1.7.0.4.txt[1.7.0.4], link:RelNotes-1.7.0.3.txt[1.7.0.3], link:RelNotes-1.7.0.2.txt[1.7.0.2], link:RelNotes-1.7.0.1.txt[1.7.0.1], diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt index 3b4a390005..ff5c0bc27a 100644 --- a/Documentation/howto/revert-a-faulty-merge.txt +++ b/Documentation/howto/revert-a-faulty-merge.txt @@ -142,6 +142,8 @@ different resolution strategies: revert of a merge was rebuilt from scratch (i.e. rebasing and fixing, as you seem to have interpreted), then re-merging the result without doing anything else fancy would be the right thing to do. + (See the ADDENDUM below for how to rebuild a branch from scratch + without changing its original branching-off point.) However, there are things to keep in mind when reverting a merge (and reverting such a revert). @@ -177,3 +179,91 @@ the answer is: "oops, I really shouldn't have merged it, because it wasn't ready yet, and I really need to undo _all_ of the merge"). So then you really should revert the merge, but when you want to re-do the merge, you now need to do it by reverting the revert. + +ADDENDUM + +Sometimes you have to rewrite one of a topic branch's commits *and* you can't +change the topic's branching-off point. Consider the following situation: + + P---o---o---M---x---x---W---x + \ / + A---B---C + +where commit W reverted commit M because it turned out that commit B was wrong +and needs to be rewritten, but you need the rewritten topic to still branch +from commit P (perhaps P is a branching-off point for yet another branch, and +you want be able to merge the topic into both branches). + +The natural thing to do in this case is to checkout the A-B-C branch and use +"rebase -i P" to change commit B. However this does not rewrite commit A, +because "rebase -i" by default fast-forwards over any initial commits selected +with the "pick" command. So you end up with this: + + P---o---o---M---x---x---W---x + \ / + A---B---C <-- old branch + \ + B'---C' <-- naively rewritten branch + +To merge A-B'-C' into the mainline branch you would still have to first revert +commit W in order to pick up the changes in A, but then it's likely that the +changes in B' will conflict with the original B changes re-introduced by the +reversion of W. + +However, you can avoid these problems if you recreate the entire branch, +including commit A: + + A'---B'---C' <-- completely rewritten branch + / + P---o---o---M---x---x---W---x + \ / + A---B---C + +You can merge A'-B'-C' into the mainline branch without worrying about first +reverting W. Mainline's history would look like this: + + A'---B'---C'------------------ + / \ + P---o---o---M---x---x---W---x---M2 + \ / + A---B---C + +But if you don't actually need to change commit A, then you need some way to +recreate it as a new commit with the same changes in it. The rebase commmand's +--no-ff option provides a way to do this: + + $ git rebase [-i] --no-ff P + +The --no-ff option creates a new branch A'-B'-C' with all-new commits (all the +SHA IDs will be different) even if in the interactive case you only actually +modify commit B. You can then merge this new branch directly into the mainline +branch and be sure you'll get all of the branch's changes. + +You can also use --no-ff in cases where you just add extra commits to the topic +to fix it up. Let's revisit the situation discussed at the start of this howto: + + P---o---o---M---x---x---W---x + \ / + A---B---C----------------D---E <-- fixed-up topic branch + +At this point, you can use --no-ff to recreate the topic branch: + + $ git checkout E + $ git rebase --no-ff P + +yielding + + A'---B'---C'------------D'---E' <-- recreated topic branch + / + P---o---o---M---x---x---W---x + \ / + A---B---C----------------D---E + +You can merge the recreated branch into the mainline without reverting commit W, +and mainline's history will look like this: + + A'---B'---C'------------D'---E' + / \ + P---o---o---M---x---x---W---x---M2 + \ / + A---B---C diff --git a/Documentation/technical/api-string-list.txt b/Documentation/technical/api-string-list.txt index 293bb15d20..6d8c24bb1e 100644 --- a/Documentation/technical/api-string-list.txt +++ b/Documentation/technical/api-string-list.txt @@ -104,8 +104,12 @@ write `string_list_insert(...)->util = ...;`. `unsorted_string_list_has_string`:: It's like `string_list_has_string()` but for unsorted lists. + +`unsorted_string_list_lookup`:: + + It's like `string_list_lookup()` but for unsorted lists. + -This function needs to look through all items, as opposed to its +The above two functions need to look through all items, as opposed to their counterpart for sorted lists, which performs a binary search. Data structures diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index 9a5cdafa9c..369f91d3b9 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -36,7 +36,7 @@ Git Transport The Git transport starts off by sending the command and repository on the wire using the pkt-line format, followed by a NUL byte and a -hostname paramater, terminated by a NUL byte. +hostname parameter, terminated by a NUL byte. 0032git-upload-pack /project.git\0host=myserver.com\0 @@ -331,7 +331,7 @@ An incremental update (fetch) response might look like this: C: 0009done\n - S: 003aACK 74730d410fcb6603ace96f1dc55ea6196122532d\n + S: 0031ACK 74730d410fcb6603ace96f1dc55ea6196122532d\n S: [PACKFILE] ---- @@ -488,7 +488,7 @@ An example client/server communication might look like this: C: 0000 C: [PACKDATA] - S: 000aunpack ok\n - S: 0014ok refs/heads/debug\n - S: 0026ng refs/heads/master non-fast-forward\n + S: 000eunpack ok\n + S: 0018ok refs/heads/debug\n + S: 002ang refs/heads/master non-fast-forward\n ---- |