Maintaining shadow branches for GitHub PRs
13 points by MaskRay
13 points by MaskRay
What (in your opinion) are the drawbacks of merging the main branch back into the PR branch: I ask because you don’t mention it (at least in “the problem”) section
But, why not just use merge instead of rebasing all the time?
I can't speak for OP but I really don't like using merge commits for features, and forbid it on anything I maintain. It breaks bisect as well as just generally making the history hard to follow. Doing merges and then one big rebase at the end can get messy and even if you recorded conflict resolutions during your merges, ime they don't always apply.
On the other hand keeping your feature branches rebased works great with either merge commits or rebase merges. And it is a lot nicer to work with locally if you share my habit of working on multiple things at the same time and then sorting the changes into appropriate branches later. So I always do it, and live with the less-than-great way it shows in forges.
It breaks bisect
No it doesn't. Just run git bisect start with --first-parent.
as well as just generally making the history hard to follow.
Always run git log with either --graph or --first-parent. If your GUI doesn't support them, get one that actually cares to understand the data model they're built against.
Doing merges and then one big rebase at the end can get messy
Yes, running the break-my-history command will break your history. I'd argue that its name should reflect that property, but I don't make that decision.
Well, no, the problem I have with bisect and merges is fundamental to the concept of a merge: you can get a correct answer out of it, but the correct answer is less useful when it blames the merge, rather than a specific one of the commits that were merged.
git log --graph becomes unreadable pretty fast to me, even for relatively slow development with short-lived branches. The information is displayed, but it is just inherently more complicated information than a linear history. At work there are often dozens of active branches at any given moment and the graph is just impenetrable noise.
As a practical point, for the author, because LLVM policy does not allow for merge commits.
I like to tell a story in a complex PR. By doing that, you can review commit by commit instead of everything at once.
When I work locally, I amend commits and break them up if necessary before pushing for the first time. When I have pushed the branch for the first time, I usually address feedback in a separate commit at the end, but it would have been more smooth to amend the original commit.
When the commits are detailed and split up like that, it's very nice to git blame years afterwards. I'm my own favourite author when doing blames because the commit messages are (imho) very good :)
You can (and should!) still do that and merge your branch in with a merge commit instead of a fast-forward though. It's up to an individual development group whether they want to do a traditional merge or a rebase/fast-forward (or even a squash merge, if they really want to invalidate all that hard work making commits atomic).
In my head, rebase is a tool intended to move commits from one place to another. All the --interactive amending stuff is just something that sort of ended up in the code that had to rewrite commits anyway (no idea if this is actually how the development actually shook out).
Am I missing something? Isn't force pushing not recommended to begin with?
I work in an environment where it's mostly not permitted to force push and enforced by hooks so the workflow ends up being: you work on your branch, you rebase, it fails, you fight with it a bit, you abort that, you create a new branch, review the reflog and cherry pick, fix as you go, curse everyone and their ancestors and pets, you realize your separate commit upstream was the one that caused your problem, curse git, stomp away and get coffee, fix it, push 😅 Really, I usually do ff-only on my local branches, rebase minimally, and have to do merges upstream so try to avoid having extra ones because that makes a potential rebase difficult. Maybe I'm just fortunate that we don't stomp on each other's branches that often.