# Re: drivers/block/cpqarray.c:938:2: error: too many arguments to function 慴lk_rq_map_sg�

4 messages from 2012-06-14 to 2012-06-14. Participants: Fengguang Wu, Junio C Hamano, Tomas Carnecky.
Thread: https://gitlist.dev/t/30805

## Fengguang Wu, 2012-06-14 09:25

Subject: Re: drivers/block/cpqarray.c:938:2: error: too many arguments to function 慴lk_rq_map_sg�
Message-ID: <20120614092519.GA12482@localhost>
URL: https://gitlist.dev/e/20120614092519.GA12482%40localhost
In-Reply-To: <4FD9A95D.40903@kernel.dk>

```
On Thu, Jun 14, 2012 at 11:05:33AM +0200, Jens Axboe wrote:
> On 06/14/2012 11:01 AM, Fengguang Wu wrote:
> > Hi Jens,
> > 
> > On Thu, Jun 14, 2012 at 08:30:11AM +0200, Jens Axboe wrote:
> >> On 06/14/2012 01:03 AM, wfg@linux.intel.com wrote:
> >>> FYI, kernel build failed on
> >>>
> >>> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git multiqueue
> >>> head:   e9a6aa8a0b7b93195774a9fcf551632bf3abcd97
> >>> commit: 67db7275fa4325d46853a4bfcb79acf32e48eca8 [1/3] multiqueue: a hodge podge of things
> >>
> >> The multiqueue branch is a private branch, it's known broken on many
> >> configs at the moment.
> > 
> > OK. Sorry my script just blindly build tests every new/updated branches
> > in the tree. It does try to reduce noise level by remembering all warned
> > error messages. However if it still presents a problem to the private
> > branches, I can either explicitly blacklist "multiqueue", or let the
> > script automatically skip commits whose "^Signed-off-by:" is still missing.
> 
> It's not a problem that you're building various branches, as long as you
> are expecting a bit of noise :-). In fact I applaud your effort on
> expanding the scope of building others branches.

Thank you :-)

> But it does raise the question of how do we best signal intermediate
> branches like this, so they can be avoided until they are ready. The
> blacklist doesn't seem like a great choice, since then I have to
> remember to remind you when it _is_ ok to build it.
> 
> How about some arbitrary tag? Instead of checking a Signed-off-by, I
> could just add a Dont-Auto-Build or something like that. What do you
> think?

Anything convenient to you would be fine.

If we can somehow tag the whole branch, it would be most convenient.
Git can add description to a branch with

        git branch --edit-description [branch name]

However I don't know how to retrieve that description on a remote
branch..

Thanks,
Fengguang

```

## Fengguang Wu, 2012-06-14 11:31

Subject: Re: drivers/block/cpqarray.c:938:2: error: too many arguments to function lk_rq_map_sg
Message-ID: <20120614113142.GA13954@localhost>
URL: https://gitlist.dev/e/20120614113142.GA13954%40localhost
In-Reply-To: <4FD9C0D2.20500@kernel.dk>

