0

I am a contributor to some open source projects that take a while to merge PRs. At any given time, I might have 2-10 outstanding PRs. Some bug fixes, some enhancements, etc. While those PRs are in flight, I want to run a local copy of the software that includes all of those branches (call it "my fork"). Sometimes, this means that I'm creating files/databases/etc that are not compatible with the main branch.

Now, when I want to create a new branch I have a problem. If I base it on main then it's ready to PR, but compiling it will take longer (since my existing object files are from the most recent compile of my fork, and my ccache cache is full of variations on those), and the binary produced won't be able to read the files I've been creating with my fork. If I base it on my fork then I have to rebase it on main before I can PR it.

I find myself doing a dance where I'm rebasing back and forth somewhere between once per commit and once per push. This gets tedious, and is somewhat error prone. It's even more complex if some of my branches are based on each other, or if I'm doing any cherry picking between branches.

Are there tools to manage this situation? What I'd like to be able to do is make a code change, commit that change in the new branch, then compile that change as part of my fork, repeat a few times, then push the new branch to create or update a PR, all with as few detours into git branch management as possible.

Simply having two working directories (whether two separate local repos that I push/pull between or one local repo with two working directories) does not solve this problem. I am still left managing rebases and merges manually, which is an error-prone process when done at the frequency necessary for this situation.

Sparr
  • 7,489
  • 31
  • 48
  • It has occurred to me that there could be some value in doing this with two separate local repos, one generally focused on main, one generally focused on my fork, and pull/merge/rebase between them. I would welcome an answer explaining how to solve my problems with that approach. – Sparr Oct 09 '22 at 21:49
  • https://github.com/felipec/git-reintegrate – 1615903 Oct 10 '22 at 09:01
  • The linked-as-dupe question only answers a small part of this question. Even with multiple working directories, I still don't have a smooth path to managing or automating the necessary rebases and merges. – Sparr Oct 24 '22 at 17:51

1 Answers1

0

Not a definitive answer because I don't think that git doesn't offer what you want out of the box but some ideas you could think about...

Maybe you could use the 'git worktree' feature.

The idea is simple : being able to work with different branches of a same repository at the same time (each branch is checked out in a different work directory) . Especially when switching from one to another is costly (i.e. when checkout, restore of packages, build or changing specific configuration takes some time or is painful/boring to do)

It's even more complex if some of my branches are based on each other, or if I'm doing any cherry picking between branches.

For this specific problem, you could have a look at the really new –update-refs feature (provided in the last 2.38 version of Git) that allows you to 'Rebase dependent branches' at the same time you do a rebase. https://github.blog/2022-10-03-highlights-from-git-2-38/#rebase-dependent-branches-with-update-refs

Philippe
  • 28,207
  • 6
  • 54
  • 78