On 2020-09-20 12:28, Andriy Gapon wrote: > Just my +100500 to this. > > On 20/09/2020 18:03, Christian Weisgerber wrote: >> On 2020-09-19, Zaphod Beeblebrox <zbeeble_at_gmail.com> wrote: >> >>> Hrm. Maybe what I hear others saying, tho, and not entirely being replied >>> to is just a nice concise document of the why. What I hear you saying is >>> that GIT has momentum and that it's popular... (and I accept that --- it is >>> evidently true), but then I hear handwaving about features, but no list of >>> features that are a clear win/loose. >> >> How about the very basics (that Warner appears to have lost sight >> of)? >> >> Git is a distributed version control system. You clone a repository >> and apart from pulling and pushing changes to another repository, >> all your work happens with the local repository. Subversion has a >> central repository and needs to talk to the server all the time. >> Laptop on a plane? No change of workflow with Git. >> >> And since it's your repository, you can cheaply create your own >> branches, where you can commit your work and have a versioned history >> of it instead of just a flat diff. I can't overstate the value of >> that. Whether you work on something that will be pushed back >> upstream or just your private changes, it has a full commit history. >> You can easily revert commits, you can upstream it one by one, you >> can upstream it with history. Back in 2009 I had my small dev group using git-svn to allow us all to work remotely with at least *some* flexibility against the $JOB svn repo. The svn interactive response was dreadful over our DSL connections. I flew to SF to the $JOB hq and purposely made a few offline commits on the plane. Then at the office I merged them, trivially. None of the devs there had any experience with git. It blew their minds. (obvs any other DVCS can do that too) git can seem to have bottomless command line complexity from the point of view of a casual user. I look at the answers to edge case problems posted on SO and just laugh. People have careers being git specialists. However you don't need to know much to get very productive. And if you use emacs, there is no debate that magit is a stellar interface to git, maybe the very best. I believe I've heard noises about its functionality being replicated into vim. Once you use something like magit even complex operations have very little cognitive overhead. For example, picking the exact changes you want to commit together from an already coded larger set of changes is easy. I'm always fixing eg. doc nits when I see them, when working on code/bugs and then later group those into their own commit. Maybe you can do that now in svn but it is a pleasure with magit. just my 2ยข Russell >> >> When FreeBSD switched from CVS to SVN, there was hope or promise >> of lightweight branches, but that never materialized. Developers >> still can't have private branches in the FreeBSD repository. For >> a while, a lot of development happened in a Perforce repository--a >> commerical version control system, whose company had donated a >> license--which offered this feature. Nowadays, everybody who does >> any but the most trivial development does so in a private Git >> repository anyway. It only makes sense to interface this directly >> with the FreeBSD repository instead of going through a SVN<>Git >> media break. >> >>> Certainly the only clear things a quick search turns up that seem relevant >>> is that GIT is GPL2.0 and SVN is Apache2.0. This was enough for LLVM vs >>> GCC and the repository is a core function, but I suppose not a necessary >>> function for forked projects that can't abide, so... >> >> There is a bit of historical precedent: The original BSD work at >> Berkeley was kept in a SCCS repository, a proprietary version control >> system at the time. >> >> And of course the fact that significant FreeBSD development has >> effectively happened in Perforce, then in Git for a long time and >> is just merged back into the Subversion repository. To put it >> bluntly, the people doing the work have voted with their feet years >> ago. >> > >Received on Sun Sep 20 2020 - 18:54:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC