[HN Gopher] Fast rebases with git-move
       ___________________________________________________________________
        
       Fast rebases with git-move
        
       Author : jdorfman
       Score  : 22 points
       Date   : 2021-10-17 20:47 UTC (2 hours ago)
        
 (HTM) web link (blog.waleedkhan.name)
 (TXT) w3m dump (blog.waleedkhan.name)
        
       | umvi wrote:
       | Rebase 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 wrote:
         | I don't even think that rebase would get slower as the repo
         | grows. It would only depend on how many commits are being
         | revised (and the contents of those commits).
        
       | faizshah wrote:
       | 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?
        
         | epage wrote:
         | I'm biased but recommend git-stack [0]. A `git stack --pull`
         | will update all branches and maintain associations.
         | 
         | I also maintain a comparison of related tools [1] that might
         | interest you. Of them I would probably recommend looking at
         | git-branchless [2]
         | 
         | [0] https://github.com/epage/git-stack
         | 
         | [1] https://github.com/epage/git-
         | stack/blob/main/docs/comparison...
         | 
         | [2] https://github.com/arxanas/git-branchless
        
         | the_gipsy wrote:
         | Gerrit?
        
         | tazjin wrote:
         | 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.
        
           | Osiris wrote:
           | A solo developer may be able to make this call but in any
           | size organization, good luck with that.
        
         | globular-toast wrote:
         | 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.
        
       | geuis wrote:
       | I'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".
        
       | secondcoming wrote:
       | The great thing about git is that it has eleventy ways of doing
       | the same thing.
        
       | Flocular wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2021-10-17 23:00 UTC)