Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git rebase in depth

git-rebase.io

Post reply on HN
Print view View original

151–160 of 248 posts

Re: Git rebase in depth

#151

Post by theoh »

irrational wrote: post #140
mixmastamyk wrote: post #77

Earlier quoted context omitted.

Yep, it was designed by and for linux kernel development, that average users are using it is an accident of history.

So what are the chances that a version of Git, or something like Git, will be developed that is suitable for the average user? Someone above made a comment about how easy it is to do X in Git, and then preceded to write lines of Git commands that are as arcane as anything an alchemist could come up with. If that is easy Git, I'd hate to see what hard Git looks like.

Git is really a toolkit for version control. Linus (or some other Git proponents?) distinguishes between "plumbing" and "porcelain": the infrastructure and the UI.

Linus wouldn't claim to be a brilliant designer of user interfaces. It's totally conceivable that somebody could come along and develop a new way of talking about Git's functionality, implemented by a new "porcelain". Changing the vocabulary, creating a more comprehensible map of the internal logic of the thing...

Re: Git rebase in depth

#152

Post by shandor »

kohtatsu wrote: post #149
shandor wrote: post #146

Earlier quoted context omitted.

This is also why commiting very often is a very good idea. I often try to reassure people new to git that "if you'll just commit often, there's basically no way you can lose work so that I can't help you get it back. Apart from deleting the whole repo folder. Don't delete the repo folder.". I also have the habit of preventing non-fast-forward pushes on origin/master, which also helps when I can tell my team that they…

Which merge strategy do you recommend? # Merge commit git merge --no-ff -m # Squash and merge git merge --no-commit --squash git commit -m # Rebase and merge git rebase --force-rebase From https://stackoverflow.com/a/52301456

I...have to admit that my merge strategy, and what I teach my teams, is "don't" :) (only slightly tongue-in-cheek)

I believe in clean, linear history, and strongly prefer rebase-based workflows to merges. That's actually one of the reasons I chose Phabricator for my current place, as it is also very opinionated towards the same way of working.

Edit: oh, and to answer your actual question, the third one.

Re: Git rebase in depth

#153

Post by hinkley »

dmitryminkovsky wrote: post #57
gwright wrote: post #32

About 99.9% of the time when people talk about rebase they talk about ‘editing’ history or ‘rewriting’ history as in the first sentence of the article. I find that terminology terribly misleading and when I was learning git and rebase it confused the heck out of me. No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. Git rebase creates a…

> No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. They are still in the repo, but if no treeish item (eg. a branch) points to them, then they'll eventually get garbage collected. Still, glad to see people are trying to elucidate git rebase. A small subset of its functionality is fundamental part of my workflow and I wouldn't know how…

> They are still in the repo, but if no treeish item (eg. a branch) points to them, then they'll eventually get garbage collected.

Why else are you going to go through the trouble of rebasing master if this isn't the goal you're shooting for? I'm a big proponent of commit history hygiene but even I can't defend rebasing master except for egregious things.

I think the only time I rebased master except for this was to fix a poorly executed mass file rename that broke git annotate.

Re: Git rebase in depth

#154

Post by rags2riches »

Chazprime wrote: post #58
gwright wrote: post #32

About 99.9% of the time when people talk about rebase they talk about ‘editing’ history or ‘rewriting’ history as in the first sentence of the article. I find that terminology terribly misleading and when I was learning git and rebase it confused the heck out of me. No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. Git rebase creates a…

This really should be the top comment here. Learning about the non-destructive nature of Git really helped me overcome the unease around using some of Git's more advanced features (especially in a team environment).

Git is non-destructive and its great. Until you learn why the really dangerous command nobody talks about is git checkout.

Re: Git rebase in depth

#155

Post by lisper »

rags2riches wrote: post #154
Chazprime wrote: post #58

Earlier quoted context omitted.

This really should be the top comment here. Learning about the non-destructive nature of Git really helped me overcome the unease around using some of Git's more advanced features (especially in a team environment).

Git is non-destructive and its great. Until you learn why the really dangerous command nobody talks about is git checkout .

Or until you accidentally check in a file that contains a secret. Then the non-destructiveness becomes a serious problem.

Re: Git rebase in depth

#156

Post by greyskull »

shandor wrote: post #152
kohtatsu wrote: post #149

Earlier quoted context omitted.

Which merge strategy do you recommend? # Merge commit git merge --no-ff -m # Squash and merge git merge --no-commit --squash git commit -m # Rebase and merge git rebase --force-rebase From https://stackoverflow.com/a/52301456

I...have to admit that my merge strategy, and what I teach my teams, is "don't" :) (only slightly tongue-in-cheek) I believe in clean, linear history, and strongly prefer rebase-based workflows to merges. That's actually one of the reasons I chose Phabricator for my current place, as it is also very opinionated towards the same way of working. Edit: oh, and to answer your actual question, the third one.

+1. Interactive rebase to squash your feature branch, then ff merge into master/mainline.

Years ago when I was just reading about git instead of using it, I saw sentiments along the lines of "always use feature branches and merge them so your thoughts and process can still be looked at later". In the last ~5 years or so I've worked professionally, I've not once wished I could reference intermediate commits in my own code or someone else's. I've found that ambiguities and clarifications can and are caught during the code review process.

I'd say another couple of benefits:

- It's relatively easy to teach git workflows when the log/graph is linear, and similarly it's _way_ easier to reason about your workspace when you have an actual production codebase.

- Merge commits can make certain operations like reverts and patches harder to reason about

Re: Git rebase in depth

#157

Post by module0000 »

I just recently(last month) broke my habit of `git checkout feature && git merge master`, replacing it with `git checkout feature && git rebase master`. Don't know why I spent so long doing it with merge, and just mentally trying to ignore the useless commit messages that resulted.

EDIT: I meant to include this link, which is a pretty brief yet thorough explanation of when/how/why to rebase: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

Re: Git rebase in depth

#158

Post by cyphar »

u801e wrote: post #141
zemo wrote: post #118

Git rebase is great. Honestly I think the argument that "if you have to push -f that means rebase is wrong" is making a huge assumption about how people use branches and why people are force pushing branches. Force pushing branches is what you do when you have pushed a branch that you expect to modify. Why would you do that? Because that's how Github and Bitbucket have taught people to conduct PR's. If your immediate…

> Force pushing branches is what you do when you have pushed a branch that you expect to modify. Why would you do that? Because that's how Github and Bitbucket have taught people to conduct PR's. I thought that Github and Bitbucket encouraged people to push up additional commits to fix issues in their PR. So, a typical PR will end up with a commit history like: Implement a feature method Add calls to new feature meth…

Almost no projects I've worked on that use GitHub ask people to push fixup commits. In fact, maintainers (like me) often have to ask people to squash their commits into reasonable chunks.

Re: Git rebase in depth

#159

Post by dahart »

AlexTWithBeard wrote: post #150
dahart wrote: post #109

Earlier quoted context omitted.

Rebase is a way to provide what you're calling "change management", and so is git stash. The rest of git is what you're calling "version control". I don't see any conflict. I don't love trying to differentiate those terms either, FWIW. Managing changes and controlling versions are "literally" the same thing. > Then I force push and the mess begins. That is your problem right there. Force pushing over published histor…

That is your problem right there. Force pushing over published history should always be avoided. That is my problem right here. There is no way to tell the difference between "I push to make something public" and "I push to back up my data in some safe location".

Well in either case, I'll just repeat: force push should always be avoided. Regular push without forcing can handle both of those scenarios, publishing commits to your team, and also backing up data to a safe location.

That said, making backup data in a safe location isn't what git was really made for. If you really don't want history to be there, you can use cp or rsync, or you can git clone -depth 0 from the backup machine, or just use backup software. There's "bup" which is a backup tool based on git...

Re: Git rebase in depth

#160

Post by Nullabillity »

gwright wrote: post #32

About 99.9% of the time when people talk about rebase they talk about ‘editing’ history or ‘rewriting’ history as in the first sentence of the article. I find that terminology terribly misleading and when I was learning git and rebase it confused the heck out of me. No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. Git rebase creates a…

It's not 'editing' the raw history files, but you're still presenting a false history to your coworkers. To me there are essentially two kinds of rebases:

- Summarizing history: squashing "implemented subfeature A.A" and "implemented subfeature A.B" into "implemented feature A"

- Rewriting history: moving commits around, changing the base commit, and so on

In my opinion summarizing history is acceptable, you're making a creative decision that certain information will not be useful in the review/when trying to understand the code in the future.

Rewriting, on the other hand, is essentially lying. You're creating repository states that never existed, and which you have never tested. In the worst case, consider the following history:

    *     F: (master) Merge branch 'component2'
    |\  
    | *   E: (component2) Fixed component 2's integration with 1
    | *   D: (component2) Merge branch 'master' into component2
    | |\  
    | |/  
    |/|   
    * |   C: (master) Refactored component 1's API
    | *   B: (component2) Implemented component 2 that depends on 1
    |/  
    *     A: (master) Base
Yes, it could probably be completely linearized, but that would be a horrible idea. Commit B will leave the repository in a completely nonsensical state. Sure, you could squash in E to mitigate it (since, luckily, nothing else happened in component 2 in the meantime), but then you're still stuck explaining what will likely look like a bunch of really weird design decisions compared to if you had designed against component 1's new API immediately.

Historical context matters. If in doubt, don't rebase. Never `git pull --rebase` blindly.

Post reply on HN