All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.