Solved Help with migration to git

[PMc]

And as for git usage: You can create as many clones as you like, but why would you, just for looking at a different branch?

While building (e.g. world), one certainly cannot switch the branch. And building tends to take a while.

And typically, while I glance at the output of the test build, I suddenly remember those security patches for the production version which I wanted to apply. Or something similar.
(I do already run the scripted builds from zfs snapshot/clone, for that reason.)

 

[Jose]

Ahh, thanks for mentioning, this brings up the backup topic. And while one does not want to copy the whole repo into some backup stprage, the local patches are certainly worth being cared for.

Copy the whole repo is what I would do when I was learning Git, and I was fixin' to do something dangerous. A git directory is completely self-contained. All the metadata lives under the .git directory. Some of it is plain text files, like the .git/config file. I'm a big fan of this simplicity.

You can even get really fancy and set up a copy of your Git repository as a local remote. I found use for that when I had to walk away from a Git repo, but wanted to git-cherry-pick(1) some good commits out of the b0rked copy.

 

[zirias@]

While building (e.g. world), one certainly cannot switch the branch.

If you REALLY run into a situation where you MUST look at two different branches in your filesystem at the same time, you can still just clone the repo locally (this won't touch the working copy of the repo you're cloning, so it doesn't matter when a build is running). Local clones are special, they use hardlinks wherever possible, to save space and time for cloning. So, you could for example do something like this:

git clone -b releng/13.0 --single-branch /usr/src /usr/src-13rc2

Of course --single-branch is just an example here, you might want a clone with all branches, you can use this for your *local* branches just as well, you can even do commits in the cloned repository and push them back to your original one later. Welcome to a "real" SCM

 

[PMc]

This is not tested, but something like

# Initial setup
git switch -c local-desktop1 origin/branches/2021Q1
(make some changes)
git add (...)
git commit (...)

# Update upstream branch
git fetch branches/2021Q1
git switch local-desktop1
git rebase origin/branches/2021Q1

# New quarterly branch
git fetch branches/2021Q2
git switch local-desktop1
git rebase origin/branches/2021Q2

The last line did not work as intended. It did rebase not only the local commits, but also the public security fixes that went into 2021Q1, resulting in lots of merge conflicts.

With the help of the manpages I then was somehow successful with this:
git rebase --onto origin/branches/2021Q2 origin/branches/2021Q1 local-desktop1
git branch --set-upstream-to origin/branches/2021Q2

Then I tried if one could daisy-chain those branches (as I am quite tired of editing the same patch for N machines), i.e. create a
local-general, based on origin/branches/2021Q2 (for all the common local patches), and then a
local-desktop1, based on local-general, for the things specific to this machine (e.g. kernelconfig)
And this seems to work also.

OTOH, the versatility has a downside. I created a local branch from Rel 10.2, changed something in etc/syslog.conf, and added a new file into etc/ppp.
Then I did rebase the local branch to Rel 12.2. This did run without any error or warning.

The etc/syslog.conf does no longer exist in 12.2. It is now in sbin/syslog. The patch was nicely moved along to the new location.
The etc/ppp directory does also no longer exist in 12.2, as the content has been moved to usr.sbin/ppp. Now it was created and the new file is still there.

Certainly those actions taken are the most practical solution to handle such things. But, looking at the history now does not give much clue about what has happened. There seems no way to list commits with the changed files (except full diffs), and no information whatsoever seems to exist about where the change was originally created, or on which branch.

So I think I got the point why You guys warn about rebase being dangerous. It practically destroys the history.

But then, looking further, there are solutions to this specific issue as well: for archiving purposes the local branch could just be copied and kept attached to Rel. 10.2 (there seems to be an abundance of cheap branches available ), and then the new copy could be rebased to 12.2 with the interactive option, manually verifying that the patches are still placed appropriately - and eventially updating the commitlog texts as necessary. I think that would be proper for a smaller set of local fixes which have to be verified anyway during major release upgrades.

Copy the whole repo is what I would do when I was learning Git, and I was fixin' to do something dangerous.

I'm considering it a bit different: system patches belong into the offsite backup (they are required to get your site back at all) - and only the .git directories make about 2.5 GB compressed. My offsite backup used to live on a stick - now I have some cloud, but periodically moving such an amount through a weak dsl uplink is also not really what I like, given that it's mostly redundant.

But there seems to be a nicer approach. There is a file .git/config:

[...]
[branch "main"]
        remote = origin
        merge = refs/heads/main
[branch "releng/12.2"]
        remote = origin
        merge = refs/heads/releng/12.2
[branch "releng/10.2"]
        remote = origin
        merge = refs/heads/releng/10.2
[branch "local"]
        remote = origin
        merge = refs/heads/releng/12.2
[branch "local-at-10.2"]
        remote = origin
        merge = refs/heads/releng/10.2

Now just create a command from grouping this data git bundle create Backupfile refs/heads/main..main refs/heads/releng/12.2..releng/12.2 refs/heads/releng/10.2..releng/10.2 refs/heads/releng/12.2..local refs/heads/releng/10.2..local-at-10.2 and this is the backup.

Welcome to a "real" SCM

Hehe!

BTW, is this a bug?

$ git log
commit 15d8ad6b102338f3674f4c145c543813353bfc55 (HEAD -> local)
$ git log | cat
commit 15d8ad6b102338f3674f4c145c543813353bfc55

Not only the annoying color is removed, the whole info is removed.

 

[olli@]

BTW, is this a bug?

$ git log
commit 15d8ad6b102338f3674f4c145c543813353bfc55 (HEAD -> local)
$ git log | cat
commit 15d8ad6b102338f3674f4c145c543813353bfc55

Not only the annoying color is removed, the whole info is removed.

No, it’s not a bug.
When stdout is a TTY, git(1) prints additional information and formatting for human consumption.
When stdout is not a TTY, it assumes that it’s output is being parsed by another script or program, so it produces simplified output.

BTW, quite a lot of programs behave differently depending on the TTY. For example:

olli@ryzen:~ > vmstat
procs  memory       page                    disks     faults         cpu
r b w  avm   fre   flt  re  pi  po    fr   sr nd0 nd1   in    sy    cs us sy id
1 0 0 585G   29G   433   0   0   0   524  234   0   0   44 20924  2580  0  0 99

olli@ryzen:~ > vmstat | cat
procs       memory         page                       disks     faults         cpu
r b w       avm      fre   flt  re  pi  po    fr   sr nd0 nd1   in    sy    cs us sy id
2 0 0 613221524 29991256   433   0   0   0   524  234   0   0   44 20922  2580  0  0 99

 

[Jose]

The last line did not work as intended. It did rebase not only the local commits, but also the public security fixes that went into 2021Q1, resulting in lots of merge conflicts.

That is very annoying. I wonder if it's a side-effect of the fact that the canonical repo is still Subversion. I'll have to try this and see after the cut over to Git happens.

 

[PMc]

That is very annoying. I wonder if it's a side-effect of the fact that the canonical repo is still Subversion. I'll have to try this and see after the cut over to Git happens.

Probably not - I think I tried it with the src repo...
But found the behaviour logical: somehow the thing must be told from exactly which branchpoint onwards it should move the commits around.
And over all I am quite happy with it all - it seems to be possible to arrange things in a way I would like, and to keep track of them (well, more or less) - so I could put my stuff into a new design.
(I am not so happy about the 3500 loc shellscript that have grown over 20 years and do the builds currently. )