https support?

[aaronbartell]

I didn't see it in the code and was wondering if https (tls/ssl) support exists for ungit?

I was basically wanting to start ungit and listen on a port with my supplied certificate.

[Ajedi32]

Ungit's primary use case involves ungit's "server" running on the same machine you're using it on, so HTTPS wasn't really a concern. You could probably add HTTPS though by serving Ungit through a reverse proxy like nginx...

[jung-kim]

So I don't think anybody uses it but ungit does have a primitive security feature that allows a set of ips. If you are concerned with security you can use that as an alternative.

And yes, https is more permanent and proper solution for this. It should be relatively easy for someone who have done this in express and socketio.

[aaronbartell]

Agreed ungit's original purpose was for local stuff. It is simply the best git UI I've used and so I am also starting to make use of it on the server-side (multi-tenant server-side developers).

I will see if I can put together the necessary code and produce a PR.

[Ajedi32]

Yeah, given the number of people who seem to want to use ungit this way, I actually think an "ungit on the server" approach might be something worth putting a bit more effort towards supporting.

One thing I'm a bit confused about though is why so many people seem to want to manipulate git repositories directly on the server. git's model normally revolves around users making changes locally then pushing those changes to the server, so why do so many people want to run ungit directly on the server itself? :confused:

Could you clarify your use case? I'm really interested in hearing why so many people want to use ungit this way.

[jung-kim]

I agree with @Ajedi32, that beauty of git is that it allows us in distributed computers independently from each other. Shared centralized development environment is something that we should runaway screaming. Also, having ungit running on each developer's computer is much easier now with recent implementation to packaging ungit with electron.

Now, getting back to the original issue of HTTPS, I do see arguments for HTTPS out side of this context as I'm one of those hippie paranoid developer and I would like to implement it soon. But it is not on the top of todo list.

[Ajedi32]

One possible application for this I could imagine is running ungit on a remote development server or VM that you're accessing via SSH. SSH is great for command line stuff, but not so good with GUIs. Running ungit on the server would allow you to get full GUI access to a remote git repository.

I'm not really sure if that's the use case people requesting these sort of features have in mind or not though. I got the impression that it was something else.

[aaronbartell]

One thing I'm a bit confused about though is why so many people seem to want to manipulate git repositories directly on the server.

Development in the browser/cloud is taking off\ and I've been using it for some time and like it a lot because it lessens the amount of time I, and my team, have to maintain a laptop dev environment. Instead I install each version of software (Ruby, Node, Git, Python, ungit, etc) on the server once for all developers to use. I still have a central git repo (BitBucket). I then do all of my work in my /home/aaron/git folder on the server and git push to Bitbucket.

\ http://bit.ly/browser-based-ide

Hope that makes sense.

Shared centralized development environment is something that we should runaway screaming.

I come from a IBM background (IBM i, fka AS/400) where development always occurred on the server and it was/is hugely efficient. The issue with doing that on Linux/Unix is having the right boundary management in place (i.e. Docker) so developers don't step on each other's feet.

[Ajedi32]

Ah, so it is similar to the scenario I imagined. And yes, I agree that's certainly a reasonable use case.

On a side note, I prefer to do development on a configuration managed VM, not a central server. That has the advantage of allowing you to just rebuild the VM if you mess up your environment, and it doesn't require a network connection, while still giving you the benefits of a single unified development environment shared by all developers.

[Lennie]

Here are some more use cases when files are created 'remotely' on some server:

1. Keep your website in a git repo:
2. For example Wordpress automatically downloads and installs (security) updates. So you keep all the files of the production site in a git repo. So you can keep track what was changed (with git and git history you can be pretty sure your website wasn't changed by some third-party like for use in a phishing attack without you noticing what was changed).

This is why I created my own little tool in the past: https://github.com/lennie/git-webcommit

1. For some type of work building completely new environments for everyone just takes to much time or just costs to much because of the size of the environment.
2. For example when creating automation scripts for deploying infrastructure. You might have to deploy multiple new VMs (this takes a lot of times, maybe no room for that many VMs on your local machine) or even re-image physical machines. You are probably working on a small part and can destroy and redeploy that small part each time, but you need the larger environment to be able to even test your modified code. This means you are working remotely, logged in to a server. So you want to commit where you are logged in. Then when you have some certainty that the code works because you've redeployed the small part multiple times and fixed most of the bugs; you push your code to the remote repo and redeploy the whole thing and see if that small part works as part of the whole.

Pretty certain there are other use cases where source files are created remotely and maybe some people keep other stuff in git repositories.

Files on servers change and people want to keep them in git, deal with it. ;-)

Anyway, I think just having a good nginx tutorial or example config might be enough.

[jung-kim]

Files on servers do change and people may want to keep them in git. And git deals with it via allowing you to synchronize with remote git via pull, check out or other methods. What I have hard time understand is why would multiple people modifying source code on a single shared sever via whether that is done with git or not. Multiple people modifying and working on same files in a server is the exact problem git is helping you not to do as it can cause terrible problems.

Frankly, I really don't care whether you practice this discouraged practice or not. All I'm trying to say is that git is a distributed source code control system. No body is going to stop you from use it in a centralized server somewhere despite it being distributed nature. But do understand if development efforts for Ungit are focused on the distributed part as I believe it should stay true to the nature of git.

[aaronbartell]

What I have hard time understand is why would multiple people modifying source code on a single shared sever via whether that is done with git or not. Multiple people modifying and working on same files in a server is the exact problem git is helping you not to do as it can cause terrible problems.

There's lots of separation on the server from one user to the next. This can be done with a variety of methods including Docker, chroot, permissions, etc. In short, every developer logging into the server has a separate git repository they are working with.

[Lennie]

Yes this is a single user working in the same environment at the same time. Just is that the environment is on a some server, not local.

[jung-kim]

I can understand such use case and I don't have any problem with that. Not that anyone ever need my opinion or should care about my opinion.