How to push properly a la subversion

Hi

I'm discovering git switchig from svn, so I'm still confused... I want actually to use git but keeping this idea of one common/public repo that different users push/pull from.

I tried just by cloning A to B, changing/commiting B and the pushing to A but: then on A the last log is integrated but I have this message with gitk "local changes checked in to index but not commited", and those local changes are actually the version of A before the commit from B :-( What I expected with svn mentality is that A is changed and updated...

So 2 questions: -how to remedy? -hot to avoid?

I could remedy on A by git reset --hard, but ideally I would not need to remedy to that...

Should I enter a specifical push option? Or rather work on section "Setting up a shared repository"? in http://www.kernel.org/pub/software/scm/git/docs/gitcvs-migration.html ? I tried to do it entering:

$ mkdir /pub/my-repo.git $ cd /pub/my-repo.git $ git --bare init --shared $ git --bare fetch /home/alice/myproject master:master

but then I get also this message "local changes checked in to index but not commited" and especially there are many git files appearing that we would not want to see.... And furthermore it seems there are complicated permissions/ssh issues that I don't need (I'm doing for now only locally).

So can those new files be avoided? What is the best way to set-up git to have kind of central repo?

Thanks for your precious help!!

Matthieu Stigler

On Wed, Jul 29, 2009 at 6:32 PM, Matthieu Stigler<matthieu.stigler@gmail.com> wrote:

You need to configure A as a "bare" repository. For example: http://toolmantim.com/articles/setting_up_a_new_remote_git_repository

Future versions of git will prevent you from accidentally getting A into the inconsistent state that you've managed to produce.

Avery

On Wed, Jul 29, 2009 at 08:32:46PM +0200, Matthieu Stigler wrote:

This is because git-push does not change your working tree. So, your normally should never push to the branch that is currerently checked out. (New versions of Git will warn you about that). As to having a common/shared repo, it should be a "bare" repository.

Strange... The above commands work perfectly for me.... And if you have a bare repo then it should not have 'index'. So, the error does not make much sense to me... Is it produced by gitk? Hmm, maybe some old version of gitk did not work correctly with a bare repo... I dunno...

I don't understand your troubles with permissions. Basically, there are
two options to setup a shared repo:
1. where every developer has each own account
2. a single account (but still each has each own ssh key)

The 'shared' option during init is necessary only for the first case to make repository group writable. All users who can push to it should be members of the group.

If you want to have a single system account for all users, you have two
options:
- gitosis
- ssh based authentification with forced command and then update hook
  if extra check is needed (see Documentation/howto/update-hook-example.txt)

Dmitry

On Thu, Jul 30, 2009 at 10:11:43AM +0200, Matthieu Stigler wrote:

Actually, gitk and 'git gui' are very nice... Well, I do prefer the command line, but I still use gitk to see the history. There are some other GUIs out there, but they should be installed separately.

ssh client works fine on Windows, but I have never installed a shared repo on Windows, which would require to install a ssh server. So, I don't think I can help here.

If you want to have a shared repo then every developer should have the write access to it and every file created by any developer should be writable by other developers in the same group. To prevent any developer from removing anything on the server, they should not have the normal access to it but only through git-shell (i.e. git-shell should be specified as the login shell). Now, it is often inconvinient to have many special users accounts. So, you can use gitosis, which requires only one user account and identified users by their SSH key. I heard that some people set up it on Windows, but it was Cygwin version of Git.

As to the simplest way, it is probably to use a distributed workflow: each developer has their own repo, which is writable for him/her and readable for other developers. (You can easily to do with sharable folders by assigning appropriate permissions, and you probably will not need to deal with SSH at all). In this workflow, every group has each own team leader or co-ordinator, who is responsible for integration other people work. Then the repo of the team leader will becomes the "official" repo of the project, but it is only social a convention and not a technical one. Any developer can fetch from any repository (see also git-remote). IMHO, the distributed workflow is far superior to having everyone to push to the same repo.

In fact, as closer you emulate SVN workflow, more SVN issues, you will pick up. For instance, 'svn commit' does two things: it creates a new commit and propogate this changes to the server. In general, it is a very bad thing to do, because you end up with a lot of work-in-progress commits, which may be steps in the wrong direction, but they interfere with other people work. With Git even using a central repo, you can do better -- developers can push their work when they have finished. Still, you may want to have some code review process. How are you going to organize that? And then when someone works on some feature or have some other work-in-porgress, you still want that this work will be properly backed up (or at least, store more than in one place). So, you naturally want to give every developer repo on that server where he/she can push their work _before_ it is become part of the official history of the project. And, finally, it is always good to have someone who co-ordinates everyone's efforts, so intergation will be not randomly but based on priorities and quality of one's work...

Dmitry

Hi Dmitry and all

Thanks for taking time to explain me in details the philosophy of git vs svn, it helped me a lot. Two comments/questions:

The first is that as you say,

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 ;-)

Second, you said

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

And if yes, can I automate that in hooks/post-update in A? Or post-commit in B?

Thanks a lot!

Matthieu

2009/7/30 Dmitry Potapov <dpotapov@gmail.com>:

On Tue, Aug 04, 2009 at 09:17:45AM +0200, Matthieu Stigler wrote:

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.

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

Quoting Matthieu Stigler <matthieu.stigler@gmail.com>

The standard way to communicate changes to a repository with a working tree A from your repository B is to pretend as if A fetches from B even when you are pushing from B to A..

Here are some recommended readings:

 * http://git.or.cz/gitwiki/GitFaq#Whywon.27tIseechangesintheremoterepoafter.22gitpush.22.3F
 * http://git.or.cz/gitwiki/GitFaq#push-is-reverse-of-fetch

 * "Push into another repository" item in http://www.kernel.org/pub/software/scm/git/docs/everyday.html illustrates this with an example.

 * http://article.gmane.org/gmane.comp.version-control.git/123331