Asked  7 Months ago    Answers:  5   Viewed   25 times

I am looking for opinions of how to handle large binary files on which my source code (web application) is dependent. We are currently discussing several alternatives:

  1. Copy the binary files by hand.
    • Pro: Not sure.
    • Contra: I am strongly against this, as it increases the likelihood of errors when setting up a new site/migrating the old one. Builds up another hurdle to take.
  2. Manage them all with Git.
    • Pro: Removes the possibility to 'forget' to copy a important file
    • Contra: Bloats the repository and decreases flexibility to manage the code-base and checkouts, clones, etc. will take quite a while.
  3. Separate repositories.
    • Pro: Checking out/cloning the source code is fast as ever, and the images are properly archived in their own repository.
    • Contra: Removes the simpleness of having the one and only Git repository on the project. It surely introduces some other things I haven't thought about.

What are your experiences/thoughts regarding this?

Also: Does anybody have experience with multiple Git repositories and managing them in one project?

The files are images for a program which generates PDFs with those files in it. The files will not change very often (as in years), but they are very relevant to a program. The program will not work without the files.



If the program won't work without the files it seems like splitting them into a separate repo is a bad idea. We have large test suites that we break into a separate repo but those are truly "auxiliary" files.

However, you may be able to manage the files in a separate repo and then use git-submodule to pull them into your project in a sane way. So, you'd still have the full history of all your source but, as I understand it, you'd only have the one relevant revision of your images submodule. The git-submodule facility should help you keep the correct version of the code in line with the correct version of the images.

Here's a good introduction to submodules from Git Book.

Tuesday, June 1, 2021
answered 7 Months ago

Since the node_modules directory is already tracked as part of the repository, the .gitignore rule will not apply to it.

You need to untrack the directory from git using

git rm -r --cached node_modules
git commit -m "removing node_modules"

You can run the above 2 in git-bash.

After this, the .gitignore rule will ignore the directory away.

Note that this will remove the directory node_modules from your other repos once you pull the changes in. Only the original repo where you made that commit will still have the node_modules folder there.

Saturday, August 7, 2021
answered 4 Months ago

I would recommend using tags (tag tutorial)

From your master branch since you are done v1.0 add a tag called v1.0.

git tag -a v1.0 -m "Tagging release 1.0"

This way you can always come back to a specific version at any time by calling git checkout [tag_name]

Another common practice is to use branches to work on features until they are stable.

git checkout -b [feature-branch]

That creates a new branch named whatever is in [feature-branch] and checks it out. Be sure to do this from where you want to start working on the feature (typically from master).

Once stable they can then be safely merged into master. From master run:

git merge [feature-branch]

This way your master branch always stays in a working state and only completed items get added once ready. This will allow you to keep a working copy of the app at all times (ideally anyways) for testing, etc.

You could use branches for each version of the application however using tags makes it so you can't merge into another branch version by accident.

Friday, September 3, 2021
answered 3 Months ago

There are likely several ways to approach this problem, here's my thought.

Make a new makefix branch and commit the makefile there. Whenever you need to make the project, switch to that branch. You can work in master and just keep merging, or rebasing the makefix branch against master.

The general idea is that you're creating a branch containing your Makefile that is never pushed.

Personally I would rebase makefix against master so my Makefile changes always stayed ahead of the actual pushable code. It just feels cleaner in my head.

Code Example

git branch makefix
git checkout makefix

Make your changes to Makefile

git add Makefile
git commit -m "Add Local Makefile Changes to Compiler Path"

For every-day work

git checkout master
git fetch upstream
git merge upstream/master

git checkout makefix
git rebase master

It's long and ugly, so I hope someone else has a better way =]

Sunday, September 12, 2021
answered 3 Months ago

you can ignore some files using the --ignore-paths option of git svn:

               This allows one to specify a Perl regular expression that will
               cause skipping of all matching paths from checkout from SVN.
               The --ignore-paths option should match for every fetch
               (including automatic fetches due to clone, dcommit, rebase,
               etc) on a given repository.

                   config key: svn-remote.<name>.ignore-paths

               If the ignore-paths config key is set and the command line
               option is also given, both regular expressions will be used.


               Skip "doc*" directory for every fetch


               Skip "branches" and "tags" of first level directories

Saturday, November 6, 2021
Martin Vseticka
answered 4 Weeks ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :