So thanks to cdfrey, I'm a little closer on two fronts.
First, the problem as given has a solution for hack #2 but apparently not hack #1. Here's the new sequence of commands:
git checkout base_url git log # Manually find the last commit in staging before I branched git rebase --onto master [COMMIT ID FROM ABOVE] git checkout master git merge base_url
So no more patches, yay! However, you probably notice that
we still have to use git log
to find the
branchpoint. After some discussion of this, it seems that
if we have merged from the feature branch back to the branch
it came from, there's no way around this. git does not
maintain the history of where something came from and where
it goes back to, it holds onto the heads and then follows
the chain of commits back. So once we're merged, there's no
branch point anymore... the trees are the same.
However, we did figure out a potential way to implement our workflow in the future. Instead of branching from staging, the feature branch should start off branching from master. After it's been worked on, it gets merged to staging. But since it started off from master, that should still leave the feature branch with a clear path of changes to apply to master. Once the changes have been tested in staging, we can merge the feature branch into master and it's then "okay" for the branchpoint to disappear since the work is completed.