[dead]
Unified versus Split Diff
181–184 of 184 posts
Re: Unified versus Split Diff
#182A third (fourth?) option worth mentioning here is difftastic[0], which uses "structural" diffing (as opposed to line diffing) for more granular diff highlighting. [0] https://github.com/Wilfred/difftastic
ediff in emacs does this. Refine is what highlights the words that are different.
This blog post also details using difftastic within emacs and has neat comparisons:
Re: Unified versus Split Diff
#183That kinda feels like how I review with vim. * A little scripting around opening the PR, which basically performs a "vimdiff baseref : file ) file "-style dance on the changes(see :h diff). Using vim's tabs is great for this as they're really only views, so you can hold individual buffers open in distinct states at the same time. * Scroll locking still works as expected in the main view, but you can avoid it in a sep…
What do you mean exactly by "push as a comment" and "pulls text comments"? Is it some sort of custom logic specific to your work place?
Oops, poorly worded and using internal terminology. I'll try again ;)
We use some internal tooling to make things work, but the concepts are generic git and $forge.
Push a comment: I'll make a hand-wavy suggested edit, then a vim mapping basically performs a ":`w !curl". If you only used GitHub, then piping to something like "gh pr comment"¹ could perform a similar-ish role(albeit a little weaker).
Pull comments: We automate merges so that PR text(including replies) are available in the repo. For the general discussion they're attached as notes², and for code comments(including --fixup commits) they're processed to assign the correct attribution via trailers³ to the original commit at merge time. Most of the attribution functionality could be re-implemented with "git rebase --autosquash" and by providing a "git interpret-trailers" wrapper as $EDITOR.
Re: Unified versus Split Diff
#184Earlier quoted context omitted.
I'd like my PRs to tell a very sanitised story of how I could have come up with the change, with the power of foresight. Basically, first you write your code however you see fit. Then you use git to rewrite history to make the reviewers life easy, and then you give it to the reviewer. The reviewer doesn't need to know that my original version had a bug that I fixed later. I can make it look like I came up with a bug…
I used to do that but these days I prefer the whole story be in there so I can reference it later if I run into the same bug in a different place. In general I find my past efforts to maintain a clean git history were probably not that useful, as long as you're not running e.g. 4 or 5 branches in parallel with crossing history. Branch off, make change, merge back main, PR, is fine.
Most of the time most PRs are small and can be squashed into a single commit, and still produce useful history.
Sometimes it makes sense to have multiple commits. The next step up the complexity ladder is:
- one preparatory refactoring commit that does _not_ change behaviour
- one simple commit that changes behaviour