6 ms·

> it makes me feel safer This for me is one of the biggest things I like about working under version control, even solo. It gives me the freedom to explore som

> it makes me feel safer This for me is one of the biggest things I like about working under version control, even solo. It gives me the freedom to explore some crazy idea or refactor without having to think about the way back if it doesn't pan out. If it turns out to be more complex than I am willing to do now, I can stash or branch. If I think back to my pre-source control days, I used to leave commented code everywhere, or just make a full copy of the folder. It doesn't take long before this becomes an absolute mess. Copying in particular was a barrier: you had to realize it was necessary then interrupt your flow to do something that would take a several seconds. (By contrast, if you commit as you go - especially everytime you get to a working "checkpoint" - there's zero extra effort needed.)

jonwinstanley 6y ago
Yes totally. It gives you freedom to try things you don’t fully understand in your IDE or framework too then decide whether you want to revert everything afterwards.
colllectorof 6y ago
Modern IDEs often ave basic source control baked in. You don't even need to commit anything. I wonder whether there is any point in using Git for basic version control if those features are already available.
- dimitrios1 6y ago
  Yes: you like the interface for git already and are productive with it versus learning how to achieve the same productivity while learning the idiosyncrasies of your chosen IDE platform.
  - hinkley 6y ago
    I'm butchering something someone said here about a month ago: Some people cut a trail through the jungle, others just push the branches out of the way and expect everyone behind them to do the same.
- majormajor 6y ago
  At least in IntelliJ, I find using the local file history stuff painful. With explicit source control, I'm making specific decisions to check in known states. When I have to resort to the local file history stuff, there's a lot more of "oh, here I undo'd a typo" and so on type of things. That said, it can be a lifesaver when I didn't make an explicit commit, then started doing stuff, then realized "ok this got out of hand AND I wish I could go back five minutes but it's gonna be annoying."
  - hinkley 6y ago
    The intellij local history works best when your code is a raging monolith. It punishes you when you find coupling in otherwise uncoupled code, and that punishment is there whether you leave the coupling or try to fix it. One of the failure modes for people leaving a mess is if it's too hard to fix it they give up. So that's no good.
- coding123 6y ago
  Most IDEs that have basic source control baked in typically means it has a git client and UI. I know that years ago I used Netbeans local history but it's a per-file history and does nothing to keep a set of files at a specific "save point" together.
- dpedu 6y ago
  Committing aside, git also has stash. Many people prefer using one consistent tool (git) over the variety of IDE's equivalent features available.
  - greyhair 6y ago
    I posted elsewhere. Stash is your friend. If you aren't using stash today, learn it. And learn the difference between 'stash pop' and 'stash apply'. Each has its place and time.
Debug_Overload 6y ago
Yeah, writing code without source control sounds horrible. Can't imagine what it must've been like for those who had to suffer through such time.
- ska 6y ago
  We’ve had effective source control since the 70s, latest 80s; for the most part working without it was self inflicted.
  - deleted 6y ago
    [deleted]
  - greyhair 6y ago
    Exactly. When people say 'before we had version control' I want to ask, how old are you? And by the way, I am older than just about all of you. Started with SCCS with versioned control lists to determine what got pulled from SCCS. The outer wrapper was all written in shell. 1980s. Talking about a large system, eight or ten sub projects, each sub project in its own versioned source tree. A release spec pulled the SCCS deltas of all the sub project control lists, and then SCCS was directed by those versioned control lists to pull all the source code for each sub project. So yes, version control that I am aware of was firmly entrenched in 1980. And I am certain it goes back further than that.
- noarchy 6y ago
  I know a contractor who has worked for a major company that I won't name. He has told me that their source control was, for a time, Google Drive. He knew it was a recipe for disaster but real work was nonetheless getting done, and the client was satisfied. They didn't know how the sausage was being made, but they liked the output. I think a lot of people who haven't been around the scene wouldn't believe these stories, but this stuff happens a lot. Like major commercial projects with no tests whatsoever (unit, integration, or otherwise), that are still successful and making a lot of money.
  - icedchai 6y ago
hinkley 6y ago
Exploratory refactoring turns out to be very close to an exercise in creative writing, as I learned one day accidentally from my lit major friend. Take the section you are stuck on, print it out, cut it up into sentences or phrases, and just rearrange them until either it makes sense, or you figure out where you went wrong. Rearranging code statements until something makes sense is exactly what refactoring is.
- systemvoltage 6y ago
  I beg to differ. Refactoring is not merely rearranging code statements. Refactoring is restructuring of the code starting from the architectural and abstract goal and then looking at how pieces of existing code would fit. Sometimes, that requires writing new code and tests. Refactoring by definition also means not breaking the user space. I've never heard of any serious writer printing out their prose and cutting it and rearranging it. That just sounds absurdly unnecessary to me.
  - hinkley 6y ago
    > code starting from the architectural and abstract goal you are either using a different definition of architecture or this is wrong. Refactoring is bottom up construction. Most of the time when I see people frustrated or struggling (including myself) it's because they have forgotten this and need to take a break.
    - systemvoltage 6y ago
      I am using the standard architecture difinition. More information here: https://en.wikipedia.org/wiki/Code_refactoring https://en.wikipedia.org/wiki/Code_refactoring There are many goals in refactoring, specifically this section: > Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory. I was addressing OP's analogy to cutting pieces of written prose and rearranging.

jonwinstanley 6y ago

Yes totally. It gives you freedom to try things you don’t fully understand in your IDE or framework too then decide whether you want to revert everything afterwards.

colllectorof 6y ago

Modern IDEs often ave basic source control baked in. You don't even need to commit anything. I wonder whether there is any point in using Git for basic version control if those features are already available.

dimitrios1 6y ago
Yes: you like the interface for git already and are productive with it versus learning how to achieve the same productivity while learning the idiosyncrasies of your chosen IDE platform.
- hinkley 6y ago
  I'm butchering something someone said here about a month ago: Some people cut a trail through the jungle, others just push the branches out of the way and expect everyone behind them to do the same.
majormajor 6y ago
At least in IntelliJ, I find using the local file history stuff painful. With explicit source control, I'm making specific decisions to check in known states. When I have to resort to the local file history stuff, there's a lot more of "oh, here I undo'd a typo" and so on type of things. That said, it can be a lifesaver when I didn't make an explicit commit, then started doing stuff, then realized "ok this got out of hand AND I wish I could go back five minutes but it's gonna be annoying."
- hinkley 6y ago
  The intellij local history works best when your code is a raging monolith. It punishes you when you find coupling in otherwise uncoupled code, and that punishment is there whether you leave the coupling or try to fix it. One of the failure modes for people leaving a mess is if it's too hard to fix it they give up. So that's no good.
coding123 6y ago
Most IDEs that have basic source control baked in typically means it has a git client and UI. I know that years ago I used Netbeans local history but it's a per-file history and does nothing to keep a set of files at a specific "save point" together.
dpedu 6y ago
Committing aside, git also has stash. Many people prefer using one consistent tool (git) over the variety of IDE's equivalent features available.
- greyhair 6y ago
  I posted elsewhere. Stash is your friend. If you aren't using stash today, learn it. And learn the difference between 'stash pop' and 'stash apply'. Each has its place and time.

Debug_Overload 6y ago

Yeah, writing code without source control sounds horrible. Can't imagine what it must've been like for those who had to suffer through such time.

ska 6y ago
We’ve had effective source control since the 70s, latest 80s; for the most part working without it was self inflicted.
- deleted 6y ago
  [deleted]
- greyhair 6y ago
  Exactly. When people say 'before we had version control' I want to ask, how old are you? And by the way, I am older than just about all of you. Started with SCCS with versioned control lists to determine what got pulled from SCCS. The outer wrapper was all written in shell. 1980s. Talking about a large system, eight or ten sub projects, each sub project in its own versioned source tree. A release spec pulled the SCCS deltas of all the sub project control lists, and then SCCS was directed by those versioned control lists to pull all the source code for each sub project. So yes, version control that I am aware of was firmly entrenched in 1980. And I am certain it goes back further than that.
noarchy 6y ago
I know a contractor who has worked for a major company that I won't name. He has told me that their source control was, for a time, Google Drive. He knew it was a recipe for disaster but real work was nonetheless getting done, and the client was satisfied. They didn't know how the sausage was being made, but they liked the output. I think a lot of people who haven't been around the scene wouldn't believe these stories, but this stuff happens a lot. Like major commercial projects with no tests whatsoever (unit, integration, or otherwise), that are still successful and making a lot of money.
- icedchai 6y ago

hinkley 6y ago

Exploratory refactoring turns out to be very close to an exercise in creative writing, as I learned one day accidentally from my lit major friend. Take the section you are stuck on, print it out, cut it up into sentences or phrases, and just rearrange them until either it makes sense, or you figure out where you went wrong. Rearranging code statements until something makes sense is exactly what refactoring is.

systemvoltage 6y ago
I beg to differ. Refactoring is not merely rearranging code statements. Refactoring is restructuring of the code starting from the architectural and abstract goal and then looking at how pieces of existing code would fit. Sometimes, that requires writing new code and tests. Refactoring by definition also means not breaking the user space. I've never heard of any serious writer printing out their prose and cutting it and rearranging it. That just sounds absurdly unnecessary to me.
- hinkley 6y ago
  > code starting from the architectural and abstract goal you are either using a different definition of architecture or this is wrong. Refactoring is bottom up construction. Most of the time when I see people frustrated or struggling (including myself) it's because they have forgotten this and need to take a break.
  - systemvoltage 6y ago
    I am using the standard architecture difinition. More information here: https://en.wikipedia.org/wiki/Code_refactoring https://en.wikipedia.org/wiki/Code_refactoring There are many goals in refactoring, specifically this section: > Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory. I was addressing OP's analogy to cutting pieces of written prose and rearranging.