Re: Plans for git

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.
Well, I (mostly lurk) on the linux-nfs_at_vger.kernels.org mailing list,
where the Linux NFS work gets done.
What I see is the following, when someone has an enhancement/change
for the Linux NFS code.
Do I see one diff with all the changes in it...No.
I see anywhere from a few to over 50 email messages, each with
one little piece of the pie, out of git.

I have no idea how they review this stuff.
If I were stuck doing it, I'd end up creating an unpatched tree, copying it
and applying all the patches to the copy and then creating a single diff
to look at in phabricator, which does display the changes very nicely.

So, I hope that a transition to git does not encourage "lots of small
loosely related commits" to the FreeBSD repository.

Also, I find svnweb useful, mostly to look at the commits done to a
file in temporal (most recent first) order. The global serial revision
number is very nice, but so long as it is easy to see the temporal
ordering of changes, I can live with that.

> 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.
I, on the other hand, will have no use for this. I can easily keep track of
changes I do by naming file.sav, file.sav2,...
I like to carefully merge changes into the repository checkout after I've
tested them, taking a careful look at the changes as I go.
I find most of the subtle bugs (that wouldn't be detected during normal
testing) during this "code inspection".
--> I think anything that encourages another look at the change before
      commit is a good thing.
      Put another way, slow and careful is better than quick and easy, imho.

I've live with the transition, but to be honest, I know it won't make my
work better or easier, rick

You can easily revert commits, you can upstream it one by one, you
can upstream it with history.

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.

--
Christian "naddy" Weisgerber                          naddy_at_mips.inka.de
_______________________________________________
freebsd-current_at_freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"