What I need is some way to deal with my 6 month old release branches that are completely incompatible with the current develop branch.
When I make a fix on the 6 month old branch, I have to manually cherry pick it to the current release and develop branch, and by cherry picking I lose all association between those three commits now ostensibly containing the same changes (though not really, because conflict resolution makes all of them different).
The `-x` argument to cherry-pick helps a little bit with traceability. It adds a line to the commit message that refers back to the original commit by its SHA.
If you decide that the way things were done way back when on the release branch isn't quite how you want to proceed in the future, you just amend the message to reflect the additional changes. The SHA is still there to reach back and see how things were done in the first place.
Start a feature branch off from the last common ancestor between your branches of interest. Make your commit against that. Then merge that feature branch into the old release branch, current release branch and feature branch.
You might still have to do lots of conflict resolution, but at least this way you can preserve the associations in a form legible to git.
This works a bit better, if you can regularly merge your release branches back into your development branch, since then the last common ancestor will be exactly the release branch.
This sounded great, but then I realized that we have a PR based workflow. My issue with that was that I cannot resolve conflicts for all three target branches on the single branch.
It works fine locally, when you just run merge and fix conflicts in one action.
But I need to push my branches to bitbucket/github to go through a review process, so you can’t stay with one branch.
I guess I could run the merge, and resolve the conflicts locally, then push a separate branch to make a PR with for each target with the original+merge commit inside.
I actually use this technique on a PR based workflow.
In BitBucket, you can make multiple PRs from the same branch.
> I guess I could run the merge, and resolve the conflicts locally, then push a separate branch to make a PR with for each target with the original+merge commit inside.
Yes, that's basically what I do. Though most of the time, I don't need to bother with the merge commit, because I only do this dance to get something into both master and release, but they haven't diverged too far, yet.
All I want are some more guardrails and maybe visualization when I’m doing rebase stuff.
My biggest burn is when I am rebasing and addressing conflicts and I do the wrong thing like a pull or a commit or something and then it’s just completely unclear to me what I’ve broken and why my conflicts are getting far worse every stage of the rebase.
The rebase feature of https://git-fork.com/ is actually pretty nice. Interactive rebase works well, the only shortcoming is its lack of support for `git rebase -r`.
I like the norwegian black metal asthetic of their website header, :p. But it looks like pretty much every other git client, can't see any unique selling points other than the one you mentioned.
Have you seen the rest of the https://github.com/arxanas/git-branchless project? It includes commit graph visualization and an undo feature, which works with rebases.
I used tortiseSVN pretty extensively but only used tortiseGit for a bit before adopting GitExtensions - I dislike the habit of interacting through context menus primarily and prefer the full separate application.
It’s not the number of commits, it’s the number of files changing that can slow you done. If you are in a monorepo where tens or hundreds of thousands of files are changing everyday, checking out the old branch before rebasing can take a while.
That said, this is only a problem at my work. Even the largest of open source repos I have worked on have been mostly fine with Git’s slow rebase implementation.
I don't even think that rebase would get slower as the repo grows. It would only depend on how many commits are being rebased (and the contents of those commits).
yeah, I was thinking the same thing. I've never benchmarked it, but I assume rebase speed is a result of the delta of commits between your branch and the branch you're rebasing against, not the absolute size of commits for a repo
More interested in hearing more about the use case for this tool. AFAIK Git was created for use with Linux, which is a large codes base with lots of churn. One would asume rebase would work with a large codebase like that
I heartily approve of rebase-first development methodology.
But rebasing is not something that has ever been slow for me. Even in huge monolithic repos with frequent changes, it takes at most a couple seconds to reconcile my work branch against master.
Maybe this will help some team with specific needs, but I highly advise against just adopting it because “heard rebasing was slow”.
You can see in the demo performance on `gecko-dev`, which is a Git mirror of a Mozilla repo. You probably need to have 500k+ commits/100k+ files before it starts being useful. My work has a large Git monorepo, which is why I made this tool, and it's very useful for me.
Author here, happy to answer any questions. I also recommend you check out the rest of the `git-branchless` suite, which contains other helpful tools, such as commit graph visualization and a commit graph undo feature: https://github.com/arxanas/git-branchless
git-move and git-branchless do some great stuff, I wish this wasn't focused on the performance side to distract from the real value.
What I find useful is not the performance but this line
> For example, it can move entire subtrees, not just branches
The referenced docs mention other great quality of life improvements that streamline standard workflows (e.g. deleting local PR branches when merged into upstream)
When performance does matter is when the rebase operation is a small part of a larger operation. In my related tool, git-stack [0], I rebase all branches on top of their latest upstream branches along with re-arranging and squashing fixup commits and soon other features. When automating entire workflows, having each part be fast is important for the whole to still have decent performance.
I found it very hard to motivate a lot of the other features. Many people don't use and don't see the value of tree-based development. See this feedback from a user: https://github.com/arxanas/git-branchless/issues/6
So I decided to focus primarily on features which everyone understands, such as performance. (Of course, many people then say "why do we need this? git rebase is already plenty fast", but they get the principle.)
If this is a faster and drop-in replacement, why doesnt the git project just use this? Sentences like "This isn’t strictly necessary for many rebases, and can be quite slow on sizable repos." kind of scare me.
Upstream Git is working on the underlying machinery to make this possible (merge-ort, sparse indexes), but they have a lot more workflows to accommodate and code to update. The fact that I don't have to worry about preserving all the existing workflows means that I can just say "I have decided to represent indexes differently in-memory, and it took me 1 day to do so."
git-move itself has no conflict resolution mechanism, and falls back to git-rebase if there are merge conflicts. So the git project cannot "just use this" as-is.
Im looking for a workflow to replace having multiple dependent branches (unmerged code reviews) and rebasing each of them when you have to revise one of the branches for Code review comments. Any suggestions?
Drop Github, use something like Gerrit and then embrace linear history. If you have very active development with frequent conflicts (requiring lots of rebasing to get things merged) you might want to look at a merge bot like gerrit-queue, but don't do it before it becomes a problem.
Even if you have linear history on main (squash commits from PRs). You still have this problem if you have multiple out-standing PRs and one of them is dependent on another.
Even the email based flow presents a series of changes as a thread of email messages, so the association between changes that are related or depend on each other is maintained.
Once a patch set looks good to the maintainer, it's merged. Email clients do enforce looking at the changes as a series of diffs on a per commit basis.
The tool is not your problem, your task prioritization is. if you have dependent branches, you have specific order you have to merge them or split the shared code into a separate branch that gets done before the 'branchoff'.
I disagree here. The tooling is a big problem. If you revise one of the earlier commits, it's pretty hard to coax Git into rebasing the dependent commits and branches properly.
I'm not entirely sure what your problem is but you could try deferring the rebase using !fixup and !squash commits. I prefer this workflow during code reviews because then reviewers can see exactly what's changing.
The speed of rebase has never been a problem for me, but this feature is very intriguing to me:
> It moves branches on any intermediate commits. git rebase only moves the branch pointing to the commit which was checked out at the time of the rebase.
Many times I've had a chain of branches that I want to send out as PRs in sequence (smaller PRs are easier to review), but rebasing can result in some of this branches pointing at the wrong (pre-rebase) commits.
If HG truly shines I don’t know why people would choose Git over it. Even if Github was famous, its not like iOS came first so Android never picked up?
The million factors which you mention might be the reasons you don’t know why people chose git over Hg.
If anything you have come up with a vague claim mentioning HG is better on a git thread, without any explanation or feature comparison.
> If anything you have come up with a vague claim mentioning HG is better on a git thread
No, I didn't. Can you please point out to us where I did that?
> If HG truly shines I don’t know why people would choose Git over it
Git had a head start because Torvalds invented it and it became the SCM of Linux kernel,
then other free software developers on linux ecosystem followed that (GNOME etc.).
Github became hip and took of among open source developers few years after that. Rest is network effect.
> yet bitbucket based on Hg didn’t take off
Because bitbucket UI was more clunky and corparate-y looking compared to Github. Is it really surprising Github was more popular among Silicon Valley crowd? That's totally unrelated to it using hg instead of git.
My apologies, I have mixed up your comment with parent comment. But since you joined the conversation.
Like I said, if Hg really shines in what it does, there is no reason why it would’ve not become a viable alternative.
Git has its pros and cons like Hg but it managed to outshine whatever benefits hg offered.
Yes bitbucket and Github are related because, bitbucket was one of the main companies to offer it, which sucked, in turn dropped Hg adoption.
How many people do you think work on Linux kernel, for it to drive git adoption?
There are 10000x more php developers than Linux kernel developers. If Hg was able to entice them, it would’ve been different may be, which it couldn’t.
But I agree with your point git was seen more favourable for open-source due to Github.
We're talking past each other, I don't think we'll reach anywhere.
You say hg sucked thus bitbucket dropped it. I say bitbucket sucked, regardless of hg, thus nobody adopted bitbucket, went with Github instead, indirectly adopting git.
> How many people do you think work on Linux kernel, for it to drive git adoption? There are 10000x more php developers than Linux kernel developers. If Hg was able to entice them, it would’ve been different may be, which it couldn’t.
If hg would be able to entice them, they'd be stuck with using subpar hosts like bitbucket, or hosting repos themselves (and having to figure out different solutions to other features github offered, like bug reports). Which is actually what a lot of large open source projects did in late 2000's/early 2010's, but even those eventually moved to Github because of network effect. (See for example discussions for Python project moving to Github)
> The version control software market has evolved a lot since Bitbucket began in 2008. When we launched, centralized version control was the norm and we only supported Mercurial repos.
But Git adoption has grown over the years to become the default system, helping teams of all sizes work faster as they become more distributed.
As we surpass 10 million registered users on the platform, we're at a point in our growth where we are conducting a deeper evaluation of the market and how we can best support our users going forward.
After much consideration, we've decided to remove Mercurial support from Bitbucket Cloud and its API.
When I make a fix on the 6 month old branch, I have to manually cherry pick it to the current release and develop branch, and by cherry picking I lose all association between those three commits now ostensibly containing the same changes (though not really, because conflict resolution makes all of them different).
There must be a better way.