CODEWITHSUNDEEP
git
FooBar
FooBar

Reputation: 16478

Git: Changed numbers of lines of code per day

I want to measure the number of changed/added/deleted lines of code per day, for a longer run project.

The project is already on git, but I'm only committing irregularly at this point. Do I understand correctly that git mainly supports #changed-lines, as difference between commits? In that case, I'd need a script that commit -am every day, in case there's something I forgot to commit.

I understand that commits are originally thought of to be change-based, not time-based. However, I'm alone on this project, and this would lead to the following commit structure:

01.01. 05:06 manual commit "foo bar done"
01.01. 23:59 automatic commit -am
01.02. 03:06 manual commit "asdf  done"
01.02. 05:07 manual commit "asdf  done"
01.02. 12:15 manual commit "asdf  done"
01.02. 23:59 automatic commit -am

I'd be willing to take on the additional noise added by these commits, if it allows me to more accurately measure the number of lines changed per day. However, it'd be nicer if these automatic commits outside of my current work environment, such that they don't mess with my regular commits.

Is there perhaps a way to have two git repositories for the same folder? Or can I commit my automatic commits to a separate branch that doesn't mess with the rest?

Apparently, I need to be more explicit: I am aware of how to count lines between commits, I'm looking for a way to create daily commits that help me count the lines -- in a way that doesn't interfere with my regular setup and commits

Upvotes: 1

Views: 1011

Answers (3)

cmaster - reinstate monica
cmaster - reinstate monica

Reputation: 40604

I agree with Roland Smith that you should not dirty your commit history with automatic commits, especially not with commits done with git commit -a.

That said, you could do the following:

  • Maintain two independent branches in the same repository.

    The first branch is your normal master, to which you only ever commit explicitly and manually.

    The second branch is your automatic daily changes branch, which you don't ever touch manually.

    These two branches are not linked to each other. No merging, just history recorded twice.

  • The script for your daily automatic commit performs the following actions:

    1. Assert on HEAD pointing to master. You don't want your repo to be in an unexpected state when this script is run.

    2. Save the current state with git stash, so that it can be restored later perfectly.

    3. It then checks out the commit created by the stash (which puts your repo in detached head state). This restores the state of both the index and the working directory to the state you had before the stash.

    4. It performs a git reset --soft automatic-branch to attach to the automatic commit branch retaining the current index state.

    5. It performs a git commit -m "$(date <whatever-date-format-options-you-prefer>)". Note that you don't need git add, everything's already staged by the combination of git checkout and git reset --soft.

    6. It switches back to master with git branch master and restores the index and working directory with git stash pop. Since it was asserted that HEAD is on master in the first step, this git stash pop is guaranteed to succeed without conflict.

Of course, this all feels a bit hacky, and I won't be willing to give any guarantees for this not to loose data under special circumstances. But it's certainly better than mingling automatic git commit -a commits into your normal history.

Upvotes: 1

FooBar
FooBar

Reputation: 16478

The cleanest solution I found is to have several git repositories in the same directory: the default one for standard git functionality, and an additional one for tracking purposes. When a repository already exists, the following sequence of commands adds a new one for tracking.

git mv .git .git_backup
git init .
mv .git .gittracking
mv .git_backup .git

Then, standard git commands run over the old repository. For tracking purposes, use --git-dir=.gittracking. The following script is ready to be run by cron job, adding all new python files subdir code, commiting those together with all other changes:

#!/bin/bash
# track to git
git --git-dir=.gittracking add code/\*.py
git --git-dir=.gittracking commit -am "hourly track"
git --git-dir=.gittracking push

Upvotes: 1

Roland Smith
Roland Smith

Reputation: 43495

To get a count of the lines changed, parse the output of git log --shortstat.

An example:

commit 0710693045fb10832d218354966edd979515c794 (tag: refs/tags/3.3.3)
Author: Roland Smith <[email protected]>
Date:   Sun Aug 20 16:24:11 2017

    Update documentation. Refactor build.py.

 4 files changed, 25 insertions(+), 36 deletions(-)

commit ab73ef004ab55ba76b6a3a305edab3f723454387 (tag: refs/tags/3.3.2)
Author: Roland Smith <[email protected]>
Date:   Tue Aug 15 15:35:27 2017

    Disable automatic version generation.

 3 files changed, 19 insertions(+), 19 deletions(-)

commit 7ea8788b6e280d05fc93ad370e74a002c7f6f691 (tag: refs/tags/3.3.1)
Author: Roland Smith <[email protected]>
Date:   Thu Jul 13 00:32:16 2017

    Shorten often used operator in types.

 1 file changed, 50 insertions(+), 50 deletions(-)

Execute git log --shortstat and capture the output. Using your favorite programming language filter out the lines that start with Date and the lines that contain insertion and deletion From there it is quite simple to parse these lines and gather the information that you want.

Work should only be considered finished when it is committed. So using automatic commits to generate better linecounts is a bad idea. It will foul up you commit history. Automation is not a replacement for proper commit discipline.

Edit: You could also use git diff to check and count uncommitted changes if you are so inclined.

Upvotes: 0

Related Questions