On Mon, 9 Jul 2012 00:11:40 -0700 (PDT)
Michel wrote:
[...]
> Now, using git, I clone the git repo to do some work.
> To be sure to have all files in my clone, I do a git checkout
> "special_tag_before_import" then I modify the above files, for
> example, and I commit them. The push says "Everything up-to-date"
>
> So, in my mind, I say : OK, the origin is not in the same checkout
> state... So, I do the checkout "special_tag_before_import" in the
> first git repo, and redo a clone like that
> In this 2nd clone, after commiting some "tests modifications", the
> push says "Everything is up to date"...
>
> So, where is my fault ?
The problem is somewhat complex to explain.
The idea is that Git has branches and tags, but while they all are
named references to commits, they differ in that when you check out a
branch and record a new commit, the branch pointer is updated to point
to that new commit. If you check out a tag and record a new commit,
the tag is (obviously) not updated, and since tags do not belong to any
branch, no branch pointer is updated as well. More precisely, when you
check out anything which is not a branch (you can happliy check out any
commit at all just by specifying its SHA-1 name), you end up being in
the so-called "detached HEAD" state: each time you commit, that commit
does not belong to any branch, and the only reference which points to
it is the HEAD reference.
That was the explanation of what happens when you commit in your
situation. Note that this situation is a bit dangerous as if you
decide to check out any branch while being in this "detached HEAD"
state, you will lose a convenient reference to your series of commits.
They will not be lost, but getting hold onto them will require some
extra work. So if you committed something valuable, consider running
something like
$ git checkout -b my_new_branch
at this point to turn your series of developments into a branch (more
details below).
The problem with push is largely unrelated to this one.
The behavior of Git when you push heavily depends on what you pass to
`git push` and how is your repository configured with regard to pushes.
First, you can tell `git push` precisely what to update on the remote
side with which series of local commits. For instance, you can do
$ git push origin HEAD:refs/heads/master
and that would make the "master" branch in the remote repo be updated
with what the HEAD in the local repository currently points at.
Second, if you call `git push` with just the name of a remote repo, like
$ git push origin
then Git figures out what to push by consulting the "push.default"
configuration variable [1] which defaults to the value "matching" which
means Git tries to push local branch "master" to remote "master", local
branch "foo" to remote branch "foo" and so on for all the local
branches [2].
Now, since your commits did not update any branch (above, I explained
why), your simple `git push ` has nothing to update the remote
side with--everything is exactly up-to-date.
Let's now consider how you should change your workflow.
The first thing you should do is to fork a branch off your
"special_tag_before_import" tag. Now you can check it out and be sure
any commit you do will move that branch forward. You can then push
that branch to the remote repo.
The second thing to do is to read a good book on Git to get firm hold
on the concepts. "Pro Git" [3] is highly recommended.
1. In fact it might be even more complicated as you can specify
per-remote rules for pushing.
2. Read the `git config` manual about the values the "push.default"
option might take and how they change the behaviour.
3. http://git-scm.com/book/
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/git-users?hl=en.
