4 ms·

I was at Google when they implemented something like this in their source code viewing system. If you see a typo in a comment, for example, you click the pencil

by zellyn 9y ago

I was at Google when they implemented something like this in their source code viewing system. If you see a typo in a comment, for example, you click the pencil icon on that line, which pops open an editor with your cursor on that line, fix the typo, and can create and submit for review a pull request right there. Less than a minute. It is fantastic. I'm so glad Gitlab is providing competition to Stash and Github. Nice work.

segmondy 9y ago
Someone in my twitter feed was just asking for this feature last night. I don't want to open an editor, checkout, fetch, edit, commit, push, open a PR to a PR when I can just do it in an editor. I don't use Gitlab but I agree, it's a brilliant feature.
- sytse 9y ago
  Thanks! There is a place for web editors (quick edits, new projects) and local editors (working on the same codebase for a longer time). As warned against we don't want to fall in a rabbit hole of spending all our time on this instead of the other parts of our complete DevOps vision https://about.gitlab.com/2017/10/11/from-dev-to-devops/ https://about.gitlab.com/2017/10/11/from-dev-to-devops/ (logs, roadmaps, create project on push, binary repository, incremental rollouts, tracing). Therefore we based the web IDE on the awesome VScode. This means that it is a doable effort to maintain it.
  - Create 9y ago
    Hi! It would be nice to see burndown charts in CE along with EBS[1], just like pipelines and runners. [1] http://help.fogcreek.com/7676/evidence-based-scheduling-ebs http://help.fogcreek.com/7676/evidence-based-scheduling-ebs
    - connorshea 9y ago
      See our Stewardship page[0] for how we determine what goes in EE vs. CE, for now Burndown Charts will stay in EE. As for EBS, feel free to open an issue for it[1] since I couldn't find one :) [0]: https://about.gitlab.com/stewardship/ https://about.gitlab.com/stewardship/ [1]: https://gitlab.com/gitlab-org/gitlab-ee/issues https://gitlab.com/gitlab-org/gitlab-ee/issues
- vog 9y ago
  This is not so much an argument for a Web IDE. It is an argument against the cumbersome Git workflows, and the even more cumbersome GitHub Pull Request workflow on top of that. Why can't I fix the typo in my editor, hit "upload", enter some commit message and be done with it?
  - mastax 9y ago
    > Why can't I fix the typo in my editor, hit "upload", enter some commit message and be done with it? You can do this, if you have permission from the repository and have a local up-to-date clone already. I suppose it would be nice to be able to create a PR to someone elses repo without needing to fork first. I don't see any other reasonable way to make this easier.
  - zellyn 9y ago
    I'd respectfully disagree. In a monorepo the size of Google's (or even Square's, where I work now), there would be a whole schlep to open the file in your editor. Much better to fix right there where you're browsing. Also, at Google, it's not even Git, or a Git/Github workflow.
    - vog 9y ago
      Please respect the context of a comment, and refrain from strawman arguments. This was not about whether or not this feature is good for the Google repo (of course it is, nobody disputed that!). This was about whether and how to apply this to other projects.
      - zellyn 9y ago
        Please respect the fact that some of us actually read comments and reply to them thoughtfully. Throwing around trite accusations of “strawman” arguments doesn't help anything. The comment I replied to was claiming that it was the git workflows (I assume for submitting, but am open to correction) that make this cumbersome. I was pointing out that in an enormous repository (and I did mention my current employer as an example too -- and we use Git, not Google's internal tooling), just getting to the point of having the latest version of some far-flung file that you usually never touch open in your editor is cumbersome enough to make this feature a win, regardless of whether the workflows for submitting the change disappear altogether.

by zellyn 9y ago

segmondy 9y ago

Someone in my twitter feed was just asking for this feature last night. I don't want to open an editor, checkout, fetch, edit, commit, push, open a PR to a PR when I can just do it in an editor. I don't use Gitlab but I agree, it's a brilliant feature.

sytse 9y ago
Thanks! There is a place for web editors (quick edits, new projects) and local editors (working on the same codebase for a longer time). As warned against we don't want to fall in a rabbit hole of spending all our time on this instead of the other parts of our complete DevOps vision https://about.gitlab.com/2017/10/11/from-dev-to-devops/ https://about.gitlab.com/2017/10/11/from-dev-to-devops/ (logs, roadmaps, create project on push, binary repository, incremental rollouts, tracing). Therefore we based the web IDE on the awesome VScode. This means that it is a doable effort to maintain it.
- Create 9y ago
  Hi! It would be nice to see burndown charts in CE along with EBS[1], just like pipelines and runners. [1] http://help.fogcreek.com/7676/evidence-based-scheduling-ebs http://help.fogcreek.com/7676/evidence-based-scheduling-ebs
  - connorshea 9y ago
    See our Stewardship page[0] for how we determine what goes in EE vs. CE, for now Burndown Charts will stay in EE. As for EBS, feel free to open an issue for it[1] since I couldn't find one :) [0]: https://about.gitlab.com/stewardship/ https://about.gitlab.com/stewardship/ [1]: https://gitlab.com/gitlab-org/gitlab-ee/issues https://gitlab.com/gitlab-org/gitlab-ee/issues
vog 9y ago
This is not so much an argument for a Web IDE. It is an argument against the cumbersome Git workflows, and the even more cumbersome GitHub Pull Request workflow on top of that. Why can't I fix the typo in my editor, hit "upload", enter some commit message and be done with it?
- mastax 9y ago
  > Why can't I fix the typo in my editor, hit "upload", enter some commit message and be done with it? You can do this, if you have permission from the repository and have a local up-to-date clone already. I suppose it would be nice to be able to create a PR to someone elses repo without needing to fork first. I don't see any other reasonable way to make this easier.
- zellyn 9y ago
  I'd respectfully disagree. In a monorepo the size of Google's (or even Square's, where I work now), there would be a whole schlep to open the file in your editor. Much better to fix right there where you're browsing. Also, at Google, it's not even Git, or a Git/Github workflow.
  - vog 9y ago
    Please respect the context of a comment, and refrain from strawman arguments. This was not about whether or not this feature is good for the Google repo (of course it is, nobody disputed that!). This was about whether and how to apply this to other projects.
    - zellyn 9y ago
      Please respect the fact that some of us actually read comments and reply to them thoughtfully. Throwing around trite accusations of “strawman” arguments doesn't help anything. The comment I replied to was claiming that it was the git workflows (I assume for submitting, but am open to correction) that make this cumbersome. I was pointing out that in an enormous repository (and I did mention my current employer as an example too -- and we use Git, not Google's internal tooling), just getting to the point of having the latest version of some far-flung file that you usually never touch open in your editor is cumbersome enough to make this feature a win, regardless of whether the workflows for submitting the change disappear altogether.