You’re building an internal app for managing git repos. Your users are largely nontechnical, and are vocally pushing for the ability to globally edit commit messages through the web UI. What do you do?
Posted by labab99@reddit | ExperiencedDevs | View on Reddit | 20 comments
Purely hypothetical :)
Pretend GitLab and GitHub don’t exist. For any other contrivances in the premise, assume there are political reasons. It’s far too late to use a repo backend other than git.
SlightStruggler@reddit
If they are nontechnical how are they going to commit anything?? And why would you let a nontechnical person edit commit messages globally?????????????????????????
git is not a ticketsystem tool, there are different layers with different tools for a reason. There is no use case for nontechnical users to use git that would not be fully covered by an appropriate program within their user level.
If you really want to build it, you are basically just creating a primitive textboard with a git backend that serves no purpose besides littering.
kbielefe@reddit
git notescomes to mind first. It lets you associate notes with a commit without changing it.evanthx@reddit
Why on earth am I building something that has like a million open source versions already available?!
grumd@reddit
Add a middleware layer that the users use to communicate with git. They shouldn't directly edit commits, they should work with something user-friendly that uses git as the "backend". Then just have an sql database of "commit messages" that simply map commit hash -> message, and the actual real git commit message could be something else
TheTacoInquisition@reddit
This was my first thought. Stop showing the commit messages to non-technical users, build a comms app around it instead.
But to add, understand what issue they're trying to solve it first. If non-technical users are not finding the commit messages helpful, but like to read about what was added/changed then build the above, but to solve a real issue. If the commit messages are unhelpful to *everyone* (for example, "fix", "", "8367283 lol") then a non-technical solution should be used to stop the silliness. If they want more of a changelog kind of thing, then mimic the PR approach github has and allow a "feature" comment to be added at branch merge points.
grumd@reddit
Yeah if the commit messages are shitty then just use commitizen/commitlint
chrisrrawr@reddit
seconding this. we had to do essentially this to stop offshore teams from breaking everything everywhere when they tried to deploy to envs. give them an easy to use workflow, make sure they can't mess with the auto update, and no one is going to dig in or question what it's doing.
shozzlez@reddit
This reads like some prompt you would feed your ai chat.
Drawman101@reddit
No
Timely_Cockroach_668@reddit
This is psychotic
etxipcli@reddit
Think about the users, they don't care about the technical details. Understand their needs better and don't rewrite git history.
Esseratecades@reddit
My largely non-technical userbase is using an analog for GitHub/GitLab? Who's dumb idea was this?
bluenautilus2@reddit
honestly i would add a custom layer on top of the commits. it stores a description for each commit. initialize it to the original commit message, but it can be edited. use the commit hash as the primary index
No_Jackfruit_4305@reddit
Show them a video of someone going through merge conflict badlands. Then tell them that this is what they're asking for. If they dont understand, then I'd use a practical exercise to explain better. Everyone has to work on the same artwork. They share a common endgoal, but assign each work with possible overlap. Then somehow prevent them from seeing everyone else progress (use tracing papers). Finally combine everyone's art together without trying to fix anything. Does it look horrible? Of course it does, they all blindly contributed without knowing what others did.
Out of curiosity, what experience do these people have with large group projects? And what are they building exactly?
UnbeliebteMeinung@reddit
"Experienced Dev"
Fyren-1131@reddit
I'd say that this is all wrong, and whatever they're trying to do is either for the wrong reasons, or they're actually trying to do the wrong thing itself.
It's like an organizational X/Y-problem at scale. Fascinating.
engineered_academic@reddit
The question here is why. Why is going to drive the entire process.
-Dargs@reddit
Editing the commit message serves no purpose to non technical people so why make it a feature? Do they think changing the method changes the behavior of the code? The commit log is a description of what has happened in a changeset. It serves no purpose other than to document changes at a high level. It is not a release log. It is not public facing. It is not always representative of full features and can have WIP code.
Tell them no and hide git commit history from people that aren't working on the code. Joe shmoe from product doesn't need to be looking at git logs. He should talk to the engineering team if necessary to confirm production functionality
VillageTube@reddit
Ask why? Everything here sounds wrong.
kondorb@reddit
What non-technical users have to do with git? That's an oxymoron, keep those two entities as far away from each other as possible.
If you really want users to collaborate git-style you'll have to hide that git behind some UI that will prevent users from screwing everything up.