Programming

3 readers

1 users here now

This magazine is dedicated to discussions on programming languages, software development, and coding. Whether you are a beginner programmer or an experienced developer, this is the place for you. Here you can share your knowledge, ask questions, and engage in discussions on topics such as coding languages, software engineering, web development, and more. From the latest trends and frameworks to tips and tricks for debugging, this category covers a wide range of topics related to programming.

founded 2 years ago

git bisect and the importance of a clean history (danielrotter.at)

submitted 9 months ago by danrot@kbin.social to c/programming@kbin.social

4 comments fedilink hide all child comments

The value of a clean git history is often underestimated. I will explain one of the advantages based on the git bisect command.

you are viewing a single comment's thread
view the rest of the comments

[–] kevincox@lemmy.ml 0 points 9 months ago* (last edited 9 months ago) (1 children)

All of this can only work with a clean git history containing only working commits.

This isn't really true.

You can use git bisect skip to skip commits that can't be evaluated. So if you are tracking down the failure of test foo and this commit fails to build, you can skip it.
If all merged commits are green then you can use --first-parent to avoid testing inside a development branch. This way you can identify which merge caused the issue, even if other merges had broken commits.

So it is easier in general if you have all working commits, but it isn't necessary. Really as long as you have green history on your main branch you will be able to get good results without much effort. I would highly suggest using some sort of merge-queue based workflow to ensure that the master branch is always green.

I would generally prefer using --first-parent rather than forcing squashing. As smaller commits can be much easier to understand and the fact that commit IDs don't change when being merged can make it much easier to manage stacked PRs and hotfix backporting.

[–] danrot@kbin.social 1 points 9 months ago

I agree that some stuff is easier when not squashing commits, but for the teams I've been working with I've felt that the pros of squashing outweigh the cons, but of course YMMV.

But I didn't know about git bisect skip, thanks for the tip! But sincere question: What happens if there are e.g. three adjacent broken commits? If I have skip all three of those and the error was introduced in one of them, then git cannot tell me which commit introduced the error, right?