linux-next workflow question for cifs

linux-next workflow question for cifs

[Steve French]

Trying to figure out the easiest way for the workflow for the new
cifs-2.6.git linux-next branch for this scenario:

- push a series of patches to cifs-2.6.git linux-next
- someone adds an ack to a patch in the middle, or even a coding
change to a patch in the middle
- how do I easiest make this change and repush (without constantly
doing git push --force)

Do I rename the branch on my local workstation, do a git push (what is
the option to delete a branch remotely...?), then switch on the local
box to the newly renamed branch, amend the patch (will gitk or other
gui tool make this easier than what I use today which is git command
line option which launches a vi-like interface  which is a little bit
of a pain), rename the branch back and then push the new linux-next
branch (and create it on the remote server) ....

-- 
Thanks,

Steve

Re: linux-next workflow question for cifs

[Jeff Layton]

On Wed, 9 May 2012 08:19:05 -0500
Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Trying to figure out the easiest way for the workflow for the new
> cifs-2.6.git linux-next branch for this scenario:
> 
> - push a series of patches to cifs-2.6.git linux-next
> - someone adds an ack to a patch in the middle, or even a coding
> change to a patch in the middle
> - how do I easiest make this change and repush (without constantly
> doing git push --force)
> 
> Do I rename the branch on my local workstation, do a git push (what is
> the option to delete a branch remotely...?), then switch on the local
> box to the newly renamed branch, amend the patch (will gitk or other
> gui tool make this easier than what I use today which is git command
> line option which launches a vi-like interface  which is a little bit
> of a pain), rename the branch back and then push the new linux-next
> branch (and create it on the remote server) ....
> 

The upstream linux-next tree is recreated from scratch every time. So,
there's no harm in rebasing that branch, or rewriting its history. Only
the end product matters.

I use stgit heavily, so editing a patch description in the middle of a
stack is trivial. Not sure what you can do with regular git tools or
something like gitk.

I guess you could create a new branch and cherry-pick all of the
patches from the old, while doing something like "git commit --amend"
to add Reviewed-by lines and such. It's a bit cumbersome, but the basic
git tools are sort of primitive for this sort of thing...

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: linux-next workflow question for cifs

[Sachin Prabhu]

On Wed, 2012-05-09 at 09:45 -0400, Jeff Layton wrote:
> On Wed, 9 May 2012 08:19:05 -0500
> Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> > Trying to figure out the easiest way for the workflow for the new
> > cifs-2.6.git linux-next branch for this scenario:
> > 
> > - push a series of patches to cifs-2.6.git linux-next
> > - someone adds an ack to a patch in the middle, or even a coding
> > change to a patch in the middle
> > - how do I easiest make this change and repush (without constantly
> > doing git push --force)
> > 
> > Do I rename the branch on my local workstation, do a git push (what is
> > the option to delete a branch remotely...?), then switch on the local
> > box to the newly renamed branch, amend the patch (will gitk or other
> > gui tool make this easier than what I use today which is git command
> > line option which launches a vi-like interface  which is a little bit
> > of a pain), rename the branch back and then push the new linux-next
> > branch (and create it on the remote server) ....
> > 
> 
> The upstream linux-next tree is recreated from scratch every time. So,
> there's no harm in rebasing that branch, or rewriting its history. Only
> the end product matters.
> 
> I use stgit heavily, so editing a patch description in the middle of a
> stack is trivial. Not sure what you can do with regular git tools or
> something like gitk.
>
> I guess you could create a new branch and cherry-pick all of the
> patches from the old, while doing something like "git commit --amend"
> to add Reviewed-by lines and such. It's a bit cumbersome, but the basic
> git tools are sort of primitive for this sort of thing...
> 

I've used git rebase -i <commit list>
to amend the commit messages, reorder the patches and also to squash
multiple patches into a single patch. However I am not sure you can push
a branch modified in this manner to a remote server. If you are using a
fresh remote branch each time, this is a non issue.

Sachin Prabhu

Re: linux-next workflow question for cifs

[Steve French]

