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:
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
Em Tue, 19 Jun 2007 09:33:05 +0200
Claudio Scordino [off-list ref] 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
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 [off-list ref] 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.
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 <command>" is equivalent to "git --git-dir=. <command>", 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