<story><title>Git: Using Advanced Rebase Features for a Clean Repository</title><url>https://mtyurt.net/2017/08/08/git-using-advanced-rebase-features-for-a-clean-repository/</url></story><parent_chain><item><author>ekidd</author><text>Editing git history makes sense in several cases:&lt;p&gt;1. Projects like the Linux kernel which use frequently use &amp;#x27;git bisect&amp;#x27; to perform a binary search on the history of project (to find when a bug was introduced), or where the patch series tell a story to code reviewers.&lt;p&gt;2. Open source projects, where some contributors have terrible git habits that the maintainers don&amp;#x27;t want to merge.&lt;p&gt;Editing git history makes &lt;i&gt;less&lt;/i&gt; sense in other circumstances:&lt;p&gt;1. When dealing with less sophisticated git users who don&amp;#x27;t understand git&amp;#x27;s data model. About 90% of git nightmares begin when a novice git user tries to rebase something.&lt;p&gt;2. When it adds a whole layer of unnecessary process for zero payoff. If your developers all work in short-lived branches with clean histories, then just go ahead and merge normally without forcing everybody to jump through a bunch of hoops to beautify a history that nobody ever looks at anyway. Git was designed to handle branches.&lt;p&gt;I always twitch a bit when I see a 10-page blog post describing a &amp;quot;git workflow&amp;quot;, with all sorts of complicated branching rules and heavy use of rebasing. That can make sense in certain specialized situations, but it shouldn&amp;#x27;t be considered a &amp;quot;best practice&amp;quot; that everybody needs to emulate.</text></item></parent_chain><comment><author>burntsushi</author><text>&amp;gt; I always twitch a bit when I see a 10-page blog post describing a &amp;quot;git workflow&amp;quot;, with all sorts of complicated branching rules and heavy use of rebasing. That can make sense in certain specialized situations, but it shouldn&amp;#x27;t be considered a &amp;quot;best practice&amp;quot; that everybody needs to emulate.&lt;p&gt;I tend to justify this based on a simple observation: writing clean code that is easy for others to understand is &lt;i&gt;also&lt;/i&gt; hard. If you could write a document that teaches others how to write clean code, what would it contain? How long would it be? How complex would it be? I&amp;#x27;m betting you&amp;#x27;ve built up a repertoire of wisdom on writing easy to read code, and I&amp;#x27;m betting that document would be quite long, especially if you furnished it with examples.&lt;p&gt;I think it&amp;#x27;s the same for commit history. If you&amp;#x27;re rebasing, then you&amp;#x27;re probably trying to shoot for a clean history that other humans can understand. Maintaining a clean history can be just as hard (and just as rewarding) as maintaining clean code.</text></comment>
<story><title>Git: Using Advanced Rebase Features for a Clean Repository</title><url>https://mtyurt.net/2017/08/08/git-using-advanced-rebase-features-for-a-clean-repository/</url></story><parent_chain><item><author>ekidd</author><text>Editing git history makes sense in several cases:&lt;p&gt;1. Projects like the Linux kernel which use frequently use &amp;#x27;git bisect&amp;#x27; to perform a binary search on the history of project (to find when a bug was introduced), or where the patch series tell a story to code reviewers.&lt;p&gt;2. Open source projects, where some contributors have terrible git habits that the maintainers don&amp;#x27;t want to merge.&lt;p&gt;Editing git history makes &lt;i&gt;less&lt;/i&gt; sense in other circumstances:&lt;p&gt;1. When dealing with less sophisticated git users who don&amp;#x27;t understand git&amp;#x27;s data model. About 90% of git nightmares begin when a novice git user tries to rebase something.&lt;p&gt;2. When it adds a whole layer of unnecessary process for zero payoff. If your developers all work in short-lived branches with clean histories, then just go ahead and merge normally without forcing everybody to jump through a bunch of hoops to beautify a history that nobody ever looks at anyway. Git was designed to handle branches.&lt;p&gt;I always twitch a bit when I see a 10-page blog post describing a &amp;quot;git workflow&amp;quot;, with all sorts of complicated branching rules and heavy use of rebasing. That can make sense in certain specialized situations, but it shouldn&amp;#x27;t be considered a &amp;quot;best practice&amp;quot; that everybody needs to emulate.</text></item></parent_chain><comment><author>kobeya</author><text>&amp;gt; 1. Projects like the Linux kernel which use frequently use &amp;#x27;git bisect&amp;#x27; to perform a binary search on the history of project (to find when a bug was introduced), or where the patch series tell a story to code reviewers.&lt;p&gt;This seems like an instance of adapting development practices to bad tooling, whereas we could be fixing the tool itself. Shouldn&amp;#x27;t there simply be a &amp;quot;tree aware&amp;quot; git-bisect that can intelligently handle branches and merges? That would resolve this sticking point.&lt;p&gt;&amp;gt; 2. Open source projects, where some contributors have terrible git habits that the maintainers don&amp;#x27;t want to merge.&lt;p&gt;Then tell them to go away and come back with a cleaned up PR.</text></comment>