Doing a git clone within a LAN without Internet

On the laptop where the repo to be clone is hosted, we run the command git daemon from the terminal.

Sample command on the HOST:

 $ git daemon --base-path=<path_to_folder_containing_project_folder> --export-all --verbose  

<path_to_folder_containing_project> is the folder containing your projects folders, it will provide all projects under that folder. You're basically looking for the project folder containing the .git folder.

The client:

 $ git clone git://<local ip>/<project name>  

It's that easy but do note that the cloned repo's origin will be pointing to the HOST IP, so you need to use git remote set-url origin to point it to a different IP or origin. 

We might want to run git daemon with the --verbose option to get more details in case we run into problems.

If we are getting connection problems, you might have to check Firewall settings to allow the connection.

Reference

* https://stackoverflow.com/questions/5200181/how-to-git-clone-a-repo-in-windows-from-other-pc-within-the-lan

Keeping a Forked Repo up to date

Keep your fork up to date by tracking the original "upstream" repo that you forked. To do this, you'll need to add a remote:

# Add 'upstream' repo to list of remotes
git remote add upstream https://github.com/UPSTREAM-USER/ORIGINAL-PROJECT.git

# Verify the new remote named 'upstream'
git remote -v

Whenever you want to update your fork with the latest upstream changes, you'll need to first fetch the upstream repo's branches and latest commits to bring them into your repository:

# Fetch from upstream remote
git fetch upstream

# View all branches, including those from upstream
git branch -va

Now, checkout your own master branch and merge the upstream repo's master branch:

# Checkout your master branch and merge upstream
git checkout master
git merge upstream/master

If there are no unique commits on the local master branch, git will simply perform a fast-forward. Now, your local master branch is up-to-date with everything modified upstream.

Gracefully dealing with different SSH keys for different domains or accounts

This problem often happens when you mix your personal ssh keys along with your company's and you work off a single workstation or laptop.

Even if the user and host are the same, they can still be distinguished in the ~/.ssh/config.

Host gitlab.com
  HostName git.company.com
  User git
  IdentityFile /home/whoever/.ssh/id_rsa.alice
  IdentitiesOnly yes

Host kitlab.com
  HostName git.company.com
  User git
  IdentityFile /home/whoever/.ssh/id_dsa.bob
  IdentitiesOnly yes

Then you can use gitlab.com and kitlab.com instead of the hostname in your git remote.

git remote add g-origin git@gitlab.com:whatever.git
git remote add k-origin git@kitlab.com:whatever.git

You probably want to include the option IdentitiesOnly yes to prevent the use of default ids.

Ref: https://blog.developer.atlassian.com/different-ssh-keys-multiple-bitbucket-accounts/

Azure Cloud, an annoying mess of random errors & warnings

Context: We recently moved to Azure from AWS. We did this for business reasons. It's been about 2 months since we moved.

This would have not been a big deal if Azure wasn't a buggy P.O.S mess.

A few examples:

1. Random errors when completing a merge request. What the fuck is Status Code 0: error error?

Status code 0: error error? #WTF

2. You use Git flow? Well MS says 'fuck you'. You can't complete Pull Request from the command line. Doing a git flow feature finish from a CLI, Azure will mark your PR as abandoned unlike the other services. AND THEY EVEN HAVE THE BALLS TO CALL IT A FEATURE!! F!*@*#!@#(*!!!!

3. Random Status code: 200 errors when using the Azure CLI to do stuff. But when you do the same thing with the SLOW AS ASS web app console, no error. If you're a devops guys, do you feel safe?

4. RESOLVING MERGE CONFLICTS IS ASS BACKWARDS!! If a PR will be marked as conflict, you have to pull the PR branch and attempt local merge to see the conflict. You will not find the conflicts in the File viewer.  WHAT. THE. FUCK.

The take away is unless the cost savings is significant, really significant, move to Azure otherwise don't. Personally, I'd rather pour gasoline over my laptop and setting it on fire rather than use Azure for my projects EVEN IT WAS FREE.

Azure Cloud, an annoying mess of random errors & warning and things not working as expected.


Edit. Ironically, the day when I put up this post, I ran into #4.

Random quirk with Windows, Git and an executable Bash script

The context of the problem was that I was making a Docker container with Linux image. It's to be deployed to a cloud service and I'm working from Windows machine. Of course the container would need code to run. To facilitate this, I wrote a basic bash script - scrape.sh.

On Windows, the scrape.sh file already is executable

For disclosure, I'm working with Scrapy here.

From my Windows terminal, the scrape.sh script seems to be already executable. I thought I was fine and I did the whole git cycle of add, commit and push.

The problem shows up when the container tries to run. It will spit out an error saying that it can't execute the scrape.sh script because it's lacking rights. It seems that git commits my bash script as an ordinary file not as an executable despite what I saw on the Windows terminal. The fix though was quite easy.

$ git add --chmod=+x -- afile
$ git commit -m"afile is now executable"

Relevant link:

• Stackoverflow
• Git-docs

Cleaning up your local repo from too many dead branches

