> I'm planning to write a section in the "Nutshell guide" on rewriting
> history and rebasing. I have a question related to rewriting history. As
> usual, I'll assume that the part of the history I'm mucking with has not
> been pushed or pulled by anyone.
> Suppose I have been working on some topic branch for a while and been
> overly trigger happy, i.e. I have produced a ridiculous number of
> commits along the way. At some point when I'm done I want to publish my
> changes, but doing so would create an insanely obese history full of
> near nonsense commits. What I want to do is to slim down the commit log
> into pieces that actually makes sense. What is the preferred (or best,
> most convenient) way of doing this? The way I have done this previously
> is essentially:
>
> 1. git branch -m mytopic tmp_mytopic # rename
> 2. git branch mytopci tmp_mytpoic~42 # go back in history
> Loop:
> 3.1 git log; git diff; git annotate...
> 3.2 git diff tmp_mytopic~42..tmp_mytopic~33 | git-apply
> 3.3 git commit -m "sane commit message" -a
> 4. git branch -d tmp_mytopic
>
> If I need to reorder commits I can first use git-rebase -i to get
> everything streamlined. There must be a better way of doing this, right?
IIRC rebase -i is also capable of merging the commits. So you can use it
for the whole thing.
--
Jan Hudec <bulb@xxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
