How to push properly a la subversion

How to push properly a la subversion

[Matthieu Stigler]

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

Re: How to push properly a la subversion

[Avery Pennarun]

On Wed, Jul 29, 2009 at 6:32 PM, Matthieu
Stigler<matthieu.stigler@gmail.com> wrote:
> 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...

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

Re: How to push properly a la subversion

[Dmitry Potapov]

On Wed, Jul 29, 2009 at 08:32:46PM +0200, Matthieu Stigler wrote:
>
> 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...

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.

>
> 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....

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...

> And furthermore it seems there are complicated  
> permissions/ssh issues that I don't need (I'm doing for now only 
> locally).

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

Re: How to push properly a la subversion

[Dmitry Potapov]

On Thu, Jul 30, 2009 at 10:11:43AM +0200, Matthieu Stigler wrote:
> 
> Furthermore, there are reluctant to install any new softwares
> and to use command line software,

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.

> I used for now portable GIT on windows,
> which seems to have also ssh.

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.

> So I understood that I need to set-up a shared repo, thanks for your
> advices! Now do I really need all those permissions issues? What is the
> simplest way to deal with that?

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

Re: How to push properly a la subversion

[Matthieu Stigler]

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,
>'svn commit' does two things: it creates a new commit and propogate this changes to the server

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

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 Thu, Jul 30, 2009 at 10:11:43AM +0200, Matthieu Stigler wrote:
>>
>> Furthermore, there are reluctant to install any new softwares
>> and to use command line software,
>
> 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.
>
>> I used for now portable GIT on windows,
>> which seems to have also ssh.
>
> 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.
>
>> So I understood that I need to set-up a shared repo, thanks for your
>> advices! Now do I really need all those permissions issues? What is the
>> simplest way to deal with that?
>
> 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
>

Re: How to push properly a la subversion

[Dmitry Potapov]

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

Re: How to push properly a la subversion

[Nanako Shiraishi]

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

> 2009/7/30 Dmitry Potapov <dpotapov@gmail.com>:
>
> 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
>
> And if yes, can I automate that in hooks/post-update in A? Or post-commit in B?

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

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

How to push properly a la subversion

[Matthieu Stigler]

Hi

Thanks Dmitiri and Avery for your help and advices! I could understand
a little bit better, but I'm still confused. Actually what I did not
mention is that we are working on windows (actually 2000 and soon
vista :-(). The institute have a big programming project and I try to
introduce version control hopefully with git. The project is now
stored in a shared disk and there are no security/permissions issues
(every body is allowed to erase it basically:-(). Furthermore, there
are reluctant to install any new softwares and to use command line
software, I used for now portable GIT on windows, which seems to have
also ssh.

So I understood that I need to set-up a shared repo, thanks for your
advices! Now do I really need all those permissions issues? What is
the simplest way to deal with that?

I looked at http://toolmantim.com/articles/setting_up_a_new_remote_git_repository
but I'm stuck with first command:
ssh myserver.com

Does that need I should have previously set-up a ssh server? Is this a
necessary step?


In my case, the shared disk is say: T:\project\gitrepo
How should I do?

The second line in the tuto mentions:

mkdir /var/git/myapp.git && cd /var/git/myapp.git
Here /var is linux specific...
Is it any directory that is concerned or is it required to be in /var?
How do I set-it up in windows?


Finally, should I rather use something like Putty on windows?

Thank you so much for your precious help, I'm just discovering git...

Matthieu
2009/7/29 Dmitry Potapov <dpotapov@gmail.com>
On Wed, Jul 29, 2009 at 08:32:46PM +0200, Matthieu Stigler wrote:
>
> 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...

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.

>
> 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....

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...

> And furthermore it seems there are complicated
> permissions/ssh issues that I don't need (I'm doing for now only
> locally).

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