Core Concerns / Functionality?
dazinator opened this issue · 16 comments
Propose we discuss / document a simple list of concerns for GitTools.Core - i.e what functionality do we want in version 1?
Perhaps then we can break that out into issues and make some appropriate assignments. I imagine that stuff we place in the core has allready been implemented in multiple tools, seperately - so we'll need the ability to discuss / review where (if anywhere) the most appropriate implementation lies.
Does this sound like a sensible idea?
Sounds good. I can think of a few:
- Git extensions (extension methods written for all git repositories, including unit tests)
- Dynamic repositories (and the ability to re-fetch instead of full cloning that is implemented recently in some tools)
- Logging (already there, LibLog)
- IO services (do we see a need to abstract this)?
I would love to see a GitTools.Core.Testing and it has the GitVersion testing stuff (the fixtures/test extensions like .MakeACommit().
- 👍
- 👍
- 👍
- Unsure, i'd leave it out for now unless we need it to provide the functionality in core?
Is it really necessary to make it a separate package? Sounds a bit too harsch simply for testing scenarios. Why not a Testing namespace inside GitTools.Core? It's not that it will explode the assembly in size, but we can discuss it here.
This is probably another discussion, but I would like to provide a git abstraction for querying the metadata we need for most of these tools (we need branches, commit tree etc). But we don't need the actual repo.
If we abstracted this then we could make the dynamic repository stuff transparent. For github we use the github API directly which can query the git structure without cloning.
@GeertvanHorrik i'm happy with a testing namespace, it is a small collection of classes and extension methods
Sounds complex, park that for v2?
@GeertvanHorrik yep, definitely a v2 thing.
@JakeGinnivan good, I will copy some of the stuff from GitVersion to GitTools.Core.
Lets use PR's going foward? :)
sounds like overkill, but ok for now
We have enough people so we can turn it around, but we have multiple implementations of all this stuff at the moment. Also can fix API issues and stuff which exists while putting into core
@dazinator what were the bits which got added in gitreleasenotes which are not in core so far?
@JakeGinnivan - potentially stuff we could leave until v2 now.
So I don't pollute this convo too much - here's a gist with an explanation of those changes:- https://gist.github.com/dazinator/cef95296b27e2f965716
Why don't you create a feature branch and start implementing it? Then we can check if we make it for v1.
Ok - will do!
I think we can close this issue and create separate ones for new features.