Since we use a-b-c for mywork commits in one place, I think it would be
logical to also use a-b-c too in other illustration on this topic.
Signed-off-by: Kirill Smelkov <kirr@xxxxxxxxxx>
---
Documentation/user-manual.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index fecc4eb..87ca1a7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2424,41 +2424,41 @@ Keeping a patch series up to date using git rebase
--------------------------------------------------
Suppose that you create a branch "mywork" on a remote-tracking branch
"origin", and create some commits on top of it:
-------------------------------------------------
$ git checkout -b mywork origin
$ vi file.txt
$ git commit
$ vi otherfile.txt
$ git commit
...
-------------------------------------------------
You have performed no merges into mywork, so it is just a simple linear
sequence of patches on top of "origin":
................................................
o--o--o <-- origin
\
- o--o--o <-- mywork
+ a--b--c <-- mywork
................................................
Some more interesting work has been done in the upstream project, and
"origin" has advanced:
................................................
o--o--O--o--o--o <-- origin
\
a--b--c <-- mywork
................................................
At this point, you could use "pull" to merge your changes back in;
the result would create a new merge commit, like this:
................................................
o--o--O--o--o--o <-- origin
\ \
a--b--c--m <-- mywork
................................................
--
1.7.3.6.g64005
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html