3 ms·
> A complete and utter waste of time. You spend more time messing about with rebase than solving problems. Unless you're using a garbage client (eg, the git CL
by gregmac 5y ago
> A complete and utter waste of time. You spend more time messing about with rebase than solving problems.
Unless you're using a garbage client (eg, the git CLI) a rebase to get rid of the "typo" "oops" type commits (when you forgot something) takes I'd say 10-20 seconds.
Most commonly I do this when I have several changes on the go at once and forget to commit a fixed unit test, new import, or something like that. I usually realize it right away, so my commit will usually be "add test" or "amend 2 commits ago" or something to remind myself which one it goes to (and it sticks out, because my other commits are usually in the format "PROJ-1234: Add new --host command-line option").
> When you're digging through VCS history due to a bug you often ignore the commit message anyway - if the code did what it seemed to do you wouldn't be there.
I presume this is doing a bisect or something to narrow down where a bug was introduced?
My experience comes from the opposite side. Usually I identify the line of code causing a bug, it makes me go "wtf, what is this even supposed to be doing?" so I do a git blame. Hopefully the commit message is useful and ideally leads me back to the original bug/ticket, so I can figure out what the original intent/fix was, rather than inadvertently breaking something (or re-causing a different bug it fixed). I'll also note that in code that is well-commented and well-tested, this step is rarely necessary.
As an example, say I come across something like this:
if (port > 443) ignoreErrors = true;
Clearly, this was added to solve some some problem, but even without any context it's pretty obviously a bad solution to whatever that problem is. Git blame lets me go back to see what the original reason/bug was, evaluate if it's still relevant and then either fix it properly or safely remove this line.
- FalconSensei 5y ago> My experience comes from the opposite side. Usually I identify the line of code causing a bug, it makes me go "wtf, what is this even supposed to be doing?" so I do a git blame. If the commit message is something like: PROJECT-TICKETNUMBER Description, you can you know... see the ticket/issue along with full details and discussions?
- sethherr 5y ago> I'll also note that in code that is well-commented and well-tested, this step is rarely necessary. This is the most important line from this comment. If I'm using blame or bisect, it means I did something wrong. I merge 10 times a day - and if it takes me a minute, because I'm slower than you - that means it's ten minutes a day. Add the cognitive load of the whole process and the added time of explaining it to other team members - 10 minutes is an underestimate. I'm going to spend that time writing tests and comments, since even you note that they're the better option. Squash is good enough. I spend my energy improving the right things.
- codesnik 5y agogit CLI isn't so bad for that, why? I do --fixup commits all the time, git commit -i gives me all the power to reorder, merge and even split commits.
- tharkun__ 5y agoWhoa whoa, hold your horses. I have used nothing _but_ the git CLI for all my commits, rebases and squashes for the better part of 10 years now. I do agree with you though that rebasing and squashing are absolutely easy and awesome and whoever doesn't agree probably comes at it from a badly run repository with utterly bad practices and it would probably _benefit_ from a proper squashing and rebasing practice.
- hashhar 5y agoHave people not seen autosquash when rebasing? And the --fixup and --squash options to commit? Check those out. It makes the rebase automated with correct commits getting fixed up or squashed as you desire.