Merge branch 'maint'
[git] / Documentation / howto / rebase-and-edit.txt
1 Date:   Sat, 13 Aug 2005 22:16:02 -0700 (PDT)
2 From:   Linus Torvalds <torvalds@osdl.org>
3 To:     Steve French <smfrench@austin.rr.com>
4 cc:     git@vger.kernel.org
5 Subject: Re: sending changesets from the middle of a git tree
6 Abstract: In this article, Linus demonstrates how a broken commit
7  in a sequence of commits can be removed by rewinding the head and
8  reapplying selected changes.
9
10 On Sat, 13 Aug 2005, Linus Torvalds wrote:
11
12 > That's correct. Same things apply: you can move a patch over, and create a
13 > new one with a modified comment, but basically the _old_ commit will be
14 > immutable.
15
16 Let me clarify.
17
18 You can entirely _drop_ old branches, so commits may be immutable, but
19 nothing forces you to keep them. Of course, when you drop a commit, you'll
20 always end up dropping all the commits that depended on it, and if you
21 actually got somebody else to pull that commit you can't drop it from
22 _their_ repository, but undoing things is not impossible.
23
24 For example, let's say that you've made a mess of things: you've committed
25 three commits "old->a->b->c", and you notice that "a" was broken, but you
26 want to save "b" and "c". What you can do is
27
28         # Create a branch "broken" that is the current code
29         # for reference
30         git branch broken
31
32         # Reset the main branch to three parents back: this
33         # effectively undoes the three top commits
34         git reset HEAD^^^
35         git checkout -f
36
37         # Check the result visually to make sure you know what's
38         # going on
39         gitk --all
40
41         # Re-apply the two top ones from "broken"
42         #
43         # First "parent of broken" (aka b):
44         git-diff-tree -p broken^ | git-apply --index
45         git commit --reedit=broken^
46
47         # Then "top of broken" (aka c):
48         git-diff-tree -p broken | git-apply --index
49         git commit --reedit=broken
50
51 and you've now re-applied (and possibly edited the comments) the two
52 commits b/c, and commit "a" is basically gone (it still exists in the
53 "broken" branch, of course).
54
55 Finally, check out the end result again:
56
57         # Look at the new commit history
58         gitk --all
59
60 to see that everything looks sensible.
61
62 And then, you can just remove the broken branch if you decide you really
63 don't want it:
64
65         # remove 'broken' branch
66         git branch -d broken
67
68         # Prune old objects if you're really really sure
69         git prune
70
71 And yeah, I'm sure there are other ways of doing this. And as usual, the
72 above is totally untested, and I just wrote it down in this email, so if
73 I've done something wrong, you'll have to figure it out on your own ;)
74
75                         Linus
76 -
77 To unsubscribe from this list: send the line "unsubscribe git" in
78 the body of a message to majordomo@vger.kernel.org
79 More majordomo info at  http://vger.kernel.org/majordomo-info.html