Rod McLaughlin

Correction to "When Git lies to you" (11 aug 13)

If you search the web, you'll find I'm not the only user to accuse the Git source control program of lying.

The solution I gave in the above post is wrong. This is the real solution:

git push $1 HEAD:$1 # where $1 is the name of the remote repo (probably the name of current dir)

Although Git IS the best version-control system ever, it's not exactly intuitive to the average geek.

If I don't specify HEAD, isn't it obvious that's what I mean? But Git was written by the creator of Linux, for whom nothing like that is obvious at all. Torvalds and team branch and merge several times daily.

Here's the experience of a normal user:

You have two computers
From the first one, you copy an entire .git folder to the second
On the first computer, you add that remote folder with 'git add remote'
You check it out
You do a local change, and 'git commit -a'
Then 'git push'
It says 'everything up to date'
It doesn't say what is up to date, but local and remote repos can't both be up to date, because they differ
But if you do
'git remote add reponame me@myothercomputer:reponame'
'git push reponame HEAD:reponame' 
it'll push your changes into the remote repo

Here's Linus Torvalds explaining Git:

One more thing. Suppose you have made a local change, commited it, and pushed it to the remote repo as describe above. You then pull the remove repo to another folder, like this:

git clone me@myothercomputer:reponame
cd reponame
git log | less

and you are surprised to see the topmost commit is older than the one you just commited to the remote repo

If your latest commit number is 'abc123', you can cd into the newly checked out repo, then

git checkout abc123


git log | less

will tell you you have the latest checkin. In fact, you had it all along, since you cloned it, but you hadn't checked it out! Obvious, huh? To Linus Torvalds...

A clear explanation of the advantages of Git (and other distributed version control systems) is here:


Portland London