[HN Gopher] Git as a debugging tool
       ___________________________________________________________________
        
       Git as a debugging tool
        
       Author : lucasoshiro
       Score  : 64 points
       Date   : 2024-03-30 19:05 UTC (3 hours ago)
        
 (HTM) web link (lucasoshiro.github.io)
 (TXT) w3m dump (lucasoshiro.github.io)
        
       | n4r9 wrote:
       | Another way to use git to debug - albeit more tedious - is to
       | manually check out branches (using a binary search) until you
       | find the exact change that caused an issue. This is helpful if
       | you have no idea what part of the code is causing a problem, but
       | you know the problem didn't exist a month ago. Performance issues
       | are a good example.
        
         | yjftsjthsd-h wrote:
         | I don't know about branches, but if you're just traversing
         | history that's a textbook use for git bisect, right?
        
           | globular-toast wrote:
           | Yep. Git bisect automatically does a binary search to find
           | the earliest breaking commit. You can either test each
           | version manually or, if you have a script that will pass or
           | fail, like a unit test, you can tell git and it will do
           | everything automatically. I love it when I get to use git
           | bisect.
        
             | amboar wrote:
             | A handy trick I've developed is using`git bisect` to solve
             | otherwise intractable rebase conflicts:
             | 
             | https://codeconstruct.com.au/docs/bisect-intractable-
             | rebase-...
        
           | n4r9 wrote:
           | Yes, failure to rtfa on my part.
        
         | nonethewiser wrote:
         | Thats called git bisect
        
       | cerved wrote:
       | Another thing you can do when you have two versions, one which
       | fails and one which doesn't, but where the commits are of the
       | messy work in progress nature and not atomic changes, is
       | gradually stage the changes from the bad version onto the good
       | version until it starts failing
       | 
       | Basically git checkout -p until things fail
        
         | lucasoshiro wrote:
         | Thanks for the comment! It looks to be a very useful tip for
         | doing after bisect on repositories where people insist to
         | squash pull requests.
        
       | ozay wrote:
       | _git blame shows only who made the last change. Maybe that person
       | only changed the name of a variable, applied a codestyle change,
       | moved a function declaration to another file or many other things
       | that the change was almost irrelevant to the code behavior._
       | 
       | There are a few options that help you out with this:
       | 
       | -M Detect moved or copied lines within a file
       | 
       | -C In addition to -M, detect lines moved or copied from other
       | files that were modified in the same commit.
       | 
       | --ignore-rev <rev> Ignore changes made by the revision when
       | assigning blame, as if the change never happened
       | 
       | --ignore-revs-file <file> Ignore revisions listed in file
       | 
       | https://git-scm.com/docs/git-blame
        
         | PhilipRoman wrote:
         | I recommend just skipping blame and going to git log -L to see
         | the full evolution of a range of lines, I set up a little
         | keybind in vim which does this for the current visual selection
         | and it works much better than blame.
        
           | a_e_k wrote:
           | And for those using Magit in Emacs, you can do this by
           | selecting a region of lines and hitting `C-c M-g l`.
           | 
           | https://magit.vc/manual/magit/Commands-for-Buffers-
           | Visiting-...
        
       | billllll wrote:
       | Didn't know Git had a bisect feature. I'll keep that in mind for
       | later.
       | 
       | Other than bisect though, I do think a lot of the practices
       | outlined in the article (checking the blame, logs, search, etc)
       | is way easier to do in a web UI, at least for someone like me who
       | hasn't tailored their workflow for the command line. The tooling
       | is so ubiquitous that it's easily available. I personally think
       | GitHub does okay in those regards.
        
       ___________________________________________________________________
       (page generated 2024-03-30 23:00 UTC)