On 7/29/07, David Kastrup <dak@xxxxxxx> wrote:
>
> Suppose that I have created a half-baked patch A suiting my personal
> needs and went on from there, having something like
>
> ...->A->B->...
>
> Now at some point of time I decide that really A should be made fit
> for submission.
What I do in this sort of situation varies on how good I was about
keeping A and B "independent"; first of all, let's assume you're not
on 'master', you're on 'some-feature' (and if you weren't, it's easy
to make it a branch, tho you might have to rebase the branch to the
point on master where the patch is meaningful to others, and
optionally rewind master to keep it clean)
some-feature: A->B->...
/
master: ->W->X->Y->Z
If I really want to edit *just* A and not use any of B at all, then
the excellent rebase -i would do the job - you may want to rebase to
Z, or if A weren't the first commit exclusive to your branch, you
could rebase to whatever that is...
The point is that rebase -i will let you say "edit just A, just apply
B afterwards" and it will rewrite history for you after you fix A, and
then it will try to apply B on top of A, and so on until you're done.
Sometimes, rebase -i doesn't cut it for me, (because I didn't make my
commits cleanly separated, or perhaps because I haven't totally
explored rebase) - then I do it the "old-fashioned way" which it the
way this was usually done before rebase -i. I make a temporary branch
off of master called (apply-some-feature) and I start generating diffs
between this new branch and some-feature. A apply them, sometimes
reaching across commits and so forth, and commit the changes in nice,
clean format. When I'm done, *I* usually merge these onto master (if
its my own project) but if you were going to make it into a patch, I
would probably just replace some-feature with apply-some-feature.
It's probably pretty self-evident, but (git) diff (and some sort of
visual patch-applier) is pretty powerful and you can generate very
"narrow" diffs to look at just the parts you want to for a given step
in this process. And of course, you can use to to make sure that at
the end, apply-some-feature and some-feature's HEADS have the same
tree (or not, if you chose to omit some debugging stuff as I often
do).
By the way, the way Bruce suggested was fine too, I just though I'd
share what I do in this sort of situation (and I do it often because I
always forget to make my commits clean the first time)
Jason
-
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
