A git flow for single-user development on multiple machines

[Mario F.]

I've moved recently to git and am trying to decide how to best take advantage of it in the following project scenario:

- Single user development
- Development happens anytime on one of three computers
- These computers don't connect to a common network
- Project sources are moved between computers on a pen drive

Currently I'm copying the project .git folder along with the sources into the pen drive. But I don't want to risk corrupting my git repository elsewhere if by chance the copy happens with silent errors.

I don't want to use the pen drive as a central repository either. For the same reasons. But I need to share the git repository between all three computers.

[laserlight]

Currently I'm copying the project .git folder along with the sources into the pen drive. But I don't want to risk corrupting my git repository elsewhere if by chance the copy happens with silent errors.

I don't want to use the pen drive as a central repository either. For the same reasons.

But you won't get silent errors if you merge from or rebase onto the pen drive central repository and test, then push to the pen drive central repository.

[manasij7479]

AFAIK, git does a lot of hashing and checking to see if there are errors.
Can you force an error that can not be detected by a 'git status' ?

[phantomotap]

Currently I'm copying the project .git folder along with the sources into the pen drive.

But I don't want to risk corrupting my git repository elsewhere if by chance the copy happens with silent errors.

O_o

You should stop doing things by hand.

Copy-To-USB): Use `git' to publish--merge/whatever--to the pen drive as a repository.

Copy-From-USB): Use `git' to subscribe--pull/whatever--from the pen drive to your active machine.

[Edit]
Yikes. Twice in five minutes...
[/Edit]

Soma

[Mario F.]

Ok. I think I'm getting the hang of it. Thanks.

[Codeplug]

I use bitvise ssh server to host my "central" git repo's. If anyone wants the settings to use, let me know.

gg

[brewbuck]

Here's the pattern I would use:

At the end of a work session, "git clone" your repo from the workstation onto the USB stick.
At the beginning of a work session, "git pull" from the USB stick to the repo on the workstation (if it's a different workstation than last time). Then DELETE the repo off the USB stick.

I would absolutely not copy .git folders to and fro.

BTW, I solved this problem for myself by installing GitLab on one of my cloud instances. It's like my own private GitHub, complete with merge control and issue tracking.

[laserlight]

At the end of a work session, "git clone" your repo from the workstation onto the USB stick.
At the beginning of a work session, "git pull" from the USB stick to the repo on the workstation (if it's a different workstation than last time). Then DELETE the repo off the USB stick.

What's your rationale for always doing a git clone and "DELETE the repo off the USB stick"?

[phantomotap]

Then DELETE the repo off the USB stick.

O_o

A protocol which asks that I delete a valuable backup is not a protocol to which I will agree.

Using "git" will ensure, hopefully, that you don't override good data with bad.

However, "git" doesn't do silvering. If the local data is even a little trashed, you can't restore with a `git' command.

[Edit]
Depending on which bits get corrupted, you could recover some objects from the repository by looking through the history.

Why go through the trouble when you could just keep an extra copy around?
[/Edit]

Soma

[Mario F.]

Ok. ermm...

To be clear, if I clone the repo, make changes to the copy on the same branch and commit, I cannot push the changes to the origin? I'm getting:

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.

How exactly do I push my changes to the USB pen origin after a day's work on my remote repo?

[brewbuck]

What's your rationale for always doing a git clone and "DELETE the repo off the USB stick"?

Because Mario said "I don't want to use the pen drive as a central repository either."

Blowing it away is a good way to ensure it doesn't acquire a significance of its own beyond being just a transfer medium.

If it were my personal problem, I'd definitely leave the repo on the stick.

[brewbuck]

Ok. ermm...

To be clear, if I clone the repo, make changes to the copy on the same branch and commit, I cannot push the changes to the origin? I'm getting:

What origin? I thought you had three dev machines, each of which is equivalent. The "origin" is the "authoritative" respository. You claim you don't have one.

Make sure you are distinguishing between the concept of the "remote" and the "origin." Your setup has no origin, but you are tracking various remotes.

[brewbuck]

O_o

A protocol which asks that I delete a valuable backup is not a protocol to which I will agree.

There are already four copies of the repo, how many more should we add? Another 15?

Using "git" will ensure, hopefully, that you don't override good data with bad.

To me this looks like a matter of policy, not a question about the reliability of a memory stick. If the policy is that the stick is just a sneakernet cable, then leaving the repo on the stick gives the wrong impression of the actual policy.

[laserlight]

To be clear, if I clone the repo, make changes to the copy on the same branch and commit, I cannot push the changes to the origin? I'm getting:

The error message means: you have a working tree in the destination repository and that could be problematic, so we're not letting you push unless you get rid of the working tree or insist that we allow the push anyway.

A quick search brings up Git bare vs. non-bare repositories for your reading pleasure. There's an example towards the end of how you could initialise a bare repository, so you could try doing that on your USB stick. Alternatively, you could try the configuration options mentioned in the error message to proceed anyway.

EDIT:

Because Mario said "I don't want to use the pen drive as a central repository either."

Blowing it away is a good way to ensure it doesn't acquire a significance of its own beyond being just a transfer medium.

Right, but that was stated "For the same reasons" as why Mario F. did not want to copy .git directories around. Since the reasons do not actually apply, I reasoned that this requirement does not necessarily apply either.

There are already four copies of the repo, how many more should we add? Another 15?

There will always be one copy in the USB stick whenever it is not plugged into a computer.

[Mario F.]

I read the file, thanks laserlight. The whole bloody terminology and workflow of this stupid tool (git) is giving me an headache.

Look, I'll dig deeper into git later. This is just nonsense a waste of time. I need to get to work, not to struggle with this thing. I'll follow brewbuck advice for now, until I get a hang of git. He presents a much straightforward way to just get things done. I just need to keep my commits synced between the laptop while travelling, my computer at the office and my main development computer at home.