"stg branch -l" updates branch metadata incorrectly

[chucklever]

This is a repository that has already been initialized with stgit (older than v1.1). The other branches that git can find here were created with "stg branch --create".

[cel@morisot linux]$ stg version
Stacked Git 1.3
git version 2.33.0
Python version 3.9.6 (default, Jul 16 2021, 00:00:00) 
[GCC 10.3.1 20210422 (Red Hat 10.3.1-1)]
[cel@morisot linux]$ stg branch -l
Available branches:
Upgraded branch fix-write-chunk-padding to format version 5
  s 	fix-write-chunk-padding           | 
stg branch: fix-write-chunk-padding.stgit: no such branch
[cel@morisot linux]$ git branch -l
  fix-write-chunk-padding
* for-next
  for-next.stgit
  master
  master.stgit
  topic-rdma-fault-injection
  topic-rdma-fault-injection.stgit
  topic-rpcrdma-version-two
  topic-rpcrdma-version-two.stgit
[cel@morisot linux]$ stg branch -l
Available branches:
  s 	fix-write-chunk-padding           | 
> s 	for-next                          | 
    	for-next.stgit                    | 
Upgraded branch master to format version 5
  s 	master                            | tracks master in torvalds/linux.git
stg branch: master.stgit: no such branch
[cel@morisot linux]$ stg branch -l
Available branches:
  s 	fix-write-chunk-padding           | 
> s 	for-next                          | 
    	for-next.stgit                    | 
  s 	master                            | tracks master in torvalds/linux.git
Upgraded branch topic-rdma-fault-injection to format version 5
  s 	topic-rdma-fault-injection        | 
stg branch: topic-rdma-fault-injection.stgit: no such branch
[cel@morisot linux]$

[jpgrayson]

Thank you, as always, @chucklever for taking the time to write up this issue.

I am able to reproduce the issue. The nature of the problem is that each invocation of stg branch --list causes one StGit-enabled branch to have its stack format upgraded before exiting with the "no such branch" error.

Workaround: run stg branch --list one time for each StGit enabled branch. This will cause all branches to be updated at which point the "no such branch" error and "Upgraded branch ..." messages will go away.

I will work-up a repair for this problem, but because there is a workaround and because the workaround only needs to be applied once, I'm not going to immediately cut a new release with this repair.

[chucklever]

Thank you, as always, @chucklever for taking the time to write up this issue.

I am able to reproduce the issue. The nature of the problem is that each invocation of stg branch --list causes one StGit-enabled branch to have its stack format upgraded before exiting with the "no such branch" error.

Workaround: run stg branch --list one time for each StGit enabled branch. This will cause all branches to be updated at which point the "no such branch" error and "Upgraded branch ..." messages will go away.

Confirmed that this works for all branches except the current one, which leaves "branchname.stgit". Even changing to a different branch and running stg branch --list does not remove it. I destroyed that remainder with "git branch -D branchname.stgit".

I will work-up a repair for this problem, but because there is a workaround and because the workaround only needs to be applied once, I'm not going to immediately cut a new release with this repair.

Agreed, this is not a catastrophic issue.

[chucklever]

Further notes to report. Immediately after the update to branch version format 5:

[cel@klimt linux]$ stg se
+ optimize-drc-pruning
+ split-svcrdma-wc-receive
+ split-svcrdma-wc-send
+ split-svcrdma-wc-read-write
+ svc-alloc-arg-tracepoint
+ trace-page-offset
+ fix-xdr-stream-subsegment
+ legacy-write-encoders-use
+ remove-svc-generic-dispatch
+ de-dup-pc-release
+ pc-decode-synopsis-one
+ pc-decode-synopsis-two
+ save-location-of-nfsv4
+ pc-encode-synopsis-one
> pc-encode-synopsis-two
[cel@klimt linux]$ stg pop
Error: HEAD and top are not the same.
       This can happen if you modify a branch with git.
       "stg repair --help" explains more about what to do next.
stg pop: Command aborted (all changes rolled back)
[cel@klimt linux]$ stg repair
Checking patch appliedness ... 
  optimize-drc-pruning is now unapplied
  split-svcrdma-wc-receive is now unapplied
  split-svcrdma-wc-send is now unapplied
  split-svcrdma-wc-read-write is now unapplied
  svc-alloc-arg-tracepoint is now unapplied
  trace-page-offset is now unapplied
  fix-xdr-stream-subsegment is now unapplied
  legacy-write-encoders-use is now unapplied
  remove-svc-generic-dispatch is now unapplied
  de-dup-pc-release is now unapplied
  pc-decode-synopsis-one is now unapplied
  pc-decode-synopsis-two is now unapplied
  save-location-of-nfsv4 is now unapplied
  pc-encode-synopsis-one is now unapplied
  pc-encode-synopsis-two is now unapplied
done
No patch applied
[cel@klimt linux]$

The content of the entire series has spilled into the working directory, but the individual patches aren't empty. I can recover with stg reset --hard; stg push -a

[jpgrayson]

@chucklever thank you for these additional details.

[jpgrayson]

I think this one is sufficiently resolved.