| |
| ▲ | fweimer 7 hours ago | parent | next [-] | | Ticket systems are quite ephemeral. I still have access to commit messages from the 90s (and I didn't work on the software at the time). I haven't been able to track the contents of the gnats bug tracker from those days. And of course tickets can be private, so even if the data survived migration, you may not have access to it (principle of least privilege and all that). | |
| ▲ | 7 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | skydhash 8 hours ago | parent | prev [-] | | Not really about design, but technical reasons why this solution came to be when it’s not that obvious. It’s not often needed. And when it does, it usually fits in a short paragraph. | | |
| ▲ | ImPostingOnHN 8 hours ago | parent [-] | | > technical reasons why this solution came to be What you're describing here is a design. The most important parts of a design are the decisions and their reasoning. e.g. "we decided on tool/library pattern X over tool/library/pattern Y because Z" – that is a design, usually discussed outside (and before) a commit message. You discuss these decisions with others, document the discussion and decision, and then you have a design and can start writing code. Let me ask you this: suppose you have a task that needs to be done eventually, and you want to write down some ideas for it, but don't want to start coding right now. Where do you put those ideas? How do you link them to that specific task? | | |
| ▲ | shakna 7 hours ago | parent | next [-] | | So you'd disagree with style that Linux uses for their commits? Random example: Provide a new syscall which has the only purpose to yield the CPU after the
kernel granted a time slice extension. sched_yield() is not suitable for that because it unconditionally
schedules, but the end of the time slice extension is not required to
schedule when the task was already preempted. This also allows to have a
strict check for termination to catch user space invoking random syscalls
including sched_yield() from a time slice extension region. From 99d2592023e5d0a31f5f5a83c694df48239a1e6c | | |
| ▲ | ImPostingOnHN 6 hours ago | parent [-] | | I think my post makes it pretty clear that I would. If you want, I could cite several examples of organizations which use the method I described, so you can weigh it against the one example you provided, and get the full picture. In your example, for example, where was the issue tracked before the code was written? The format you linked makes it difficult to get the history of the issue. Let me ask you this: suppose you have a task that needs to be done eventually, and you want to write down some ideas for it, but don't want to start coding right now. Where do you put those ideas? How do you link them to that specific task? | | |
| ▲ | shakna an hour ago | parent | next [-] | | Git was built for email, because that's the system Linux uses. Commits appear inline. Diffs are reviewed and commented inline. Email is the review process, and commits contain enough information that git blame can get you a reasoning - it doesn't require you checking the email archive. Rather than a dead ticket that no longer exists. I can also supply you a list of companies that make use of git's builtin features if you like. But thats probably not relevant to discussing management techniques. | |
| ▲ | skydhash 3 hours ago | parent | prev [-] | | Everyone has its own system although companies do tend to codify it with a project manager. I used TODO.txt inside the repo. an org file, Things.app, a stack of papers, and a whiteboard. But once a task is done, I can summarize the context in a paragraph or two. That’s what I put in the commits. |
|
| |
| ▲ | skydhash 3 hours ago | parent | prev [-] | | Here is an example https://cgit.freebsd.org/src/commit/?id=407b1e4980189252fade... You can find more example there https://cgit.freebsd.org/src/log/?showmsg=1 |
|
|
|
