[git-users] Help on `git-clone --bare`

2011-08-19 Thread Jay Lan

Hi,

I am new to the GIT world and try to manage a
multiple developers local git repo.

I created a local repo by `git clone --bare`.
Then, I git clone from that local repo to my work area.
After made a change, I committed and pushed back
to the local repo.

At the local repo, `git show commit` showed the
commit I pushed. However, `git log` does not show
the commit. I seemed not able to see the commit if I
do not have the commit ID.

Also, when I git clone to yet another work area
at this point, the new work tree does not see my
earlier commit.

Anyone has used a git clone --bare model?
What did I do wrong here? Advice is much appreciated!


Regards,
Jay

--
You received this message because you are subscribed to the Google Groups Git for 
human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.



Re: [git-users] Help with git clone

2011-04-13 Thread Antony Male

On 11/04/2011 4:12 pm, Konstantin Khomoutov wrote:

On Mon, 11 Apr 2011 13:43:25 +0100
Antony Maleantony.m...@gmail.com  wrote:

[...]

When you clone (or fetch) a repository over the git protocol, a
program on your computer (git-fetch-pack) and a similar one on the
server (git-upload-pack) coordinate to figure out exactly what
commits (roughly speaking) needs to be sent to you.

HTTP, however, is a dumb protocol, meaning that this approach
cannot be taken.
Therefore, some auxiliary files need to be present on the server, to
allow your client to figure out what commits it needs to request.

These files aren't generated by default -- you need to run git
update-server-info after every commit in order to generate them.

Being pedantic here, for clarity: this is needed to be run after every
push, not commit--a push can send a whole lot of commits in one go
which is a common pattern for a DVCS.

[...]


You're quite right -- slip on my part there.

For even more clarity:
When serving a repo over HTTP, the repo that your HTTP server points to
should be 'bare' -- that is, it was creating using 'git init --bare',
meaning it consists solely of the contents of what would normally be in
a .git directory, and therefore has no working copy (no checked-out files).
By convention, your bare repo's folder name ends with '.git' (eg
InAJiffy.git).

You then keep another copy of your repo elsewhere in your workspace, and
commit to that. When you're ready to share your changes (which may
consist of more than one commit), you push them to the bare repo.

The post-update hook runs when the repository is pushed to, and so will
run (providing it's properly configured) when you push your changes to
the bare repo.

Antony



--
You received this message because you are subscribed to the Google Groups Git for 
human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.



Re: [git-users] Help with git clone

2011-04-12 Thread Konstantin Khomoutov
On Tue, Apr 12, 2011 at 10:56:44AM +0530, Mohith Thimmaiah wrote:

  On Mon, 11 Apr 2011 13:43:25 +0100
  Antony Male antony.m...@gmail.com wrote:
  [...]
   When you clone (or fetch) a repository over the git protocol, a
   program on your computer (git-fetch-pack) and a similar one on the
   server (git-upload-pack) coordinate to figure out exactly what
   commits (roughly speaking) needs to be sent to you.
  
   HTTP, however, is a dumb protocol, meaning that this approach
   cannot be taken.
   Therefore, some auxiliary files need to be present on the server, to
   allow your client to figure out what commits it needs to request.
  
   These files aren't generated by default -- you need to run git
   update-server-info after every commit in order to generate them.
  Being pedantic here, for clarity: this is needed to be run after every
  push, not commit--a push can send a whole lot of commits in one go
  which is a common pattern for a DVCS.
 Prefer to use the soln suggested by Antony
 [1]: http://progit.org/book/ch4-1.html#the_https_protocol
 [2]: http://progit.org/book/ch4-5.html
 This is onetime setup - no need to run
 after every push. Just so others who follow can see this
Well, we both presented the same solution, just pointed to different
docs (Antony pointed to a book and I pointed to the manual page).
Hence my remark refers to how that hook runs--once per push which may
bring arbitrary number of commits (and even update several refs (read:
branches and tags) in one go using those commits).

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.



Re: [git-users] Help with git clone

2011-04-12 Thread Mohith Thimmaiah
Acknowledged - they were the same soln.

Thank you
T

On Wed, Apr 13, 2011 at 4:50 AM, Konstantin Khomoutov 
flatw...@users.sourceforge.net wrote:

 On Tue, Apr 12, 2011 at 10:56:44AM +0530, Mohith Thimmaiah wrote:

   On Mon, 11 Apr 2011 13:43:25 +0100
   Antony Male antony.m...@gmail.com wrote:
   [...]
When you clone (or fetch) a repository over the git protocol, a
program on your computer (git-fetch-pack) and a similar one on the
server (git-upload-pack) coordinate to figure out exactly what
commits (roughly speaking) needs to be sent to you.
   
HTTP, however, is a dumb protocol, meaning that this approach
cannot be taken.
Therefore, some auxiliary files need to be present on the server, to
allow your client to figure out what commits it needs to request.
   
These files aren't generated by default -- you need to run git
update-server-info after every commit in order to generate them.
   Being pedantic here, for clarity: this is needed to be run after every
   push, not commit--a push can send a whole lot of commits in one go
   which is a common pattern for a DVCS.
  Prefer to use the soln suggested by Antony
  [1]: http://progit.org/book/ch4-1.html#the_https_protocol
  [2]: http://progit.org/book/ch4-5.html
  This is onetime setup - no need to run
  after every push. Just so others who follow can see this
 Well, we both presented the same solution, just pointed to different
 docs (Antony pointed to a book and I pointed to the manual page).
 Hence my remark refers to how that hook runs--once per push which may
 bring arbitrary number of commits (and even update several refs (read:
 branches and tags) in one go using those commits).

 --
 You received this message because you are subscribed to the Google Groups
 Git for human beings group.
 To post to this group, send email to git-users@googlegroups.com.
 To unsubscribe from this group, send email to
 git-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/git-users?hl=en.



-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.



[git-users] Help with git clone

2011-04-11 Thread Mohith Thimmaiah
Im new to git :)

I have a repo which I have exposed via http at careerinsight.org/
git_repo/InAJiffy/ so that other who need to access it via http have a
way to get to it

Now I am able to clone the git repo locally (without http) and also
via http

# clone over http
git clone http://careerinsight.org/git_repo/InAJiffy/ IAJ1
# clone locally on the same m/c
git clone git_repo/InAJiffy/ IAJ2

Now strangely enough all my new changes are there in the clone done
locally - but the clone over http seems to be an old one

# git branch shows master in both places
$ git branch
* master

# git log shows diff stuff in both places
Its obvious that the http clone is an older version. I can see that
git log --stat is very diff for both

Please help !!! Im confused
1. Why are the 2 cloned repos different
2. How can I tell the clone over http command to get the same stuff as
the clone done locally

Thanks a ton in advance

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.



Re: [git-users] Help with git clone

2011-04-11 Thread Antony Male

On 11/04/2011 1:15 pm, Mohith Thimmaiah wrote:

Im new to git :)

I have a repo which I have exposed via http at careerinsight.org/
git_repo/InAJiffy/ so that other who need to access it via http have a
way to get to it

Now I am able to clone the git repo locally (without http) and also
via http

Now strangely enough all my new changes are there in the clone done
locally - but the clone over http seems to be an old one

Please help !!! Im confused
1. Why are the 2 cloned repos different

 2. How can I tell the clone over http command to get the same stuff as
 the clone done locally


Take a look at [1] and [2].

When you clone (or fetch) a repository over the git protocol, a program 
on your computer (git-fetch-pack) and a similar one on the server 
(git-upload-pack) coordinate to figure out exactly what commits (roughly 
speaking) needs to be sent to you.


HTTP, however, is a dumb protocol, meaning that this approach cannot 
be taken.
Therefore, some auxiliary files need to be present on the server, to 
allow your client to figure out what commits it needs to request.


These files aren't generated by default -- you need to run git 
update-server-info after every commit in order to generate them. Have a 
look at the default post-update hook for an easy way to do this.


In your case, it looks like the auxiliary files are out of date, meaning 
that a fetch over HTTP won't fetch any commits since the auxiliary files 
were created.


Hope this solves your problem,
Antony

[1]: http://progit.org/book/ch4-1.html#the_https_protocol
[2]: http://progit.org/book/ch4-5.html



--
You received this message because you are subscribed to the Google Groups Git for 
human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.



Re: [git-users] Help with git clone

2011-04-11 Thread Konstantin Khomoutov
On Mon, 11 Apr 2011 13:43:25 +0100
Antony Male antony.m...@gmail.com wrote:

[...]
 When you clone (or fetch) a repository over the git protocol, a
 program on your computer (git-fetch-pack) and a similar one on the
 server (git-upload-pack) coordinate to figure out exactly what
 commits (roughly speaking) needs to be sent to you.
 
 HTTP, however, is a dumb protocol, meaning that this approach
 cannot be taken.
 Therefore, some auxiliary files need to be present on the server, to 
 allow your client to figure out what commits it needs to request.
 
 These files aren't generated by default -- you need to run git 
 update-server-info after every commit in order to generate them.
Being pedantic here, for clarity: this is needed to be run after every
push, not commit--a push can send a whole lot of commits in one go
which is a common pattern for a DVCS.

[...]

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.