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