HEADS UP: FreeBSD changing from Subversion to Git this weekend

ralphbsz

Son of Beastie

Reaction score: 1,852
Messages: 2,841

* Github stores git repositories.
True. But git repositories can also be stored many other places. I think I have at least half a dozen at home for my personal software, and they are only stored on my home server, and nowhere else (in particular not on GitHub). Matter-of-fact, because of git's distributed nature, there is typically not one "server" repository and many "clients", but repositories are equivalent. Anyone who downloads the complete source will have a repository on their own computer. And in theory could re-distribute their own repository to other people, and start a whole separate tree. However, there is typically or a few repositories from which official builds are made.

* FreeBSD has a copy of their repository on Github.
True. But it is only one of many copies. I could make a copy of the source (honestly, I've rarely downloaded the FreeBSD source in my life), and modify it to my heart's content, and redistribute it, if I felt like it.

* The master copy of the FreeBSD repository is not on Github.
That's the copy from which the official builds are made, and which the official developers work on.
 

msplsh

Well-Known Member

Reaction score: 130
Messages: 402

Had reason to try this

pkg install git-tiny
(installs 0 dependencies on my system)
git clone -o freebsd -b releng/12.2 --depth 1 https://git.freebsd.org/src.git /usr/src

Well, that was easy...
 

chrcol

Well-Known Member

Reaction score: 48
Messages: 457

Why not keep the custom kernel files in a branch? Looks like git stash apply will keep all your previous stashes. Won't that get confusing after a while? Also keeping your kernel configs in a branch will let you diff arbitrary versions, etc.
I have no idea on git syntax, I always felt svn is way more user friendly thats why I asked on here. :) Thanks
 

ralphbsz

Son of Beastie

Reaction score: 1,852
Messages: 2,841

Look on the web for a SVN to git translation table. I'm sure they exist. When I started using Mercurial (both at work and at home), I printed a translation table of git -> hg commands and taped it on the edge of my monitor at work.
 

scottro

Daemon

Reaction score: 664
Messages: 1,721

Thanks, been running a laptop that right now requires CURRENT for video to work right. This means upgrading pkgs often messes things up. Looks like it (13.x) is almost on schedule, I'll probably wait till an RC is released to change the laptop though.
 

T-Daemon

Daemon

Reaction score: 610
Messages: 1,283

... been running a laptop that right now requires CURRENT... Looks like it (13.x) is almost on schedule...

I hope this is not seen as nit-picking addressing this minor detail (I have been recently accused doing so by focusing on such), CURRENT (git main) is now 14, after stable/13 has been branched.

This means upgrading pkgs often messes things up.
Since stable/13 has been branched on 01/22/2021 a new drm-kmod port (package), graphics/drm-fbsd13-kmod, has been introduced, upgrading might go more smoothly.

I'll probably wait till an RC is released to change the laptop though.
Meanwhile, maybe you are interested, there is an FreeBSD-13.0-ALPHA2 image availaible, freebsd-update(8) should be working.
 

scottro

Daemon

Reaction score: 664
Messages: 1,721

Thanks for the updates. I may try that, and no, it's not nitpicking, it's giving the correct information. I guess I should, if getting into this, start another thread, as I'm taking it way off topic, but I do thank you for the information.
But on topic, seems I can get that source with

git clone -b stable/13 , etc.
Doing that, and running
egrep "^REVISION|^BRANCH" newvers.sh
gets me
Code:
REVISION="13.0"
BRANCH="ALPHA2"

(but freebsd-update isn't working with it yet)
 
Last edited:

Jose

Aspiring Daemon

Reaction score: 462
Messages: 608

I have no idea on git syntax, I always felt svn is way more user friendly thats why I asked on here. :) Thanks
I have a love-hate relationship with the Git stash. It can be awfully handy, but it can also cause confusion if you abuse it. Typically something like this happens. I'm working along, and I need to pull in some changes that someone else has committed. Let's look at a contrived example using the Freebsd source:
Code:
$ git status
On branch releng/12.1
Your branch is up to date with 'origin/releng/12.1'.

