Version control on FreeBSD

[SirDice]

I don't like anything proprietary holding my source code.

What do you think is proprietary with git?

 

[kpedersen]

For me, it is: "yyyy.mm.dd-hhmm code name.rar"
I don't like anything proprietary holding my source code.

The .rar format is proprietary (and obsolete)

Or did you mean you don't like binary database files when it comes to backups? Possibly CVS might be a better choice. It is all plain text RCS files.

 

[bgavin]

Obsolete or not, RAR is highly effective and very stable.
ZIP is probably obsolete, but support for it isn't going away anytime in the foreseeable future, either.

RAR is the only compression engine I've found that I can call with a full command line to archive files and reset the archive bit.
I've written an entire backup application that manages space, etc with RAR as the compression engine.
7Zip does not offer anything like this.

 

[bgavin]

What do you think is proprietary with git?

It's in the cloud and requires internet access and an account to reach it.
git isn't anything I'm interested in pursuing.
One of my customers got royally burned by the Dell Vault, and that does color my opinion about internet storage.

 

[sko]

It's in the cloud and requires internet access and an account to reach it.

are you confusing git with github by any chance?
git has nothing to do with 'cloud' nor requires any internet or network access...

 

[Eric A. Borisch]

It's in the cloud and requires internet access and an account to reach it.
git isn't anything I'm interested in pursuing.
One of my customers got royally burned by the Dell Vault, and that does color my opinion about internet storage.

Git is completely distributed. Use it entirely locally if you like, or across the network to other systems you control, or (only if you want) with a web repository service like GitHub or GitLab… or set up www/gitlab on your own machine if you want a web interface, just not one run by someone else.

As I mentioned above, it’s very easy to get started: git init . && git add * && git commit -m “initial commit” and you have saved the current directory’s contents into an entirely local git repository (in the .git/ directory created wherever you pointed git init). To see what has changed at some point later, a simple git diff is what you need.

So don’t cut yourself off from using git (the tool) over a distaste or mistrust (not entirely unfounded) of a website and concerns of future enshittification.

 

[astyle]

I have to admit, I used to be confused over the differences between gitlab and plain git. What makes matters worse is that when I try to look for a proper git command on Google, I get hits that are applicable to github, rather than plain git...

 

[decuser]

I use fossil for anything that will outlive the current environment and git for /etc.

As root:

cd /etc
git init
git add .
git commit -m "initial commit"

Make lots of changes, then git diff, then:

cd /etc
git add .
git commit -m "made a lot of changes"

Rinse and repeat.

But, like I said fossil for everything else. It's better, in my view. I used RCS back when, then SVN, then Mercurial, then Git, but about 2 years ago, I got tired of trying to figure out where the branches went wrong, how merge stuff, how to serve it up via web, etc. and switched to fossil. It works great. I run the server via inetd.

 

[kpedersen]

Obsolete or not, RAR is highly effective and very stable.

I still use Acrobat Exchange on Windows 3.1 so I agree, what works, works.

Both are proprietary too unfortunately.

 

[bgavin]

NTBackup was widely used, and totally proprietary.
When Microsoft killed it, any existing files in that format became unusable.

When I was at IBM, the 3420 tape drive was the staple for archival data storage.
Thousands of these tapes were collected for environmental data, and all are now unreadable because the 3420 no longer exists.

I'm perfectly happy with RAR because I can always take a machine out of mothballs and load on a VM if push came to shove.
Then again, my VMware is proprietary also.
The common denominator: none of it is in the cloud, nor subject to the whims of cloud loss or management.

My critical RAR backups are kept on an offline series of disks, and away from any contamination by ransomware.
git/github never interested me, as they seem clumsy and hard to use.
Then again, I'm not a native 'NIX guy either.

 

[PMc]

git/github never interested me, as they seem clumsy and hard to use.
Then again, I'm not a native 'NIX guy either.

I understand that; I don't like it either. It's not really clumsy, but they turned things around: version control is all about order and discipline, and to our thinking this usually means some top-down layout. But they did the opposite, they made it a decentral structure with no implicit authority.
And yes, it works. But it's not intuitive, not self-explanatory - it feels like something is standing on their head.
But we can't help it, so I just made my comment, and that's it.

 

[PMc]

concerns of future enshittification.

Thanks for this one, it is wonderful! I just walked it in my mind during my evening walk, and it gets on and on!
The explanation sounds as this is an entirely professional business sciences term - but trying to literally translate it into German yields an already existing and commonly used word, and that one is a colloquial diminuitive for the word: lie. Perfect!

 

[ccammack]

For those of you using version control for config files, how do you track only the files that you care about? Three options I'm aware of:

1. Nothing special - add the files you care about. git status will just list a bunch of stuff in "untracked" files.
2. Ignore * and force add the files you care about.
3. Make a repo with only the files you care about outside of /etc, and copy them into place as needed.

I like the bare git repo method, but there are a lot of untracked files to wade through. I think this could be improved with a wrapper script for dotfiles, but I haven't written it yet, so I might be completely wrong. Here's the theory:

Most of the time, I only want to see files in dirs that are already under version control, so when I call wrapper status, I actually want the wrapper script to first call git --git-dir=$gd --work-tree=$wt ls-tree --full-tree -r --name-only HEAD to generate a list of dirs in the repo, then call git --git-dir=$gd --work-tree=$wt status -- $dirs to restrict the status command to only consider those dirs. This should prevent the flood of unrelated untracked files in the output.

To occasionally display untracked files in specific a dir that the wrapper would otherwise skip because it hasn't been added to the repo, the wrapper script should also have a -d <dir> option that uses the specified <dir> instead of running ls-tree. That way, running wrapper -d $HOME status would reproduce the existing flood of untracked files that you see now using option #1, and running wrapper -d . status would only show untracked files in the current dir to make it easier to focus on a few files at a time.

Please let me know if anyone sees a problem with this approach or discovers anything out there that solves this problem already.

 

[Eric A. Borisch]

I like the bare git repo method, but there are a lot of untracked files to wade through. I think this could be improved with a wrapper script, but I haven't written it yet, so I might be completely wrong. Here's the theory:

If you're only interested in files you are already tracking, use git status -uno (see git-status(1)).

Note you can also explicitly set files/paths/wildcards you are not interested in seeing via .gitignore file(s). (See gitignore(5).)

git is a very widely used tool, and widely used by programmers who tend to like to be configure a tool to be used just so. I would assume that most things you want to do with it are already implemented, and would suggest spending some time looking to see if that's the case before writing wrappers around it.

 

[ccammack]

If you're only interested in files you are already tracking, use git status -uno (see git-status(1)).

For this purpose, I'm interested in all files from dirs that contain files that are already being tracked (and any untracked files in their subdirs), which is not the same thing as hiding untracked files. Perhaps -uno could be used to generate that initial directory list like ls-tree does, but it doesn't solve the basic problem, which is to exclude the flood of untracked files at the work-tree level, but show the untracked files and changed files at a level somewhere down below the work-tree level.

Note you can also explicitly set files/paths/wildcards you are not interested in seeing via .gitignore file(s). (See gitignore(5).)

Yes, and patmaddox mentioned this already as option #2. I'm suggesting a 4th possible option, which may or may not work out.

git is a very widely used tool, and widely used by programmers who tend to like to be configure a tool to be used just so. I would assume that most things you want to do with it are already implemented, and would suggest spending some time looking to see if that's the case before writing wrappers around it.

*plonk*

 

[Eric A. Borisch]

For this purpose, I'm interested in all files from dirs that contain files that are already being tracked (and any untracked files in their subdirs), which is not the same thing as hiding untracked files.

Aha. I didn't pick up on this subtlety.

I think I would head down the .gitignore path (to exclude directories you never have interest in) in this case, but that's just me. Note you can switch things around to have an allowlist of not-ignored items/directories in your .gitignore, if that's easier.