When using `git bisect` to find a bug, `git bisect good` and `git bisect bad` are not the only options available, there's also `git bisect skip`. You should only mark as bad commits that specifically manifest the bug you're looking for and not, say, build errors or other unrelated bugs. It is true however that the type of build breakage potentially brought in by using git rebase will require you to do more bisect steps.
Don't use Git rebase
41–50 of 88 posts
Re: Don't use Git rebase
#42When using `git bisect` to find a bug, `git bisect good` and `git bisect bad` are not the only options available, there's also `git bisect skip`. You should only mark as bad commits that specifically manifest the bug you're looking for and not, say, build errors or other unrelated bugs. It is true however that the type of build breakage potentially brought in by using git rebase will require you to do more bisect ste…
> It is true however that the type of build breakage potentially brought in by using git rebase will require you to do more bisect steps.
Or leave you with an inconclusive result if the guilty commit also happens to be one of the skipped commits
Re: Don't use Git rebase
#43`git rebase --exec {rebuild project}` solves the issue of invisible errors in commits. I'm a big fan of Gerrit's review workflow, which requires every commit to build in isolation. I also usually try to squash my changes into logical independent commits before review. I like rebase because it's prettier, but I also think there's an issue with the non-rebase case that the OP has missed: unless you rebase, you're setti…
Yes, yes and yes. We had this issue on the Neovim project a while ago [1]. This caused us to switch workflows [2] (although I would have preferred the --exec approach that you mentioned).
Also see comment [3] by TheCorey mentioning you can use `git bisect --skip`. However, in the mentioned case with Neovim, very few commits actually built, making the process non-deterministic somehow (it kept going in cycles).
[1]: https://github.com/neovim/neovim/issues/6431
Re: Don't use Git rebase
#44There's a more nuanced approach to git rebase. You should use it the other way around - switch to your feature branch and `git rebase master` to update your branch and resolve conflicts. Then test it and `git merge`. I also use git rebase to tidy up the branch's history - generally not entirely squashing it, though.
Or well, simply use both. Feature branch, use merge - the feature is an important artefact, and there it is important for the history to show it.
Bug Fix branch, working on a shared branch, use rebase. The branching in those case is a side effect the exact time two colleague committed on the same branch. There is no information you gather from that, it is just a technical blip in the history.
Not quite sure the obsession people have in using only 50% of the tool they have because the other 50% could be misused.
Similarly, digging for a bug in several hundred commits is going to be shit. Hindsight is very deceptive with bug hunting - they always hide in plain sight, if you know where it is, it is easy to imagine "oh, I would have seen it immediately with a merge". Maybe, probably not.
You see that of that kind of overreaction in Management. There is a bug in production, we must introduce more testing, or more testing phase, or change the way we design the around that single experience. But sometimes, bugs just happen.
Re: Don't use Git rebase
#45This seems like a knee jerk reaction because a co-worker's sloppy rebase caused you to waste a day. This highlights a bigger issue, many people don't learn their tools well enough. I've been teaching my fellow senior engineers how to use git the last six months because they've only been using git GUIs until then. They're terrified of merge conflicts and they often make mistakes fixing them. I'd rather educate people…
My thoughts precisely. I mostly use rebase, except when I know multiple commits in my feature branch will cause merge conflict with master - in that case, I save myself the trouble, do a merge and be done with resolving all conflicts in one go.
My ideology is - prefer rebase first, resort to merge if it will let you do the gnarly merge fast. Of course this is because of the development environment I work in where we just don't use bisect and the workflow is different. I also keep in mind that if I work on a different repository with differing testing/development processes this ideology will change.
The first few days I work on any new project(due to a job/project transition), I figure out how I can iterate as fast as I can and see what my time saving points are. How to best use the git I know, on the current repo, is also a minor part of this poking process.
Re: Don't use Git rebase
#46Earlier quoted context omitted.
There's no such thing as "real" history - you don't commit every line of code you add or remove, or even every character. Rather, you choose some points in time to commit. For me, those are often arbitrary - I can't get something to work at a certain point, so I make a WIP commit with the buggy work at that point, and will come back to it the next day. Before I merge my branch back into master, though, I want my comm…
Well, assuming that you are adding features in parallel you have an history. You have a branch with feature A and are about to build feature B, which is now based on A, someone else is building feature C which is also based on A. Building B and C might require different or equal changes to A. There's no guarantee that any of these features will be built in order since they might have different priorities, difficultie…
Yeah I think my point was more that a blanket ban on rebasing is too rigorous. I agree that once you want to integrate B and C (or both into A), a merge is usually the best way to do it - and I think that's what TFA was actually referring to.
It fails to consider the case, however, of rewriting B's history internally, not as a way of integrating with A or C, but as a way of making its commits clear. Afterwards, you'd still do a merge of A into B and then merging B back once you see that's successful.
Re: Don't use Git rebase
#47There's a more nuanced approach to git rebase. You should use it the other way around - switch to your feature branch and `git rebase master` to update your branch and resolve conflicts. Then test it and `git merge`. I also use git rebase to tidy up the branch's history - generally not entirely squashing it, though.
Yep, I use it to keep my feature branch up to date, too.
Re: Don't use Git rebase
#48There's a more nuanced approach to git rebase. You should use it the other way around - switch to your feature branch and `git rebase master` to update your branch and resolve conflicts. Then test it and `git merge`. I also use git rebase to tidy up the branch's history - generally not entirely squashing it, though.
> You should use it the other way around
Yes, that's how I thought it was meant to be used.
(At first I got confused reading this article because I assumed that's what they were talking about too.)
Re: Don't use Git rebase
#49`git rebase --exec {rebuild project}` solves the issue of invisible errors in commits. I'm a big fan of Gerrit's review workflow, which requires every commit to build in isolation. I also usually try to squash my changes into logical independent commits before review. I like rebase because it's prettier, but I also think there's an issue with the non-rebase case that the OP has missed: unless you rebase, you're setti…
But that's exactly why I prefer merges - seeing that the problem wasn't in any individual branch, but resulted from the combination of changes in both is the most honest result that I would've wanted to see. Why do you label this as a 'failure'?
Re: Don't use Git rebase
#50I tend to use rebase solely for the purposes of creating tidy commits before I merge my changes into a staging branch.
For example when I'm working on a feature I tend to do n things at once, but I then want to create logical commits which separate the work into logical unit which could be reverted etc. as necessary. If in this process I notice that I've forgotten something (or for that matter, realise later than I've introduced a bug / broken tests) I'll tend to create a patch commit for that logical unit and then `git rebase -i HEAD~n` and then fixup that patch into the original commit.
Also, whenever I'm done for the day instead of stashing I: `git commit -am "wip"; git push; git reset HEAD~1 --soft` (i.e. push my changes up to Origin to avoid any localized mishaps with my PC resulting in a loss of work). I then force push to my feature branch.
I know that both of these "change history", but as long as they're isolated to my own feature branches I see no reason to avoid doing so...