masukomi
Keeping comments in another branch instead of an API server
Wouldn't it make sense for devs to simply have another branch on the repo they are commenting on, to add the private comments? They don't need to push that branch if they want to keep it secret. I.e why have a web server?
Wouldn't it make sense for devs to simply have another branch on the repo they are commenting on, to add the private comments? They don't need to push that branch if they want to keep it secret. I.e why have a web server?
there are 2 problems with that as i see it, but they're tightly coupled.
The core problem is sharing, either with yourself on another device or with a team.
backstory
PC was written because i was working on a team of contractors on a codebase that was a freaking nightmare. I wanted to leave comments and breadcrumbs EVERYWHERE because there was so much chaos. it took so much time and mental energy to figure out how B worked that by the time you got back to A all the energy spent on figuring it out was now forgotten and had to be mostly redone.
I'm talking tons of figuring stuff out before making ANY changes just wrap our heads around things, and it wouldn't have been appropriate to litter the client's codebase with those notes to ourselves.
If PC existed then my coworkers and I could have left our breadcrumbs to each other across the codebase, and all we would need was a cron-job to sync down the latest from the shared PC codebase.
Your suggestion
The problem, as i see it, is that i frequently go to computer 1 do some work, go to computer 2 work on the same repo. While i may git fetch and keep all my upstream references up to date, i don't see myself, or others to remember to constantly sync down "the other branch" which contained the PC stuff. So, things would get out of sync.
You could get around this by writing a custom command for git checkout that also updated the "other" branch with the PC comments but I don't think many people would be interested in that approach.
I guess you could set up a cron job for each repo but that seems... more of a pain.
Additionally, by baking 99% of the functionality into a server it means that writing plugins for various editors is very easy. If we got rid of the server then a lot more code would have to be implemented and adoption ( and thus sharing within teams) would be even more of an uphill struggle than it already is. ;)
In conclusion
If you can think of a way to do this entirely in 1 repo, that allows for users to use multiple devices, or share with others, without relying on a user doing any of the following I 100% want to hear it.
- configuring a cron for each repo
- needing to remember to sync an alternate branch for PC
- needing to use an alternate comand for
git checkout/ git fetch / whatever
Maybe there's a way with a post-update hook?
Right, I think we may have different use cases, where both ways have their benefits.
The direction I was coming from was that if I'm working with large and unfamiliar code bases, it would help me if I get to add off-band comments/thoughts/todo items to any locations without adding them as regular comments within actual code, as they may just be random thoughts and not really helpful to anyone else. And the reason for having them within git would be that I wouldn't have to run any additional infrastructure to make it work (other than needing an editor plugin).
I think we may have different use cases, where both ways have their benefits.
To me they seem almost identical. The only real difference is that syncing & sharing isn't important to you. 99% of the time it isn't to me either. I'm either leaving private comments on personal repos (home computer) or work repos (work computer) and the two don't cross, and so-far only 1 of my coworkers has ever shown even mild interest in the idea of being able to leave "private comments".
Also, because so few people see the value of leaving private comments there's a strong argument to be made that getting team-members to join in the commenting or care about yours is... very low.
...the reason for having them within git would be that I wouldn't have to run any additional infrastructure to make it work (other than needing an editor plugin).
I think that's 100% valid. However, even if we say "meh, i don't care about anything other people do" there are 2 "problems" remaining.
- other devs (or worse, the client if you're a contractor) can see your comments branch if it ever gets pushed. If you don't push it, then you loose all your comments unless you're backing up your git repo locally.
- if a bug is discovered in the core process, or a feature is added, it has to be added to every plugin. Massive duplication of effort.
For me 2 is the big problem. 1 is ... debatable, but i think the potential downside is high enough that i don't want to be the person responsible for it happening to someone else.
I ended up writing a blog post protecting users from the consequences of their comments. The basic summary is that storing private comments in the same repo is dangerous, and in the extreme cases can get a person who does it fired, or worse.
BUT with regards to the comment about running additional infrastructure, I have a question and a suggestion.
Question: If you're like most devs you have one or more tiny LSP server processes running in the background providing useful info about your code like compile errors, and warnings. Why is that acceptable but not something like this? Especially considering how conservative PC is with regards to resources (memory and CPU). PC takes up very little memory (~7Mb) and essentially no CPU (~0.0% at idle). It can also be auto-started by the plugin (the emacs plugin does this), and like the editor plugin, only has to be thought about when you install it the first time.
Suggestion: If the running of the additional resource is really important to you, the core functionality can 100% be moved into the plugin. 99% of it lives in one 403 line file that i think would be pretty easy to port to other languages. HOWEVER, for the protection of you and anyone who might use your plugin I'd strongly encourage you to never save the files in the same repo. There's very little upside, and a significant potential downside (see the blog post linked above).