portmgr suggests that we update the documentation so that it discourages the use of portsnap. As a substitute, we can document how to use gitup. The reasoning behind discouraging the use of portsnap is: portsnap is fragile, portmgr has had absolutely no success in having things evolved for years, and while it was great in the old CVS times where networks were flacky, and CVS was hard to use, there has been better alternatives, with svn, there was svnup, and with git, there is gitup. Both use the repository directly, and don't require a third party middleware.
gitup works, but it's not the main thing we should be encouraging. People should use just plain git. We are in this weird cycle where we're recommending tool after tool to avoid just checking out the repo, when the simplest thing is just to check out the repo.
gitup is useless - too slow. On local SATA SSD: [~]# time gitup ports # Host: git.freebsd.org # Port: 443 # Repository: /ports.git # Target: /usr/ports # Have: a2c5d69385fe0d8c5a666d570f5b464ca302d37d # Want: a2c5d69385fe0d8c5a666d570f5b464ca302d37d # Branch: main real 2m58,839s user 0m34,055s sys 0m20,755s On remote HDD via NFS: [~]# time gitup ports # Host: git.freebsd.org # Port: 443 # Repository: /ports.git # Target: /usr/ports # Have: a2c5d69385fe0d8c5a666d570f5b464ca302d37d # Want: a2c5d69385fe0d8c5a666d570f5b464ca302d37d # Branch: main real 22m28,088s user 0m57,772s sys 0m36,280s Look at fields: "Have" = "Want", so it's just check without update.
The only reason I mentioned gitup is because people seem to be allergic to git, and it provided another way to access the repository, of course using git is better.
(In reply to Mateusz Piotrowski from comment #0) > … document how to use gitup. … 👍 please do. From line 1 at <https://cgit.freebsd.org/ports/tree/net/gitup/pkg-descr?id=c1e26e39b09d42f834f7c0d2ddad50c90b0a7ce6#n1>: >> … minimalist, dependency-free …
(In reply to Adam Weinberger from comment #1) > … git … Use of git is already suitably documented in FreeBSD areas. In particular, the FreeBSD Foundation article linked (three options) from <https://old.reddit.com/comments/pfo6pc/-/>.
(In reply to VVD from comment #2) > gitup is useless Untrue. Too harsh. > too slow. Pros and cons of gitup, including the likelihood of inclusion in base, can be discussed in FreeBSD Forums, if you like. <https://forums.freebsd.org/posts/544851>: * an explanation for relative slowness when pulling * a quote about future attention to disk performance. ---- For now: * use of gitup is reasonably widespread * the wish for documentation is reasonable.
(In reply to Adam Weinberger from comment #1) "gitup works, but it's not the main thing we should be encouraging. People should use just plain git." I strongly disagree. Git, like perl, is a Swiss Army chainsaw. (There's an interactive webpage that's there only to guide git users toward fixing mistakes they make using it.) A chainsaw with attached scalpels is the right tool if you need to amputate the hindleg of a live, kicking elephant near the hip and to do that fast. To butter my toast? Let me have a dull butter knife instead, please.
(In reply to PauAmma from comment #7) IMHO, the operations one needs to do with git are simple enough that adding the complexity of having the user choose and others support multiple tools is not worth it. If you're only using vanilla ports and poudriere, I believe you can get ports and build packages without ever running git directly, instead having poudriere run it via "poudriere ports -c" and "poudriere ports -u". For anything past that, you're going to be making changes to ports and then need to use git proper in order to generate patches. And to me, we should be able to provide packages that meet users needs without them having to build them themselves, which puts any package building into the realm of ports developers, but I know we're not there yet.
This is a documentation bug for the FreeBSD Handbook. git === > Use of git is already suitably documented in FreeBSD areas. – including … drum roll … the Handbook. We have: <https://docs.freebsd.org/en/books/handbook/mirrors/#git> > A.3. Using Git > > … how to install Git on a FreeBSD system and use it to create a > local copy of a FreeBSD repository. Additional information on the > use of Git is included. gitup and got ============= Neither gitup nor Game of Trees (got) is mentioned in the Handbook. The wish to document gitup is consistent with tracking by the Git Migration Working Group. <https://www.freebsd.org/status/report-2021-07-2021-09/#_git_migration_working_group>
Whether we will use gitup as the next tool or not I think is a different question. But I want to stop encouraging portsnap at least. I maintain quite a number of ports and often have to deal with mails(not bugs) where users are using portsnap and have somewhat a broken tree. Switching to a git clone simply fixes the problem. I have also created and submitted a bug #263315 for this purpose. I am not against gitup but unless it's in the base it doesn't make any sense. We will need something else to get the ports tree to build itself.
(In reply to Muhammad Moinur Rahman from comment #10) Oops sorry the bug #264763.
(In reply to Muhammad Moinur Rahman from comment #10) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264763#c2
Add git ("git-lite"?) to base or keep portsnap as default tool for ports. gitup is extremely slow - useless in real use, git isn't in base yet.
(In reply to VVD from comment #13) By the by I think everyone is missing a point here. This is not about removing portsnap from the base neither adding gitup/got in the base. And git/git-lite is never going to be landed in the base as the code is GPLv2. The entire purpose of this is to discourage usage of portsnap. Just consider that when someone is planning to migrate to FreeBSD from Linux. And for port installation they are trying portsnap and somehow while portsnap fetch update it pollutes the tree making the tree unusable. Do you think that a new user will be interested with continuing with FreeBSD. No. That is the main purpose. People who are regular user and know about this will continue using it. If broken they know how to fix it. But a newbie in the FreeBSD world might not know about it and might lose interest sooner than ever.
Last year's <https://github.com/freebsd/freebsd-doc/commit/6feb98a1718ebd4abf0c4cfc0445c1be3337db1a> removed references to portsnap from the FreeBSD Handbook and other areas. Last month's <https://github.com/freebsd/freebsd-src/commit/df53ae0fdd98e9452095ac2fdaf95fcfac8c9c7f>: * removed portsnap * encourages installation of the devel/git package, and use of related commands. I'll await the outcome of bug 270911 before documenting use of gitup.
Using devel/git creates a chicken and egg problem and it comes with a huge amount of dependencies which not everyone wants to have on the system. gitup has no dependencies, but base and works. Not as fast as git, but super simple. I don't consider git as the first tool of choice due to its complexity. I worked on many issues with John Mehr in gitup, have been using it now for years, with very little pain.
(In reply to Michael Osipov from comment #16) > it comes with a huge amount of dependencies which not everyone wants to have on the system The git-lite or git-tiny packages are much more palatable options (to me as well). We are definitely best served by recommending git as the first and best choice, but describing the alternatives (including the alternate git packages) gives people the tools to make their own decisions.
This bug report is for documentation, and opening comment 0 was clear: > … document how to use gitup. … For alternatives to gitup, please take discussion elsewhere. Thank you.
See also: bug 273359
Remove unneeded Cc: .
I seriously wonder what's with portsnap reliability. In the early days and with my system crashing due to HW issues and broken file systems, I managed to break things, but nothing that a "rm -rf /usr/ports ; portsnap fetch extract" could not have fixed in a flash. The same about people finding git overcomplex. A port user who is not developing anything will never use format-patch, apply/am, thereabouts, but I will provoke things a bit and claim that everyone corrupting their git checkout have tried to cheat the git tool, followed outdated incorrect third-party documentation, or have an otherwise unreliable system that crashed (checking on fsync() or thereabouts). Before we use {SVNTOOL}up - concretely gitup - at scale, we never know what its quirks are and how reliable things are, but I see it's immature (for instance, https://github.com/johnmehr/gitup/issues/94 as filed by Graham) I have yet (knocking on wood) to see a corrupted Git repo from official Git tools following Git recommendations. I personally would not want to distract people and fellow FreeBSD developers by recommending a tool that has issues (see Vladimir's exhibits in the comments above) and that I personally do not know and - in a port developer/contributor, committer role - do not want to waste time with.
(In reply to Matthias Andree from comment #21) > … portsnap … git … Can we focus on documentation of gitup? Thanks.