3 ms·

For these people, I think a manual backup is what they actually want. “If I fuck up so bad I have to roll back.” I don’t think it’s wrong necessarily either, an

by toxik 5y ago

For these people, I think a manual backup is what they actually want. “If I fuck up so bad I have to roll back.” I don’t think it’s wrong necessarily either, and GitHub actually encourages this behavior with the easy Web file uploads. Many repositories are now 99% automatically created commits by drag and drop. I think these people would be better served by a backup system where you can pin snapshots. They don’t really want to use VCSs like they’re meant to be.

Nursie 5y ago
How are version control systems meant to be used, if not as a history of the work? If not as a remote backup of work in progress? I get the whole “we should have a neat history of feature commits” argument, but that’s really only one facet of a good source control system. The fact that these goals appear to conflict shows me there’s some sort of lack in git. For all its (many, many) problems, uber-complex source control system ClearCase at least allowed you to specify a view, so you could see both types of information depending on your use-case.
- jen20 5y ago
  They’re not really in conflict at all. The workflow I’ve been using for ~11 years is: - Make a branch for my work. - Commit early, often and with often meaningless commit messages like “WIP” or “try x” or “nope x doesn’t work, do y instead” - in other words, what the work was. - Push this branch to a remote (either personal or shared depending on policy) largely to synchronise between machines, but also as a backup. - When ready to integrate, interactively rebase into a set of cohesive units which are independently buildable and have detailed commit messages which explain why the work was done, not what the works was. - Push _this_ as a pull request, Gerrit change set, or email patch, depending on policy. This approach gives you the best of both worlds: fast, easy backup and easy unwind when doing work, and a clean history for the benefit of future developers on the project.
  - Nursie 5y ago
    You still lose your real commit history though, and I’ve found it useful to have that in the past. A dead end or experimental avenue that turned out not to have use at the time turns out to be a real timesaver later. I’m fact I’ve found that far more useful than a well curated history. Having both would be a good thing. Having both in a not-ridiculously overcomplex system even better… I wonder if there even is a sweet spot.
    - jen20 5y ago
      I agree that having both would be preferable - and to some extent GitHub gives you that (via the "squash and merge" button). Unfortunately it doesn't appear that workflow is usable in a lot of cases since the commit message cannot be reviewed independently in this model, unlike in Gerrit. You can always keep your working branches on a personal remote, or interesting sets of changes in gists, however.
      - Nursie 5y ago
        > You can always keep your working branches on a personal remote This kinda defeats the point again, to my view. I’m not familiar enough with gists to know if they would solve this.
oauea 5y ago
Too bad for them, because they're (supposedly) professional software developers hired to work on this project and the project uses git.

by toxik 5y ago

Nursie 5y ago

How are version control systems meant to be used, if not as a history of the work? If not as a remote backup of work in progress? I get the whole “we should have a neat history of feature commits” argument, but that’s really only one facet of a good source control system. The fact that these goals appear to conflict shows me there’s some sort of lack in git. For all its (many, many) problems, uber-complex source control system ClearCase at least allowed you to specify a view, so you could see both types of information depending on your use-case.

jen20 5y ago
They’re not really in conflict at all. The workflow I’ve been using for ~11 years is: - Make a branch for my work. - Commit early, often and with often meaningless commit messages like “WIP” or “try x” or “nope x doesn’t work, do y instead” - in other words, what the work was. - Push this branch to a remote (either personal or shared depending on policy) largely to synchronise between machines, but also as a backup. - When ready to integrate, interactively rebase into a set of cohesive units which are independently buildable and have detailed commit messages which explain why the work was done, not what the works was. - Push _this_ as a pull request, Gerrit change set, or email patch, depending on policy. This approach gives you the best of both worlds: fast, easy backup and easy unwind when doing work, and a clean history for the benefit of future developers on the project.
- Nursie 5y ago
  You still lose your real commit history though, and I’ve found it useful to have that in the past. A dead end or experimental avenue that turned out not to have use at the time turns out to be a real timesaver later. I’m fact I’ve found that far more useful than a well curated history. Having both would be a good thing. Having both in a not-ridiculously overcomplex system even better… I wonder if there even is a sweet spot.
  - jen20 5y ago
    I agree that having both would be preferable - and to some extent GitHub gives you that (via the "squash and merge" button). Unfortunately it doesn't appear that workflow is usable in a lot of cases since the commit message cannot be reviewed independently in this model, unlike in Gerrit. You can always keep your working branches on a personal remote, or interesting sets of changes in gists, however.
    - Nursie 5y ago
      > You can always keep your working branches on a personal remote This kinda defeats the point again, to my view. I’m not familiar enough with gists to know if they would solve this.

oauea 5y ago

Too bad for them, because they're (supposedly) professional software developers hired to work on this project and the project uses git.