b4 prep HEAD fails when specifying branch point

b4 prep HEAD fails when specifying branch point

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

Using Debian bullseye with backports of git installed to get
filter-branch if I attempt to run b4 prep it refuses to create a
new branch saying:

| $  b4 -d prep -n b4-test -f v6.0-rc3
| Running git --no-pager status --porcelain=v1 --untracked-files=no
| Running git --no-pager symbolic-ref -q HEAD
| Running git --no-pager config -z --get-regexp branch\.master\..*
| Running git --no-pager rev-parse --show-toplevel
| Running git --no-pager config -z --get-regexp b4\..*
| Running git --no-pager config -z --get-regexp gpg\..*
| Looking for the cover letter commit with magic marker "--- b4-submit-tracking ---"
| Running git --no-pager log --grep --- b4-submit-tracking --- -F --pretty=oneline --max-count=1 --since=1.year
| Running git --no-pager config -z --get-regexp user\..*
| Running git --no-pager symbolic-ref -q HEAD
| Running git --no-pager symbolic-ref -q HEAD
| Running git --no-pager config -z --get-regexp branch\.master\..*
| CRITICAL: fork-point %s is not on the current branch.
|           Switch to the branch you want to use as base and try again.

AFAICT this happens no matter what fork point is specified.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: b4 prep HEAD fails when specifying branch point

[Konstantin Ryabitsev]

On Tue, Dec 06, 2022 at 10:07:19PM +0000, Mark Brown wrote:
> Using Debian bullseye with backports of git installed to get
> filter-branch if I attempt to run b4 prep it refuses to create a
> new branch saying:

Thank you for the report -- looks like I broke it when I fixed it last. ;)
It shouldn't break in the current master.

-K

Re: b4 prep HEAD fails when specifying branch point

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Tue, Dec 06, 2022 at 05:15:46PM -0500, Konstantin Ryabitsev wrote:
> On Tue, Dec 06, 2022 at 10:07:19PM +0000, Mark Brown wrote:

> > Using Debian bullseye with backports of git installed to get
> > filter-branch if I attempt to run b4 prep it refuses to create a
> > new branch saying:

> Thank you for the report -- looks like I broke it when I fixed it last. ;)
> It shouldn't break in the current master.

Thanks.  That fixed the immediate thing however I ran into
another issue while trying to test it:

| $ b4 prep -n b4-test2 -f next/master
| CRITICAL: This appears to already be a b4-prep managed branch.

Given that I'm asking to start from a specific point I'd have
expected that the current branch shouldn't matter.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: b4 prep HEAD fails when specifying branch point

[Konstantin Ryabitsev]

On Tue, Dec 06, 2022 at 10:58:05PM +0000, Mark Brown wrote:
> > Thank you for the report -- looks like I broke it when I fixed it last. ;)
> > It shouldn't break in the current master.
> 
> Thanks.  That fixed the immediate thing however I ran into
> another issue while trying to test it:
> 
> | $ b4 prep -n b4-test2 -f next/master
> | CRITICAL: This appears to already be a b4-prep managed branch.
> 
> Given that I'm asking to start from a specific point I'd have
> expected that the current branch shouldn't matter.

Right, this can be more nuanced than it is right now. It's this blunt mostly
because we can run into multiple troubles here if we're not careful. For
example:

- if you specify a fork-point that's past the start of the series, we will run
  into trouble because we will end up with multiple cover letter commits in
  the history
- if you specify a fork-point that exists on multiple branches, we'll need
  some logic to make sure that we don't use another prep branch as our
  tracking branch -- but only when we use non-default cover letter storage
  strategies

Since my primary goal with this work is to simplify the process for newbies
and occasional committers, b4 tries to enforce the workflow of 1) switch to
the branch from which you want to fork, b) specify the tag in this branch that
you want to use as the fork-point.

I may either add the logic above, or just give a less obtuse error message,
such as:

    CRITICAL: This appears to already be a b4-prep managed branch.
              To avoid possible ambiguity, please switch to the branch
              on which you want to base your work and then try again.

Or a bit of both.

Thank you for the report.

-K

Re: b4 prep HEAD fails when specifying branch point

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

On Tue, Dec 06, 2022 at 08:11:00PM -0500, Konstantin Ryabitsev wrote:
> On Tue, Dec 06, 2022 at 10:58:05PM +0000, Mark Brown wrote:

> - if you specify a fork-point that's past the start of the series, we will run
>   into trouble because we will end up with multiple cover letter commits in
>   the history
> - if you specify a fork-point that exists on multiple branches, we'll need
>   some logic to make sure that we don't use another prep branch as our
>   tracking branch -- but only when we use non-default cover letter storage
>   strategies

> Since my primary goal with this work is to simplify the process for newbies
> and occasional committers, b4 tries to enforce the workflow of 1) switch to
> the branch from which you want to fork, b) specify the tag in this branch that
> you want to use as the fork-point.

Right, so a common use case here is that you want to fork from a remote
branch (generally something in the maintainer's tree).  For me that'd
probably mean that I'd end up with a lot of branches tracking a branch
called tmp.  I'm not sure if that *matters* though.

> I may either add the logic above, or just give a less obtuse error message,
> such as:

>     CRITICAL: This appears to already be a b4-prep managed branch.
>               To avoid possible ambiguity, please switch to the branch
>               on which you want to base your work and then try again.

> Or a bit of both.

That'd make it clear that it's an intentional decision which would be
good.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: b4 prep HEAD fails when specifying branch point

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

On Wed, Dec 07, 2022 at 12:42:20PM +0000, Mark Brown wrote:
> On Tue, Dec 06, 2022 at 08:11:00PM -0500, Konstantin Ryabitsev wrote:

> > Since my primary goal with this work is to simplify the process for newbies
> > and occasional committers, b4 tries to enforce the workflow of 1) switch to
> > the branch from which you want to fork, b) specify the tag in this branch that
> > you want to use as the fork-point.

