Search code examples
gitdvcssmartgit

GIT GUI for solo project: Windows PC for development, but git + active, working project repo on a LAN headless linux server?


I just installed git for the first time for a solo project -- and now I don't know how I lived without version control for so long. I wanted to see if maybe a GUI would be helpful, but I have a problem...

  • My development machine is running windows
  • The project is on a headless linux server on the LAN
  • Project directories are shared through samba and mapped as network drives on the windows pc
  • I am the only one using this server, so there's no need to clone the repo to the windows pc
  • If I use git through SSH none of this is a problem at all

The GUI git clients I've tried so far all assume I'm running git on the machine I install them on, though. If I try to operate on the linux-hosted repo with widnows-installed git, it's (not unexpectedly) slow as molasses and seems to have compatibility issues.

Is there any way to make this work for smartgit? Or any other decent client?

I did install gitweb, which seems nice enough to look through project history, but I can't actually 'do' anything with it.

EDIT: If I could maybe broaden this question and just ask for a word of advice on how to proceed, ie: suck it up and use Putty with something else for visualization, clone the repo and push/pull, or do something different like svick's X Server suggestion.


Solution

  • Okay, I'll be marking my own answer correct for clarity and not vanity, to hopefully help someone caught in a similar predicament. I hope no one will be offended.

    As, a side note, after coming up with a working solution, I still ended up using SSH and a drive-mapped shared linux directory for development, but it's useful to have a local place on the windows machine to put a working repo. GIT is just slow as molasses on windows for me no matter what, so I'll be using it that way as little as possible -- but that's just me.

    If your bash-foo is weak like mine, webmin can help with the below. So here's what I ended up doing:

    Summary:

    • Web-based project (LAMP stack in my case)
    • Solo developer
    • 1 Windows pc used for development
    • 1 headless linux server to host the stack and the project

    Purpose:

    • Set up a working repo locally on the windows PC to enable efficient use of git GUI clients, etc without having to make a whole working stack or commit and push to see what the hell just happened. PHP on windows sucks (yes, yes, more than usual har har), and so do a lot of other things.

    Solution upside:

    • No need to duplicate the LAMP stack on the windows machine, or screw with the database to have a working local repo
    • Preview your changes in real-time without having to commit or push

    Solution downside:

    • Local (windows) repo only functional if computer is on the network
    • You might see a bit of network latency due the loopty-loo nature of what's happening here

    Prerequisites:

    • Static or MAC based IPs for both the windows and linux machines
    • git, BIND, Samba, Apache (or similar) on the linux box
    • SSH client (Putty?), msysgit, git GUI of choice (gitextensions/smartgit/gitgui) on the windows box

    What to do:

    1. Set up a shared directory on the windows box for the repo
    2. Mount this directory on the linux box
    3. Point BIND to the linux box's own IP for your two domain (eg: myproject.lin and myproject.win) -- (apologies for the fake tlds, but use your own discretion here)
    4. Make the linux box your dns resolver for either the windows box or your network router
    5. Set up two domain-based servers in Apache (the ones above) and direct them to the appropriate locations (eg: '/mnt/windows-pc/myproject' and '/var/www/myproject')
    6. Make sure your application configuration can map relative paths for obvious reasons
    7. Samba-share the linux repo and maybe map it as a windows network drive for convenience
    8. Clone your linux box's repo to the windows directory
    9. Push changes as needed back to the linux shared project directory

    To further complicate what probably hardly needed any explanation here is a (simplified) diagram: something to do with pants i thinks