I have done some research. To copy the repo to protect against change, I should:

clone the remote repo into a local version.

create a new empty remote.

add the remote to the local repo and push.

Does this sound right?

Josheir

“push” and “fetch” are the core commands to exchange data with other repos. “pull” is a combined “fetch” and “merge”, so that exchanges data as well.

As long as you don't use those commands, no data is exchanged in my experience. Note that GUI apps for git repos typically do lots of transfers automatically in an attempt to keep both in sync, so avoid them in your experiments ?

“origin” is not black magic, it's only a convenient name map to save you from typing the full url-like address of the remote as an argument to push or fetch. Try “git remote -v”, that lists the name map. “git remote remove origin” deletes the entry, I don't know enough of git internals to know whether that fully erases all knowledge of the remote repo. (That is, does “git push” without further arguments resolve the remote destination address using the name map?)

Judging from the “.git/config” file (in the root of the repository) it should be:

[branch "master"]
        remote = origin
        merge = refs/heads/master

looks to me like master remote is resolved through the thing named “origin”, It doesn't have an url-address there.

Other options exist as well, you can back-up your checked-out repository copy to an archive file (it's just a directory tree, although it has symlinks at my system, so your archiver should be able to handle those), I always use ‘tar’ (tar czf repobackup20200323a.tgz path/to/repo).

If you make a mess, simply move the mess out of the way (or remove it) and restore by unpacking the archive.

Alberth, I have been under the weather, but I have just made a script that is broken in a way, but still works. I think I need to change my #s to REMs for example. Also, the merge is checking out the master branch. Just wanted to say thanks!

Josheir

You're welcome.

I used a Linux shell for that script, if you use a different command language, it likely needs a few changes. Comment isn't quite needed, but it is nice to read what it is supposed to do ?

Sure, assumption is on branch four with a change:

# to work, open with right click and left click open
# this works, however not reading # correctly and master is already checked out during merge
# must be checked out on new branch already that has a commit
# on branch and branch already exists, so:
# git checkout branch4
# consider changing # to REM
echo ------initial commit
git add .
git commit -m "creates this commit message."
git push --set-upstream origin branch4

# (on branch4)
echo ------merging master
git merge master
# (resolve any merge conflicts if there are any)
# already checked out
git checkout master
git merge branch4 
#(there won't be any conflicts now)
git push


# on old master branch: 
git checkout -b branch5 master
PAUSE
 

Edit comment, doesn't have a commit!

Commits are always useful to have ?

Let me add some comments for fun and profits.

# to work, open with right click and left click open

Alternatively, you can fold the script in a “doit.BAT” file, start a command(?) program, and type “doit”. (I think, I haven't touched a Windows system in a few decades.)

# this works, however not reading # correctly and master is already checked out during merge

I use Linux, where shells use “#” as comment character. BAT files indeed use REM.

git add .
git commit -m "creates this commit message."

This adds everything new or modified under “.”. A more subtle way of creating commits is to list the files and directories to add explicitly, ie “git add file1 file2 dir1 ../otherdir/file3”. In that way, you can just hack away until it all works, and at the end create a nice series of commits where you incrementally create the new feature, instead of pushing everything in one big blob of changes. It takes a bit of practice though, and it depends on how important you consider a readable commit history.

You may find that you want to add only some of the changes in a file (and keep the other changes in that file for a next commit) every now and then. git provides a -e (--edit) flag for that purpose which pops up an editor with the full diff of the file, and then you can delete everything but the changes you want to have in the commit that you are creating. When you try this, you'll find “git status” of much use.

git push --set-upstream origin branch4

Nice! I always forget the “--set-upstream” option, so I simply always type “git push origin branch4” instead.

As you are pushing, this creates a “branch4” label at the remote. You don't seem to delete that label at all (both locally and remotely), so you're creating a nice collection of labels.

# (on branch4)
echo "------merging master"
git merge master
# (resolve any merge conflicts if there are any)

This brings in new changes that appeared in local master since you created ‘branch4’. In a setting where others change the remote master as well, you would first update the local master with the remote changes. (git checkout master; git fetch origin; git merge --fast-forward origin/master).

Note that “git fetch origin; git merge --fast-forward origin/master” isn't the fastest way to do this, “git pull” combines these commands, although I have no clue how “pull” works as I always use the above “fetch” / “merge --fast-forward” sequence.

Instead of merging, you can also do a rebase, as in “git checkout branch4; git rebase master”. Basically, it moves entire ‘branch4’ on top of ‘master’, ie like you started writing ‘branch4’ after the new changes were brought in (there is no “merge” commit" in the branch then).

# already checked out
git checkout master
git merge branch4
#(there won't be any conflicts now)
git push

I don't understand your “already checked out” comment, you're on ‘branch4’. You do need to “git checkout master” to change branches.

The “merge” will be conflict-free indeed, as the merge you did above unified the starting point of ‘branch4’ with the top of ‘master’. Theoretically, “git push” could fail here, if someone else changed the remote master in the mean time.

# on old master branch:
git checkout -b branch5 master

I am not sure what “old master branch” you are referring to. You just merged “branch4” into it. Sure you can start “branch5” from the moment before you merged “branch4”, but why would you want to do that?

Alberth said:
I am not sure what “old master branch” you are referring to. You just merged “branch4” into it. Sure you can start “branch5” from the moment before you merged “branch4”, but why would you want to do that?

Old master branch is the local master branch. My idea was to use numbers with the branches to keep them in order and than letters…

Branch1 - Branch 9

Brach9a

brach9b, etc.

I thought this was great because each branch would be an in order feature.

Josheir

For diff and reset and checking history, etc.

Well, I suppose it is all in the master history. The next branch has to be called something, though?