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
Em Tue, 19 Jun 2007 09:33:05 +0200
Claudio Scordino <[email protected]> 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.
Signature · 1 line
Luiz Fernando N. Capitulino
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
Quoted 18 lines · Luiz Fernando N. Capitulino
Em Tue, 19 Jun 2007 09:33:05 +0200
Claudio Scordino <[email protected]> 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.
Quoted 9 lines · Claudio Scordino
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 <command>" is equivalent to "git --git-dir=. <command>", and it only tells where to find repository...
Quoted 3 lines
and
git clone --bare ...
...while "git clone --bare" setups _bare_ repository, which means 1:1 mapping of references, and no working area.
Signature · 3 lines
Jakub Narebski Warsaw, Poland ShadeHawk on #git
Hi,
Quoted 5 lines · Claudio Scordino
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?
Quoted 3 lines
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.
Quoted 3 lines
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