6 ms·
One idiot with rebase destroys history with no trace. I worked with such an idiot in a parallel team. I can't say how many weeks of work randomly got destroyed
by btilly 2y ago
One idiot with rebase destroys history with no trace. I worked with such an idiot in a parallel team. I can't say how many weeks of work randomly got destroyed by said idiot.
I hate rebase on shared code I don't care how clean jt looks. Don't mess with history.
- Feathercrown 2y agoI wouldn't consider rebasing your own local commits on top of a more recent remote master to be messing with history in any meaningful way, and that's the most useful method of rebasing.
- lmm 2y agoRebasing unpushed commits is ok. But I have yet to see a workflow that provides good enough guardrails to make it something you can do safely.
- saagarjha 2y agoProtect your main branch?
- lmm 2y agoOne of the great advantages of git is being able to pull from other people's feature branches, not just master. So protecting just master isn't good enough.
- saagarjha 2y agoYeah so you have them go through the workflow that doesn’t ruin things, like pull requests?
- lmm 2y agoI don't want to have to go back and forth with someone to pull their branch. I want to just be able to pull anything they've pushed.
- NewJazz 2y agoI'll often just do a git reset --hard origin/branch-name
- lmm 2y agoRight but that doesn't help if you've done your own work on top of their changes.
- iainmerrick 2y agoI think rebase is generally the correct approach here. If you've done your own work on top of their old changes, rebase your work on top of their new changes.
- lmm 2y agoThat's possible but it requires a bunch of manual tracking and results in wasted/duplicate effort with people resolving the same conflicts multiple times.
- cnity 2y agoJust use: > git pull --rebase
- from-nibly 2y ago--force-with-lease And only on working branches. I do this every single day.
- lmm 2y agoNot good enough, that can mean you rebase changes that someone else has based further work on (but hasn't pushed it yet, or has pushed it to a different branch).
- from-nibly 2y agoWhy are you having people base their work off your in progress work? Git is not the issue with what you are describing.
- lmm 2y ago> Why are you having people base their work off your in progress work? To collaborate more closely and reduce (or get ahead of) conflicts. The whole point of using git at all is to be able to base your work off other people's in-progress work; if you're not interested in doing that then Subversion works better.
- quectophoton 2y agoI can give an example scenario. Assuming "H" is the hash of the current state of the repository content, consider this initial state of the repository (most recent first): H(3) Implement feature B H(2) Implement feature A H(1) Initial commit Now you implement "shiny feature", so your history in your branch looks like this: H(5) Shiny feature, improvements. H(4) Shiny feature, initial implementation. H(3) Implement feature B H(2) Implement feature A H(1) Initial commit You tested H(4) and H(5), and everything looks good. Then you `git pull --rebase`, and your history looks like this: H(10) Shiny feature, improvements. H(9) Shiny feature, initial implementation. H(8) Pulled commit C H(7) Pulled commit B H(6) Pulled commit A H(3) Implement feature B H(2) Implement feature A H(1) Initial commit You test H(10) because it's the current state of your repo, looks good, and merge (or create PR, whatever). With the usual pull request flows, `H(9)` (i.e. anything between your new "base" and your most recent commit) usually stays untested, entirely ignored by the developers, and you would only ever find out if you ever need to bisect. Not usually a problem, unless you have a rule of "every commit should be verified/tested" and the untested commits have a change that doesn't prevent a build but still causes issues (e.g. something that's only visual, or a new config file was added to a "conf.d" directory and its presence changed some behavior, stuff like that).
- citrin_ru 2y agoTo avoid this you can squash H(9) and H(10) before pushing to a shared branch, this way only one tested commit will be added on top of existing commits.
- doix 2y agoI really don't understand how you can lose weeks of work. The person that would have done the force push would have the original commit in their reflog. ORIG_HEAD would be set. Everyone else that had a copy of the repo would have had a copy of the "lost" commits. I really cannot imagine how many things would have to go wrong for weeks of work to be lost.
- chaorace 2y agoThere is a hierarchy to these things: - Person who destroys git history - Person who hates destroying git history - Person who knows how to recover "destroyed" history - Person who knows how to truly destroy git history
- pcl 2y ago> - Person who knows how to truly destroy git history … tell me more!
- doix 2y agoI cannot imagine how one could _truly_ destroy git history. You could destroy it locally, sure no problem. You _might_ be able to destroy it on your remote, but if you're using something like Github/Gitlab/Bitbucket I'm sure they'll have a cache that isn't trivial to remove from. But even if you remove it locally and from remote, there's no way you're removing it from other peoples clones. And other people could have pushed to other remotes. Stuff "leaks" so much in git, that it's really hard to lose work. The only way I could see someone losing work is if they never commit or if they never push. But even if you don't push and just rebase, you're not losing work. You would have to go out of your way to delete git history locally.
- dale_glass 2y agoA rebase can be undone, because the old commits keep hanging around in the repo. Rebase doesn't delete or rewrite anything, it just creates new commits and adjusts branch pointers, so the old stuff is still there just hard to get at because nothing points at it anymore. You just need to find an old commit ID somewhere, normally the reflog. The old stuff will go away on its own eventually due to git's self-maintenance procedures removing unreachable commits, or it can be done forcefully by adjusting the gc parameters to get rid of it.
- arghwhat 2y agoOne never rebases shared code. They rebase their own work branch. Messing with history of master/main/integration branches should be blocked. Rebase is a necessary part of a workflow even if you like merge commits. You're severely missing out if interactive rebases are not part of your toolbox.
- ansible 2y agoDidn't you guys have filesystem backups of a shared git repository? This is exactly what backups are for.
- globular-toast 2y agoRebase cannot destroy "weeks of work". No git command can delete commits. Unless you have some insane garbage collection policy that is very far from any defaults. This is your fault for not understanding your tools.