GitLogParser: Simplify and automate the process further

[NearW]

Feature request

Description

Right now, the user always has to run three commands in order to generate a cc.json from a gitlog file. Like a lot of imports, they consume some sort of data source and generates a cc.json. This is a design decision.

Commands required: git log --numstat --raw --topo-order --reverse -m git ls-files > file-name-list.txt ccsh gitlogparser <log_file> -n <file-name-list>

However, I think it would be a better user experience if the user simply provides a path to a project and the ccsh itself creates the gitlog file and the filenames and imports it with the GitLogParser.

Acceptance criteria

• The user can run a task to parse git metrics from a given local file system path (repo path)
• The user can run a task to parse git metrics from a given git log and a given file-names-list
• The user has to specify in the command, which of both approches he wants to use (this is implicitly done, see Development Note).
• The README files are updated
• The README should still contain information, how to create the git log and the file name list.
• The documentation in GitHub Pages is updated (if any).
• The user can use the gitlogparser (sub) commands interactively
  • The user is asked for the sub-command to be used
  • The user is asked for required and optional parameters interactively

Assumptions & Exclusions

Development notes (optional Task Breakdown)

• It might make sense to deliver small junks with multiple small PRs to deliver value to the Users quickly.
• [ ] Create a sub task like this ccsh gitlogparser repo-scan --repo-path <path>
  • [ ] --repo-path is an optional parameter. If set, creaate file-name-list and git-log for this path
  • [ ] if not set, show info message, that the parser is trying to to create file-name-list and git log for current working directory and please print current working directory in this info message.
    • [ ] if not possible, inform user with a speaking error message
  • [ ] and as a last step run the original gitlogparser logic to create cc.json file from both files.
• [ ] Create a sub task like this ccsh gitlogparser log-scan --git-log <path> --repo-files <path>
  • [ ] --git-log is a required parameter.
  • [ ] --repo-files is the old -n parameter and it is required.
  • [ ] as a last step run the original gitlogparser logic to create cc.json file from both files.
• [ ] It should be possible to use the sub commands interactively

Open questions

• We should think about how to implement the interactive dialogs for "sub-sub-commands". Currently we do this for the sub commands on level 2 (e.g. ccsh gitlogparser). Now we need this functionality for the third level as well (e.g. ccsh gitlogparser repo-scan). It is recommended to not develop a big solution, that is reusable for all parsers/importers that might have some 3rd-level sub commands in the future (YAGNI). We can think about this if someday we want to extend/add other parsers/importers with this kind of interactive sub commands.

[HannahMagin]

commit 1d0b99a7c30d5ea019701c66a27a566391e5e09f was accidentally not linked

[HannahMagin]

Thoughts: I agree to keep the old version, as we might not always have the possibility to connect to the repository itself. However, in my opinion it is problematic that given the implementation is as described above, the first argument can either be a path to a directory OR a to a prepared file and that depending on this, the -n parameter is either required or not wanted. This makes the usage unclear for the user and the code relatively complicated. So ccsh gitlogpaser FILE ccsh gitlogparser PATH -n ccsh gitlogparser -n would all be invalid commands, the user could enter accidentally, we have to handle and give a meaningful error message.

Possible solutions:

• Implement it like this, ignoring the possible problems
• Leave the old command as it is, have a completely new command that handles the preparation as well (ccsh gitrepositoryparser FILE)
• Add a switch -> ccsh gitlogparser PATH —repository vs ccsh gitlogparser FILE -n
• ???

[ce-bo]

@HannahMagin and I talked about a possible solution. I updated the development notes accordingly.