$ git rev-parse --verify HEAD # Show current commit
$ git rev-parse --verify HEAD # Show current commit
b1da0e305c906fb242bc8...
df0eb55ce43fa48b652340183b5f9cc69daa2350
```
```
<br>
<br>
...
@@ -380,5 +383,61 @@ Will revert *both your code and your results* as they were. The workflow is the
...
@@ -380,5 +383,61 @@ Will revert *both your code and your results* as they were. The workflow is the
- `git checkout SOURCE_COMMIT`: Going back to the state before the step 1
- `git checkout SOURCE_COMMIT`: Going back to the state before the step 1
- `gblk pre-co`: checks if there is no new data inside the results folder otherwize it stops the checkout.
- `gblk pre-co`: checks if there is no new data inside the results folder otherwize it stops the checkout.
- `git checkout DESTINATION_COMMIT`
- `git checkout DESTINATION_COMMIT`
- `gblk checkout --mode hard`: hard is the default mode used when hooks are created. With hard mode, the results folder is completly deleted, this action is skipped if with --mode soft. Then the backup of the first commit is extracted into the results folder.
- `gblk checkout --mode hard`: *hard* is the default mode used when hooks are created. With hard mode, the *results folder is completly deleted*, this action is skipped if with `--mode soft`. Then the backup of the first commit is extracted into the results folder. `--mode soft` can lead to have a `results` folder with *both old and new files*. It usage is **not recommended**.
:::
:::
## Git Borg Linker - checkout {.unnumbered .unlisted}
Let's go back to our example project (in slide 11, 14, 15 and 17):
In this project, we're using *hooks*:
```bash
$ echo "echo 'a newline' >> results/result.txt" >> src/script.sh # Add anew line into result.txt file
$ bash src/script.sh # Execute the script
$ cat results/result.txt # display the new content of the file