```
On Thu, Jun 14, 2012 at 12:45:38PM +0200, Jens Axboe wrote:
> On 06/14/2012 12:02 PM, Fengguang Wu wrote:
> > On Thu, Jun 14, 2012 at 11:05:33AM +0200, Jens Axboe wrote:
> >> On 06/14/2012 11:01 AM, Fengguang Wu wrote:
> >>> Hi Jens,
> >>>
> >>> On Thu, Jun 14, 2012 at 08:30:11AM +0200, Jens Axboe wrote:
> >>>> On 06/14/2012 01:03 AM, wfg@linux.intel.com wrote:
> >>>>> FYI, kernel build failed on
> >>>>>
> >>>>> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git multiqueue
> >>>>> head:   e9a6aa8a0b7b93195774a9fcf551632bf3abcd97
> >>>>> commit: 67db7275fa4325d46853a4bfcb79acf32e48eca8 [1/3] multiqueue: a hodge podge of things
> >>>>
> >>>> The multiqueue branch is a private branch, it's known broken on many
> >>>> configs at the moment.
> >>>
> >>> OK. Sorry my script just blindly build tests every new/updated branches
> >>> in the tree. It does try to reduce noise level by remembering all warned
> >>> error messages. However if it still presents a problem to the private
> >>> branches, I can either explicitly blacklist "multiqueue", or let the
> >>> script automatically skip commits whose "^Signed-off-by:" is still missing.
> >>
> >> It's not a problem that you're building various branches, as long as you
> >> are expecting a bit of noise :-). In fact I applaud your effort on
> >> expanding the scope of building others branches.
> >>
> >> But it does raise the question of how do we best signal intermediate
> >> branches like this, so they can be avoided until they are ready. The
> >> blacklist doesn't seem like a great choice, since then I have to
> >> remember to remind you when it _is_ ok to build it.
> >>
> >> How about some arbitrary tag? Instead of checking a Signed-off-by, I
> >> could just add a Dont-Auto-Build or something like that. What do you
> >> think?
> > 
> > OK, I'll add a grep for "Dont-Auto-Build". If it's found in *any*
> > commit of the branch, the build script will skip the whole branch.
> > Does this make sense to you?
> 
> Yeah that'll work for me. A description or tag might be more elegant,
> but this is easier...

Great, let's settle with the in-commit tag "Dont-Auto-Build" for now :)

"git branch --edit-description" could potentially be the most elegant
solution, unfortunately for now there seems no way for me to retrieve
the branch description edited by you..

Another alternative, git tag, has the problem that it goes out of sync
every time you do rebase, which will sure happen a lot for early RFC
patches.

Thanks,
Fengguang

```

## Tomas Carnecky, 2012-06-14 11:52

Subject: Re: drivers/block/cpqarray.c:938:2: error: too many arguments to function lk_rq_map_sg
Message-ID: <1339674758-ner-4999@calvin>
URL: https://gitlist.dev/e/1339674758-ner-4999%40calvin
In-Reply-To: <20120614113142.GA13954@localhost>

```
On Thu, 14 Jun 2012 19:31:42 +0800, Fengguang Wu <wfg@linux.intel.com> wrote:
> On Thu, Jun 14, 2012 at 12:45:38PM +0200, Jens Axboe wrote:
> > On 06/14/2012 12:02 PM, Fengguang Wu wrote:
> > > OK, I'll add a grep for "Dont-Auto-Build". If it's found in *any*
> > > commit of the branch, the build script will skip the whole branch.
> > > Does this make sense to you?
> > 
> > Yeah that'll work for me. A description or tag might be more elegant,
> > but this is easier...
> 
> Great, let's settle with the in-commit tag "Dont-Auto-Build" for now :)
> 
> "git branch --edit-description" could potentially be the most elegant
> solution, unfortunately for now there seems no way for me to retrieve
> the branch description edited by you..
> 
> Another alternative, git tag, has the problem that it goes out of sync
> every time you do rebase, which will sure happen a lot for early RFC
> patches.

Commit notes or a special namespace for branches (refs/heads/wip/...) would
also be an option.

tom


```

## Junio C Hamano, 2012-06-14 17:26

Subject: Re: drivers/block/cpqarray.c:938:2: error: too many arguments to function 慴lk_rq_map_sg�
Message-ID: <7vpq91erer.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vpq91erer.fsf%40alter.siamese.dyndns.org
In-Reply-To: <20120614092519.GA12482@localhost>

```
Fengguang Wu <wfg@linux.intel.com> writes:

> If we can somehow tag the whole branch, it would be most convenient.
> Git can add description to a branch with
>
>         git branch --edit-description [branch name]
>
> However I don't know how to retrieve that description on a remote
> branch..

The branch description is designed to be a place you leave your
temporary note locally outside the history, until you are ready to
set the contents of the branch in more permanent storage (e.g. by
merging it to an integration branch, or sending pull requests for
it) at which time the information is consumed (e.g. inserted in the
merge commit message or pull request message).  The history exchange
via "git push" / "git fetch" is by definition about exchanging the
history, and will not transfer branch descriptions.

For shared and more permanent notes, "git notes" may be more
suitable vehicle.

```
