git-check-attr(1)

One of the changes I pulled into the master branch turns out to +

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 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 -barebone Porcelain.

First, prepare a throw-away branch in case I screw things up.

+barebone Porcelain.

First, prepare a throw-away branch in case I screw things up.

$ git checkout -b revert-c99 master

Now I am on the revert-c99 branch. Let's figure out which commit to +

Now I am on the revert-c99 branch. Let's figure out which commit to revert. I happen to know that the top of the master branch is a merge, and its second parent (i.e. foreign commit I merged from) has the change I would want to undo. Further I happen to know that that -merge introduced 5 commits or so:

+merge introduced 5 commits or so:

$ git show-branch --more=4 master master^2 | head
@@ -293,18 +341,18 @@ merge introduced 5 commits or so:
 *+ [master^2~4] Replace zero-length array decls with [].
 *  [master~1] tutorial note about git branch

The —more=4 above means "after we reach the merge base of refs, +

The —more=4 above means "after we reach the merge base of refs, show until we display four more common commits". That last commit would have been where the "portable" branch was forked from the main git.git repository, so this would show everything on both branches since then. I just limited the output to the first handful using -head.

Now I know master^2~4 (pronounce it as "find the second parent of +head.

Now I know master^2~4 (pronounce it as "find the second parent of the master, and then go four generations back following the first parent") is the one I would want to revert. Since I also want to say why I am reverting it, the -n flag is given to git revert. This prevents it from actually making a commit, and instead git revert -leaves the commit log message it wanted to use in .msg file:

+leaves the commit log message it wanted to use in .msg file:

$ git revert -n master^2~4
@@ -316,18 +364,18 @@ $ git diff HEAD ;# to make sure what we are reverting makes sense.
 $ make CC=gcc-2.95 clean test ;# make sure it fixed the breakage.
 $ make clean test ;# make sure it did not cause other breakage.

The reverted change makes sense (from reading the diff output), does +

The reverted change makes sense (from reading the diff output), does fix the problem (from make CC=gcc-2.95 test), and does not cause new -breakage (from the last make test). I'm ready to commit:

+breakage (from the last make test). I'm ready to commit:

$ git commit -a -s ;# read .msg into the log,
                     # and explain why I am reverting.

I could have screwed up in any of the above steps, but in the worst +

I could have screwed up in any of the above steps, but in the worst case I could just have done git checkout master to start over. Fortunately I did not have to; what I have in the current branch -revert-c99 is what I want. So merge that back into master:

+revert-c99 is what I want. So merge that back into master:

$ git checkout master
@@ -340,14 +388,14 @@ Updating from 10d781b9caa4f71495c7b34963bef137216f86a8 to e3a693c...
  server-info.c  |    2 +-
  5 files changed, 8 insertions(+), 8 deletions(-)

There is no need to redo the test at this point. We fast forwarded -and we know master matches revert-c99 exactly. In fact:

There is no need to redo the test at this point. We fast forwarded +and we know master matches revert-c99 exactly. In fact:

$ git diff master..revert-c99

says nothing.

Then we rebase the pu branch as usual.

says nothing.

Then we rebase the pu branch as usual.

$ git checkout pu
@@ -375,24 +423,24 @@ Finished one cherry-pick.
 First trying simple merge strategy to cherry-pick.
 Finished one cherry-pick.

The temporary tag pu-anchor is me just being careful, in case git -rebase screws up. After this, I can do these for sanity check:

The temporary tag pu-anchor is me just being careful, in case git +rebase screws up. After this, I can do these for sanity check:

$ git diff pu-anchor..pu ;# make sure we got the master fix.
 $ make CC=gcc-2.95 clean test ;# make sure it fixed the breakage.
 $ make clean test ;# make sure it did not cause other breakage.

Everything is in the good order. I do not need the temporary branch -nor tag anymore, so remove them:

Everything is in the good order. I do not need the temporary branch +nor tag anymore, so remove them:

$ rm -f .git/refs/tags/pu-anchor
 $ git branch -d revert-c99

It was an emergency fix, so we might as well merge it into the +

It was an emergency fix, so we might as well merge it into the release candidate branch, although I expect the next release would -be some days off:

+be some days off:

$ git checkout rc
@@ -410,7 +458,7 @@ Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f
  server-info.c  |    2 +-
  5 files changed, 8 insertions(+), 8 deletions(-)

And the final repository status looks like this:

$ git show-branch --more=1 master pu rc
@@ -434,7 +482,7 @@ Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f

-Last updated 02-Jul-2008 03:02:15 UTC +Last updated 2008-07-22 09:19:19 UTC diff --git a/howto/revert-branch-rebase.txt b/howto/revert-branch-rebase.txt index 865a66632..e70d8a31e 100644 --- a/howto/revert-branch-rebase.txt +++ b/howto/revert-branch-rebase.txt @@ -1,4 +1,4 @@ -From: Junio C Hamano +From: Junio C Hamano To: git@vger.kernel.org Subject: [HOWTO] Reverting an existing commit Abstract: In this article, JC gives a small real-life example of using diff --git a/howto/separating-topic-branches.txt b/howto/separating-topic-branches.txt index 0d73b3122..6d3eb8ed0 100644 --- a/howto/separating-topic-branches.txt +++ b/howto/separating-topic-branches.txt @@ -1,4 +1,4 @@ -From: Junio C Hamano +From: Junio C Hamano Subject: Separating topic branches Abstract: In this article, JC describes how to separate topic branches. diff --git a/howto/update-hook-example.txt b/howto/update-hook-example.txt index 8b2ec502f..697d91888 100644 --- a/howto/update-hook-example.txt +++ b/howto/update-hook-example.txt @@ -1,4 +1,4 @@ -From: Junio C Hamano and Carl Baldwin +From: Junio C Hamano and Carl Baldwin Subject: control access to branches. Date: Thu, 17 Nov 2005 23:55:32 -0800 Message-ID: <7vfypumlu3.fsf@assigned-by-dhcp.cox.net> diff --git a/technical/api-index.html b/technical/api-index.html index 908710886..19171bb33 100644 --- a/technical/api-index.html +++ b/technical/api-index.html @@ -3,7 +3,7 @@ - + GIT API Documents @@ -263,9 +311,9 @@ div.exampleblock-content {

-GIT has grown a set of internal API over time. This collection -documents them. - +GIT has grown a set of internal API over time. This collection +documents them. + allocation growing API @@ -333,11 +381,6 @@ documents them. -path-list API - - - - quote API @@ -368,6 +411,11 @@ documents them. +string-list API + + + + tree walking API @@ -376,13 +424,13 @@ documents them. xdiff interface API - -2007-11-24 + +2007-11-24

-Last updated 02-Jul-2008 03:02:23 UTC +Last updated 2008-07-22 09:19:20 UTC diff --git a/technical/api-index.txt b/technical/api-index.txt index 4a1190de6..619d4447b 100644 --- a/technical/api-index.txt +++ b/technical/api-index.txt @@ -20,13 +20,13 @@ documents them. * link:api-lockfile.html[lockfile API] * link:api-object-access.html[object access API] * link:api-parse-options.html[parse-options API] -* link:api-path-list.html[path-list API] * link:api-quote.html[quote API] * link:api-remote.html[Remotes configuration API] * link:api-revision-walking.html[revision walking API] * link:api-run-command.html[run-command API] * link:api-setup.html[setup API] * link:api-strbuf.html[strbuf API] +* link:api-string-list.html[string-list API] * link:api-tree-walking.html[tree walking API] * link:api-xdiff-interface.html[xdiff interface API] //////////////////////////////////////////////////////////////// diff --git a/technical/api-path-list.txt b/technical/api-path-list.txt deleted file mode 100644 index 9dbedd0a6..000000000 --- a/technical/api-path-list.txt +++ /dev/null @@ -1,126 +0,0 @@ -path-list API -============= - -The path_list API offers a data structure and functions to handle sorted -and unsorted string lists. - -The name is a bit misleading, a path_list may store not only paths but -strings in general. - -The caller: - -. Allocates and clears a `struct path_list` variable. - -. Initializes the members. You might want to set the flag `strdup_paths` - if the strings should be strdup()ed. For example, this is necessary - when you add something like git_path("..."), since that function returns - a static buffer that will change with the next call to git_path(). -+ -If you need something advanced, you can manually malloc() the `items` -member (you need this if you add things later) and you should set the -`nr` and `alloc` members in that case, too. - -. Adds new items to the list, using `path_list_append` or `path_list_insert`. - -. Can check if a string is in the list using `path_list_has_path` or - `unsorted_path_list_has_path` and get it from the list using - `path_list_lookup` for sorted lists. - -. Can sort an unsorted list using `sort_path_list`. - -. Finally it should free the list using `path_list_clear`. - -Example: - ----- -struct path_list list; -int i; - -memset(&list, 0, sizeof(struct path_list)); -path_list_append("foo", &list); -path_list_append("bar", &list); -for (i = 0; i < list.nr; i++) - printf("%s\n", list.items[i].path) ----- - -NOTE: It is more efficient to build an unsorted list and sort it -afterwards, instead of building a sorted list (`O(n log n)` instead of -`O(n^2)`). -+ -However, if you use the list to check if a certain string was added -already, you should not do that (using unsorted_path_list_has_path()), -because the complexity would be quadratic again (but with a worse factor). - -Functions ---------- - -* General ones (works with sorted and unsorted lists as well) - -`print_path_list`:: - - Dump a path_list to stdout, useful mainly for debugging purposes. It - can take an optional header argument and it writes out the - string-pointer pairs of the path_list, each one in its own line. - -`path_list_clear`:: - - Free a path_list. The `path` pointer of the items will be freed in case - the `strdup_paths` member of the path_list is set. The second parameter - controls if the `util` pointer of the items should be freed or not. - -* Functions for sorted lists only - -`path_list_has_path`:: - - Determine if the path_list has a given string or not. - -`path_list_insert`:: - - Insert a new element to the path_list. The returned pointer can be handy - if you want to write something to the `util` pointer of the - path_list_item containing the just added string. -+ -Since this function uses xrealloc() (which die()s if it fails) if the -list needs to grow, it is safe not to check the pointer. I.e. you may -write `path_list_insert(...)->util = ...;`. - -`path_list_lookup`:: - - Look up a given string in the path_list, returning the containing - path_list_item. If the string is not found, NULL is returned. - -* Functions for unsorted lists only - -`path_list_append`:: - - Append a new string to the end of the path_list. - -`sort_path_list`:: - - Make an unsorted list sorted. - -`unsorted_path_list_has_path`:: - - It's like `path_list_has_path()` but for unsorted lists. -+ -This function needs to look through all items, as opposed to its -counterpart for sorted lists, which performs a binary search. - -Data structures ---------------- - -* `struct path_list_item` - -Represents an item of the list. The `path` member is a pointer to the -string, and you may use the `util` member for any purpose, if you want. - -* `struct path_list` - -Represents the list itself. - -. The array of items are available via the `items` member. -. The `nr` member contains the number of items stored in the list. -. The `alloc` member is used to avoid reallocating at every insertion. - You should not tamper with it. -. Setting the `strdup_paths` member to 1 will strdup() the strings - before adding them, see above. diff --git a/technical/api-string-list.html b/technical/api-string-list.html new file mode 100644 index 000000000..7095ff7a2 --- /dev/null +++ b/technical/api-string-list.html @@ -0,0 +1,541 @@ + + + + + + +string-list API + + + +string-list API + + + +The string_list API offers a data structure and functions to handle sorted +and unsorted string lists. +The string_list struct used to be called path_list, but was renamed +because it is not specific to paths. +The caller: + + + +Allocates and clears a struct string_list variable. + + + + +Initializes the members. You might want to set the flag strdup_strings + if the strings should be strdup()ed. For example, this is necessary + when you add something like git_path("…"), since that function returns + a static buffer that will change with the next call to git_path(). + +If you need something advanced, you can manually malloc() the items +member (you need this if you add things later) and you should set the +nr and alloc members in that case, too. + + + +Adds new items to the list, using string_list_append or + string_list_insert. + + + + +Can check if a string is in the list using string_list_has_string or + unsorted_string_list_has_string and get it from the list using + string_list_lookup for sorted lists. + + + + +Can sort an unsorted list using sort_string_list. + + + + +Finally it should free the list using string_list_clear. + + + +Example: + + +struct string_list list; +int i; + +memset(&list, 0, sizeof(struct string_list)); +string_list_append("foo", &list); +string_list_append("bar", &list); +for (i = 0; i < list.nr; i++) + printf("%s\n", list.items[i].path) + + + + + + +Note + It is more efficient to build an unsorted list and sort it +afterwards, instead of building a sorted list (O(n log n) instead of +O(n^2)). + ++ +However, if you use the list to check if a certain string was added +already, you should not do that (using unsorted_string_list_has_string()), +because the complexity would be quadratic again (but with a worse factor). + + +Functions + + + + +General ones (works with sorted and unsorted lists as well) + + + +print_string_list + + + + Dump a string_list to stdout, useful mainly for debugging purposes. It + can take an optional header argument and it writes out the + string-pointer pairs of the string_list, each one in its own line. + + + +string_list_clear + + + + Free a string_list. The string pointer of the items will be freed in + case the strdup_strings member of the string_list is set. The second + parameter controls if the util pointer of the items should be freed + or not. + + + + + + +Functions for sorted lists only + + + +string_list_has_string + + + + Determine if the string_list has a given string or not. + + + +string_list_insert + + + + Insert a new element to the string_list. The returned pointer can be + handy if you want to write something to the util pointer of the + string_list_item containing the just added string. + +Since this function uses xrealloc() (which die()s if it fails) if the +list needs to grow, it is safe not to check the pointer. I.e. you may +write string_list_insert(…)->util = …;. + + +string_list_lookup + + + + Look up a given string in the string_list, returning the containing + string_list_item. If the string is not found, NULL is returned. + + + + + + +Functions for unsorted lists only + + + +string_list_append + + + + Append a new string to the end of the string_list. + + + +sort_string_list + + + + Make an unsorted list sorted. + + + +unsorted_string_list_has_string + + + + It's like string_list_has_string() but for unsorted lists. + +This function needs to look through all items, as opposed to its +counterpart for sorted lists, which performs a binary search. + + + + + +Data structures + + + + +struct string_list_item + + + +Represents an item of the list. The path member is a pointer to the +string, and you may use the util member for any purpose, if you want. + + + +struct string_list + + + +Represents the list itself. + + + +The array of items are available via the items member. + + + + +The nr member contains the number of items stored in the list. + + + + +The alloc member is used to avoid reallocating at every insertion. + You should not tamper with it. + + + + +Setting the strdup_strings member to 1 will strdup() the strings + before adding them, see above. + + + + + + +Last updated 2008-07-22 09:19:19 UTC + + + + diff --git a/technical/api-string-list.txt b/technical/api-string-list.txt new file mode 100644 index 000000000..92b3ecdae --- /dev/null +++ b/technical/api-string-list.txt @@ -0,0 +1,128 @@ +string-list API +=============== + +The string_list API offers a data structure and functions to handle sorted +and unsorted string lists. + +The 'string_list' struct used to be called 'path_list', but was renamed +because it is not specific to paths. + +The caller: + +. Allocates and clears a `struct string_list` variable. + +. Initializes the members. You might want to set the flag `strdup_strings` + if the strings should be strdup()ed. For example, this is necessary + when you add something like git_path("..."), since that function returns + a static buffer that will change with the next call to git_path(). ++ +If you need something advanced, you can manually malloc() the `items` +member (you need this if you add things later) and you should set the +`nr` and `alloc` members in that case, too. + +. Adds new items to the list, using `string_list_append` or + `string_list_insert`. + +. Can check if a string is in the list using `string_list_has_string` or + `unsorted_string_list_has_string` and get it from the list using + `string_list_lookup` for sorted lists. + +. Can sort an unsorted list using `sort_string_list`. + +. Finally it should free the list using `string_list_clear`. + +Example: + +---- +struct string_list list; +int i; + +memset(&list, 0, sizeof(struct string_list)); +string_list_append("foo", &list); +string_list_append("bar", &list); +for (i = 0; i < list.nr; i++) + printf("%s\n", list.items[i].path) +---- + +NOTE: It is more efficient to build an unsorted list and sort it +afterwards, instead of building a sorted list (`O(n log n)` instead of +`O(n^2)`). ++ +However, if you use the list to check if a certain string was added +already, you should not do that (using unsorted_string_list_has_string()), +because the complexity would be quadratic again (but with a worse factor). + +Functions +--------- + +* General ones (works with sorted and unsorted lists as well) + +`print_string_list`:: + + Dump a string_list to stdout, useful mainly for debugging purposes. It + can take an optional header argument and it writes out the + string-pointer pairs of the string_list, each one in its own line. + +`string_list_clear`:: + + Free a string_list. The `string` pointer of the items will be freed in + case the `strdup_strings` member of the string_list is set. The second + parameter controls if the `util` pointer of the items should be freed + or not. + +* Functions for sorted lists only + +`string_list_has_string`:: + + Determine if the string_list has a given string or not. + +`string_list_insert`:: + + Insert a new element to the string_list. The returned pointer can be + handy if you want to write something to the `util` pointer of the + string_list_item containing the just added string. ++ +Since this function uses xrealloc() (which die()s if it fails) if the +list needs to grow, it is safe not to check the pointer. I.e. you may +write `string_list_insert(...)->util = ...;`. + +`string_list_lookup`:: + + Look up a given string in the string_list, returning the containing + string_list_item. If the string is not found, NULL is returned. + +* Functions for unsorted lists only + +`string_list_append`:: + + Append a new string to the end of the string_list. + +`sort_string_list`:: + + Make an unsorted list sorted. + +`unsorted_string_list_has_string`:: + + It's like `string_list_has_string()` but for unsorted lists. ++ +This function needs to look through all items, as opposed to its +counterpart for sorted lists, which performs a binary search. + +Data structures +--------------- + +* `struct string_list_item` + +Represents an item of the list. The `path` member is a pointer to the +string, and you may use the `util` member for any purpose, if you want. + +* `struct string_list` + +Represents the list itself. + +. The array of items are available via the `items` member. +. The `nr` member contains the number of items stored in the list. +. The `alloc` member is used to avoid reallocating at every insertion. + You should not tamper with it. +. Setting the `strdup_strings` member to 1 will strdup() the strings + before adding them, see above. diff --git a/user-manual.html b/user-manual.html index 3be7ee71b..a2339f789 100644 --- a/user-manual.html +++ b/user-manual.html @@ -1,4 +1,4 @@ -Git User's Manual (for version 1.5.3 or newer)Git User's Manual (for version 1.5.3 or newer) Table of Contents Preface 1. Repositories and Branches How to get a git repository How to check out a different version of a project Understanding History: Commits Understanding history: commits, parents, and reachability Understanding history: History diagrams Understanding history: What is a branch? Manipulating branches Examining an old version without creating a new branch Examining branches from a remote repository Naming branches, tags, and other references Updating a repository with git-fetch Fetching branches from other repositories 2. Exploring git history How to use bisect to find a regression Naming commits Creating tags Browsing revisions Generating diffs Viewing old file versions Examples Counting the number of commits on a branch Check whether two branches point at the same history Find first tagged version including a given fix Showing commits unique to a given branch Creating a changelog and tarball for a software release Finding commits referencing a file with given content 3. Developing with git Telling git your name Creating a new repository How to make a commit Creating good commit messages Ignoring files How to merge Resolving a merge Getting conflict-resolution help during a merge Undoing a merge Fast-forward merges Fixing mistakes Fixing a mistake with a new commit Fixing a mistake by rewriting history Checking out an old version of a file Temporarily setting aside work in progress Ensuring good performance Ensuring reliability Checking the repository for corruption Recovering lost changes 4. Sharing development with others Getting updates with git-pull Submitting patches to a project Importing patches to a project Public git repositories Setting up a public repository Exporting a git repository via the git protocol Exporting a git repository via http Pushing changes to a public repository What to do when a push fails Setting up a shared repository Allowing web browsing of a repository Examples Maintaining topic branches for a Linux subsystem maintainer 5. Rewriting history and maintaining patch series Creating the perfect patch series Keeping a patch series up to date using git-rebase Rewriting a single commit Reordering or selecting from a patch series Other tools Problems with rewriting history Why bisecting merge commits can be harder than bisecting linear history 6. Advanced branch management Fetching individual branches git fetch and fast-forwards Forcing git-fetch to do non-fast-forward updates Configuring remote branches 7. Git concepts The Object Database Commit Object Tree Object Blob Object Trust Tag Object How git stores objects efficiently: pack files Dangling objects Recovering from repository corruption The index 8. Submodules Pitfalls with submodules 9. Low-level git operations Object access and manipulation The Workflow working directory -> index index -> object database object database -> index index -> working directory Tying it all together Examining the data Merging multiple trees Merging multiple trees, continued 10. Hacking git Object storage format A birds-eye view of Git's source code 11. GIT Glossary A. Git Quick Reference Creating a new repository Managing branches Exploring history Making changes Merging Sharing your changes Repository maintenance B. Notes and todo list for this manual Preface Git is a fast distributed revision control system. This manual is designed to be readable by someone with basic UNIX +Git User's Manual (for version 1.5.3 or newer) Git User's Manual (for version 1.5.3 or newer) Table of Contents Preface 1. Repositories and Branches How to get a git repository How to check out a different version of a project Understanding History: Commits Understanding history: commits, parents, and reachability Understanding history: History diagrams Understanding history: What is a branch? Manipulating branches Examining an old version without creating a new branch Examining branches from a remote repository Naming branches, tags, and other references Updating a repository with git-fetch Fetching branches from other repositories 2. Exploring git history How to use bisect to find a regression Naming commits Creating tags Browsing revisions Generating diffs Viewing old file versions Examples Counting the number of commits on a branch Check whether two branches point at the same history Find first tagged version including a given fix Showing commits unique to a given branch Creating a changelog and tarball for a software release Finding commits referencing a file with given content 3. Developing with git Telling git your name Creating a new repository How to make a commit Creating good commit messages Ignoring files How to merge Resolving a merge Getting conflict-resolution help during a merge Undoing a merge Fast-forward merges Fixing mistakes Fixing a mistake with a new commit Fixing a mistake by rewriting history Checking out an old version of a file Temporarily setting aside work in progress Ensuring good performance Ensuring reliability Checking the repository for corruption Recovering lost changes 4. Sharing development with others Getting updates with git-pull Submitting patches to a project Importing patches to a project Public git repositories Setting up a public repository Exporting a git repository via the git protocol Exporting a git repository via http Pushing changes to a public repository What to do when a push fails Setting up a shared repository Allowing web browsing of a repository Examples Maintaining topic branches for a Linux subsystem maintainer 5. Rewriting history and maintaining patch series Creating the perfect patch series Keeping a patch series up to date using git-rebase Rewriting a single commit Reordering or selecting from a patch series Other tools Problems with rewriting history Why bisecting merge commits can be harder than bisecting linear history 6. Advanced branch management Fetching individual branches git fetch and fast-forwards Forcing git-fetch to do non-fast-forward updates Configuring remote branches 7. Git concepts The Object Database Commit Object Tree Object Blob Object Trust Tag Object How git stores objects efficiently: pack files Dangling objects Recovering from repository corruption The index 8. Submodules Pitfalls with submodules 9. Low-level git operations Object access and manipulation The Workflow working directory -> index index -> object database object database -> index index -> working directory Tying it all together Examining the data Merging multiple trees Merging multiple trees, continued 10. Hacking git Object storage format A birds-eye view of Git's source code 11. GIT Glossary A. Git Quick Reference Creating a new repository Managing branches Exploring history Making changes Merging Sharing your changes Repository maintenance B. Notes and todo list for this manual Preface Git is a fast distributed revision control system. This manual is designed to be readable by someone with basic UNIX command-line skills, but no previous knowledge of git. ChapterÂ 1, Repositories and Branches and ChapterÂ 2, Exploring git history explain how to fetch and study a project using gitâread these chapters to learn how to build and test a particular version of a software project, search for @@ -1001,7 +1001,7 @@ the result would create a new merge commit, like this: git-rebase(1): $Â gitÂ checkoutÂ mywork $Â gitÂ rebaseÂ origin This will remove each of your commits from mywork, temporarily saving -them as patches (in a directory named ".git/rebase"), update mywork to +them as patches (in a directory named ".git/rebase-apply"), update mywork to point at the latest version of origin, then apply each of the saved patches to the new mywork. The result will look like: o--o--O--o--o--o <-- origin \ diff --git a/user-manual.txt b/user-manual.txt index 8761ee7e7..c5641af19 100644 --- a/user-manual.txt +++ b/user-manual.txt @@ -2431,7 +2431,7 @@ $ git rebase origin ------------------------------------------------- This will remove each of your commits from mywork, temporarily saving -them as patches (in a directory named ".git/rebase"), update mywork to +them as patches (in a directory named ".git/rebase-apply"), update mywork to point at the latest version of origin, then apply each of the saved patches to the new mywork. The result will look like:

Author

Documentation

AUTHOR

GIT

Author

Documentation

SYNOPSIS

DESCRIPTION

DESCRIPTION

OPTIONS

OPTIONS

SEE ALSO

SEE ALSO

Author

Author

Documentation

Documentation

GIT

GIT

Author

Documentation

Author

Documentation

Author

GIT

SYNOPSIS

DESCRIPTION

DESCRIPTION

OPTIONS

OPTIONS

Author

Author

Documentation

Documentation

GIT

GIT

Author

Documentation

SYNOPSIS

DESCRIPTION

DESCRIPTION

OPTIONS

OPTIONS

Output format

Output format

diff format for merges

diff format for merges

Generating patches with -p

Generating patches with -p

combined diff format

combined diff format

other diff formats

other diff formats

EXAMPLES

EXAMPLES

Author

Author

Documentation

Documentation

GIT

GIT

Author

Documentation

Author

Documentation

Author

Documentation

Author

Documentation

Author

GIT

DESCRIPTION

DESCRIPTION

OPTIONS

OPTIONS

Output Format

Output Format

Author

Author

Documentation