Skip to content

Instantly share code, notes, and snippets.

@PoignardAzur
Last active May 24, 2021 16:43
Show Gist options
  • Select an option

  • Save PoignardAzur/756f65f011e52e4ea12b77c769e65231 to your computer and use it in GitHub Desktop.

Select an option

Save PoignardAzur/756f65f011e52e4ea12b77c769e65231 to your computer and use it in GitHub Desktop.

Povcon

Alternate git frontend

TODO

Note: have feature to track previous commits that interacted with your local branch last rebase (eg to handle renames)

Eg maybe you added a function foo that calls bar locally, but since the last rebase an outside commit has renamed bar to baz.

That feature could be plugged into by IDE to suggest renaming bar to baz.

Log format

The default format of git log is way too verbose.

Every workplace I've been in recommended using some combination of `--oneline --

  • oneline by default
  • based on the remote branch by default

Rebase-by-default

Have logs reported in a way that favors the upstream branch


Diff model

I want to make something clear: any diff/merge algorithm you use for a git repository will be inherently heuristic; you can't have a mathematically consistent model of changes because git doesn't record changes, it records snapshots.

But I think git's heuristics leave a lot of value on the table. Here are some changes I'd want to make:

Syntax-aware grouping

Git considers a file as a linear sequence of lines; when diffing two files, it will create its patchset based on what lines are in one file and not the other, without consideration for how these files might be grouped together syntactically.

Sometimes this creates odd diffs TODO

Instead gix should try to preserve blocks based on a very basic syntax analysis (eg try to group parens)

Treat indentation as a special case

Sometimes a user does nothing but eg put a big chunk of code in an if-block. This is a kind of change that should ideally be really easy to represent: Say "add an if statement, add an opening bracket, indent these lines to the right, add a closing bracket".

TODO Instead git produces these really huge, unreadable patches; the number of lines a reader has to inspect to parse the change is way higher than the semantic change actually warrants

Notice inline changes

Sometimes a change to a given line is fairly small, and keeps the line recognizably the same; for instance, changing the single variable's name inside a larger expression.

Git doesn't notice this, and doesn't make a difference between a small change to a line and a complete rewrite.

Gix should try and notice these inline changes

  • For diffs, to produce diffs that visually highlight those changes (like github)
  • For merges; if there two indepent patches to the same line, merging them shouldn't require a manual merge

Track code moves

Sometimes a user will cut and paste a function from one part of the code to another.

Git doesn't notice this, and will treat it as an indepent removal and addition. Gix should try to notice this (though, again, heuristics);

  • For diffs (to indicate "this was moved")

  • For merges (TODO - example)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment