mricon / b4

Tool to help with email-based patch workflows
GNU General Public License v2.0
59 stars 20 forks source link

prep failing #19

Closed marcosps closed 6 months ago

marcosps commented 6 months ago

I installed b4 from current github master:

pipx install --force git+https://github.com/mricon/b4                                        1 ✘ 
Installing to existing venv 'b4'
  installed package b4 0.13.dev0, installed using Python 3.11.6
  These apps are now globally available
    - b4
done! ✨ 🌟 ✨

My current branch is kselftests/next. When I tried to run prep, it happed:

b4 prep -n lp-selftests-fixes                                                             ✔  4s 
Not able to get current branch (git symbolic-ref HEAD)
Not able to get current branch (git symbolic-ref HEAD)
Not able to get current branch (git symbolic-ref HEAD)
Traceback (most recent call last):
  File "/home/mpdesouza/.local/bin/b4", line 8, in <module>
    sys.exit(cmd())
             ^^^^^
  File "/home/mpdesouza/.local/pipx/venvs/b4/lib64/python3.11/site-packages/b4/command.py", line 397, in cmd
    cmdargs.func(cmdargs)
  File "/home/mpdesouza/.local/pipx/venvs/b4/lib64/python3.11/site-packages/b4/command.py", line 78, in cmd_prep
    b4.ez.cmd_prep(cmdargs)
  File "/home/mpdesouza/.local/pipx/venvs/b4/lib64/python3.11/site-packages/b4/ez.py", line 2233, in cmd_prep
    if is_prep_branch() and not cmdargs.fork_point:
       ^^^^^^^^^^^^^^^^
  File "/home/mpdesouza/.local/pipx/venvs/b4/lib64/python3.11/site-packages/b4/ez.py", line 660, in is_prep_branch
    if find_cover_commit(usebranch=mybranch) is None:
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mpdesouza/.local/pipx/venvs/b4/lib64/python3.11/site-packages/b4/ez.py", line 688, in find_cover_commit
    lines = b4.git_get_command_lines(None, gitargs)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mpdesouza/.local/pipx/venvs/b4/lib64/python3.11/site-packages/b4/__init__.py", line 2681, in git_get_command_lines
    ecode, out = git_run_command(gitdir, args)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mpdesouza/.local/pipx/venvs/b4/lib64/python3.11/site-packages/b4/__init__.py", line 2654, in git_run_command
    ecode, out, err = _run_command(cmdargs, stdin=stdin, rundir=rundir)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mpdesouza/.local/pipx/venvs/b4/lib64/python3.11/site-packages/b4/__init__.py", line 2619, in _run_command
    logger.debug('Running %s' % ' '.join(cmdargs))
                                ^^^^^^^^^^^^^^^^^
TypeError: sequence item 10: expected str instance, NoneType found

Am I using in the wrong way?

Thanks!

mricon commented 6 months ago

I'm not familiar with pipx, but I don't think it would matter. I'm curious about the fact that calling "git symbolic-ref HEAD" is failing. Can you run git symbolic-ref HEAD in the same place in the tree where you tried to run b4 prep?

marcosps commented 6 months ago

I'm not familiar with pipx, but I don't think it would matter. I'm curious about the fact that calling "git symbolic-ref HEAD" is failing. Can you run git symbolic-ref HEAD in the same place in the tree where you tried to run b4 prep?

$ git symbolic-ref HEAD 
fatal: ref HEAD is not a symbolic ref
$ git branch
  * (HEAD detached at kselftests/next)

In my understanding b4 prep would create a new branch based on my current HEAD (I tried to pass -f kselftests/next and the same error appeared.

But, I created a new branch based on kselftests/next by using:

$ git switch -C fix-kselftests kselftests/next
branch 'fix-kselftests' set up to track 'kselftests/next'.
Switched to a new branch 'fix-kselftests'

And symbolic-ref HEAD worked:

$ git symbolic-ref HEAD
refs/heads/fix-kselftests

And then b4 prep worked:

$ b4 prep -n lp-selftests-fixes
Created new branch b4/lp-selftests-fixes
Created the default cover letter, you can edit with --edit-cover.

I believe I'm doing something wrong here :P

mricon commented 6 months ago
$ git symbolic-ref HEAD 
fatal: ref HEAD is not a symbolic ref
$ git branch
  * (HEAD detached at kselftests/next)

Right, we don't currently expect the tree to be in a detached-head state.

I believe I'm doing something wrong here :P

No, you're good -- we just need to properly handle the situation where we're starting with a detached HEAD. It shouldn't cause a critical failure.

I'll keep this issue open until I have a fix in place.

Thanks for the report.