-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
git commit log history pollution #3
Comments
I see what you mean. That's because I was not committing code during the work session, but only at the moment I clocked out. The more appropriate work flow should be: hourly-in #commits to WorkLog.md
<perform work and stage changes>
hourly commit.message="my commit message" # updates WorkLog.md and commits changes
<repeat as necessary>
hourly-out # only commits to WorkLog.md For the gui, I plan on using the status of the work log to indicate who is currently on the clock (and available to contact). Here is another use case: <start work on a file and stage it for commit>
hourly-in # commit those files with clock-in message
git push # notify coworkers which files you are editing
<perform other work on files until you are ready to commit>
hourly commit.message="here is what I did"
hourly-out # tell coworkers not to bother you
git push This second use case might actually avoid some merge conflicts! |
Looking at the above workflows, I'm thinking of the following feature:
This way, you can still notify other devs as to which files you are editing (by pushing with clock-in) or when you are done working with them (by pushing with clock-out). It's completely optional and just depends on what works best for your team. I should also go back through my other repos and clean up the clock messages... |
Generally speaking, Git works well without requiring explicit ownership of who edits a file. I think there is a value in tracking the clock-in/clock-out times, but on a different channel that does not interfere with the regular check-ins. (you want to check-in/check-out every day, but you may want to push a feature several times a day or once every few days). |
This does not conflict with that workflow. Clocking in on individual files is a completely optional feature open to anyone who wants someone to know what files they are working on. If you want to do all your work in "ninja" mode, hourly won't stop you. The crucial bit I'm trying to preserve is the ability to audit what was done during a work session. Using a different branch for the clock messages would obfuscate that.
I work hourly, so I clock in and out like 10 times a day, committing code during each session. Keep in mind, developers are just the beginning: I want hourly to be useful to all freelancers, so making it easy to see who is working on what/when would be useful, even though it's totally optional. |
Also, I found these! This way it's just one character which would appear on your work log commits - everything else about your repo would be business-as-usual. What do you think? |
Let's assume you do put it all in a different hidden branch. Maybe this is something you can consider as an option: explicit or hidden clock-in/out tracking. In any case, you really want to get feedback from other freelancers and people that hire freelancers (the ones producing and the ones consuming this information). |
This is an old issue, but I'm still considering it
The way this could work:
Pros:
Cons:
|
Looking at the commit history of a project like this one or Kamodo, you can see that most of the commits are about check-in and check-out.
This is too noisy and can hurt adoption of hourly.
Git commit history should be about the project.
One idea is to use a hidden branch per our discussion on chat, to keep this metadata out of the commit history users are seeing.
The text was updated successfully, but these errors were encountered: