developement_explanations.md glow up 2
This commit is contained in:
parent
040508defb
commit
3a04aa0089
@ -94,11 +94,11 @@ LFS is a Git extension that lets you manipulate selected files (by name, express
|
||||
This is a very interesting mechanism, which we will not use for the same reason as the `--filter` clone: we only want to keep one specific version of the files, which would in any case be downloaded by LFS.
|
||||
|
||||
## Delete history
|
||||
The git filter-branch command is not recommended by the Git documentation. It has several security and performance flaws. It can be used to rewrite branch history using filters.
|
||||
The `git filter-branch` command is not recommended by the Git documentation. It has several security and performance flaws. It can be used to rewrite branch history using filters.
|
||||
|
||||
The Java repo-cleaner library works, but the Git documentation considers the Python filter-repo library to be faster and more secure. We do not wish to install either Python or Java, hence we will not dig any deeper into these two possibilities here.
|
||||
|
||||
We want to delete the entire history without filtering, so the git command fetch --depth=1 followed by a git checkout, reset or merge works for us.
|
||||
We want to delete the entire history without filtering, so the git command `git fetch --depth=1` followed by a git checkout, reset or merge works for us.
|
||||
|
||||
## checkout ? merge ? reset ?
|
||||
Once we have fetched the changes to our local remote/ folder, what is the best way to apply them to our index and working directory?
|
||||
@ -131,25 +131,28 @@ git merge --allow-unrelated-histories temp
|
||||
git branch -D temp
|
||||
```
|
||||
|
||||
Advantage:
|
||||
Advantage:
|
||||
Disadvantage: creation of a temporary branch.
|
||||
|
||||
### `git checkout -force -B main origin/main`
|
||||
This command is equivalent to `git merge -s ours` and `git reset --hard`, with the difference that you end up in detached HEAD state, which does nos cause any problem in our case since we do not want to push any changes from our repository.
|
||||
Advantage :
|
||||
|
||||
This command is equivalent to `git merge -s ours` and `git reset --hard`, with the difference that you end up in detached HEAD state, which does nos cause any problem in our case since we do not want to push any changes from our repository.
|
||||
Advantage :
|
||||
Disadvantage: detached HEAD state.
|
||||
|
||||
### `git reset --hard`
|
||||
`git reset --hard` is equivalent to `git merge -s ours` and `git checkout --force -B`.
|
||||
Advantage:
|
||||
Disadvantage:
|
||||
|
||||
`git reset --hard` is equivalent to `git merge -s ours` and `git checkout --force -B`.
|
||||
Advantage:
|
||||
Disadvantage:
|
||||
|
||||
Tests show that the most memory-efficient options are `git checkout -force -B`, `git merge -s ours` and `git --reset hard`, which all do the same thing. However, `git reset --hard` does not involve the creation of a temporary branch and does not end in detached HEAD state, hence it is the one we choose.
|
||||
|
||||
### Submodule management
|
||||
|
||||
Submodules are initially cloned using `git clone --recurse-submodules --remote-submodules`.
|
||||
They are updated using `git submodule update --init --recursive --force --depth=1 –remote`.
|
||||
`git reset --hard` must be supplied with the `--recurse-submodules` option in order to delete submodules from the working directory.
|
||||
`git reset --hard` must be supplied with the `--recurse-submodules` option in order to delete submodules from the working directory.
|
||||
The same rules apply to submodules as to the rest of the repository. In the .gitmodules file, it is possible to specify rules for importing submodules, such as a certain tag or branch. By removing `--remote-submodules` from `git clone` and `--remote` from `git submodule update`, submodules will be identical to the repository being cloned and no longer to the original submodule repository.
|
||||
|
||||
## Tests
|
||||
|
Loading…
Reference in New Issue
Block a user