I could imagine that in ten years git will feel strangely slow and ceremonial. Why not just continuously work and continuously deploy live-edited software
Zed is our office
21–30 of 343 posts
Re: Zed is our office
#22As long as I don't have to use, feel free to include it. It is really not essential feature for editor.
I run update and Collab requires you to sign in... which again, it is fine if you want it. I don't, so it can be dormant, icon is really tiny, doesn't take much space.
The feature of Zed that is most annoying yet essential is frequent updates. Pretty much daily when I switch to Zed window, I can expect update and restart, which messes up my window layout, so this is annoyance. Getting updates and knowing you guys are shipping good stuff is what is essential.
I think integrating terminal ai's is great move and useful. Sometimes I use it like that, often I use it in terminal (like the outside of the editor terminal) and switch to editor to review or update stuff. Same with git. I am old-fashioned.
Re: Zed is our office
#23I tried the collaborative features to pair program with a colleague a few months ago, but it was bad. It was very flaky in establishing a connection. In the cases we were able to establish a connection, the voice chat would not work. We tried to make it work for a couple of days, and then we gave up. Has there been lots of work in the past few months on the collaborative features?
Re: Zed is our office
#24I could imagine that in ten years git will feel strangely slow and ceremonial. Why not just continuously work and continuously deploy live-edited software
[deleted]
Re: Zed is our office
#25 If you've been a developer long enough, you might recall the teletype package for Atom—both built by Zed's founders.
Appropriately working together on a truly collaborative tool, Martin Ott, Martin Pittenauer, Dominik Wagner, and Ulrich Bauer of Technische Universitat Munchen won the Best Mac OS X Student Project for Hydra 1.0.1, a Rendezvous-based text editor that enables multiple people to contribute to a shared document. (Adam and about ten other attendees at MacHack used Hydra to take notes during this year’s Hack Contest.)
https://en.wikipedia.org/wiki/SubEthaEdit
https://tidbits.com/2003/06/30/apple-announces-design-awards...
Re: Zed is our office
#26I could imagine that in ten years git will feel strangely slow and ceremonial. Why not just continuously work and continuously deploy live-edited software
Often projects need a history of stable checkpoints, and source control is one way to provide that.
Re: Zed is our office
#27I could imagine that in ten years git will feel strangely slow and ceremonial. Why not just continuously work and continuously deploy live-edited software
I feel the opposite way, that git branching and merging will become a bigger part of the job as more code is written by agents in parallel and then accepted by other agents or humans.
Re: Zed is our office
#28commence feature creep
The collaboration tools built into Zed have basically existed since the product launched. It is one of the primary drivers behind the product - they wanted to build the best editor for remote code collaboration.
I think the most difficult question are going to be how do you constraint that core feature without ever wanting to add more to it?
For instance, collaboration is a huge topic. You can have coding collaboration on the file, and that would be basic and appropriate, you can then replicate slack and you'll have chat rooms, which is entering creep territory, but it's natural! Then soon the chat room will need to link with issues and you can now have TODOs linked to some kanban board and we should be able to speak while we code on the same file! And this goes on and on.
It's exceedingly rare that the organization found hard courage to specifically avoid features that looks like easy pickings for the purpose of avoiding them.
Re: Zed is our office
#29You guys need to figure out how to create Slack shared channels in Zed and we're all switching until they won't be needed anymore.
Re: Zed is our office
#30I have been trying to figure out how this works in concert with Git (or SCM in general). Is one of the developers in the session merely responsible for it?
I mean, you have the same "problem" when peer coding in person. Whoever is officially working on the fix will commit it. I've helped devs get around a hump for ages, you don't get "credit" for all the work you do. It's why I hate most ticketing systems (when management starts to ask why your tasks fell behind), they don't let you correctly track multiple people when they work together.
Does a `Co-authored-by:` trailer in the commit message not resolve this issue?