4 ms·
It's not so easy if you have changes belonging to different commits that are close together in code (e.g. affect the same lines). For instance, if you need to a
by blauditore 9y ago
It's not so easy if you have changes belonging to different commits that are close together in code (e.g. affect the same lines). For instance, if you need to adjust formatting in a place where also functionality will change, it's extremely tedious to rebase if you have logical changes before and after the formatting commit.
- fragmede 9y agoSadly, you're right, but while AST-based diff (vs text-as-code based) has yet to become mainstream, code formatting standards date back to the second ever programmer, and some of those are for good reason. To use a trivial example, Python allows trailing commas for list items, eg: [1,2,]. With diffing in mind, list_o_things = [ thing1, thing2, ] then, the diff to add "thing3," is a single line , rather than two in order to add a comma to the preceeding line. The solution, then, is the code should be "properly" formatted at all times, to avoid running into a situation that goes formatting -> logical change -> formatting leading to the problem you describe. There are similar hacks, where git's diff implementation supports ignoring white space, and doing word-based (vs line-based) diffing, but what we're really after is AST-based diffing tool(s).
- majewsky 9y ago> The solution, then, is the code should be "properly" formatted at all times This is why I love gofmt(1).