> Right, so a common use case here is that you want to fork from a remote
> branch (generally something in the maintainer's tree).  For me that'd
> probably mean that I'd end up with a lot of branches tracking a branch
> called tmp.  I'm not sure if that *matters* though.

Ah, yeah - turns out it really does matter, b4 send gets very confused
about what it should send if the base branch isn't actually the base
branch.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Feature requests

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

Hi Konstantin,

I've had another look at potentially adopting b4 prep/send as a
replacement for the bits of my scripting that it covers.  I did
find a couple of gaps that are causing friction though:

 - Some command line options for extracting the metadata for the
   series would be helpful - the main one I'm looking for is
   series.revision, some of my scripts operate on all the
   branches I've got that have unsent changes which I could do by
   comparing the current version with the last sent version.  An
   equivalent of git config get/set for the series metadata would
   cover all this and more.

 - Being able to get the commit ID of the metadata commit would
   be useful so I can do testing on the actual commits in the
   branch (when using the commit cover strategy).  Alternatively,
   I'd use this to generate a list of commits in the branch so
   that list would also do the job, but getting the ID for the
   metadata commit seems more general.

 - It would be nice if there was an option to sign the tags used
   when tagging sent branches, especially when signing the actual
   sent patches.

Thanks for working on b4, it's really useful.

Thanks,
Mark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Feature requests

[Konstantin Ryabitsev]

[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]

On Tue, Dec 06, 2022 at 11:52:25PM +0000, Mark Brown wrote:
> Hi Konstantin,
> 
> I've had another look at potentially adopting b4 prep/send as a
> replacement for the bits of my scripting that it covers.  I did
> find a couple of gaps that are causing friction though:
> 
>  - Some command line options for extracting the metadata for the
>    series would be helpful - the main one I'm looking for is
>    series.revision, some of my scripts operate on all the
>    branches I've got that have unsent changes which I could do by
>    comparing the current version with the last sent version.  An
>    equivalent of git config get/set for the series metadata would
>    cover all this and more.
> 
>  - Being able to get the commit ID of the metadata commit would
>    be useful so I can do testing on the actual commits in the
>    branch (when using the commit cover strategy).  Alternatively,
>    I'd use this to generate a list of commits in the branch so
>    that list would also do the job, but getting the ID for the
>    metadata commit seems more general.

I believe the latest master should have what you need:

    $ b4 prep --show-info
    branch: b4/bupkes-bogus
    cover-subject: [RFC] Another completely bogus series, ignore
    prefixes: RFC
    change-id: 20221205-bupkes-bogus-8f0db5172091
    revision: 6
    cover-strategy: commit
    base-branch: master
    base-commit: bce9332220bd677d83b19d21502776ad555a0e73
    start-commit: 8398c66ced5379a8b84d59ec7f703e9809b17c12
    end-commit: ae4436d441721dd884355b637f02dbc620ad422d
    commit-ae4436d44172: Rename linux into pengux
    commit-c0075ed67f3f: Makefile: Make it a ninja penguin


>  - It would be nice if there was an option to sign the tags used
>    when tagging sent branches, especially when signing the actual
>    sent patches.

Theoretically, this is already possible via tag.gpgSign = yes. Would that be a
suitable approach?

-K

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Feature requests

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]

On Fri, Dec 09, 2022 at 04:09:32PM -0500, Konstantin Ryabitsev wrote:
> On Tue, Dec 06, 2022 at 11:52:25PM +0000, Mark Brown wrote:

> > I've had another look at potentially adopting b4 prep/send as a
> > replacement for the bits of my scripting that it covers.  I did
> > find a couple of gaps that are causing friction though:
> > 
> >  - Some command line options for extracting the metadata for the

...

> >    comparing the current version with the last sent version.  An
> >    equivalent of git config get/set for the series metadata would
> >    cover all this and more.

> I believe the latest master should have what you need:

>     $ b4 prep --show-info
>     branch: b4/bupkes-bogus
>     cover-subject: [RFC] Another completely bogus series, ignore
>     prefixes: RFC
>     change-id: 20221205-bupkes-bogus-8f0db5172091
>     revision: 6
>     cover-strategy: commit
>     base-branch: master
>     base-commit: bce9332220bd677d83b19d21502776ad555a0e73
>     start-commit: 8398c66ced5379a8b84d59ec7f703e9809b17c12
>     end-commit: ae4436d441721dd884355b637f02dbc620ad422d
>     commit-ae4436d44172: Rename linux into pengux
>     commit-c0075ed67f3f: Makefile: Make it a ninja penguin

That does the read side great, thanks - the write side would still be
useful, mainly for the base-branch which can change during the lifetime
of a series (it's common to move between mainline and topic branches in
the upstream repo in both directions).

> >  - It would be nice if there was an option to sign the tags used
> >    when tagging sent branches, especially when signing the actual
> >    sent patches.

> Theoretically, this is already possible via tag.gpgSign = yes. Would that be a
> suitable approach?

Yes, that should work for me for now - I guess there will be some people
who do use unsigned tags who'd want to sign these particular tags.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]