> 1. http:// protocol cannot be authenticated. It cannot be > pushed to. It can only be used for anonymous clones. > Similar for https:// and git:// protocols. Those > anonymous clones are valid clones but that remote > protocol cannot be used to push back to the remote > repository.
Got it :) > The https://savannah.nongnu.org/maintenance/UsingGit/ > page documents a way to convert a checked out sandbox > from one remote branch to another remote branch without > needing to clone it again. Thanks for the reference. I'll check it out. > 2. The "//" protocol. I am not sure where you copied that > link from but that is an HTML link intended for the user > to select in the web browser and is not valid in other > contexts. On the following link: https://savannah.nongnu.org/project/admin/editgroupfeatures.php?group=datestamp Here when I selected the git feature, I saw two links, one for git and one for git web browsing. I tried both of them. >From your further explanation, I understood my mistake. > The clone section of the cgit project page shows the > recommended URLs for cloning. (which wasn't active when I wrote this mail :P) It got activated after my first push. > Two notes. As described above git:// and https:// are > anonymous read-only sources only. The only writable source > is ssh:// protocol which is authenticated. Okay. In general also I prefer ssh only, so no problem. > Secondly although it is not advertized it is also available > over http protocol the same as https protocol. This helps > our free software friends who access the Internet from > behind restrictive firewalls. Thanks for this information. I didn't know this. > Also noting that git itself uses secure hashing to verify > content. But generally https avoids problems with > troublesome web proxies and many other problems. I > recommend always using ssh:// protocol for developer access > as it is fully authenticated and most robust. Sure! I know that you have subsequently been successful. Very often the best readers and editors of documentation are those who are reading it for the first time. If you have any suggestions for the documentation it would be appreciated. The link which actually worked for me was the following: git remote set-url origin ssh://nir...@git.sv.nongnu.org/srv/git/datestamp.git It is given in the UsingGit documentation-page, but what I felt was it comes a bit late and the heading is not quite clear (at least for new people like me). What does "Fixing checkout from git:// to ssh://" mean? Is there any problem with the checkout from git:// that needs to be fixed? How I made it work is a weird story :P I remember using `git set-url` at some point of time, so I literally searched for `git set-url` on that web-page and the first command I found on that page worked for me, but I feel this is not a good sign for the manual. > This is the users mailing list. It's a community of users > just like yourself who are all using Savannah. This is a > great resource for people who can share their knowledge and > help other free software hackers. I feel very lucky to be a small part of it :) > At this time all of the web pages are managed using > CVS. Which to new people today sounds very scary. But let > me assure you that if you have succeeded with git that using > cvs is much less problematic! Your project page starts with > some documentation on setting up web pages. > https://savannah.nongnu.org/cvs/?group=datestamp > The Savannah documentation for CVS is here. > https://savannah.nongnu.org/maintenance/CvsGettingStarted/ > I want to send this mail off so will avoid making it too > much longer. Please ask questions. People will help. But for > the web there is a team of GNU webmasters who both work on > the site and can help. Let me link to the webmastering > documentation. There is a lot of good information there. > https://www.gnu.org/server/standards/README.webmastering.html Thanks for the reference I will check it out. I will now try to explain what I have already tried with CVS and then explain the problem I am facing. I used the following command to clone(?) the project. cvs -z3 -d:pserver:anonym...@cvs.savannah.nongnu.org:/sources/datestamp co datestamp After this I got a directory named datestamp which had another directory named CVS inside it. Now I had no clue about how to go ahead, so what I instead did was (don't laugh :P) cloning a CVS directory of another project, whose web-page was very simple. I cloned the following project: https://savannah.nongnu.org/projects/emacsy/ There I found one index.html inside the emacsy/ directory. So I wrote my own index.html and placed it inside the datestamp/ directory. I hope this isn't a problem. If it is, then it is the fault of the developer of emacsy XD. Then I issued the following command: cvs add index.html which returned: cvs2 [server aborted]: "add" requires write access to the repository I tried a lot of things, but every time I was prompted by a message which wanted me to add the index.html first. So I think I need to solve this particular problem first. The questions I have now are as follows: 1. How to {add|commit|push} this index.html to my CVS? 2. After pushing, is it automatically interpreted as the homepage or I have to do something? 3. I already have a git repository with all the files and history, is it recommended to have the same files in CVS also? 4. If yes, what would be the ideal structure of the datestamp/ directory? Currently it as follows: . ├── CVS │ ├── Entries │ ├── Repository │ └── Root └── index.html and the directory structure of my actual project datestamp is as follows: . ├── COPYING ├── datestamp │ ├── build.lua │ ├── datestamp.dtx │ ├── datestamp-example.pdf │ ├── datestamp-example.tex │ ├── datestamp.ins │ ├── datestamp.pdf │ ├── support │ │ ├── datestamp-example.ds │ │ └── gfdl-tex.tex │ └── testfiles │ ├── datestamp-example.lvt │ ├── datestamp-example.tlg │ └── support │ └── datestamp-example.ds └── README.txt How would you suggest me to incorporate this structure and my index.html in the CVS repository? Best, निरंजन