On Wed, May 9, 2012 at 9:04 AM, Sachin Prabhu <sprabhu-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Wed, 2012-05-09 at 09:45 -0400, Jeff Layton wrote:
>> On Wed, 9 May 2012 08:19:05 -0500
>> Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> > Trying to figure out the easiest way for the workflow for the new
>> > cifs-2.6.git linux-next branch for this scenario:
>> >
>> > - push a series of patches to cifs-2.6.git linux-next
>> > - someone adds an ack to a patch in the middle, or even a coding
>> > change to a patch in the middle
>> > - how do I easiest make this change and repush (without constantly
>> > doing git push --force)
>> >
>> > Do I rename the branch on my local workstation, do a git push (what is
>> > the option to delete a branch remotely...?), then switch on the local
>> > box to the newly renamed branch, amend the patch (will gitk or other
>> > gui tool make this easier than what I use today which is git command
>> > line option which launches a vi-like interface  which is a little bit
>> > of a pain), rename the branch back and then push the new linux-next
>> > branch (and create it on the remote server) ....
>> >
>>
>> The upstream linux-next tree is recreated from scratch every time. So,
>> there's no harm in rebasing that branch, or rewriting its history. Only
>> the end product matters.
>>
>> I use stgit heavily, so editing a patch description in the middle of a
>> stack is trivial. Not sure what you can do with regular git tools or
>> something like gitk.
>>
>> I guess you could create a new branch and cherry-pick all of the
>> patches from the old, while doing something like "git commit --amend"
>> to add Reviewed-by lines and such. It's a bit cumbersome, but the basic
>> git tools are sort of primitive for this sort of thing...
>>
>
> I've used git rebase -i <commit list>
> to amend the commit messages, reorder the patches and also to squash
> multiple patches into a single patch. However I am not sure you can push
> a branch modified in this manner to a remote server. If you are using a
> fresh remote branch each time, this is a non issue.

since you can't manipulate the sparse trees directly on git.samba.org as easily,
then the problem is how do you best do "git remote-branch-delete" and 2nd
what is best gui for editing a patch description in middle (git rebase
-i or commit --amend
works but is harder to use)




-- 
Thanks,

Steve

Re: linux-next workflow question for cifs

[Jeff Layton]

On Wed, 9 May 2012 09:38:07 -0500
Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Wed, May 9, 2012 at 9:04 AM, Sachin Prabhu <sprabhu-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Wed, 2012-05-09 at 09:45 -0400, Jeff Layton wrote:
> >> On Wed, 9 May 2012 08:19:05 -0500
> >> Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>
> >> > Trying to figure out the easiest way for the workflow for the new
> >> > cifs-2.6.git linux-next branch for this scenario:
> >> >
> >> > - push a series of patches to cifs-2.6.git linux-next
> >> > - someone adds an ack to a patch in the middle, or even a coding
> >> > change to a patch in the middle
> >> > - how do I easiest make this change and repush (without constantly
> >> > doing git push --force)
> >> >
> >> > Do I rename the branch on my local workstation, do a git push (what is
> >> > the option to delete a branch remotely...?), then switch on the local
> >> > box to the newly renamed branch, amend the patch (will gitk or other
> >> > gui tool make this easier than what I use today which is git command
> >> > line option which launches a vi-like interface  which is a little bit
> >> > of a pain), rename the branch back and then push the new linux-next
> >> > branch (and create it on the remote server) ....
> >> >
> >>
> >> The upstream linux-next tree is recreated from scratch every time. So,
> >> there's no harm in rebasing that branch, or rewriting its history. Only
> >> the end product matters.
> >>
> >> I use stgit heavily, so editing a patch description in the middle of a
> >> stack is trivial. Not sure what you can do with regular git tools or
> >> something like gitk.
> >>
> >> I guess you could create a new branch and cherry-pick all of the
> >> patches from the old, while doing something like "git commit --amend"
> >> to add Reviewed-by lines and such. It's a bit cumbersome, but the basic
> >> git tools are sort of primitive for this sort of thing...
> >>
> >
> > I've used git rebase -i <commit list>
> > to amend the commit messages, reorder the patches and also to squash
> > multiple patches into a single patch. However I am not sure you can push
> > a branch modified in this manner to a remote server. If you are using a
> > fresh remote branch each time, this is a non issue.
> 
> since you can't manipulate the sparse trees directly on git.samba.org as easily,
> then the problem is how do you best do "git remote-branch-delete" and 2nd
> what is best gui for editing a patch description in middle (git rebase
> -i or commit --amend
> works but is harder to use)
> 
> 

This will delete a remote branch:

    $ git push <remotename> :<remote branch name>

...then just re-push the branch.

    $ git push <remotename> <local branch>:<remote branch>

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: linux-next workflow question for cifs

[J. Bruce Fields]

On Wed, May 09, 2012 at 08:19:05AM -0500, Steve French wrote:
> Trying to figure out the easiest way for the workflow for the new
> cifs-2.6.git linux-next branch for this scenario:
> 
> - push a series of patches to cifs-2.6.git linux-next
> - someone adds an ack to a patch in the middle, or even a coding
> change to a patch in the middle
> - how do I easiest make this change and repush (without constantly
> doing git push --force)

The other way to deal with it is:
	- if there's a coding change, add another patch on top.
	- if an ack or attribution got lost, apologize and try to
	  do better next time.

There are advantages to clean bisectable history, and there are also
advantages to real append-only history:
	- if someone's doing extra work on top of your branch, then
	  rebasing their stuff becomes easier.
	- if someone finds a bug in your branch and fixes it, then you
	  have a record of how that actually happened.

My personal balance is to have one append-only branch that's what gets
pulled into next, and then a different tree with any works in progress
that I can point someone to if necessary.

And I try not to push to the append-only branch until I'm pretty sure
there's been a chance for review, etc.

Not saying that's perfect--there are times when I would've liked to get
a patch some more testing in -next before really committing to it, and
at least one case when someone was annoyed not to be able to improve the
change log on something they submitted.

--b.

Re: linux-next workflow question for cifs

[Jeff Layton]

On Wed, 9 May 2012 13:52:19 -0400
"J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> wrote:

> On Wed, May 09, 2012 at 08:19:05AM -0500, Steve French wrote:
> > Trying to figure out the easiest way for the workflow for the new
> > cifs-2.6.git linux-next branch for this scenario:
> > 
> > - push a series of patches to cifs-2.6.git linux-next
> > - someone adds an ack to a patch in the middle, or even a coding
> > change to a patch in the middle
> > - how do I easiest make this change and repush (without constantly
> > doing git push --force)
> 
> The other way to deal with it is:
> 	- if there's a coding change, add another patch on top.
> 	- if an ack or attribution got lost, apologize and try to
> 	  do better next time.
> 
> There are advantages to clean bisectable history, and there are also
> advantages to real append-only history:
> 	- if someone's doing extra work on top of your branch, then
> 	  rebasing their stuff becomes easier.
> 	- if someone finds a bug in your branch and fixes it, then you
> 	  have a record of how that actually happened.
> 
> My personal balance is to have one append-only branch that's what gets
> pulled into next, and then a different tree with any works in progress
> that I can point someone to if necessary.
> 
> And I try not to push to the append-only branch until I'm pretty sure
> there's been a chance for review, etc.
> 
> Not saying that's perfect--there are times when I would've liked to get
> a patch some more testing in -next before really committing to it, and
> at least one case when someone was annoyed not to be able to improve the
> change log on something they submitted.
> 
> --b.

For "normal" branches that you expect people to pull, I agree. For
linux-next though, it really doesn't matter too much since it gets
re-created from scratch every day.

Rewriting history is explicitly ok there, but you do of course want
that branch to be bisectable if at all possible in order to make it
easier to track down regressions.

OTOH, if someone says "I got a panic on linux-next from on last
Thursday", it might be tough to know what was in that pull if you're
changing the history regularly. It is a bit of a balancing act, I guess.

In any case, for some background...the problem we're trying to solve
here is that patches sit on linux-cifs mailing list with no activity
for months when they should be soaking in linux-next. So we're trying
to come up with a workflow that allows us to get them into linux-next
in a more timely fashion. If that requires not using an append-only
branch, I'm ok with that...

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: linux-next workflow question for cifs

[J. Bruce Fields]

On Wed, May 09, 2012 at 02:08:47PM -0400, Jeff Layton wrote:
> For "normal" branches that you expect people to pull, I agree. For
> linux-next though, it really doesn't matter too much since it gets
> re-created from scratch every day.
> 
> Rewriting history is explicitly ok there, but you do of course want
> that branch to be bisectable if at all possible in order to make it
> easier to track down regressions.
> 
> OTOH, if someone says "I got a panic on linux-next from on last
> Thursday", it might be tough to know what was in that pull if you're
> changing the history regularly. It is a bit of a balancing act, I guess.

Yeah.  So the way I currently do it, in case it's of any use:

I have a for-next branch in my public repo, and a for-next-incoming in my
local repo.  The latter gets rebased, the former doesn't.

I apply stuff to for-next-incoming when I start considering it, but I
rearrange and rewrite it on top of for-next all the time.

Every now and then I do a

	gitk for-next..for-next-incoming

and look for the longest initial set of commits that:

	- are based on patches that have been posted at least 24 hours.
	  (Exceptions for something urgent or trivial.)
	- have passed any required review.

I run about a half hour of simple automated regression tests on the
commit at the top of that initial piece and push it to for-3.5.

I try to do that as I go along, rather than waiting a month and then
pushing a bunch out at once.

There are some things that -next testing routinely catches that I still
miss (cross-compiles or various config options).  I should probably add
more of those to my tests.

But so far that's been close enough to bisectable that I haven't felt
a strong need to break my self-imposed rule and rebase.

> In any case, for some background...the problem we're trying to solve
> here is that patches sit on linux-cifs mailing list with no activity
> for months when they should be soaking in linux-next. So we're trying
> to come up with a workflow that allows us to get them into linux-next
> in a more timely fashion. If that requires not using an append-only
> branch, I'm ok with that...

Makes sense.

--b.