git setup for a single developer?

Question

Hello,

I often need to develop stuff on the road, with no internet/network connection. I am only a single developer, so until now I simply had a SVN repository on my machine and did a checkout on my laptop when I went away. Problem: That gives me no Source Control on the road.

So I tried out changing to git, which seems to do what I want, but I am not sure I understand properly how it's supposed to be used in my setup.

Essentially:

• Created a repository on \myserver\share\project using git init
• Cloned that repository to machine 1 using git clone
• Cloned that repository to machine 2 using git clone
• Worked on machine 2, using git commit to commit any changes to my local repository
• Finally used git push to push all changes back to \myserver\share\prohect
• Used git pull on machine 1 to get newest changes from \myserver\share\project

That works, but the git push command gives me a warning saying that pushing the checked-out branch is not supported as it may confuse the index. Now, I'm confused, because the message was also written in a serious tone, which means that I should possibly honor it (and indeed, gitk shows that I now have two branches: master and remotes/origin/master), but I do not fully understand the terminology yet.

What would be the correct steps in my situation?

• I will only ever work on machine 1 OR machine 2, never on both
• I intend to use branching as a way to have a separate branch for bugfixes/tests (just like in the usual way), but not as a way to have multiple developers
• I really mainly want to use it as an alternative to rsync my SVN.

Edit: There are two oddities. The first one is if I simply change a file, it says "Changed but not updated". which is weird:

# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   myproject/Readme.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

The second message is the one that I think is the culprit, the output of git push:

warning: You did not specify any refspecs to push, and the current remote
warning: has not configured any push refspecs. The default action in this
warning: case is to push all matching refspecs, that is, all branches
warning: that exist both locally and remotely will be updated.  This may
warning: not necessarily be what you want to happen.
warning:
warning: You can specify what action you want to take in this case, and
warning: avoid seeing this message again, by configuring 'push.default' to:
warning:   'nothing'  : Do not push anything
warning:   'matching' : Push all matching branches (default)
warning:   'tracking' : Push the current branch to whatever it is tracking
warning:   'current'  : Push the current branch
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 333 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
warning: updating the current branch
warning: Updating the currently checked out branch may cause confusion,
warning: as the index and work tree do not reflect changes that are in HEAD.
warning: As a result, you may see the changes you just pushed into it
warning: reverted when you run 'git diff' over there, and you may want
warning: to run 'git reset --hard' before starting to work to recover.
warning:
warning: You can set 'receive.denyCurrentBranch' configuration variable to
warning: 'refuse' in the remote repository to forbid pushing into its
warning: current branch.
warning: To allow pushing into the current branch, you can set it to 'ignore';
warning: but this is not recommended unless you arranged to update its work
warning: tree to match what you pushed in some other way.
warning:
warning: To squelch this message, you can set it to 'warn'.
warning:
warning: Note that the default will change in a future version of git
warning: to refuse updating the current branch unless you have the
warning: configuration variable set to either 'ignore' or 'warn'.
To file:///\\myserver\share\project
   129649b..1f4b957  master -> master

So it tells me that "pushing into the current branch" is not recommended, but I don't really get what the proper way of doing this is.

Answer 1

Otherwise seems good, but to avoid the error message you can setup the "upstream" repository as an empty repo, i.e. one that does not include a checked out copy. You do this with

git --bare init

See e.g. this example

Answer 2

The git push command requires you to specify a refspec, else you will have to edit .git/config to specify the default action in the case of no refspecs being specified. For example, consider the scenario where you have the branch named master.

For pushing the master branch, you will:

git push refs/heads/master:refs/heads/master
git push master:master
git push master

All of the above are same. The refspec looking like a path is the most unambiguous way to specify a refspec. That way, you can be sure that you are referring to the branch named master instead of the tag named master.

Otherwise, you can edit .git/config and add:

[push]
    default = matching

This would allow you to just git push, and Git will push to the remote branch of the local branch you are currently in. For example, if you are currently in branch master, git push will push the local master branch to the remote master branch.

As has been stated by janneb, you will have to use a bare repository inorder to push to it without a warning. The issue with pushing to a normal (not bare) repository is that, the primary owner (of the particular `normal' repository) will not be wanting changes added to his/her repository. At that time, if someone pushes to this repository, and deletes a branch (or any other changes), the owner will not have expected such a change. Thus, the warning.

Answer 3

You seem to have good answers to your main question, so I'll tackle this:

... if I simply change a file, it says "Changed but not updated". which is weird ...

Git, unlike every other version control system ever, requires explicit user action to include modified files in the set of things to be committed next. You have to say

$ git add <your modified files>

after editing them and before doing git commit. I have the impression that this is to make it easier to selectively commit only some of your modifications.

If you do the "git add" and then modify the files, you have to do "git add" again or it'll only commit the changes up to the point of the first "git add".

There is a shortcut, git commit -a, but it does not provide the same semantics as the commit operation in other version control systems - it adds all your modified files and all your new files, and then commits. This is usually Not What You Want, in my experience.