News for hackers. Stuff that matters.

A comment on Show HN: Hiding code from Git diff. Parent comment

Re:Show HN: Hiding code from Git diff by jsteemann on Wednesday December 13, 2017 @05:57PM (#15918496)
Non-compiling commits make bisecting harder, when the goal is to find the commit that broke the build or a specific test. IMHO having to skip over non-compiling merge commits only makes bisecting take more time, and it may also "pollute" the test pipelines if all commits are going to be built. Additionally, merging and fixing the merge in separate commits makes it much hard to revert a merge later, in case it turned out that the merge introduced something unwanted).

So I will always recommend doing the merge and fixing the merge in the same commit. Ideally this produces a squash commit that can easily be reverted later when needed. This makes the merge process more time-consuming, but it can help to keep the builds more stable, and to more easily track which commit (merge) introduced a particular problem.

[ Parent | on HN ]
Re:Show HN: Hiding code from Git diff by pkamb on Wednesday December 13, 2017 @06:06PM (#15918560)
> makes it much hard to revert a merge later

I don't think this would apply, as I'd be merging from `dev` > `feature`, resolving conflicts, and then doing a single clean no-conflict merge back from `feature` > `dev`. That's the only commit you'd need to revert to undo the merge.

(or on a new, third, `merge` branch, if you don't want to pollute the `feature` branch with commits from `dev`)

I admit the non-compiling commits might be a problem in some workflows, but `git bisect skip` is the solution to the only problem I've ever had with it.

[ Parent | on HN ]
Re:Show HN: Hiding code from Git diff by jsteemann on Wednesday December 13, 2017 @06:30PM (#15918699)
It's kind of a problem if the compile/build step takes rather long. Then you want to avoid having any additional non-compiling revision to check when bisecting.

But I agree in general, if the compile/build turn-around times allow for it, then a single no-conflict squash merge back into devel is definitely a very good approach to have clean and compiling commits, and for identifying the commits/merges that break the builds.

[ Parent | on HN ]