Everything. Everything can go wrong! :)
Git rebase, what can go wrong
311–320 of 404 posts
Re: Git rebase, what can go wrong
#312I find it fascinating that people talk about "Having a history of what people did" in such emotive terms - "Cluttering", "Polluting". What matters is that you end up with working systems. That a lot of change happened is just, well, what happened. It doesn't need to be prettied up and made to look like your development occurred in a clockwork march of cleanliness. It literally does not matter unless you spend a lot o…
The point of a clean git history is not to have a clean git history. The point is to make it possible to debug later, via bisect, or show, or even just a diff. The point is to make the workspace clean for the next guy. Instead of letting it go, maybe we should have more discipline and organization in our lives and not less.
100% agree, but nobody gives a shit, and I’ve learned to just let it go. I’ve been in so many meetings, seen so many PSAs, and you know what happens every single time? Nothing. Maybe a couple people learn what interactive rebase is for the first time, try it once, say “it lost all my code” and never try it again. Good luck explaining ref log in these cases.
Re: Git rebase, what can go wrong
#313Earlier quoted context omitted.
How is this possible, while sharing code? Doesn't this require that pushed code is perfect? What about everyone else working on the same code? Do they wait until you've reached perfection? Or, do you squash the branch once it's complete, with the assumption that there's no other development on/from that temporary branch (I envy you if so)? (I ask these questions fully assuming I'm doing it wrong.)
> Doesn't this require that pushed code is perfect? We aren’t talking about pushed code. We are talking about cleaning up the local commit history before pushing it into a shared branch.
And that's the one--and only--reasonable use of rebasing, to squash commits from a branch before merging into main. If engineers find themselves using rebase in any other context than squashing a merge, it's time to re-evaluate the processes/culture around workflow.
Re: Git rebase, what can go wrong
#314Earlier quoted context omitted.
Squash merges cut down the noise considerably.
I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand. Git history should tell a simple, understandable story of each change. For example: 1) refactor existing code, 2) add feature. Or 1) add missing tests, 2) refactor existing code, 3) add feature. But since you're working on the fly with…
It's like if someone said they wanted to invite you over for dinner. Then they started texting you. "at the grocery store". "bought a pound of beef". "bought some carrots". "Checking out now". "Arrived at home". "Turned oven on". "Turned oven to 450 degrees". "Turned oven up to 460 based on different recipe". "Starting to prep the beef now". and so on, and so on. I mean, just cook the damn dinner - I don't need to be needled about all the steps. I'll come over and bring the wine, and we'll eat a meal. I don't need to know every minor implementation detail in a commit log, to review and merge the branch. Arghhhh I have one dev on my team like this right now. I'll have to have a talk with them.
Re: Git rebase, what can go wrong
#315My team of hardware and software engineers is relatively new to Git. I’m trying to get them to commit and push small changes daily to a shared personal branch e.g. james-wip instead of one monster commit every 2 or 3 weeks. I encourage them to rebase their “named” personal branches so they’re easier to review and merge into master when they’re ready.
Re: Git rebase, what can go wrong
#316I like how Atlassian puts it: > The golden rule of rebasing > Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches. https://www.atlassian.com/git/tutorials/merging-vs-rebasing#... For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commit…
I don't mind merge commits, it's the 100 tiny individual commits some developers seem to like to do that really clutters things up. Yes, I know, git squash is a thing, but not committing until the feature is working and ready to commit is also a thing.
> not committing until the feature is working and ready to commit is also a thing
That leaves you prone to losing work if you have a false start that you need to back out of. I prefer to commit early and often on my private branches, then before submitting a pull request I clean up the history to where there are a few good commits that form useful, standalone chunks (ideally the test suite fully passes on each commit).
Re: Git rebase, what can go wrong
#317Earlier quoted context omitted.
how often is "understanding your project history" something that actually comes up for you? In all my years of working with projects in git, I will occasionally look at my history to help me find a change that may have led to a bug, but it really only comes up for me once or twice a year and even then, it is rarely an extensive deep dive and never very far back in time.
> how often is "understanding your project history" something that actually comes up for you? Frequently, for any long and complex project. Large amounts were written by people no longer working on it, and the history of how things came to be can help fill in documentation gaps and make intent clear. By "frequently" I mean something like "I check history for about 2/3rds of bug fixes, and 1/4 of adding features" to u…
I'm on a long and complex project. However most of previous folks were not very good and one reason I'm here to fix it. Their history is not particularly useful except to giggle at.
Re: Git rebase, what can go wrong
#318Earlier quoted context omitted.
> What matters is that you end up with working systems. That a lot of change happened is just, well, what happened. It doesn't need to be prettied up and made to look like your development occurred in a clockwork march of cleanliness. It literally does not matter unless you spend a lot of time doing git-bisect. And git blame. And git checkout to a past state. It "doesn't matter" only if ease of understanding your pro…
how often is "understanding your project history" something that actually comes up for you? In all my years of working with projects in git, I will occasionally look at my history to help me find a change that may have led to a bug, but it really only comes up for me once or twice a year and even then, it is rarely an extensive deep dive and never very far back in time.
It comes up often enough. I run "git blames" frequently to figure why something odd looking was introduced. It may not be a bug, but a WTF. This is in an environment with few code reviews, despite my attempts to introduce them. It is frustrating.
Re: Git rebase, what can go wrong
#319Earlier quoted context omitted.
"Clean history" is not a principal reason for VCS. "Full history so you don't accidentally lose something and can revert to any point" is the principal reason. When "clean history" conflicts with "full history", the choice should always defer to the latter. Rebase clearly breaks the full history principle.
There is obviously a point where you do not want full history. For example, it would absurd to use your editor's undo history tree with keystroke level granularity as your VCS, because in most of those points in history, the code won't even compile because you were in the middle of typing a word. If your goal is to be able to revert the codebase to a previous version, then you want your history to a series of well pr…
Clearly that's the reason you make a commit to begin with. Erasing that commit history is just silly.
Re: Git rebase, what can go wrong
#320Earlier quoted context omitted.
> the mess is the actual history. The true history is not recorded in your normal commits either. Every time you modify your source buffer, that is the true sequence of events. This truth is lost already as you undo/rework things before you commit. You're ALWAYS manipulating and telling a false story of history whether you realize it or not. Commits are a tool that give stronger backup/undo protections over simple fi…
I believe that you are confusing "full history" and "true history". Every single point in the commit history represents an actual state of a repository at a specific point of time, along with the information of which point or points were next before it. This is all part of the true history. This is not a full history - you don't have every keystroke, abandoned commit, switch between branches and so on. But nothing th…
Git was never intended to capture and preserve the order of git commit commands, and you’re making incorrect assumptions that it was a goal. Maybe the git devs knew there is no useful information and no benefit to being so strict about something so arbitrary, or maybe because forcing people to keep their commits in stone in whatever the first arbitrary way they were added is a big disincentive to making commits at random points in time, which somewhat undermines the point of having a version control system at all.
BTW rebase produces a new commit ordering, but does not modify the old one.
> You’re claiming that there were specific points of time with specific states that never actually existed.
No. You are asserting intent on the part of git users and git that has never existed, you have misunderstood what git history is. The git history is not a claim that the state at that point existed during development, you are projecting your own goals that are not shared by git or git users.
> You're losing information about points of time and specific states that actually existed, which someone once considered important enough to do a git commit over.
Hehe this is so full of assumption. You write it like I’m rebasing someone else’s work, but you already know I’m only rebasing my own commits, and I’m the one who decides what’s important enough to do a commit over.
I like commit early, commit often. I want to make small incremental commits that don’t display to others that way and I expect to put small commits and fix ups together later into a single useful commit with only one commit message.