This may be borderline off topic, but I don't really understand the desire to have git support in your text editor. It can be very nice for viewing blames, but for managing commits and stuff it has always felt a bit clunky to me. Maybe that is because of my workflow however. I typically review every line being staged by using `git add -p` so that I commit exactly what I intend to commit, and that workflow doesn't really mesh well with an editor.
I used `git add -p` until very recently (basically, until we built this feature in Zed). If you're using `add -p` and you notice a problem that you want to fix before committing, you need to go find that same bit of code in your editor, edit the code, then re-start your `add -p`. If you had chosen not to stage some preceding hunks, you need to skip over those again. Also, an editor can just render code much more readably than the git CLI can.
I use the GitHub Desktop app a lot, every day, the viewing diff there is so clear. But I am happy to use Zed to open multiple projects, switch branch, stage changes, commit and push. Otherwise I have to switch to different repo in the GitHub Desktop. In most cases, I don't need a full IDE, since I only need to make few lines change of a terraform or a markdown file, or update the dependency in a package.json.
`git add -p` opens an editor to stage individual lines/hunks right?
If so, would a better workflow not be the editor providing shortcuts to stage/unstage individual lines/hunks (which it can indicate in some state column) and a list of files with unstaged changes (to replace the inevitable `git status`)?
You get the same flexibility of crafting commits, directly from the place you’ve edited the files without having intermediate CLI commands. And all the other niceness of the editor (syntax highlighting etc).
my workflow involves switching between files in working set, sometimes going back to staged. The git panel is easier to navigate than the file tree. I also need to see all the markers for recent changes I made, they are in git diff
Inside the editor in VSCode I would select a chunk that includes the markers that I want to stage, and stage them deliberately like you do.
For the actual commit often I have to do terminal because VSCode would fail to give me the relevant commit hook error message.
> because it's 2025—Zed can ask your preferred LLM to write the message for you
Zed seems to have a lot going for it. Though the everpresent AI push has me concerned to invest my time into learning its intricacies, for fear of it devolving into Yep Another AI Editor.
So far it’s all optional stuff. I think the editor is worth trying purely for how snappy the UI is, whilst not really missing any of the nice major features of VS Code that I actually use. Even without the AI stuff, it is an editor with a lot of potential.
This may be borderline off topic, but I don't really understand the desire to have git support in your text editor. It can be very nice for viewing blames, but for managing commits and stuff it has always felt a bit clunky to me. Maybe that is because of my workflow however. I typically review every line being staged by using `git add -p` so that I commit exactly what I intend to commit, and that workflow doesn't really mesh well with an editor.
Some things are just much faster in an editor.
I used `git add -p` until very recently (basically, until we built this feature in Zed). If you're using `add -p` and you notice a problem that you want to fix before committing, you need to go find that same bit of code in your editor, edit the code, then re-start your `add -p`. If you had chosen not to stage some preceding hunks, you need to skip over those again. Also, an editor can just render code much more readably than the git CLI can.
I use the GitHub Desktop app a lot, every day, the viewing diff there is so clear. But I am happy to use Zed to open multiple projects, switch branch, stage changes, commit and push. Otherwise I have to switch to different repo in the GitHub Desktop. In most cases, I don't need a full IDE, since I only need to make few lines change of a terraform or a markdown file, or update the dependency in a package.json.
`git add -p` opens an editor to stage individual lines/hunks right?
If so, would a better workflow not be the editor providing shortcuts to stage/unstage individual lines/hunks (which it can indicate in some state column) and a list of files with unstaged changes (to replace the inevitable `git status`)?
You get the same flexibility of crafting commits, directly from the place you’ve edited the files without having intermediate CLI commands. And all the other niceness of the editor (syntax highlighting etc).
my workflow involves switching between files in working set, sometimes going back to staged. The git panel is easier to navigate than the file tree. I also need to see all the markers for recent changes I made, they are in git diff
Inside the editor in VSCode I would select a chunk that includes the markers that I want to stage, and stage them deliberately like you do.
For the actual commit often I have to do terminal because VSCode would fail to give me the relevant commit hook error message.
[dead]
> because it's 2025—Zed can ask your preferred LLM to write the message for you
Zed seems to have a lot going for it. Though the everpresent AI push has me concerned to invest my time into learning its intricacies, for fear of it devolving into Yep Another AI Editor.
So far it’s all optional stuff. I think the editor is worth trying purely for how snappy the UI is, whilst not really missing any of the nice major features of VS Code that I actually use. Even without the AI stuff, it is an editor with a lot of potential.