4 ms·

And please write proper commit messages! A short summary, preferably including a hint at which subsystem is impacted by the change. Then explain in detail the

by dirkf 7y ago

And please write proper commit messages! A short summary, preferably including a hint at which subsystem is impacted by the change. Then explain in detail the context of the change: root cause of a bug and the gist of the solution, use case(s) behind a new feature and how it can be used, ... Yes, often there's a bug/project tracking tool being used and the commit message contains a reference to the relevant entry there. But from experience I know these tools tend to change: old one gets decommissioned, data gets migrated, what was once the primary identifier is now a mere field or comment in the new system, access rights get messed up, ... Trying to understand the history then turns into an archeological expedition through various eras long gone... unless the commit messages are sufficiently self-containing.

BlueTemplar 7y ago
The issue seems to be that that tracking tool does not have its data backed up in the version control system?
- JoshuaDavid 7y ago
  This seems like it could be mitigated with an integration that watches the issue tracker for updates and then commits those updates to a docs folder on the appropriate branch of the appropriate repo. This would have saved quite a bit of headache at my last job actually.
  - BlueTemplar 7y ago
    Or just use a version control system with issue tracker support, like Fossil ?
    - JoshuaDavid 7y ago
      Switching an existing project to a new VCS loses history or at minimum causes a new layer of "identifiers in the old system don't match the new one", no? In general, I've found value in figuring out how to improve existing systems where feasible rather than trying to migrate to a new system, since the existing system probably has advantages the new one won't. At minimum, people are already familiar with the existing system.
      - BlueTemplar 7y ago
        Of course - but I'm not sure why you assumed that I would suggest that, instead of using a different VCS for a new project.
        JoshuaDavid 7y ago
        Ah. I've spent a lot more time working on projects I inherited rather than ones where I made the initial technical decisions - if you're starting a new project, you should use the most capable tools available.

by dirkf 7y ago

BlueTemplar 7y ago

The issue seems to be that that tracking tool does not have its data backed up in the version control system?

JoshuaDavid 7y ago
This seems like it could be mitigated with an integration that watches the issue tracker for updates and then commits those updates to a docs folder on the appropriate branch of the appropriate repo. This would have saved quite a bit of headache at my last job actually.
- BlueTemplar 7y ago
  Or just use a version control system with issue tracker support, like Fossil ?
  - JoshuaDavid 7y ago
    Switching an existing project to a new VCS loses history or at minimum causes a new layer of "identifiers in the old system don't match the new one", no? In general, I've found value in figuring out how to improve existing systems where feasible rather than trying to migrate to a new system, since the existing system probably has advantages the new one won't. At minimum, people are already familiar with the existing system.
    - BlueTemplar 7y ago
      Of course - but I'm not sure why you assumed that I would suggest that, instead of using a different VCS for a new project.
      - JoshuaDavid 7y ago
        Ah. I've spent a lot more time working on projects I inherited rather than ones where I made the initial technical decisions - if you're starting a new project, you should use the most capable tools available.