Submit/Workflow question

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. Basically, I'd want to do git-reset --hard A [edit some] git-commit --amend -a git-format-patch HEAD~1

in order to arrive at a nice submittable patch. However, I don't want to lose B and the following stuff, and the resulting HEAD should include the improved of A (it is fine if that needs additional steps, and it is fine if it is just HEAD that gets the fixed version, not B).

So how to do this? Branch at A^, rebase on A, fix the stuff, commit with --amend -a, rebase on master, rename the temporary branch to master (killing the old master), format and submit the patch?

Or is there some bad thinko in there?  Or is this too complicated?

David Kastrup <dak@gnu.org> writes:

Uh, too many rebases.

I mean:

Branch at A^, merge A, fix the stuff, commit with --amend -a, merge master, rename the temporary branch to master (killing the old master), format and submit the patch?

On Sun, Jul 29, 2007 at 05:56:54PM +0200, David Kastrup wrote:

Just branch on A. Or actually I just check out A at this point (leaving me not on any branch).

I'm not completely sure I follow that sequence, but something like that should work. A similar approach:

	http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#modifying-one-commit

I do something pretty close to what's described there, except I generally just cut and paste SHA1's instead of making the temporary tag.

--b.

"J. Bruce Fields" <bfields@fieldses.org> writes:

Thanks.

On 7/29/07, David Kastrup <dak@gnu.org> wrote:

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