That's really neat. I love the idea of doing as much as possible from text-based UIs, especially using Emacs.<p>I see this is built on top of Emacs, but it looks like it's entirely custom. It would be interesting to build something like this integrating with standard Emacs features. For example, merge requests could show up in an orgmode agenda list, and reviewing the merge request could be done through a layer on top of magit. You could also go a step further and offer an orgmode-like interface for working with tickets/issues.<p>Outside of the text-based UI world, GitLab has a neat feature called Review Apps [0] that lets you preview branches/merge requests for web projects, but this takes things a step further by letting you make changes and run locally.<p>[0] <a href="https://about.gitlab.com/features/review-apps/" rel="nofollow">https://about.gitlab.com/features/review-apps/</a>
"Every branch of every repo gets its own sandboxed directory. Your revision history in each branch, including uncommitted stuff, is persisted, as are build artifacts. When you switch contexts, each project is just as you left it."<p>Isn't that just svn? Why force a git-shaped peg into an svn-shaped hole?
If you walked into an office and saw them using 1984 equipment — fax machines, landlines and Rolodexes — you'd think the company is hopelessly behind times.<p>Jane Street is a cutting-edge technology corporation, but their internal tools use 80*25 text-mode UIs just like the ones you'd find on a 1984 IBM PC/AT.<p>It's not the company's fault: we developers are stuck in the tar pit of an unfortunate local maximum with all these tools built around text streams printed into a window that emulates a late '70s terminal.
It sounds really cool but also very opinionated workflow. Not to say I don't agree with it but I can only imagine the amount of effort making this whole workflow was also what went into defining what that workflow was.<p>There are a lot of workflows and I personally don't think it's on an IDE to enforce that. Yeah sure it's "integrated" but it's to the extreme which I somewhat disagree with.<p>If their workflow and emacs scripts were open sourced, I could actually try it and watch my tongue but since it's all proprietary all I can really say is good for you, thanks for sharing but I probably wouldn't use it myself.
Visual Studio does everything within the same window (source code management, code review, diffs). Yes, it's great. It does not need any 'new' paradigm, that's the standard operating modus.<p>It's a good thing this ideology of tools that simplify the process is spreading. But it's not novel.<p>This article sounds like the author never used Visual Studio.
This is pretty cool. Although, on large codebases a la facebook or google size, I would think having a copy of the repo per branch might be intractable - also, somewhat unnecessary since one can just switch branches...
this is a HCI problem. I dont think text is better than IDE or web-based code review or branch management. I'm a vim user and i have to say making everything in one terminal looks cool but really not that intuitive..
Magit combined with Magithub already offers much of what's described in the article and there's a lot on the roadmap. Jonas and Sean are doing mindblowing, amazing work in these projects. I've seen many different UI shells for Git - everything else feels childish compared to what's possible in Emacs. I learned Git mostly by trial, error and reading man pages, but only after a few months of using Magit I've become truly dangerous.
> Code review happens entirely within the editor. You’re fed a series of diffs: one keystroke to approve, one keystroke to start editing. Dive in, make your changes, leave comments for the author, push, and move on.<p>But can the reviewer easily run the code they have just edited?<p>And does changing branches require a full rebuild?
come on! just another couple of years and we can have eclipse again
(I still miss the integration between the tasks, the revision system, the code and the autodeploy stuff I had in the '90 when I was a junior dev...)
This is cool, I guess. Personally coding in a terminal like window for me would be awful - I like using my mouse to navigate among folders and save stuff etc in Atom/VSCode like environments. Plus, how often are people switching branches of code that the number of key strokes for git becomes a problem? Seems like an overengineered solution for a very niche audience - if it works for them great though.
Programming like 1980!<p>At least has colors instead of having everything in green.<p>Really the extent people go to avoid using modern developer tools.