A Basic Modder's Guide to Git and Github

[Magus]

Depeding on the flow, you don't necessarily need to rebase.

Most of the time, just

git pull upstream master

will work (pull = fetch+merge).

[Luke]

How can I merge (squash) all the existing commits of a certain branch (f.i. master) into a new (single) commit?

[lynx]

Might be easiest to create a new branch, if you want to submit a PR.
 

git checkout master
git branch turnips
git pull --squash . your-old-branch

And then submit turnips.

[Luke]

4 hours ago, lynx said:

Might be easiest to create a new branch, if you want to submit a PR.

What if I do not want to submit a PR?

I just want to rewrite my master branch history... To clarify:

Suppose my master branch has 5 commits:

• fifth (most recent commit)
• fourth
• third
• second
• first

How can I merge (squash) those 5 commits into a new commit and delete those 5 commits (so that my master branch contains only the newly created commit)?

Edited May 17, 2021 by Luke

[lynx]

git rebase -i HEAD~5

and then choose s for squash instead of p(ick)

[Luke]

14 hours ago, lynx said:

git rebase -i HEAD~5

and then choose s for squash instead of p(ick)

I got the following error:

invalid upstream 'HEAD~5'

That's probably because my master branch has exactly 5 commits.

As I said, I do not want to squash and merge the last 5 commits. I'm interested into squashing and merging all the commits...

[lynx]

Then also pass --root.

Another way would be through something like: git reset --soft initial-commit-sha # and then committing. Or cherry-pick and -n. But really, why bother, when the first two approaches are much simpler.

[Luke]

@lynx

Sigh, I'm still failing at this...

So, I tried with

git rebase -i --root

and put 'f' ('fixup') for all commits BUT the VERY FIRST commit, for which I put 'r' ('reword').

After rewriting the very first commit message, I ran

git pull origin master --allow-unrelated-histories

Finally, I pushed everything to GitHub.

However, ALL my old commits are still there in my commit history, they have not disappeared...

What am I missing, sigh...?

[Graion Dilach]

Try a GUI frontend. I'll be honest, I never even bothered to learn the git CLT in these 10 years I am using it. GitExtensions on Windows and git-cola on Linux are my go-to tools and IMo are more straightforward and intuitive when it comes to interactive rebases from my experience (during some of my C&C modding projects, I've even managed to convert some teammates over to GitExt from GitHub's own GUI tool, because that confused them).

[Mike1072]

8 hours ago, Luke said:

git pull origin master --allow-unrelated-histories

I would do exactly what you did except leave out this step, then I would do a force push to overwrite the history in the remote branch.

git push -f origin master

To be safer, before doing the force push, I would create a separate local branch where you can store the original history in case anything goes wrong (named "old-history" in this case):

git fetch
git checkout -b old-history origin/master
git checkout master

 

[Luke]

10 hours ago, Mike1072 said:

I would do exactly what you did except leave out this step, then I would do a force push to overwrite the history in the remote branch.

git push -f origin master

 

It is working fine now, thanks!

Edited June 11, 2021 by Luke

[Luke]

@Mike1072

OK, here's another issue.

On macOS, whose filesystem is generally case-insensitive, how can I lowercase ALL file names in my repo?

If I run

git config --global core.ignorecase false

and then rename some files manually in VScode, my remote will have both, say, "TEST.baf" and "test.baf".

How can I prevent Git from adding a new (renamed) file and instead tell it it's just renaming a file...?

If instead I set the previous option to true

git config --global core.ignorecase true

and manually rename a file in VScode, then nothing happens (i.e. my renaming is not registered neither as "edit" nor as "add"...)

Edited June 26, 2021 by Luke

[argent77]

1 hour ago, Luke said:

On macOS, whose filesystem is generally case-insensitive, how can I lowercase ALL file names in my repo?

Coincidentally I had to perform just the same operation today.

From what I read setting the "ignorecase" option to false is generally a bad idea on case-insensitive filesystems. It can cause all kinds of weird errors. For example, if a filename only differs in letter case it might cause git to report spurious conflicts or create duplicate files.

I can think of two options how to accomplish it anyway:

1. By brute force: Delete the original uppercase files from the git project, afterwards add the lowercase files to the project. This method is best done if you want to rename the content of whole folders. I have done it this way. It involves:

- making a backup of the files you want to rename
- deleting the files from the project:

git rm -r path/to/files/

- restoring and renaming the backed up files
- adding the (renamed) files to the project:

git add path/to/files/

Afterwards git should be smart enough to detect that the files have been renamed.

2. Enforce file renaming via -f option:

git mv -f MYFILE myfile

I haven't tested this method. But from what I could find on various websites it should at least work on macOS. You might have to specify the full path to the file you want to rename.

In either case you don't have to set the "ignorecase" option to false.

[Luke]

@argent77Thanks, both methods are working fine for me.

Also, I found out this nice little script

find -E . -iregex '.*(tpp|tph|wav|bam|baf|2da)$' | while read f; do lc=$(echo ${f} | tr A-Z a-z); git mv $f ${lc}_; git mv ${lc}_ $lc; done

When run in your root directory, it will lowercase all files whose extension matches (case-insensitively!) the specified regexp.

[Luke]

@Magus

I've got a question about submodules.

After adding a Submodule to my repo, if I then download the master branch to test changes, the Submodule folder shows as empty (everything seems to be fine on GitHub, since I can see the folder "my_submodule_name" @ <latest_commit>...)

It's like when you clone a repo with submodules and you forget to run "git submodule update --init --recursive"... However, I'm not cloning a repo with submodules, I'm just downloading it...

A quick test shows that the issue does not occur if you download a proper release (i.e., the Submodule folder is not empty). Instead, if you download the main/master branch (a.k.a. latest commit), then the Submodule folder shows as empty... Is it intended...?