installation before and after update large size difference

[daniejstriata]

When I do the initial install with "--depth 1" the total size of the ".bash-it" directory is 4.6 Mb, after running bash-it update it grows a lot to get to version 2.1.3.

Before:
4.6M	.bash_it/

After:
108M	.bash_it/

During the update a lot for changes are printed scrolling over the screen.

Expected Behavior

Why is the initial install not getting all these merges already, so that when I run bash-it update it is already up-to-date?

Current Behavior

Initial install being very small is followed by a very large update asking me if I want to update to 2.1.3(ebe59c9)

Steps to Reproduce

1. Check out a clone of this repo to a location of your choice, such as git clone --depth=1 https://github.com/Bash-it/bash-it.git ~/.bash_it
2. Run ~/.bash_it/install.sh
3. initialise bash-it
4. du -sh ~/.bash_it/
5. bash-it update
6. du -sh ~/.bash_it/

Your Environment

• Bash-it version used: 2.1.3
• List of enabled plugins, themes and aliases (use bash-it show (plugins/themes/aliases)):
• bash-it doctor output:
  DEBUG: core: main: Loading libraries(except appearance)...
  DEBUG: lib: helpers: Loading library file...
  DEBUG: lib: log: Loading library file...
  DEBUG: lib: preview: Loading library file...
  DEBUG: lib: search: Loading library file...
  DEBUG: lib: utilities: Loading library file...
  DEBUG: vendor: Loading "preexec"...
  DEBUG: core: reloader: Loading "bobby" theme...
  WARN: themes: base: Command 'battery_percentage' does not exist!
  DEBUG: core: main: Loading custom aliases, completion, plugins...
  DEBUG: core: main: Loading general custom files...
• Bash version: bash-4.2.46-34.el7.x86_64
• Operating System and version: Centos 7

[cornfeedhobo]

@NoahGorny You might be interested in this ticket as it relates to updates. My guess is that we are pulling the entire repository state when updating.

[NoahGorny]

This is caused by us using git fetch without --depth 1 in the code:

bash-it/lib/helpers.bash

Line 231 in 58f2240

git fetch $BASH_IT_REMOTE --tags &> /dev/null

I played around with it, and the shallow copy is generally a no-go together with the bash-it update command. As we already play around with #1819, the real solution would be to distribute Bash-it with a package manager, instead of recommending users to clone and use a shallow copy. Power users, or users that want to contribute, should fully clone the repo and use it this way

[daniejstriata]

@NoahGorny Why don't I get the latest version when I do the initial clone with depth 1? Then I don't have to update it (at least for a while)

[NoahGorny]

@NoahGorny Why don't I get the latest version when I do the initial clone with depth 1? Then I don't have to update it (at least for a while)

You do get the latest version, the latest dev version. We consider tags to be stable versions, and any other one as a dev one. We currently recommend cloning, which gives users the current master branch, so you actually get the latest version, just not the latest tag 😄

[gaelicWizard]

I've run this script (thanks to Stack Overflow) to find large files in the git object store:

git rev-list --objects --all |
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' |
  sed -n 's/^blob //p' |
  awk '$2 >= 2^16' |
  grep -vF --file=<(git ls-tree -r HEAD | awk '{print $3}') |
  sort --numeric-sort --key=2 |
  cut -c 1-12,41-

There's no way to fix this without rewriting history, which breaks everything...

[NoahGorny]

closing as #1819 solves this problem