With only push, pull and branch, how do you refer to an old version? Hence commits, or something like it, are needed.
And do you seriously not see the need of rebasing?
Furthermore, you seem to mistake git's distributed nature for some sort of backup scheme. That's not the case. The idea that every repo is equal is tremendously useful.
> And do you seriously not see the need of rebasing?
Git user for a decade. I never rebase, not professionally and not in my personal projects. I merge the work of other devs, no matter how ugly their history.
I don't see any real problem that rebase solves, but I do see that it mangles history and makes troubleshooting e.g. git bisect much more difficult.
Rebasing other’s stuff feels gross since it is altering externally visible history. Rebasing your own stuff before you push can make commits more clear, understandable, and meaningful. git pull —rebase is pretty unobjectionable.
Presumably they are referring to how the `--first-parent` flag works as it only uses the head of the branch from a given merge instead of including each commit from the merge.
Some projects prefer rebasing onto master instead of merging onto master or squashing onto master.
If you rebase onto master but don't clean up the commits at the end of the PR, this litters master with a bunch of "top level" commits that don't build and cause git-bisect's test to fail due to those commits not working in the first place.
If you rebase onto master but you do clean up your commits such that each commit onto master represents a fully functional version of the project, this isn't a problem however it can make a bisect take way longer than if just merge commits are tested.
If you are rebasing to this degree, I don't really understand the purpose of the rebase for a feature or issue branch (as to this degree, the last commit is the only "completed" commit of this type of branch and you are effectively squashing). It makes sense for say a release branch so you can integrate hotfixes/patches but that workflow can be just as if not more effectively handled via a merge or a squash as well.
> it can make a bisect take way longer than if just merge commits are tested.
The whole beauty of bisect is that is a binary search where if you double the number of commits you only need to do ~1 additional check. So no, it can't take "way" longer.
And it's not like you'd call it a day after finding the merge commit that breaks things - you then need to find the actual problem with that branch and the fastest way to do that is bisecting down to the individual commit so you are actually doing the same work but artificially restricting git bisect from evenly dividing the search space by restricting it to merge commits first.
That or you are stuck with somebody fighting CI or issues that aren't reproducible in their environment. It's not necessarily a junior dev issue and can just be "our tooling sucks and management refuses to invest time or money into fixing it". It's not an ideal or sustainable work environment but it's something that even senior devs still have to deal with.
Of course that should still be rebased down to a reasonable history.
If that's the case, I would have the dev go rebase that into a nice single commit. Not the guy doing the integration work. I expect that the dev's last operation was to merge from the dev branch, fix conflicts, then push a PR.
At the least, if you're dev refuses to give you a nice commit, you could merge-squash his branch.
On some projects I maintain a set of local fixes that I regularly rebase on top of the latest code. I don't need to run a bisect on those.
I've also managed other projects/branches like you have, merging the changes into my work.
I also use the cherry picking feature (which rebase builds on) a lot. That is for things like creating hot fixes, pulling in some upstream patches to my local fixes, reordering a branch, etc.
> And do you seriously not see the need of rebasing?
Rebasing isn't actually necessary, and there's a good argument to be made that you should never rebase. Fossil (the version control system used by the sqlite team) doesn't have any rebasing mechanism: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...
(there are of course also very good arguments in favour of rebasing, but my point is simply that it isn't strictly necessary in a "complete" version control system)
Of course it isn't necessary. It's just extremely useful. Of course it rewrites history, and I abhor rewriting shared history, but it's extremely useful to be able to rewrite your own private history!
Well....but you literally said above that there's a need for it. In a somewhat condescending tone. And now it's suddenly obvious that it's not necessary? Okay.
It's possible to have a need for something even though that thing is not necessary.
"Oh man, I really need a nice dinner right now" is impossible for you unless that dinner consists of the absolutely strictly minimum necessaries of nutrients in a gray tasteless slurry? Come on.
And do you seriously not see the need of rebasing?
Furthermore, you seem to mistake git's distributed nature for some sort of backup scheme. That's not the case. The idea that every repo is equal is tremendously useful.