Submit/Workflow question

Submit/Workflow question

[David Kastrup]

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, Kriemhildstr. 15, 44793 Bochum

Re: Submit/Workflow question

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> 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?

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?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Submit/Workflow question

[J. Bruce Fields]

On Sun, Jul 29, 2007 at 05:56:54PM +0200, David Kastrup 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.  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,

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

> 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?

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.

Re: Submit/Workflow question

[David Kastrup]

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

> On Sun, Jul 29, 2007 at 05:56:54PM +0200, David Kastrup wrote:
>> 
>> Suppose that I have created a half-baked patch A suiting my personal
>> needs and went on from there, having something like
>
> 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.

Thanks.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Submit/Workflow question

[Jason Sewall]

On 7/29/07, David Kastrup <dak@gnu.org> 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