Skip to content
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

Open
omry opened this issue Jan 15, 2020 · 7 comments
Open

git commit log history pollution #3

omry opened this issue Jan 15, 2020 · 7 comments

Comments

@omry
Copy link

omry commented Jan 15, 2020

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.

@asherp
Copy link
Owner

asherp commented Jan 15, 2020

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!

@asherp
Copy link
Owner

asherp commented Jan 15, 2020

Looking at the above workflows, I'm thinking of the following feature:

  1. hourly-in/out will prompt you for a commit message for if there are any staged files
  2. If you enter a commit message, hourly commits those files with your message
  3. If you leave the message blank, hourly commits your files and the work log with "clock-in" or "clock-out" message

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...

@omry
Copy link
Author

omry commented Jan 15, 2020

Generally speaking, Git works well without requiring explicit ownership of who edits a file.
merge conflicts, while are annoying - are rare and in general the added benefit from being able to edit any file without coordination is worth the rare merge conflicts.

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).

@asherp
Copy link
Owner

asherp commented Jan 16, 2020

Generally speaking, Git works well without requiring explicit ownership of who edits a file.
merge conflicts, while are annoying - are rare and in general the added benefit from being able to edit any file without coordination is worth the rare merge conflicts.

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.

(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).

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.

@asherp
Copy link
Owner

asherp commented Jan 16, 2020

Also, I found these!
"clock-in" could be replaced by ⏳
"clock-out" could be replaced by ⌛

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?

@omry
Copy link
Author

omry commented Jan 16, 2020

Let's assume you do put it all in a different hidden branch.
The data is there, you still can provide a command to view the raw data and you can still generate summaries which is what people would be looking at anyway.

Maybe this is something you can consider as an option: explicit or hidden clock-in/out tracking.
I like the clock glyphs, they are cute :)

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).
They would be able to tell you if they like the clock-in messages or want them out of the way normally.

@asherp asherp mentioned this issue Mar 22, 2020
@asher-pembroke
Copy link
Collaborator

This is an old issue, but I'm still considering it

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 way this could work:

  1. hourly-in creates/checks out username-hourly branch and updates/commits to work log and switches back to previous branch
  2. user commits other work as needed
  3. hourly-out checkout out username-hourly branch again, updates work log and switches back to previous branch

Pros:

  • All commits on working branch are still sandwiched between clock in/out messages, but the bookkeeping is in a separate branch.
  • Commit authorship will still be annotated with the current user name
  • Avoids worklog merge conflicts

Cons:

  • How do we include work logs with project documentation?
  • Total labor per branch is not explicit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants