From: kent@lysator.liu.se
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: [PATCH] Add howto about separating topics.
Date: Sun, 12 Feb 2006 13:00:52 +0100 [thread overview]
Message-ID: <m3accwrdl7.fsf_-_@ceres.unit.liu.se> (raw)
In-Reply-To: <7vmzgxn1dz.fsf@assigned-by-dhcp.cox.net> (Junio C. Hamano's message of "Sat, 11 Feb 2006 11:25:44 -0800")
This howto consists of a footnote from an email by JC to the git
mailing list (<7vfyms0x4p.fsf@assigned-by-dhcp.cox.net>).
Signed-off-by: Kent Engstrom <kent@lysator.liu.se>
---
Documentation/howto/separating-topic-branches.txt | 91 +++++++++++++++++++++
1 files changed, 91 insertions(+), 0 deletions(-)
create mode 100644 Documentation/howto/separating-topic-branches.txt
39f152ae224f45a3d977aa8966a477dbc1df676d
diff --git a/Documentation/howto/separating-topic-branches.txt b/Documentation/howto/separating-topic-branches.txt
new file mode 100644
index 0000000..090e2c9
--- /dev/null
+++ b/Documentation/howto/separating-topic-branches.txt
@@ -0,0 +1,91 @@
+From: Junio C Hamano <junkio@cox.net>
+Subject: Separating topic branches
+Abstract: In this article, JC describes how to separate topic branches.
+
+This text was originally a footnote to a discussion about the
+behaviour of the git diff commands.
+
+Often I find myself doing that [running diff against something other
+than HEAD] while rewriting messy development history. For example, I
+start doing some work without knowing exactly where it leads, and end
+up with a history like this:
+
+ "master"
+ o---o
+ \ "topic"
+ o---o---o---o---o---o
+
+At this point, "topic" contains something I know I want, but it
+contains two concepts that turned out to be completely independent.
+And often, one topic component is larger than the other. It may
+contain more than two topics.
+
+In order to rewrite this mess to be more manageable, I would first do
+"diff master..topic", to extract the changes into a single patch, start
+picking pieces from it to get logically self-contained units, and
+start building on top of "master":
+
+ $ git diff master..topic >P.diff
+ $ git checkout -b topicA master
+ ... pick and apply pieces from P.diff to build
+ ... commits on topicA branch.
+
+ o---o---o
+ / "topicA"
+ o---o"master"
+ \ "topic"
+ o---o---o---o---o---o
+
+Before doing each commit on "topicA" HEAD, I run "diff HEAD"
+before update-index the affected paths, or "diff --cached HEAD"
+after. Also I would run "diff --cached master" to make sure
+that the changes are only the ones related to "topicA". Usually
+I do this for smaller topics first.
+
+After that, I'd do the remainder of the original "topic", but
+for that, I do not start from the patchfile I extracted by
+comparing "master" and "topic" I used initially. Still on
+"topicA", I extract "diff topic", and use it to rebuild the
+other topic:
+
+ $ git diff -R topic >P.diff ;# --cached also would work fine
+ $ git checkout -b topicB master
+ ... pick and apply pieces from P.diff to build
+ ... commits on topicB branch.
+
+ "topicB"
+ o---o---o---o---o
+ /
+ /o---o---o
+ |/ "topicA"
+ o---o"master"
+ \ "topic"
+ o---o---o---o---o---o
+
+After I am done, I'd try a pretend-merge between "topicA" and
+"topicB" in order to make sure I have not missed anything:
+
+ $ git pull . topicA ;# merge it into current "topicB"
+ $ git diff topic
+ "topicB"
+ o---o---o---o---o---* (pretend merge)
+ / /
+ /o---o---o----------'
+ |/ "topicA"
+ o---o"master"
+ \ "topic"
+ o---o---o---o---o---o
+
+The last diff better not to show anything other than cleanups
+for crufts. Then I can finally clean things up:
+
+ $ git branch -D topic
+ $ git reset --hard HEAD^ ;# nuke pretend merge
+
+ "topicB"
+ o---o---o---o---o
+ /
+ /o---o---o
+ |/ "topicA"
+ o---o"master"
+
--
1.1.6.g29e5
next prev parent reply other threads:[~2006-02-12 12:01 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-09 0:29 Two crazy proposals for changing git's diff commands Carl Worth
2006-02-09 1:05 ` Linus Torvalds
2006-02-09 1:21 ` Linus Torvalds
2006-02-09 23:07 ` Carl Worth
2006-02-09 23:40 ` Junio C Hamano
2006-02-09 1:35 ` Junio C Hamano
2006-02-09 1:21 ` Junio C Hamano
2006-02-09 1:30 ` Linus Torvalds
2006-02-09 1:37 ` Junio C Hamano
2006-02-10 9:05 ` Junio C Hamano
2006-02-10 20:32 ` Comments on "status -v" (was: Two crazy proposals for changing git's diff commands) Carl Worth
2006-02-10 21:09 ` Comments on "status -v" Junio C Hamano
2006-02-10 21:35 ` Linus Torvalds
2006-02-10 22:12 ` Junio C Hamano
2006-02-10 22:51 ` Petr Baudis
2006-02-10 23:26 ` Junio C Hamano
2006-02-09 23:44 ` Two crazy proposals for changing git's diff commands Carl Worth
2006-02-10 0:13 ` Junio C Hamano
2006-02-10 1:24 ` Carl Worth
2006-02-10 2:24 ` Junio C Hamano
2006-02-10 3:18 ` Carl Worth
2006-02-10 17:06 ` Mark Wooding
2006-02-13 9:23 ` Catalin Marinas
2006-02-13 22:00 ` Prune-safe StGIT (was Re: Two crazy proposals for changing git's diff commands) Catalin Marinas
2006-02-10 19:36 ` Two crazy proposals for changing git's diff commands Kent Engstrom
2006-02-11 19:25 ` Junio C Hamano
2006-02-12 12:00 ` kent [this message]
2006-02-12 3:15 ` J. Bruce Fields
2006-02-12 3:48 ` Junio C Hamano
2006-02-09 16:44 ` Tim Larson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3accwrdl7.fsf_-_@ceres.unit.liu.se \
--to=kent@lysator.liu.se \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).