nothing to commit, working tree clean
$ vi README
$ git pull
error: cannot pull with rebase: You have unstaged changes.
error: please commit or stash them.

Arrgh, I have some changes I'm not ready to commit, but I really, really need to rebase to upstream. I know, I'll stash them
Code:
$ git stash
Saved working directory and index state WIP on 12.1: e30782bbdad Fix OpenSSL NULL pointer de-reference.
$ git stash list
stash@{0}: WIP on 12.1: e30782bbdad Fix OpenSSL NULL pointer de-reference.
$ git pull
remote: Enumerating objects: 5277, done.
remote: Counting objects: 100% (5277/5277), done.
remote: Compressing objects: 100% (86/86), done.
remote: Total 12398 (delta 5230), reused 5194 (delta 5191), pack-reused 7121
Receiving objects: 100% (12398/12398), 9.88 MiB | 12.83 MiB/s, done.
Resolving deltas: 100% (8989/8989), completed with 3679 local objects.
From https://git.freebsd.org/src
   fb6bc290fb3..94ac312a716  main                                                  -> origin/main
...
$ git stash pop
On branch releng/12.1
Your branch is up to date with 'origin/releng/12.1'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   README

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (e6a9cef2a2a028c06ac996b885f6168c54110ced)
$ git stash list

So far so good. You might notice I used "pop" instead of "apply". The pop applies the most recent change, and then drops it. My stash is empty afterwards. The stash is a last-in, first-out stack of changes. Let's say I stash multiple times.
Code:
$ git status
On branch releng/12.1
Your branch is up to date with 'origin/releng/12.1'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   README

no changes added to commit (use "git add" and/or "git commit -a")
$ git stash list
stash@{0}: WIP on 12.1: e30782bbdad Fix OpenSSL NULL pointer de-reference.
stash@{1}: WIP on 12.1: e30782bbdad Fix OpenSSL NULL pointer de-reference.

I've made three conflicting changes to README for this contrived example. The change in the working tree (notice README is marked as "modified") will conflict with the last change I pushed on to the stash. Let's see what happens when I try to pop it.
Code:
$ git stash pop
error: Your local changes to the following files would be overwritten by merge:
    README
Please commit your changes or stash them before you merge.
Aborting
The stash entry is kept in case you need it again.
$ git stash list                                                                              
stash@{0}: WIP on 12.1: e30782bbdad Fix OpenSSL NULL pointer de-reference.
stash@{1}: WIP on 12.1: e30782bbdad Fix OpenSSL NULL pointer de-reference.

Now what? I have to git stash show -p
Code:

$ git stash show -p                                                                           
diff --git a/README b/README
index aad363baf9e..7aa1dfb46c7 100644
--- a/README
+++ b/README
@@ -78,3 +78,4 @@ For information on synchronizing your source tree with one or more of
the FreeBSD Project's development branches, please see:

   https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html
+bar
diff --git a/README.md b/README.md
index 72bd634cd81..939b885a59c 100644
--- a/README.md
+++ b/README.md
@@ -80,3 +80,4 @@ For information on synchronizing your source tree with one or more of
the FreeBSD Project's development branches, please see:

   https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html
+foo

Notice this shows the newest change first (again the stash is a LIFO). This is not too bad because this is a shallow stack with trivial changes. Imagine if you had dozens of stashes with non-trivial changes in them. That's the situation you're setting yourself up for because git stash apply does not drop stash entries after it applies them like git stash pop does.

I'm re-reading this and I'm not sure I'm being clear. Questions and comments welcome.
 

olli@

Aspiring Daemon
Developer

Reaction score: 1,002
Messages: 956

Look on the web for a SVN to git translation table.
It’s not that easy. Subversion and Git have quite different paradigms, so you cannot translate all commands one-to-one.

For example, with Subversion you can check out a source tree from a server (e.g. from FreeBSD’s public subversion repository). You cannot do that with Git, because Git doesn’t work that way. Instead, you have to clone a repository (or a branch) to your local machine. As a result, you have a clone of the repository, plus a working tree. (Beware, Subversion’s term “checkout” has a different meaning with Git.)
 
Top