## NetBSD with git so far

* [[mailing-lists/tech-repository]]
* [[projects/project/cvs-migration]]
* [[github]]
* [2011-10: Fossilizing NetBSD: The road to modern version control](https://2011.eurobsdcon.org/papers/sonnenberger/fossilizing.pdf)
* [2015-01: Core statement on version control systems](http://mail-index.netbsd.org/tech-repository/2015/01/04/msg000497.html)
* [2017-06: New home for the repository conversion](http://mail-index.netbsd.org/tech-repository/2017/06/10/msg000637.html)
* [2017-09: pkgsrc Commit Message Policy](http://mail-index.netbsd.org/pkgsrc-users/2017/09/12/msg025574.html)
* [GitHub.com/NetBSD](https://github.com/NetBSD)

### Low memory hosts:

* [tuning for git on low memory](http://mail-index.netbsd.org/tech-repository/2015/01/08/msg000520.html)

git appears to have slightly different memory characteristics depending on the
protocol used.  Over http I am able to get a full clone with all history on a
256 + 256 raspberri pi.  If you bump up the memory to 512 + 256 it makes ssh
possible, which means writes are possible.

The link above has some tuning I used to get memory requirements way down.

It should be noted that git support a "shallow" clone (--depth 1) which ignores
most history but allows commits and full development.
A shallow clone works on very small systems; I would guess 128MB + a little swap
is enough.

git is slow during 'status' by default since it searches the entire tree for a
change.  It will produce a warning with tunable options if the command runs
slowly.

*Update*

After some complaining on the git@ mailing list a patch has been produced which
drops the memory requirements down quite a bit.  I can now, without much tuning,
work on my 512 system.

### CVS in parallel

I do not think this is a good idea and do not plan to advocate for it.
Git does have a cvs server built-in but I have not taken the time to set it up
for testing because it is slightly involved and I don't see the purpose.

### Conversion

One-shot to create the new True Source.  I don't think there will be many cvs
hold-outs.

See above for CVS server provided if ongoing conversion is really desired.

### existing cvs dependencies & server setup

is there a list of these?  build systems?
The entire build infrastructure of NetBSD should (even without git) change into a "jobs"-oriented workflow instead of a "server"-oriented workflow.

Very recent (summer 2017) events have shown that the ability to move things around is very important.

ivanova (cvs.netbsd.org) will become git.netbsd.org already for pkgsrc. Our restricted shell has a hook for git* commands to be passed to git-shell.


### How should NetBSD be setup

High level- private box for write master using ssh, any number of additional
systems with read-only mirrors over http:// and git://

Also see a great description of how DragonflyBSD is setup:<br>
[dfbsd server setup](http://lists.dragonflybsd.org/pipermail/users/2015-January/207421.html)<br>
[dfbsd workflows](http://lists.dragonflybsd.org/pipermail/users/2015-January/207422.html)<br>
[dfbsd config](http://lists.dragonflybsd.org/pipermail/users/2015-January/207424.html)<br>

[In 2019, FreeBSD core team has appointed a WG to explore transition from Subversion to Git.](https://www.freebsd.org/news/status/report-2019-04-2019-06.html#FreeBSD-Core-Team)

[FreeBSD has moved to git](http://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html)
[More FreeBSD git docs](https://docs.freebsd.org/en/articles/committers-guide/#git-primer)

### how to install

git should fit into NetBSD src/tools easily.  I have not personally tested
cross compilation.

### workflows

See DragonflyBSD examples given above

There are many many workflows supported in git.  For the most part I think
NetBSD developers would follow the "feature branch" workflow from the main repo
(or private/semi-private clones before merge).

Public collaboration is a big feature of git since it can format patches into
at least two different email formats and they can be submitted to a bug report
or to a mailing list, which should allow clean apply.

A non-developer could also post a pull request to github or host his git repo
for a friendly developer to add as an origin and pull his branch.

Pull Requests using mailing lists https://patchwork.readthedocs.io/en/latest/


(git origin add future-developer http://example.com/~greatguy/src.git)


### log message formats

Try to references named branches/tags instead of sha-1's
Also using the dates for commits instead of commit id's

The only rules I know about git commit messages are that the first line is treated specially insomuch that it is shown in `git log --oneline` output.

Special commit messages you might have seen around "Closes CORE-1234" etc are commands being sent to commit hooks to interact with other systems (like bug trackers).

### how to convert

[NetBSD on github](https://github.com/netbsd/)

This has been working for years.

### No lock-in

I am unable to anticipate the next generation of SCM.
Don't do anything weird like change history and we should be fine.

Maybe when we have 30 years of project history it will be time to consider
restructuring the project.  :)

git is the most widely used VCS ever so it has the best chance of conversion tools existing.
No future tool will be able to exist without a git-conversion script.

---

I think this is less a function of the tool and more a function of the project not
allowing non-"standard" actions.

### Who, When, and How Long?

* ESR/IIJ/Joerg - convert
* sometime, eventually, maybe
* assumptions/proposal:

Assuming conversion starting from date(x) to freeze(y) is relatively easy, the
refinements of Joerg/ESR conversion can continue to run in read-only mode as they
do today.  This means the "switch" is a few hours only for:

1. cvs goes read only
2. history from last git conversion pull until now is appended
3. cvs is turned off
4. git is made available over ssh

### future considerations, internal tooling, & misc

ikiwiki's main backend is git so wikisrc and pkgsrc.org websites are better as git repos.

[RCS Id and more)[https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Keyword-Expansion] addresses RDS Id expansion specifically but consider not doing this in a 1:1 way in the future. These problems are likely solved by DragonflyBSD or FreeBSD already.

Very few systems should be relying on CVS _internals_ and should, generally, be able to replace a `cvs checkout` with `git clone` and that will be the extent of it. It's not a major concern but can't be done until decisions are made.

### Addressing specific workflow concerns

The ability for CVS to checkout subdirectories appears to be a frequently requested feature. Git provides a way to do this using [[sparse checkouts|https://git-scm.com/docs/git-sparse-checkout]]. Let's demonstrate another neat feature [[worktrees|https://git-scm.com/docs/git-worktree]] so we can have multiple parallel branches checked out of `/bin/sh`

doing parallel development of a specific tool efficiently. Repeat this into as many worktrees as you want.


```
cd netbsd.git #my clone

#make a new worktree and branch named new2
git worktree add -b new2 --no-checkout ../new2
cd ../new2 #only contains a .git/ dir

#--no-cone avoids grabbing top-level files
git sparse-checkout set --no-cone bin/sh

#check on things
git sparse-checkout list
#output
# bin/sh

#get the files
git checkout new2

#did it work?
find ./ -type d
./
./bin
./bin/sh
./bin/sh/funcs
./bin/sh/USD.doc
./bin/sh/bltin

git status
On branch new3
You are in a sparse checkout with 1% of tracked files present.

nothing to commit, working tree clean
```