While git actually is able to fix previous commits, it implies rewriting the history by rebasing, hence will break any unmerged forks (i. e. all contributors will have to merge their open branches against the new master). Due to that, it is a bad practice in general. Anyways, if all developers agree upon a history rewrite, we could do it. The question is, whether it is worth the cost.
From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Dave Cramer Sent: Montag, 20. Juli 2015 18:14 To: Vladimir Sitnikov Cc: List Subject: Re: [JDBC] Git branching structure: ff or no-ff
The answer to your question(s) is mostly ignorance.
Any clue why --no-ff merges are used a lot in pgjdbc development? Any clue why "fix here, fix there" commits are not squashed before integration?
From my point of view, it makes history browsing hard: 1) Just look at https://github.com/pgjdbc/pgjdbc/commits/master Commits on Jul 9, 2015 Merge pull request #333 from zapov/master … Merge pull request #343 from phillipross/master … Merge pull request #351 from headcrashing/#328 … Merge pull request #349 from ekoontz/jsonb-support … ... Does that make much sense?
2) Even a single commit becomes two commits, so it clutters change log
