"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." Isn't that just svn? Why force a git-shaped peg into an svn-shaped hole?
I agree, that's pretty much SVN shoehorned onto a git workflow. With git there is no need to save branches into folders. At most, push feature branches to a remote repository and check them out when needed.
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. It's a good thing this ideology of tools that simplify the process is spreading. But it's not novel. This article sounds like the author never used Visual Studio.
Looks like the killer feature here wasn't doing everything from a single window. It was dedicating a sandbox per branch, saving everything, including uncommitted work and build artefacts.
This is the first time I hear of this functionality. And it would be great to do that even in a disintegrated way, like, from the command line.
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.
I agree. Another reasons why I prefer GUI are auto complete, tooltips and context menus. Also for some documents like xml, also when working with other people’s code, I find it useful to collapse/expand blocks of text. All these features pretty much require a GUI-based editor.
There doesn't seem to be anything about those features that makes them require a GUI.
e.g. I'm using ZSH specifically for it's command line autocomplete stuff. Emacs has helm for context narrowing and really good support for context menus. Vim will let you collapse/expand blocks of text including in XML using a mouse in a terminal window.
For spelling errors Vim will give you an straight red underline in the terminal and squiggly underline in its "GUI" versions. I assume that Emacs is the same.
I'm not suggesting you leave VS by the way. I'm just saying that your GUI only examples aren't GUI only.
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. 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. It's not the company's fault: we developers are stuck in the tar pit of an unfortunate local maximum with all…
Would you prefer a web app? Why?
No, HTML is limited in the same way as terminal emulation: it's not the right tool to describe UIs and interactions.
I'd like to see more progress made in real desktop interfaces.
So you got to the third bullet point on the first page, forgot the first two, stopped reading and decided to comment?
The charitable way to put that would have been "I don't see how the features you listed are related to to the first two bullet points". I might have misunderstood some technical nuance in the article but I could honestly use the exactly same statements as in the first two bullet points to describe my workflow with VS. This is not with Git though, so that might complexify the process. Maybe someone who is working with…
VS lets you save a sandbox per branch? May I ask since when? (The most recent version I have used was 2012).
I recently started using Emacs in a tiling window manager on Linux after using "standard" GUI editors like PyCharm, AppCode, Atom, VSCode, etc. on macOS. At first, I felt exactly like you describe - it felt so constraining not having a tree view and tabs I could click on. But after a while I got used to using a keyboard shortcut to quickly jump between files or search for a file to open. I'm slowly getting used to it…
> it felt so constraining not having a tree view and tabs I could click on There are emacs packages for tree views[0] and tabs[1], but as you note the built-in buffer management is more powerful. Stuff like Helm or Ivy is even better! There's also an emacs uuidgen package, which can generate a uuid & insert it with M-x uuidgen; you could of course bind it to a key sequence if you use it frequently. 0: https://github.…
Thous things are pretty much things to avoid in my opinion. I used to have NERDTree in Vim and all kind of other useless nonsense. After I learned how to use fuzzy searching to jump between files and definitions all tree view does is take up space.
Even with Atom finding files is way faster than clicking through the tree viewer.
"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." Isn't that just svn? Why force a git-shaped peg into an svn-shaped hole?
I'm glad that I wasn't the first (or second) person to notice this.
Admittedly, 99% of people are using git as a centralised source control system, and outside of branching/merging there hasn't been much of a change in workflow for many. I've not used their system, so I don't know how well this svn-like system works, but every time I think back to svn all I can think of is how painful this workflow was.
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. It's a good thing this ideology of tools that simplify the process is spreading. But it's not novel. This article sounds like the author never used Visual Studio.
You'd be surprised. Our domain has so much snobbery and elitism that it's entirely possible that a developer tried 1 (one) IDE, maybe decades ago, didn't configure it at all (or couldn't, at the time) and decided for all eternity that IDEs are bad. It's quite funny sometimes when you show someone modern functionality in a modern IDE and they have to accept that the people making IDEs are, basically, not all morons (w…
I recently switched over to Visual Studio Code and even though I previously had a bit experience with it, switching over was frustrating. It takes time to change your work flow, to set up the IDE as needed, to get plugins and what not fine-tuned.
Now I can't imagine working without Visual Studio Code because all those seemingly little features add up and what do you mean I can seamlessly use Git to manage my code or easily rename variables and functions without breaking stuff WHAT
The charitable way to put that would have been "I don't see how the features you listed are related to to the first two bullet points". I might have misunderstood some technical nuance in the article but I could honestly use the exactly same statements as in the first two bullet points to describe my workflow with VS. This is not with Git though, so that might complexify the process. Maybe someone who is working with…
VS lets you save a sandbox per branch? May I ask since when? (The most recent version I have used was 2012).
In my work I use VS with TFS as the source control. Each branch is in a separate directory, and one can store explicit change sets at any point in time as "shelve sets" without actually committing them into the repository. So there are the two hierarchy levels to experimentation - one can create a new parallel branch on the fly, or do experimentation on top of a branch using shelve sets. That's not explicitly a sandbox, but provides for most cases where one needs to experiment / have distinct development lines / put away random experiments etc. So, uh, depending where you need a sandbox the features may or may not exist.
"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." Isn't that just svn? Why force a git-shaped peg into an svn-shaped hole?