I only have a handful of additional patch files (read: untracked files) in my ports tree, that git is not aware of. For the time being I'd like to keep it that way and I guess that shouldn't be a problem then?
I only have a handful of additional patch files (read: untracked files) in my ports tree, that git is not aware of. For the time being I'd like to keep it that way and I guess that shouldn't be a problem then?
portsnap fetch update
pkg version -vIL=gitup ports
make fetchindex
pkg version -vIL=
It's as much a problem as it was with SVN. but as long as you don't commit these to your local branch tracking main from freebsd,
--ff-only won't have any effect.git pull
git checkout -b local
git add mycat/addedport
git commit
[edit commit message: "add port mycat/addedport"]
git add devel/frobnicate/Makefile
git commit
[edit commit message: "devel/frobnicate: fix build with libfoobar"]
[…]git fetch origin main:main
git rebase mainI have no intention of committing those files.
I'd rather call those additions than changes, as these are all additional files that live in the corresponding port's files directory. So no file under version control is actually changed. Most of these are additional patches that get applied during the patch phase when building the port. The only exception is an .asterisk.makeopts file which is pretty much expendable, as it can easily be recreated. And from your explanation it seems that I would have to perform additional steps each and every time I update the ports tree, so I don't think it's worth it for the time being.
Again: stop putting words in my mouth. If you must go round in circles and read between the lines, please be correct about what's between.
-o <name>, --origin <name> appears in git-clone(1) however I know so little about git, I can't tell the reason(s) for inclusion or omission in cases such as this. % git clone -o freebsd $URL -b branch [dir] -o in the earlier review copy at https://hackmd.io/hJgnfzd5TMK-VHgUzshA2g#Normal-Clone There are two ways to make a Git repository appear on your filesystem. You can go into a directory and type git-init(1). You'll now have a brand-spankin' new Git repository with no commits in it. It will also not have any connections to any remote repositories. It will bask in its unique snowflake nature until you connect it to the mean and nasty Internet.
-o flag is for, to specify a different name for the remote whence the repo came.
-- it's fixed for 0.91 which I'll be pushing out once proxy support is fully implemented (hopefully soon).
zfs snapshot flash/usr/ports@portsnap
zfs create flash/usr/ports_git
zfs set mountpoint=/usr/ports_portsnap flash/usr/ports
zfs set mountpoint=/usr/ports flash/usr/ports_git
vi /usr/local/etc/gitup.conf
"ports" : {
"repository" : "/ports.git",
"branch" : "main",
"target" : "/usr/ports",
"ignores" : [
"distfiles",
"packages",
],
},
gitup ports -v 1
# Host: git.freebsd.org
# Port: 443
# Repository: /ports.git
# Target: /usr/ports
# Want: d73721414d8ded2d68448effc25c895057225a0e
# Branch: main
# Action: clone
portversion -vl "<"
[Reading data from pkg(8) ... - 1474 packages found - done]
Fetching the ports index ... /usr/bin/env fetch -am -o /usr/ports/INDEX-13.bz2 https://www.FreeBSD.org/ports/INDEX-13.bz2
/usr/ports/INDEX-13.bz2 2271 kB 2448 kBps 01s
done
[Updating the portsdb <format:bdb_btree> in /usr/ports ... - 31029 port entries found .........1000.........2000.........3000.........4000.........5000.........6000.........7000.........8000.........9000.........10000.........11000.........12000.........13000.........14000.........15000.........16000.........17000.........18000.........19000.........20000.........21000.........22000.........23000.........24000.........25000.........26000.........27000.........28000.........29000.........30000.........31000 ..... done]That's exactly the scenario
The benefit is to have your own history with meaningful commits, the ability to track your own changes and easily correct mistakes, and a much easier way to resolve any conflicts should they ever happen. It's nothing you have to do, just a nice tool. To take full advantage, you'd have to learn how to work with "rebase", e.g. from here: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
git stash. This will be obligatory if you ever run into a conflict, then you'll have to git stash before you can successfully git pull. To get your changes back afterwards, write git stash pop. In that case, the "stash" is kind of a single commit that will be rebased onto your working copy with "pop". It's your decision whether this is good enough for you. I just recommend the local branch for easy management of several unrelated changes Uhm, I don't think having to issue two commands (a merge and a rebase) for updating instead of just one pull command is really a drawback
Sure, walking a large tree takes time, but attributing a difference of magnitudes to it still looks like ignoring a problem…
sys/usr/ports used 3,89G -
sys/usr/ports referenced 3,89G -
sys/usr/ports compressratio 2.62x -
sys/usr/ports compression lz4 local
sys/usr/ports copies 1 default
sys/usr/ports dedup off default
sys/usr/ports logicalused 5,85G -
sys/usr/ports logicalreferenced 5,85G - git clone -o freebsd --single-branch --depth 1 https://git.freebsd.org/ports.git . the usage is quite different:sys/usr/ports used 789M -
sys/usr/ports referenced 789M -
sys/usr/ports compressratio 1.74x -
sys/usr/ports compression lz4 local
sys/usr/ports copies 1 default
sys/usr/ports dedup off default
sys/usr/ports logicalused 502M -
sys/usr/ports logicalreferenced 502M -I understand that it would make my life much easier if it were actually changes (that have a history) we're talking about, But the files in question are not present at all in the repo and are unified diffs against the original sources of a specific port. Nothing you would ever want to manually edit. Either those patches apply cleanly, or (if the original sources have diverged too much) you will have to manually merge the changes and then create a new diff. And given the fact we're talking about a total of 8 files relating to 4 ports, I don't think the additional overhead is justified. If at some point it gets more (and more complex) I would probably think about such a more organized solution though.
The "always bad thing" about switching from A to B is that your usual workflow no longer works, but you neither know nor are able to use the advantages of the new tool; you only get disadvantages at first.
With local changes, you should use git, not gitup.
Sorry, but that's totally wrong. You do realize that it took FreeBSD 2 or so years before they came to this decision and carried out the change? See 3 years ago I wrote this guide on Git. Back then it was the next new cool thing but after 3 more years?
Just traversing the ports tree (
find . >/dev/null) takes a little less than 2 minutes on one of my older machines that still has a HDD (i.e. rotating rust). And that’s without actually opening the files, let alone calculating checksums. This is UFS mounted with the noatime flag; otherwise it would probably take even longer.
Hm. I don't own any SSDs, my testing is on a raidz pool with 4 HDDs, and I can't reproduce any substantial(!) slowdown with gitup. But maybe ZFS' ARC helps a lot here?
Good question. I did my test with empty cache, because that’s the typical case when updating the ports tree. When I repeat the test immediately, the traversal is much faster, of course, because the whole ports tree is still in the cache. Also, I don’t have any RAID (I guess most users have only one disk for FreeBSD).
github.com
First time running on my desktop gave:
time gitup ports -v 1
# Host: git.freebsd.org
# Port: 443
# Repository: /ports.git
# Target: /usr/ports
# Want: 9aae35b48f216c96c71d782f0f14e3cfd6a70f90
# Branch: main
# Action: clone
Executed in 55.59 secs fish external
usr time 7.04 secs 512.00 micros 7.04 secs
sys time 14.61 secs 256.00 micros 14.61 secsroot@Tuna2 ~# time gitup ports -v 1
# Host: git.freebsd.org
# Port: 443
# Repository: /ports.git
# Target: /usr/ports
# Have: cf118ccf875508b9a1c570044c93cfcc82bd455c
# Want: 0997d61ae7a84a95b0e81febfac0e4da9a247ac2
# Branch: main
# Action: pull
________________________________________________________
Executed in 15.16 secs fish external
usr time 3.38 secs 514.00 micros 3.38 secs
sys time 7.19 secs 265.00 micros 7.19 secstime gitup ports -v 1
# Host: git.freebsd.org
# Port: 443
# Repository: /ports.git
# Target: /usr/ports
# Have: 0997d61ae7a84a95b0e81febfac0e4da9a247ac2
# Want: 0997d61ae7a84a95b0e81febfac0e4da9a247ac2
# Branch: main
________________________________________________________
Executed in 8.37 secs fish external
usr time 2.33 secs 0.00 millis 2.33 secs
sys time 5.13 secs 5.16 millis 5.13 secsIt's unfortunately not documented, AFAIK. That command was posted to
freebsd-ports a couple of days ago: -U switch: -m null and -M /path/to/git/ports to point Poudriere at a manually-maintained Git checkout of the ports tree.Disclaimer: I'm trying to help you. Let me know if I'm annoying you instead and I'll shut up. No need to read the following if that's the case.
2021Q1mychanges with your local port changesgit switch 2021Q1
git pull --ff-only
git switch mychanges
git rebase 2021Q1git switch -c 2021Q2 -t origin/2021Q2
git switch mychanges
git rebase 2021Q2git switch 2021Q2
git pull --ff-only
git diff mychanges..
