niklasrosenstein / git-worklog

Migrated to https://gitlab.niklasrosenstein.com/NiklasRosenstein/python/nr.cli.git-worklog

👋 Hi, I'm Niklas. I like Python, Kubernetes and Tooling.

git-worklog's Issues

Ability to filter/process output from show command

Specifically, I'm thinking about the ability to

• Filter by start and end times (eg. only show logs from the past 10 days) or keywords in the command
• Convert output to other formats (TSV -> CSV, JSON, Excel)
• Create reports (potentially across multiple users), eg. as PDF, Excel, LaTex or HTML

Command to checkout and immediately checkin again

This would be useful to simply to create a commented entry in the logs but continue working immediately.

Example:

$ git timetrack checkpoint -m "Did this and that"

Option to store logs in a separate repository

It would be nice if the work logs could, optionally, be stored in a separate repository instead of in the timetracking branch. That repository could then be configured with .gitconfig. In such a case, the logs should not be stored in a timetracking branch but instead in a branch that is named after the current project that you're working on. This should also be configured with .gitconfig.

Eg. you could configure the repository in your global ~/.gitconfig:

[timetracking]
  repository = ~/repos/timetracking

And then do a per-project

$ git config timetracking.project myprojectname

--time option bad default arguments

Using the --time option in the worklog checkin or worklog checkout commands does not apply proper default values. This needs to be fixed in git_worklog/timetable:parse_time().

$ git wl checkin --time 15:50
checked in: Niklas Rosenstein at 01/Jan/1900:15:50:00

Command to abort the current session

Something like

$ git timetrack abort
Aborting session for Niklas Rosenstein
Checked in at 25/Nov/2017:16:00:15 +0100

Option to automatically push on checkout

This could be enabled in the global ~/.gitconfig, eg.:

[timetracking]
  push-on-checkout = true

or additionally as a command-line flag --push to the git timetracking checkout command.

There is also the potentional of existing changes on the remote and conflicts. I think that simply doing git pull or even git pull --rebase would suffice. Also, I imagine we can think about potential conflicts another time (if you consistently push your work logs and no-one else modifies your own work logs, it should be fine).