On Mon, 9 Jul 2012 00:11:40 -0700 (PDT) Michel <msimi...@wanadoo.fr> 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  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 . Now, since your commits did not update any branch (above, I explained why), your simple `git push <remote>` 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"  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 firstname.lastname@example.org. 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.