On Tue, Aug 04, 2009 at 09:17:45AM +0200, Matthieu Stigler wrote: > > This was a source of confusion for me and I did not get it > immediately. Maybe be help page git-svn crash course could be more > detailed about that? It just mentions the analogy git commit -a /svn > commit (so the first step you mention) but not the second (svn commit > is similar to git push also)? Personaly, I think this could help a lot > newbies like me ;-) I see that it may be a source for confusion if you look at it from the team workflow POV, you can even say that 'git push' is analogue of 'svn commit'. But it is a general principle of Git that all commands except specifically designed to propagation changes ('fetch', 'push', 'pull' and 'remote') to work locally. So, it is not only that all commits are created locally but also branches, tags, etc. And, though, your repo may be visible to other directly, but it is more commonly that you have to push your changes to some bare repository on the server where it can be seen by other developers. So, I am not sure how better to state that in "Git - SVN Crash Course", and what is the right place for that. Maybe, a few words should be added to the section titled "Things You Should Know", but I am not sure about wording. Your suggestions are welcome. > > Second, you said > > So, your normally should never push to the branch that is currerently checked out. (New versions of Git will warn you about that). > > Is there a way to avoid that? Manually, do I just need on post A > (against which it was pushed from clone B) to use: > git-reset --hard HEAD Normally, you should push to a bare repository, so it not an issue. Yet, there are some situations when it can happen. For instance, you have two computers on which you work and you want to push your work from one them to another directly without using any bare repo. In this case, you can use 'git reset --hard HEAD' after push (and it can be done automatically by hooks) but you should be *sure* that uncommitted changes in that working directory, otherwise they will be lost. So, I really don't think it is a good idea to do automatically. There are a few alternatives though. Instead of pushing to the checkout branch, you can push to a new branch (See refspec for details). There is also Johannes Schindelin's patch called "Add a few more values for receive.denyCurrentBranch", which adds the 'updateInstead' value. It may be want you want, but it is not included to the official Git, because there very few users who want to this feature. Do you really foresee a setup where you will push to a non-bare repo quite often? Dmitry -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html