git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).