9

My team and I work on different networks. We don't have an internet connection nor do we share the same network. Thus the only way we can transfer files is using thumbdrives.

The only way I can commit to the remote Git repository is if I use my colleague's computer which has network access to the Git server. What commands do I have to run for me to fetch, merge, then push my commits onto her computer, short of transferring my entire working directory over?

Like, say transfer only the commits that the remote server lacks.

EDIT: I forgot to mention the thumbdrive might get wiped periodically as part of security measures. Remote repo on thumbdrive is still a pretty good idea though!

Cardin
  • 5,148
  • 5
  • 36
  • 37
  • 1
    In addition to other answers, use **bundles**; See [How to use git-bundle for keeping development in sync?](http://stackoverflow.com/q/3635952/124319) and the accepted answer. – coredump Jun 03 '15 at 08:21

3 Answers3

2

You can setup a git remote on a filesystem, so I assume if you mount your thumbdrive on their machine they could add you repo as a remote and merge in your changes

# Mount thumbdrive
# Add a remote to the filesystem
git remote add cardin_usb /Volumes/myusb # or whatever the usb path is

# pull in the changes
git fetch cardin_usb
# merge any branches as per normal eg
git checkout master
git merge cardin_usb/my_feature

Edit - just read you want to do the changes only. You could generate patches if you know the last commit the remote server has:

git format-patch lastServerCommit^..HEAD --stdout > new_changes.patch

Then transfer this via usb, and your coworker can submit.

acanby
  • 2,936
  • 24
  • 26
  • That sounds viable! But the thumbdrive might get wiped periodically, which would mean a need to reinit a remote repo on the thumbdrive. – Cardin Jun 03 '15 at 07:55
  • 1
    What about exporting a patch with all of your commits? I have updated my answer to cover this – acanby Jun 03 '15 at 07:56
  • Consider trying bundles before using patches; patches are going to result in big commits. – coredump Jun 03 '15 at 08:29
  • 1
    @Cardin This is a minor detail, but I am really curious about why would anybody wipe that thumbdrive periodically (btw, when it happens `git clone --bare` is easy to do, easier than dealing with patches manually). – coredump Jun 03 '15 at 08:31
  • @coredump: It's part of security measures. It's a shared thumbdrive so at fixed intervals the administrator will claim it back, wipe it. Btw how big are those patches going to be? Is it equivalent to as if I had pulled the commits? Versus bundle which I assume compresses the delta somehow, while still preserving commits? – Cardin Jun 03 '15 at 08:37
  • 1
    @Cardin (Security, well, I understand...) A patch is the equivalent of multiple commits being squashed together: all your small, atomic commits end up resulting in a single commit. This is not really about size, but about destroying the useful history that `git` enables you to create in the first place. What is exchanged by pull/fetch is already a bundle (the compressed delta, as you said). `git bundle` allows you to have your own way of transporting that data, in particular "by sneakernet" (see: http://linux.die.net/man/1/git-bundle). – coredump Jun 03 '15 at 08:52
  • @coredump: oh dang. I definitely wouldn't want to squash the commits (plus that sounds like it rewrites my repo history). `git bundle` should work, though conflicts would be extremely painful in cmd line without a GUI (i use SourceTree - it doesn't have `git bundle` supported) – Cardin Jun 03 '15 at 09:03
  • 1
    @Cardin I don't know SourceTree, sorry, but what if you only do `git fetch` to get your commits from a bundle, from the command-line? `fetch` should only update the branches: there is no conflict (yes, I am quoting Darth Vader). Then, SourceTree might be able to see that references are updated. – coredump Jun 03 '15 at 09:15
  • 1
    @coredump: Oh yeah, you're right, it could work! (That's part of why I love Git. Modify the same staging area in bash and GUI) – Cardin Jun 03 '15 at 09:41
2

In an addition you can create an ethernet network between your machines and using lan you can ssh each others machine and pull the changes.

for e.g git remote add xyz myuser@laptop:/path/to/repo.git git pull xyz abc

Pooja
  • 1,254
  • 14
  • 17
  • ethernet is interesting... But for my case it probably wouldn't help because it's a direct connection with no antivirus sitting in between - IT security would raise it as a concern. I'll still upvote your answer though, it might still be helpful for others! :) – Cardin Jun 03 '15 at 08:40
1

Your basic strategy should be to clone the repo on your local computer onto the thumb drive, setup the remote repository, and then push the repository from your coworker's computer:

On your computer:

git clone file:////192.168.1.1/yourbranch
git remote add myorigin https://path/to/remote/repository

On your coworker's computer:

git pull myorigin/yourbranch  (or git rebase myorigin/yourbranch)
git push myorigin yourbranch

I assume that the IP address of your coworker's computer is 192.168.1.1 although you will need to change this (type ipconfig from a Windows command prompt). This also assumes that you have a file yourbranch.git on your local machine which you are able to clone.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360