kriegaex commented on PR #124: URL: https://github.com/apache/xalan-java/pull/124#issuecomment-1817721917
> I agree that my squash earlier in this branch was badly premature It was just a historical practice that you learned and a convention, albeit dated, which still is in effect in too many projects. > in past projects having atomic merges seemed to be a win In CVS and SVN, commits and branch switches were expensive and merges painful. That is where this practice might partially come from. Developers wanted to avoid that pain by avoiding feature branches, committing infrequently and merging even more infrequently. Combine that, and you get a preference for squashed merges. In Git, it is different: All operations except for fetch and push can be done offline without any network connection. I.e., commit, branch switch, merge are blazingly fast. In SVN, all of these require network connections and bandwidth. If SVN, a merge basically is rooted in a rather naive diff between two directory trees, while Git retains a DAG (directed acyclic graph) of the commit, branch, merge history, which is why several types of merge conflicts you would encounter in SVN simply do not occur, e.g. if you re-merge the same branch multiple times. Last but not least, even bisect is a local operation and thus also fast. In SVN you can bisect logically, if you want, but each checkout requires loading tons of data from a central server. I.e., using that error hunting strategy is way less enticing than with Git. Hence, nobody cared much about small commits in the old times. Been there, seen that. For me personally, back then, knowing SVN well and even administering it, for a few years I avoided using Git. Then one weekend, I got curious and started to read ["Pro Git" by Scott Chacon](https://git-scm.com/book/en/v2), which nowadays is available in many languages and open source. I could not put the book down, and at the end of the weekend I had read it back to back, because the technical concept behind Git was so intriguing. It was all so simple, one had to wonder why nobody had come up with something like it before and SCM had not been like that forever. I immediately switched to Git in all my personal projects and never looked back. I established a practice of consequently using feature branches and small commits, and my life as a developer became so much better over night. As an agile coach, since then I have introduced Git to dozens of teams in several organisations. Despite initial resistance against feature branches and frequent merges due to fear caused by lack of kn owledge, all developers embraced it, once they got the hang of it. For me, agile software development - or let me just call it clean and professional software development - is next to unthinkable without feature branches for reasons which to explain would make this post even more lengthy. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
