Suggestions for documentation

Hi,

    I just want to suggest to put some missing information in the git manpages.

1) As my previous question shown, how to clone from a specified port is not 
currently documented. You should just add a sentence saying that the command is

git clone git://server:port/path/

2) Maybe it is better to highlight that after a push on a remote repository, the 
user has to do a checkout on that repository (people from the CVS and SVN worlds 
get easily confused, otherwise).

Moreover (and I did not fully understood why) if I just use "git checkout" without the -f option, I cannot see the changes that have been pushed from the cloned repository.

Regards,

          Claudio

Hi,

On Tue, 19 Jun 2007, Claudio Scordino wrote:

I thought this was quite standard with other protocol? I.e. http://host:port/path is what I do all the time.

Having said that, this should be relatively easy? Want to give it a try?

That has been discussed on and off, and I think that you are not using a valid workflow here. If you are pushing into another repo, _by definition_ you do not have a work tree to resolve conflicts with.

Thus, you should rather do something like "push upstream master:refs/heads/push" on the pushing side, and "merge push" on the other side.

It is a common behaviour by former CVS users (I did the same!), but it is fixable.

Same reason. This is not a valid workflow. You kind of changed the tip of the branch in the pushed-to repo behind its back. The only way to make this work that I am aware of is "git read-tree -m -u HEAD", but as I stated before, you probably want to change the way you're working.

Hth, Dscho

Em Tue, 19 Jun 2007 09:33:05 +0200 Claudio Scordino <cloud.of.andor@gmail.com> escreveu:

| Hi,
| 
|     I just want to suggest to put some missing information in the git manpages.
| 
| 1) As my previous question shown, how to clone from a specified port is not 
| currently documented. You should just add a sentence saying that the command is
| 
| git clone git://server:port/path/
| 
| 2) Maybe it is better to highlight that after a push on a remote repository, the 
| user has to do a checkout on that repository (people from the CVS and SVN worlds 
| get easily confused, otherwise).
| 
| Moreover (and I did not fully understood why) if I just use "git checkout" 
| without the -f option, I cannot see the changes that have been pushed from the 
| cloned repository.

 git-rebase documentation needs some change too. We should add some high level
description in one paragraph at the top of the file.

 I answer the very same question ('why should I want to use git-rebase?')
three times per week.

 I'll submit a patch shortly.

Hi,

    actually I didn't understand the difference between "git clone --bare" and
"git --bare fetch" either... (maybe is not clear in the documentation ?)

For instance, what should be used when setting up a public not-working repository ?

I mean, we can use both

git --bare init git --bare fetch ... master:master

and

git clone --bare  ...

Thank you in advance.

Regards,

             Claudio

Luiz Fernando N. Capitulino wrote:

Claudio Scordino wrote:

"git --bare <command>" is equivalent to "git --git-dir=. <command>", and
it only tells where to find repository...
 

...while "git clone --bare" setups _bare_ repository, which means 1:1 mapping of references, and no working area.