{title}
@@ -42,17 +41,14 @@ font-size: 22px; } - .thumbnail img { - background-size: cover; + .thumbnail { aspect-ratio: 16 / 9; + background-size: cover; background-position: center; box-shadow: 5px 5px 10px 2px rgba(0, 0, 0, 0.5); border-radius: 8px; - - flex-shrink: 0; - min-width: 100%; - min-height: 100%; + margin-bottom: 15px; } .content { diff --git a/src/routes/+layout.svelte b/src/routes/+layout.svelte index 6ce89cb..08cffd5 100644 --- a/src/routes/+layout.svelte +++ b/src/routes/+layout.svelte @@ -98,6 +98,10 @@ justify-content: center; } + header a { + text-decoration: none; + } + .nav-bar { width: 100%; max-width: 1400px; diff --git a/src/routes/+page.svelte b/src/routes/+page.svelte index 34133ad..dafb64e 100644 --- a/src/routes/+page.svelte +++ b/src/routes/+page.svelte @@ -28,11 +28,27 @@+Finding the specific commit that introduced a bug in your code can be frustrating, +especially in big projects with a lot of commits. Git bisecting is a method +used to quickly find which commit is the culprit. Git bisect works by you specifying +a so called 'bad' commit where you know the bug occurs and a commit where you know the +bug doesn't occur. Afterwards git will binary search it's way to find the commit +introducing the bug. +
++Suppose we've the following git history: +
+ + ++It could potentially contain many more commits between the known 'good' commit and the +current one. Somewhere in the commits 1, 2, 3, 4 or the current one, a bug was +introduced. One way to find the specific commit that introduced the bug, could +be to check each commit starting from commit 1 then 2 then 3 ... and so on. +This is known as a linear search, and would take very long if there are a lot +of commits between the bad and the current. +
++Instead git bisect comes to the rescue. Git bisect performs a +binary search, +which is much faster. +To use git bisect, you must tell git to start bisecting: +
+
+Afterwards we mark the 'bad' commit - any commit we know the bug occurs in. In this example
+the current commit that we know is bad have the commit hash c26cf8a
, so
+we mark the commit bad:
+
+After that we mark a previous commit that we know the bug doesn't occur in. In this
+example it's the 'good' commit (se picture above), which has a commit hash of b34ec52
+
+Now git will automatically checkout a commit somewhere in between the good and bad commit. +Your job is now to re-build your project and test if the bug occurs. If the bug +doesn't occur you report it to git: +
++However if it does occur you mark it bad: +
++You continue to do this until git has tracked down the first bad commit, ie. the +commit that introduced the bug. +
+ +