8 ms·
Fast rebases with git-move
- umvi 5y agoRebase is already lightning fast for me... Even on projects with thousands of commits! How big does your repo have to get before rebases are sluggish?
- mb7733 5y agoI 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).
- jeppesen-io 5y agoyeah, 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
- OJFord 5y agoYes, it's equivalent to checkout and cherry-pick. (And to be exact, then possibly branch -f and checkout, depending what was rebased.)
- MarkSweep 5y agoIt’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.
- cerved 5y agoa rebase checkouts out every file on every commit it's rebasing, it's quite slow
- secondcoming 5y agoThe great thing about git is that it has eleventy ways of doing the same thing.
- faizshah 5y agoIm 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?
- tazjin 5y agoDrop 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.
- Osiris 5y agoA solo developer may be able to make this call but in any size organization, good luck with that.
- searealist 5y agoEven 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.
- tazjin 5y agoIn Gerrit, the review unit is commonly one commit. IMO the Github pattern of bundling several changes in one review is a mistake.
- u801e 5y agoEven 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.
- 5y ago
- geuis 5y agoI’m not sure who this is for. 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”.
- arxanas 5y agoYou 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.
- Flocular 5y agoIf 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.
- PaulDavisThe1st 5y agogit-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.
- arxanas 5y agoUpstream 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."
- Waterluvian 5y agoAll 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.
- marton78 5y agoThe rebase feature of https://git-fork.com/ https://git-fork.com/ is actually pretty nice. Interactive rebase works well, the only shortcoming is its lack of support for `git rebase -r`.
- Cthulhu_ 5y agoI 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.
- cerved 5y agogit rebase --abort
- dataflow 5y agoAll you want is TortoiseGit. :-)
- epage 5y agogit-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. [0] https://github.com/epage/git-stack https://github.com/epage/git-stack
- arxanas 5y agoI 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 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.)
- arxanas 5y agoAuthor 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 https://github.com/arxanas/git-branchless
- chmaynard 5y agoDid you submit your work to the git project maintainers? If so, what was their response?
- arxanas 5y agoNo. See also my comment here https://news.ycombinator.com/item?id=28900781 https://news.ycombinator.com/item?id=28900781. The work isn't directly compatible, and the equivalent upstream work is already underway.
- dgfitz 5y agoI’m still an advocate of hg. I wish they had won the dvcs wars.
- searealist 5y agoWhy?
- dgfitz 5y agoBecause of the comments in this thread mentioning: I don’t understand this, I don’t know how this works. Hg doesn’t have voodoo behind it.
- Aeolun 5y agoWhat 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). There must be a better way.
- eru 5y agoWell, here's a technique you can sometimes use: 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.
- Aeolun 5y agoThis 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.
- eru 5y agoI 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.
- xenomachina 5y agoThe 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.
- arxanas 5y agoYep, that's precisely the scenario which git-move is intended to improve on. I also recommend that you try out a solution like git-stack to manage stacked PRs: https://github.com/epage/git-stack https://github.com/epage/git-stack
- xenomachina 5y agoThanks, I'll have to take a look!