karyon

could you expand on in how far this is a problem? i must say i'm glad there's finally no way of talking out of it, if the data says you did it wrong, then you most likely did it wrong and the cops should make you pay money or jail time, shouldn't they? no matter whose data it was.

even if there is something like a chilling effect, if it prevents people from speeding and running red lights, that sounds pretty cool to me.

insurances are another matter. although we probably disagree over that as well, it's certainly (even) more debatable.

> If you look at a commit, there's no "anymore", no other timeframe rather that the commit's; it's either correct or incorrect on it's own.

this is true but frankly nothing i ever cared about. I think of commits as something that i can change and break and fix through rebasing, amending and the like. This mindset makes you a lot more flexible when handling commits, and when keeping in mind that the commit hashes change while doing that, I don't see any downsides.

> It makes much more sense to merge each interface change from master to feature branch individually, resulting in atomic merge commits, each of which handles specific aspect, while staying correct.

Then we have different views on what a horrible merge is. For me, that is having dozens of merge conflicts plus multiple necessary changes not indicated by conflicts, and most of those problems need to be resolved before the project compiles and the rest has to be resolved before all tests go green. There is no "while staying correct" in there. And this, working on lots of breakages at once, while needing to fix all of them before tests are green again, this i don't like at all and will be partly mitigated by the rebasing strategy.

There certainly are advantages of merge commits, but in my (admittedly limited, especially when talking about larger projects) experience, resolving merge issues does get harder with them.

> I often don't want to record my development history in the master branch because it's messy. Instead I squash my work into a single cohesive commit

personally i rebase my commits into fewer ones so the result is a reasonable compromise between how-the-code-actually-evolved (which is messy, true) and a clear, simple progression from start to completion of the feature (one single commit if taken to the extreme).

> I can say "hey Joe, you broke the frobber when you implemented the new gizmo." that breaks if joe is not available anymore or the change is complex (or old) enough that the detailed history would help debugging, but joe doesn't have the branch lying around anymore because he deleted it or switched machines etc.

There are certainly advantages to a single commit per feature :) I just think having more information available through more commits is a good thing, and i don't see large disadvantages of having larger amounts of commits, provided you really do squash those "fix last commit" commits etc. to keep the commit count reasonable.

That notion is false, right, thus I'd rather think "this commit is not correct anymore".

Regarding getting ideas how the code was developed, for the commit that is not correct anymore I have a commit message telling me why it was added. For reasonably small commits, I don't a lot of room for misunderstandings and wrong fixes.

This applies if the required changes in your branch are rather small. I think we can agree that rebasing breaks if some changes in master require lots of changes in your branch. But so does merging, as the merge becomes even more horrible and error-prone in that case. Basically, large changes ("real" development) should happen neither in merge commits nor during rebases in my opinion.

once more, gitlab does it right and offers a "rebase" button on merge requests along with a "fast-forward merges only" option for repositories.

See http://doc.gitlab.com/ee/workflow/rebase_before_merge.html

> git bisect pointing to the merge commit as culprit is exactly what should happen

in theory, maybe. in practice, this simply does not help if you are looking at massive merge commits. sometimes, the merge goes wrong even with no conflicts, and then you can debug that massive merge with little clue where to start.

compare that to rebasing, where you have a hopefully small commit that breaks. you indeed loose the information whether the rebase broke it or the initial version was broken as well, but I don't see the practical difference, it needs to be fixed either way.

You lose a whole lot of development history information. You have no chance of finding out why these five lines of code came to be when all your commits touch hundreds or thousands of lines. Maybe the intent of the code should've been in a comment, but if there are none, it's nice to have commit messages as a backup.

Also, bisecting (and then finding the actual fault in the code) gets harder the larger the commits are.

On my two machines (with SSDs) I regularly find that copying lots of small files is severely slowed down by Windows Defender. It utilizes one core to the max and when disabling it, the copy operation gets a lot faster.

I don't know about other antivirus software though.