freshlybakedca.ke
Git fork
Documentation: remove stale howto/rebase-and-edit.txt
The "rebase and edit" howto predates the much easier solution 'git
rebase -i' by two years.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
authored by
Thomas Rast
and committed by
Shawn O. Pearce
616ab437
3fee1fe8
-79
-79
Documentation/howto/rebase-and-edit.txt
-79
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