I'm trying to add the ability for my ArchLinux installer script to check if it's update-to-date based on rather it matches (or doesn't match) the version number that's on gitlab. The primary script that runs the installer (and all of the numbered script files) is the aalis.sh script, it basically goes and runs the other files together. The version numbering would be something like 1.2.3 (major.minor.patch). Basically, whenever I make any changes to the script, I will change the script's version number of gitlab; and I want the script itself to be able to detect that its version number doesn't the match the one on github (for cases where someone has an outdated version of the script and try to run it); and automatically update itself using git fetch origin master then rerun itself using the updated contents.

We are migrating from A VMS environment to a Linux environment for some old alpha servers we are decommissioning. The one challenge I have not been able to overcome is file versioning. VMS keeps multiple copies of the same file by using a version flag. I have found multiple options on SourceForge however I have not found anyone who has experience with any of these in a major production environment. The reson this is needed is because the feeds from other systems do not take unique file names into account. We are trying to keep our scope as light as possible. Any help is greatly appreciated. The 2 main ones that appear to be available are: - Wayback - EtcKeeper - not sure If you can apply it to only one directory or multiple. Has anyone used these in an enterprise environment? Are there other options I should be considering?

Use case: distribute zsh's history between machines in source control. Is that something that I can achieve with zsh's history -- put history in version control the sync between machines? This is to avoid re-typing commands and quick trace.

I have a plain text file (not containing source code). I often modify it (adding lines, editing existing lines, or any other possible modification). For any modification, I would like to **automatically** record: - what has been modified (the diff information); - the date and time of the modification. (Ideally, I would also like to be able to obtain the version of my file at a specific time, but this is a plus, not essential). This is surely possible with Git, but it's too powerful and complex. I don't want to deal with add, commit messages, push, etc. each time. I would simply like to edit the file with vi (or equivalent), save it, and automatically record the modification as above (its diff and its time). Is there a tool to accomplish this in Linux? ---------- **Update**: Thanks for all the suggestions and the several solutions that have been introduced. I have nothing against git, but I explicitly wished to avoid it (for several reason, last but not least the fact that I don't know it enough). The tool which is closest to the above requirements (no git, no commit messages, little or nothing overhead) is RCS. It is file-based and it is exactly what I was looking for. This even avoids the use of a script, provides the previous versions of the file and avoids the customization for vi. ---------- The requirements of the question were precise; many opinions have been given, but the question is not - per se - that much opinion-based. Then, obviously, the same goal can be achieved through a tool or through a script, but this apply in many other cases as well.

I've accidentally created two branches for my Git repository: main and master, which I now need to merge. However, when using ls on the command line while checked into main branch, some files on my computer don't show up (files that don't exist in the main branch on GitHub). When I use git checkout master the files "reappear". But they must always be on my hard drive, so why are they hidden from view when checked into this one branch?

From diffutils' manual > Next come one or more hunks of diff erences; each hunk shows one area > where the files differ. Unified format hunks look like this: > > @@ from-file-line-numbers to-file-line-numbers @@ > line-from-either-file > line-from-either-file... > > **If a hunk contains just one line**, only its start line number appears. > **Otherwise** its line numbers look like ‘start,count’. An empty hunk is > considered to start at the line that follows the hunk. > > **If a hunk and its context contain two or more lines**, its line numbers > look like ‘start,count’. **Otherwise** only its end line number appears. > An empty hunk is considered to end at the line that precedes the hunk. What do they mean? Could you also give some examples to show what they mean? In particular, I couldn't tell the differences between the cases in the last two paragraphs. They seem to talk about the same cases but I suspect they don't. - What is the difference between the "if" case in the first paragraph and the "otherwise" case in the second? - What is the difference between the "otherwise" case in the first paragraph and the "if" case in the second?

I tried to find answers to this issue but I am having a hard time to find the right keywords. So here is my issue. Dongled mini PC with some itchy software when it comes to patching the system. Is it possible to get updates only for a specific release and kernel version even if a newer OS is available? I have CentOS 7.5 18.04 running here and have been told that system will be upgraded automatically if a newer OS is available. Security patches for "older" OS are only available as RedHat for paying users. Is it possible to upgrade to the latest and greatest (security) mitigating a leap to newer versions?

Is there an RCS command similar to git status, svn status, and cvs status that can show the status of each file within a directory? For example, if a file has been modified since the last check-in, such a command should say that the file is "modified". In addition, it should show whether or not the file is locked (and locked by whom).

Suppose a file has 4 revisions (1.1 to 1.4). I deleted revisions 1.2 and 1.3 using rcs -o1.2:1.3 myfile.txt. Now I want to change revision number 1.4 to become revision number 1.2. How do I do this using RCS?

Version control software seems to be used for backing up project mostly in plain text files. For backing up a file system, with large amount of files or large size, regular file copying/transferring software such as rsync seems to me more proper? If not, what is the advantage and disavantage of version control for backing up a file system? How is version control worth more than regular file copying or transferring software?

I have installed RCS in Ubuntu 20.04 using sudo apt-get install rcs. The usual RCS commands such as ci, co, rlog, rcsdiff, rcsclean, etc. work as expected. However, rcsfreeze is missing. When I try to run rcsfreeze, I get rcsfreeze: command not found. Why is it missing? How do I get the rcsfreeze command?

I'm trying to use 2 github accounts on Ubuntu 18.04. I'm also using personal-access-tokens (PAT). Following the setup I'm trying to achieve. - Have 2 github accounts - main and work on the same pc. - All repos created inside the ~/work/ directory must automatically use the work name and email for commits while all repos outside this directory must use the main name and email for commits. - Use libresecret to remember the personal-access-tokens for both accounts (main and work) to push data to github from local. - Use personal-access-tokens instead of ssh. - Save credentials per account as opposed to per repository (as is the case with using useHttpPath. Here's what I've done. ### Step 1: add the main github account 1. $ git config --global user.name "Johnny" 2. $ git config --global user.email johnny@example.com 3. $ sudo apt install libsecret-1-0 libsecret-1-dev 4. $ cd /usr/share/doc/git/contrib/credential/libsecret/ 5. $ sudo make 6. $ git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret The above allows me to push code to my main github account without typing my username and password again and again. I only need to type it once and then libsecret takes over. ~/.gitconfig up to this point.

[user]
    name = Johnny
    email = johnny@example.com

[credential]
    helper = /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

### Step 2: add the work account I want all repos inside the ~/work/ directory to be associated with the second github account. I make the following changes - Global config ~/.gitconfig

[user]
    name = Johnny
    email = johnny@example.com

[credential]
    helper = /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

[includeIf "gitdir:~/work/"]
    path = ~/work/.gitconfig

Work specific config ~/work/.gitconfig

[user]
    name = John Doe
    email = johndoe@company.com

Now when I try to push my work code, I get the following error.

remote: Permission to work_username/mywork.git denied to main_username.
fatal: unable to access 'https://github.com/work_username/mywork.git/ ': The requested URL returned error: 403

I solved it by splitting credential management for multiple repositories run by the same host. 7. $ git config --global credential.github.com.useHttpPath true Final ~/.gitconfig:

[user]
    name = Johnny
    email = johnny@example.com

[credential]
    helper = /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

[includeIf "gitdir:~/work/"]
    path = ~/work/.gitconfig

[credential "github.com"]
    useHttpPath = true

### The Issue The issue is, I have to setup the username and password for every new repository I create once. Post that I can use it without having to type in the password every time. How can I let libsecret and git know to use different passwords for authentication based on directory in which the repository exists? This already happens for the commit name/email using IncludeIf. I want to somehow extend this to password authentication too.

I'm looking for a way to do version control on my conan package, locally (note that I'm new to conan and usually the reference used by my working place is the CI_PIPELINE_IID). I was thinking of doing a script that does: make, make install, and export-pkg. I was thinking of having an environment variable that gets incremented with each use of the script, or having a file with the number in it, that I would have to read and write to increment it. I wanted to know opinions since I'm fairly new to GNU/Linux.

I have an SD card image of an Armbian based Linux system. I have done several modifications at different places to this system and I'm looking for a solution to add some versioning information to this system and/or to track the changes of the system based on a given zero state. Are there any solutions to handle it?

I have for many years had my entire $HOME directory checked into subversion. This has included all my dotfiles and application profiles, many scripts, tools and hacks, my preferred basic home directory structure, not a few oddball projects and a warehouse worth of random data. This was a good thing. While it lasted. But it's gotten out of hand. The basic checkout is the same across dozens of systems, but not all that stuff is appropriate for all my machines. It doesn't even all play nicely with different distros. I'm in the process of cleaning house -- separating the data out where it belongs, splitting out some scripts as separate projects, fixing some broken links in stuff that should be automated, etc. My intent is to replace subversion with git for the toplevel checkout of $HOME, but I'd like to pare this down to just the things I'd like to have on ALL my systems, meaning dotfiles, a few directories and some basic custom scripts. **In reading up online a lot of people seem to be doing this using the symlink approach: clone into a subdirectory then create symlinks from $HOME into the repository.** Having had my $HOME under full version control for over a decade, I don't like the idea of this approach and I can't figure out why people seem so averse to the straight checkout method. **Are there pitfalls I need to know about specific to git as a top level checkout for $HOME?** P.S. Partly as an exercise in good coding, I'm also planning on making my root checkout public on GitHub. It's scary how much security sensitive information I've allowed to collect in files that ought to be sharable without a second thought! WiFi password, un-passphrased RSA keys, etc. Eeek!

So I have a git repository that I cloned from an upstream source on github. I made a few changes to it (that are uncommitted in the master branch). What I want to do is push my changes onto my github page as a new branch and have github still see it as a fork. Is that possible? I'm fairly new to git and github. Did my question even make sense? The easiest way that I can think of (which I'm sure is the most aroundabout way), is to fork the repo on github. Clone it locally to a different directory. Add the upstream origin repo. Create a branch in that new forked repo. Copy my code changes by hand into the new local repo. And then push it back up to my github. Is this a common use case that there's a simpler way of doing it without duplicating directories? I guess I'm asking here as opposed to SO since I'm on linux using command line git and the people here give better answers imo =]

What turnkey solutions exist to put /etc under version control, under various unices? Turnkey doesn't necessarily mean part of the base install, but the following features would be nice: * hooks into VCS commands to manage metadata (ownership, permissions); * integration with the package manager (run automatically before and after installations, handle upgrades intelligently); * treat upstream file versions as a branch; * a pre-filled ignore list; * support for several underlying VCS (especially distributed ones). I use [etckeeper](http://kitenet.net/~joey/code/etckeeper/) under Debian and derivatives. It has all the above features except that it doesn't keep track of upstream versions. I would like to learn about alternatives, particularly on *BSD.

What is correct way to keep track of bitbake configuration and used layers in git?

Is there a way to fetch the remote repository of a non-checked-out remote repository with git? I have the dotfiles on my remote PC under version control (using [yadm](https://yadm.io/)) . This repository is cloned on my local PC (also using yadm). But on my local PC I'm using a different dotfiles management utility ([rcm](https://github.com/thoughtbot/rcm)) which allows for more flexibility. Since yadm and rcm work on a different basis (symlinks to ~ vs. bare git into ~) I have to jump through hoops to try stuff using yadm on my local PC: * unlink my current symlink-dotfiles with rcm * checkout the yadm-repository To undo that I then have to * remove all the files which were cloned when checking out the yadm-repository * symlink the files with rcm This is annoying. Therefore I cloned the local clone of my yadm-repository into a different folder. While I'm able to see all the remotes in my local main yadm-repository, I'm only able to fetch HEAD in the cloned yadm-repository. It looks like that:

remote PC (1):                    commit a (old, not checked out), commit b (HEAD -> master)
local  PC - main repository (2):  commit a (HEAD -> master), commit b (origin/master, not checked out)
local  PC - other repository (3): commit a (HEAD -> master), commit a origin/master

So on my repository 3 I'm only able to see the commit a (which is checked out in repository 2), but not commit b (which is not checked out in repository 2, but should be available there). My question is now: how can I get commit b in my repository 3 and why doesn't that work by just git fetching everything? ----- Update 1: Minor edits to the text were performed to (hopefully) make the issue clearer.

I have a feature branch in git that needs to be up to date with the master branch at all times. Is there any way to automatize this in git? I basically want on every commit in master branch a merge into feature branch.