b4 prep -e oddness

[Vishal Verma <vishal@kernel.org>]

Hi Konstantin,

I'm seeing some odd behavior with b4 prep -e.

A common workflow for me ends up looking like:

- current branch is master
- make some changes, commit on master
- realize this is turning into a patch series
- git switch -c new_branch (this pulls in my new commits to new_branch)
- reset master to where it was before my new commits (say v6.2-rc3)
- b4 prep -e master (I expect this to enroll new_branch, and its new
commits, with master (v6.2-rc3) as the fork point).

At this point, I get:

   NOTE: No new commits since fork-point "master"
   Created the default cover letter, you can edit with --edit-cover.

It seems to grab the state of master prior to me resetting to v6.2-rc3.

Here's a terminal log of this:


   $ git log --oneline -1
   b7bfaa761d76 (HEAD -> master, tag: v6.2-rc3) Linux 6.2-rc3
   
   $ git commit --allow-empty -m "new_commit"
   [master 9652673e06ea] new_commit
   
   $ git switch -c new_branch
   Switched to a new branch 'new_branch'
   
   $ git log --oneline -1
   9652673e06ea (HEAD -> new_branch, master) new_commit
   
   $ git switch master
   Switched to branch 'master'
   Your branch and 'linus/master' have diverged,
   and have 1 and 21 different commits each, respectively.
     (use "git pull" to merge the remote branch into yours)
   
   $ git reset --hard v6.2-rc3
   HEAD is now at b7bfaa761d76 Linux 6.2-rc3
   
   $ git switch new_branch 
   Switched to branch 'new_branch'
   
   $ b4 -d prep -e master
   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\.new_branch\..*
   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 --no-abbrev-commit --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\.new_branch\..*
   Running git --no-pager symbolic-ref -q HEAD
   Running git --no-pager show-ref --heads master
   Finding the fork-point with master
   Running git --no-pager merge-base --fork-point master
   Fork-point between new_branch and master is 9652673e06ea84926e3be7c5cef0285c60fe31ff
   Running git --no-pager rev-list 9652673e06ea84926e3be7c5cef0285c60fe31ff..
   NOTE: No new commits since fork-point "master"
   Running git --no-pager symbolic-ref -q HEAD
   Running git --no-pager config -z --get-regexp branch\.new_branch\..*
   Looking for the cover letter commit with magic marker "--- b4-submit-tracking ---"
   Running git --no-pager log --no-abbrev-commit --grep --- b4-submit-tracking --- -F --pretty=oneline --max-count=1 --since=1.year
   tracking data: {}
   Running git --no-pager config --replace-all branch.new_branch.b4-prep-cover-strategy commit
   Created the default cover letter, you can edit with --edit-cover.
   Running git --no-pager symbolic-ref -q HEAD
   Running git --no-pager config -z --get-regexp branch\.new_branch\..*
   Got strategy=commit from branch-config
   Running git --no-pager commit --allow-empty -F -
   
   $ git log --oneline -3
   c8be0da650a2 (HEAD -> new_branch) EDITME: cover title for new_branch
   9652673e06ea new_commit
   b7bfaa761d76 (tag: v6.2-rc3, master) Linux 6.2-rc3


The problematic step seems to be:

$ git --no-pager merge-base --fork-point master new_branch
9652673e06ea84926e3be7c5cef0285c60fe31ff

It looks like --fork-point uses the reflog, which has an entry for, I
guess, a stale new_commit on master. (Maybe a gc will clean this up?)

Instead, if I did this (drop --fork-point and just do a vanilla merge-
base):

$ git --no-pager merge-base master new_branch
b7bfaa761d760e72a969d116517eaa12e404c262

This is what I'd expect (-rc3).

I'm not sure if switching to this breaks other expectations though?


Thanks,
Vishal