git push in a git-init without --bare option?

git push in a git-init without --bare option?

[Pedro Sa Costa]

Hi,

I'm newbie in git and I'm trying to understand how git works.

- I see that in git, I can't do git-push to a repository that wasn't created 
with git-init --bare. Why?

- But doing git-pull and git-checkout to the same repository is possible. I'm 
really confused. Any help?

-- 
Best regards,

-----------------------

Re: git push in a git-init without --bare option?

[Elia Pinto]

Git doesn't keep track on the remote repo if someone change the
checkout file. So it was always a bad habit to push to a not bare
repo, you could lost commit. From 1.7 git don't permit, by default, to
push to a non bare repo. Best regards

2011/6/26, Pedro Sa Costa <psdc1978@gmail.com>:
> Hi,
>
> I'm newbie in git and I'm trying to understand how git works.
>
> - I see that in git, I can't do git-push to a repository that wasn't created
> with git-init --bare. Why?
>
> - But doing git-pull and git-checkout to the same repository is possible.
> I'm
> really confused. Any help?
>
> --
> Best regards,
>
> -----------------------
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
Inviato dal mio dispositivo mobile

Re: git push in a git-init without --bare option?

[Matthieu Moy]

Pedro Sa Costa <psdc1978@gmail.com> writes:

> - I see that in git, I can't do git-push to a repository that wasn't created 
> with git-init --bare. Why?
>
> - But doing git-pull and git-checkout to the same repository is possible. I'm 
> really confused. Any help?

git pull involves a merge, and merge may involve conflicts, and
conflicts involve a user fixing them ... So, doing a "git pull" to merge
in remote changes is OK, but a "git push" cannot merge changes remotely,
hence the asymetry.

Git could just send the commits, without updating the working tree, but
that would be terrible for the user. Let's say the user has no local
change before the push. His checkout points to the tip of a branch
(information stored in HEAD), so the tree matches the old HEAD. Updating
the branch means changing the commit pointed to by HEAD, hence after a
push, the tree does not match the HEAD anymore (which means the next
commit will seem to revert the pushed history). This is to prevent this
situation that Git refuses to push to non-bare repos.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git push in a git-init without --bare option?

[Pedro Sa Costa]

So this means that eveytime that I want a repository to be shared by several 
persons, the repository must always be bare?



> Pedro Sa Costa <psdc1978@gmail.com> writes:
> > - I see that in git, I can't do git-push to a repository that wasn't
> > created with git-init --bare. Why?
> > 
> > - But doing git-pull and git-checkout to the same repository is possible.
> > I'm really confused. Any help?
> 
> git pull involves a merge, and merge may involve conflicts, and
> conflicts involve a user fixing them ... So, doing a "git pull" to merge
> in remote changes is OK, but a "git push" cannot merge changes remotely,
> hence the asymetry.
> 
> Git could just send the commits, without updating the working tree, but
> that would be terrible for the user. Let's say the user has no local
> change before the push. His checkout points to the tip of a branch
> (information stored in HEAD), so the tree matches the old HEAD. Updating
> the branch means changing the commit pointed to by HEAD, hence after a
> push, the tree does not match the HEAD anymore (which means the next
> commit will seem to revert the pushed history). This is to prevent this
> situation that Git refuses to push to non-bare repos.
-- 
Best regards,

-----------------------

Re: git push in a git-init without --bare option?

[Christof Krüger]

On So, 2011-06-26 at 22:21 +0100, Pedro Sa Costa wrote:
> So this means that eveytime that I want a repository to be shared by
> several 
> persons, the repository must always be bare?

Short answer: no.

Long answer: Not necessarily, it depends on your workflow.

You could have a central "official" repository on a server that is
accessible by all members of your team. This is how centralized
version-control systems like Subversion work. You can imitate this with
git, but with git it's just convention, not a technical necessity. This
central repository would then be bare, as nobody will work on it
directly. If connectivity between developers is an issue (e.g. because
of firewalls or NAT), this might be the preferred model in some cases.
You can also use a service like github.com for example.

But you could also use it the distributed way. Then you should
understand and respect the asymmetry between push and pull. Every
developer on a team can have a local (non-bare) repository he works on.
As it is his private repository, all you can say is "hey buddy, I've got
a shiny new feature ready. Pull branch 'foobar' from my private
repository". He can then decide to pull and merge it with his code if he
wishes.

The above doesn't work if you'd allowed everyone to push around stuff to
other developers without their consent. You would lose control over your
own private repository and your working-copy would never be up-to-date
with what is the HEAD of your repo.

Of course, you can have a topology that is far more complex than what I
outlined above, combining bare and non-bare repositories at once and
having multiple repositories per developer, but I hope that the basic
idea became clear.

Regards,
  Chris