You'll eventually have too branches in your local that's untracked - ex. Not in origin or Github. This gets annoying since too many of these branches are often dead. So time to prune them:

git remote prune origin

You would assume that would work but nope. This only works on the remote repo and not your local. But you can to do this:

git branch --merged master | grep -v '^[ *]*master$' | xargs git branch -d

This is uncomplicated since this just soft deletes all branches that are already merged - the -d flag in git branch.

But if you need to check against the remote repo then a more complex command is called for:

git branch -r | awk '{print $1}' | egrep -v -f /dev/fd/0 <(git branch -vv | grep origin) | awk '{print $1}' | xargs git branch -d

The only rub here that is only works on bash or zsh shells. Also you need to run git fetch --prune first because using this.

Powershell

git checkout master; git remote update origin --prune; git branch -vv | Select-String -Pattern ": gone]" | % { $_.toString().Trim().Split(" ")[0]} | % {git branch -d $_}

Reference:

• https://stackoverflow.com/questions/13064613/how-to-prune-local-tracking-branches-that-do-not-exist-on-remote-anymore/16906759#16906759

Git aware prompts for Windows just like in Bash

At work, I use a bash terminal. It's git aware so it looks like this:

My bash prmpt

It shows the current branch and color codes the status of the repo among other things. If you want the settings, you can get the gist for it.

At home, I work with Windows. I know I can get a bash shell running on Windows but I wondered if there's a same thing for the Windows terminal.

The first thing I learn is that Windows has two terminals, the ordinary cmd.exe thing and a much more powerful thing called Powershell. Powershell can do what cmd can do and much more. Powershell is more of a platform rather than just a window to issue commands.

Which then lead me to posh-git. At default settings, it just changes your prompt to be git-aware. For example:

C:\Users\jaypax\projects\posh-git [master ≡ +0 ~1 -0 !]>

It's not exactly like my bash prompt but it's close. I might be even convinced it's better with a little tweaking.

I got to say it's pretty nice but don't take my word for it. Take it for a spin.

Dealing with outdated or abandoned pypi modules with VCS install

So I was using a small, simple but working Paypal module which unfortunately was forgotten or abandon by the original author. It was working on my Django 1.5 site up until I needed to upgrade to Django 1.10 because of the other modules. Also for security and stability reasons but that's another story for another time.

Fortunately, this Paypal module wasn't "super" broken. The errors were just a couple of lines in the templates and a function named patterns() from django.url.conf - urls.py.

This leads into a couple of solutions:

1. I could copy-pasta the code and turn it into a internal django app with the fixes.

2. I could fork it, fix and then setup by own pypi server.

3. I could find out if someone fixed this already and take it from there.

Of course, I'd pick #3 - Programmer. So, lazy. Look it up.

I was lucky to found out that someone has fixed all the issues and got it running on Django 1.10. All that's left is to fork his repo and install it into my virtual environment.

It's simple because pip already supports installing modules from a VCS.

$ pip install git+https://github.com/killertilapia/fixed-forked-project

If you need install a certain branch do this instead

$ pip install git+https://github.com/killertilapia/fixed-forked-project@branch

This also works with other VCS like Mercurial (hg+https), Bazaar (bzr+https) or for-fuck-sakes why! - SVN (svn+https).

Using git push to deploy code to DigitalOcean

There'll be times using a continue integration server or stack is a big pain in the butt. Sometimes we just want to type git push from the terminal and the live app is updated. This is that tutorial although specific to DigitalOcean. I'll bet it will roughly work the same for other cloud services.

Assumptions

• You have a Digital Ocean server (or droplet) running and configured
• You have the ssh to said droplet working

So ssh to the droplet and then navigate to /var/www (or anywhere else you want to put your code) and make two directories:

$ mkdir liveapp.com && mkdir appcode.git
$ cd appcode.git

Inside the appcode.git folder we will create a "bare" git repository: git init --bare
A bare git repository doesn't contain our code but rather the internals of the .git folder. The whole point of this is to access the hooks folder within.

The hooks folder have scripts that can be run at certain steps within the git repo's lifecycle. We want a hook script to run after we "receive" a push to this repo. Hence we create a post-receive file inside the hooks folder.

$ vi post-receive

# Type this in

#!/bin/sh
git --work-tree=/var/www/liveapp.com --git-dir=/var/www/appcode.git checkout -f

# save and exit
# make the post-receive hook executable

$ chmod +x post-receive

There! We are done for the server side. We move to the our local machines.

All we actually need is need is to add a remote target in your working git repo. Assuming you added the droplet in your local ssh config then the command should be look like:

$ git remote add droplet ssh://user@ip-of-droplet/var/www/appcode.git

# add a new commit - this will not work even if you existing commits
# you must have a new commit
$ git add .
$ git commit -m "new commit"

# push to repo - could be github or bitbucket
$ git push

# push to droplet
$ git push droplet master

If all goes to plan, then our code will show in our new "git work tree" which is the liveapp.com folder inside our droplet.

A couple more thoughts:

1. It's fairly easy to setup a sort of staging or testing folder/area with this.
2. The post-receive script can do more things like a "restart app" or send mail to admin for notification. It's just a bash script.