Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I prefer the exact opposite approach personally: no merge commits, only rebases and fast-forward merges to master

I know that many do, unfortunately.

It's a legacy of how git was used initially, I guess, and of the use of e-mail for sending Linux patches

> Though to be honest I am not sure what you mean by “jumbled” diffs.

Simple modifications such as code moved or indendation changes wil usually only be recognized by diff programs if they're on their own, without other changes included.

It's unfortunate, but since that if the state of things, adapting to it by making small commits will make reviews massively simpler.



> Simple modifications such as code moved or indendation changes wil usually only be recognized by diff programs if they're on their own, without other changes included.

Yeah, those are some of the situations where I will push multiple commits. Though indentation changes are something I prefer to avoid by using autoformatters.


> Though indentation changes are something I prefer to avoid by using autoformatters.

Well when you extract a function, add an if, loop, or do any number of other things, you can't avoid changing the indentation (unless you want to leave a mess)


Sure, and if you also change the logic inside that loop, I don’t think the combined diff ends up being “jumbled” or misleading at all. Also you can hide whitespace changes.


Even with hiding whitespace changes, the differences often don't get recognized correctly.

Rather then misleading, the diffs are much harder to check, instead of showing that only white space changed (or in general, rather than highlighting only the actual thing that was changed).

Basically, it's little additional work which guarantees simpler reviews for everyone, I think it's warranted




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: