3 ms·

This is only true until the first merge conflict or when you want to know when a bug was introduced to even find its location.

by foepys 5y ago

alisonkisk 5y ago
I resolve conflicts in GUI every week. I find the location of a bug by running tests and looking at the code.
- PaulDavisThe1st 5y ago
  git bisect will optimize the number of tests you have to run, and will reduce the amount of code you have to look at it to the minimum (in general).
  - wizzwizz4 5y ago
    Assuming a binary search over version history is a valid way of finding the bug. If you have a better idea of the probability distribution (e.g. it might've started being buggy any time in the past year, but I'm fairly sure it happened about nine months ago when the formatting of the report broke a bit) you can do a better job manually than `git bisect` – and if the bug is actually multiple bugs, or other things changed that affected the bug's presence or absence (making it appear or disappear in non-trivial patterns between versions), `git bisect` will mislead you. `git bisect` is pretty cool, but “knowing your tools” isn't the same thing as “memorising the man pages”.
    - PaulDavisThe1st 5y ago
      if you are confident that it happened about nine months ago, then just start the bisect bounded by age-appropriate commits. just a case of knowing your tools ;) yes, if the bug is a complex interaction of several different code changes, and comes and goes, then a binary search will not find it. however, it may be the fastest way to realize that it is this sort of bug. recognizing patterns in what happens when you use git bisect is another aspect of knowing your tools, and in this case, will help you move more rapidly toward a more appropriate approach.
ithkuil 5y ago
I interpreted what GP said as " the version control system is the place I store my files, so it's not just a tool, but it's an essential and necessary environment, the space where I organize my stuff"
- wizzwizz4 5y ago
  That's more what I was going for. It's also part of the background, as opposed to something I deliberately interact with, so I don't use it like a tool in my day-to-day.
wizzwizz4 5y ago
All things I know are possible. I understand Git's architecture, just like I know what an inode is. I could re-implement my own (bad) version control system, if I wanted to, just like I could make my own (bad) filesystem. But that doesn't mean I need to have memorised the CLI invocations. There's a button in Git GUI for all the things I need to do (including the things you've listed), and in the rare case where I need to do something else (e.g. submodules), I can look it up, just as I do in the rare case where I need to make a symbolic link.
- ekster 5y ago
  Thats a quite different statement from vcs not being a tool you use. At least how I read it.

This is only true until the first merge conflict or when you want to know when a bug was introduced to even find its location.

by foepys 5y ago

This is only true until the first merge conflict or when you want to know when a bug was introduced to even find its location.

alisonkisk 5y ago

I resolve conflicts in GUI every week. I find the location of a bug by running tests and looking at the code.

PaulDavisThe1st 5y ago
git bisect will optimize the number of tests you have to run, and will reduce the amount of code you have to look at it to the minimum (in general).
- wizzwizz4 5y ago
  Assuming a binary search over version history is a valid way of finding the bug. If you have a better idea of the probability distribution (e.g. it might've started being buggy any time in the past year, but I'm fairly sure it happened about nine months ago when the formatting of the report broke a bit) you can do a better job manually than `git bisect` – and if the bug is actually multiple bugs, or other things changed that affected the bug's presence or absence (making it appear or disappear in non-trivial patterns between versions), `git bisect` will mislead you. `git bisect` is pretty cool, but “knowing your tools” isn't the same thing as “memorising the man pages”.
  - PaulDavisThe1st 5y ago
    if you are confident that it happened about nine months ago, then just start the bisect bounded by age-appropriate commits. just a case of knowing your tools ;) yes, if the bug is a complex interaction of several different code changes, and comes and goes, then a binary search will not find it. however, it may be the fastest way to realize that it is this sort of bug. recognizing patterns in what happens when you use git bisect is another aspect of knowing your tools, and in this case, will help you move more rapidly toward a more appropriate approach.

ithkuil 5y ago

I interpreted what GP said as " the version control system is the place I store my files, so it's not just a tool, but it's an essential and necessary environment, the space where I organize my stuff"

wizzwizz4 5y ago
That's more what I was going for. It's also part of the background, as opposed to something I deliberately interact with, so I don't use it like a tool in my day-to-day.

wizzwizz4 5y ago

All things I know are possible. I understand Git's architecture, just like I know what an inode is. I could re-implement my own (bad) version control system, if I wanted to, just like I could make my own (bad) filesystem. But that doesn't mean I need to have memorised the CLI invocations. There's a button in Git GUI for all the things I need to do (including the things you've listed), and in the rare case where I need to do something else (e.g. submodules), I can look it up, just as I do in the rare case where I need to make a symbolic link.

ekster 5y ago
Thats a quite different statement from vcs not being a tool you use. At least how I read it.