![]() I check if the bug is still there or not. The refs/bisect/bad reference has been moved to the “Commit 10”. In gitg, my master branch looks like this: I will find the typo bug in 2 steps from now. Git bisect has reduced the commit interval and checkout the “Commit 5”. $ git bisect badīisecting: 4 revisions left to test after this (roughly 2 steps) The bug is still there, so I use git bisect bad to tell Git bisect that the current state is still broken. Now I have to check if the bug is still there or not and inform Git according to my check. For a console view, you can use git bisect view -stat. Note: It’s possible to use git bisect visualize or git bisect view to see the remaining interval in graphical tool. If I look at my master branch in Gitg (or Gitk, Gitx or any Git graphical tool…), I can see that Git has created two references refs/bisect/start and refs/bisect/good- next to my HEAD and HEAD~20 commits. The commit in the middle of my interval has been checkout ("Commit 10"). Git checks my interval and calculates that I will need 3 steps to find the wrong commit after current step. $ git bisect start HEAD HEAD~20īisecting: 9 revisions left to test after this (roughly 3 steps) So I can pass HEAD and HEAD~20 for my two references. I know that the bug was not there 20 commits ago and is present now. To do so, I run git bisect with two commits references. Ok, I have 19 occurences of "number" and 1 occurrence of "numer", let’s find which commit inserted the typo. We are going to try to find the commit which has the typo with git bisect. One of the insertions will have a typing error "numer" instead of "number". I’m going to create 20 commits each commit adding a new line “line number #” in file.txt. At each step of the process, git bisect reduce the interval and finally returns the SHA1 of the commit which has introduced the bug. Then the user has to check the bug again and inform git bisect. According to user answer, git bisect will checkout a commit in the middle of the first or the second half of the initial interval. Once checkout of the middle commit has been done, user has to test if the bug is still there or not and inform git bisect command. The command will checkout the commit in the middle of the interval of the two commits. This command requires 2 commits SHA1 (or references) to work: an old commit where the bug is not there and a recent commit where the bug is there. It is a specific type of divide and conquer algorithm. In computer science, a dichotomic search is a search algorithm that operates by selecting between two distinct alternatives (dichotomies) at each step. Git has an awesome method to find a specific commit with a dichotomic search solution. When a new bug appears in your application, the best way to fix the bug is to find which commit introduced it. This command will ask you which diff tool to use, then open the whole directory in the tool instead of each file sequencially. Now, you just have to use git meld command for your diff: $ git meld HEAD HEAD~4 $ git meld myBranch myOtherBranch git/config file: meld = !/home/workspace/git-meld/ Then, create a new alias meld in Git, for example by adding the following line in the part of you. Remote: Total 64 (delta 31), reused 57 (delta 25) ![]() Remote: Compressing objects: 100% (34/34), done. ![]() If you are using an older version, worry not! It’s possible to install a small script to do the same thing: /home/workspace $ git clone into git-meld. Unfortunately, git difftool opens files sequentially: after checking a file, you have to close the diff tool so Git can reopen it with the next file.įortunately since version 1.7.11, Git allows to see diff on a whole directory with the -dir-diff parameter. Like git mergetool to resolve merge conflicts, there is a git difftool to see diff results in a graphical tool. Just use the git mergetool command, it will ask you which tool to use. Whenever you face a merge conflict, you can use a merge tool to resolve it without too much headache. What do you think? Let’s go? Fix merge conflicts with a graphical tool Finally I will show how to merge commits into a single one before pushing it. ![]() Then we’ll explore the magic of the Git bisect command. Hi people ! Welcome to the third part of this Git Tips & Tricks series ! This week I’m going to start with 2 useful tricks to fix conflicts or just see diff in a graphical tool instead of command line. If you missed the first post and the the second one, be sure to give them a read! And now roll up your sleeves, because this is getting wicked! This is the 3rd part of the Git Tips & Tricks series from Loïc Giraudel. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |