Releases: timbrel/GitSavvy
2.27.2
2.27.1
2.27.0
Introduce rebasing directly from the Repo History
In the history views there is a new rebase menu bound to [r] which offers
very typical rebase commands.
[W] to reword the commit message of the commit under the cursor
[E] to edit the commit under the cursor
If you're on a fixup or squash commit, [r] will offer a command to apply
that fix.
At any time during a rebase you can either git: rebase --abort or
git: rebase --continue from the Command Palette. (--skip is also there.)
Note that rebasing merges is not implemented yet.
Other improvements to the Repo History
[f] now remembers the last used filters and also provides defaults like
"--reflog"
[F] toggles the filters on and off
[l] opens a menu with all files and folders under version control
For example, if you're searching through a "File History", [F] will show
you now the context of the commits.
Improvements to the Commit Message View
<tab> on the very first char of the buffer (BOF position) will show the most
recent commits.
Similar to that, fixup<tab> (and squash<tab>) can be used to construct
commit messages which are recognized as such by "git --interactive".
When you're rebasing you likely get merge conflicts rather sooner than later.
If so, a panel should open with further instructions.
What's the current workflow to resolve merge conflicts?
Usually, you should open git: status[*] which points out the files with
merging conflicts.
-
Select such a file and press
[e]to open a diff showing the merge
conflict. -
Now click into a hunk and press
[o]to open the file at that
position. Edit the conflict to your liking and save. Go back to the diff
(ctrl+tab), the diff will update.
Repeat with [o] if there are still other conflicts. Eventually the file will
be okay. Unfortunately, you cannot stage such a file in the diff view at the
moment, so close the view which will bring you back to the status dashboard.
-
[s]to stage the file. (Double check with[e]on the staged file the diff
to be committed). Proceed with other conflicting files. -
Finally,
git: rebase --continueto continue.
How does "Edit" actually work?
If you select a commit for "Edit", it will basically checkout that commit.
Again a panel opens with further instructions. You usually now open the file
you want to edit, make the change and save. Stage and amend. For example open
the diff for that file, stage the changes and [m] to start the commit process.
You can make more changes too, basically adding commits. When you're done
git: rebase --continue to continue.
Shit;
After a rebase, [f] followed by <up> should bring you the "--reflog". Hit
<enter> to redraw. You can now for example compare the old with the new tip
by selecting the old tip followed by <enter> for the standard menu.
Choose "Diff ... against HEAD", or, of course, "reset --hard".
[*] It is recommended to bind gs_show_status to a key-combo, for example
{ "keys": ["ctrl+shift+s"], "command": "gs_show_status"},
For more info:
2.26.2...2.27.0
2.26.2
2.26.1
- Make the new navigation (
up|down) in the "Repo History" snappy and more natural. #1370 - Ensure dashboards are refreshed, for example when switching projects. #1365
- Do not forcefully jump to "HEAD" when using
gin the status dashboard. #1374 - Allow
gs_show_committo show the "HEAD" commit. #1369 - Fix syntax highlighting errors in the "Line History" view. #1366
- Teach the diff syntax the "--cc" (combined diff) header. #1373
2.26.0
Implement git: Line History
A "Line History" (aka "log wtf" or "log why") basically calls
"git log -Lx,y:<some_file>". This is a supereasy to use tool in
the editor. It is usually the faster (in terms of you get the info
you're looking for faster) "blame" and also the faster "File History"
because often you're only interested in some part of a file. Really
answering "Why is this line or section of code here?".
The command can be called from normal views only. Just put your cursor
somewhere, or drag a selection, and call the command from the Command Palette.
The command is called gs_line_history if you want to bind it to a key.
Comes with:
[o] to open the complete commit under the cursor
[O] to open the file at that revision
[g] to open the graph context
Improvements to the Repo History
We already showed the path down while navigating through the history. Now
we also follow and colorize the path upwards. (For customization: the scopes
we use here are git_savvy.graph.dot.above, git_savvy.graph.path_char.above)
This is not just fancy but allows easier and faster navigation:
Use the arrow keys [up] and [down] to get to the previous or next commit.
Use [alt+up] or [alt+down] for "wide" jumps usually following the first parent.
After such a wide jump, you can use the built-in jump_back/jump_forward
commands (for example [ctrl+-] on Windows/Linux by default) to jump back
to the previous location.
There is also a new smart copy function. Just invoke the builtin "copy"
command (for example [ctrl+c]) to directly copy the commit hash, or commit
message, or a combination of both to the clipboard (if nothing is selected).
Minor: If on a HEAD commit we offer "pull", "push", and "fetch" in the
actions menu ([enter]), and the diff action opens the normal diff for staging,
unstaging etc.
Finally, we now clearly mark fixup/squash commits. (The scope here is:
string.other.rebase-hint.git-savvy.)
Improvements to the Commit Message View
Being in the diff area, you can now use [o] on a hunk to open that location
for editing. Also [,.] for navigation per hunk. But unstaging etc. is not
supported yet.
Noteable
Removed "word-diff" switch from the Diff view. This has been superseeded
by the intraline diffing feature. There is still the switch to ignore white-
space changes though, but the keybinding for that moved (from [s]) to [w].
The setting "show_commit_diff" now defaults to "full" (was: "stat").
The setting "show_full_commit_info" now defaults to "true" (was: "false").
For more info:
2.25.0...2.26.0