# Suggestions for documentation 5 messages from 2007-06-19 to 2007-06-21. Participants: Claudio Scordino, Johannes Schindelin, Luiz Fernando N. Capitulino, Jakub Narebski. Thread: https://gitlist.dev/t/8649 ## Claudio Scordino, 2007-06-19 07:33 Subject: Suggestions for documentation Message-ID: <467786B1.5000009@gmail.com> URL: https://gitlist.dev/e/467786B1.5000009%40gmail.com ``` 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 ``` ## Johannes Schindelin, 2007-06-19 09:47 Subject: Re: Suggestions for documentation Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0706191043170.4059%40racer.site In-Reply-To: <467786B1.5000009@gmail.com> ``` Hi, On Tue, 19 Jun 2007, Claudio Scordino wrote: > 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/ 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? > 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). 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. > 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. 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 ``` ## Luiz Fernando N. Capitulino, 2007-06-20 21:06 Subject: Re: Suggestions for documentation Message-ID: <20070620180615.529dff2a@localhost> URL: https://gitlist.dev/e/20070620180615.529dff2a%40localhost In-Reply-To: <467786B1.5000009@gmail.com> ``` Em Tue, 19 Jun 2007 09:33:05 +0200 Claudio Scordino 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. -- Luiz Fernando N. Capitulino ``` ## Claudio Scordino, 2007-06-21 11:24 Subject: Re: Suggestions for documentation Message-ID: <467A5FE1.1010401@gmail.com> URL: https://gitlist.dev/e/467A5FE1.1010401%40gmail.com In-Reply-To: <20070620180615.529dff2a@localhost> ``` 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: > Em Tue, 19 Jun 2007 09:33:05 +0200 > Claudio Scordino 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. > ``` ## Jakub Narebski, 2007-06-21 15:16 Subject: Re: Suggestions for documentation Message-ID: URL: https://gitlist.dev/e/f5e4no%24b6f%241%40sea.gmane.org In-Reply-To: <467A5FE1.1010401@gmail.com> ``` Claudio Scordino wrote: >     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 "git --bare " is equivalent to "git --git-dir=. ", and it only tells where to find repository... > and > > git clone --bare  ... ...while "git clone --bare" setups _bare_ repository, which means 1:1 mapping of references, and no working area. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ```