I'm creating a changelog generator that works for our specific use-case.
If I'm understanding how git works, when I git log <tag> or git log <tag1>..<tag2> (or use ...) the returned set inherently belongs to that or those tags respectively. OK, assuming I'm right, that's fine. The problem is a couple of things, though.
If I use git log <tag>, git doesn't just return a set of commits for that tag. It returns commits for that tag if that tag is the first tag of that tag pattern or all commits for all tags from the requested tag up to the first tag matching pattern. And that's OK IF I can attribute to what tag each commit belongs, but I can't it seems. This seems to be the biggest hodge-podge of git in my opinion. There doesn't seem to be an explicit way of relating commits to a specific tag, unless I'm just not doing this the right way.
I've tried using several methods to include implementations of libgit2 in code I've written and apps others have written. I've concluded that it's simply best to just rely on the system git command, which still misbehaves in my opinion:
git log --merges --decorate=full --pretty=format:%H [some tag or tag range]
per hash I do the following:
git show $hash -s --decorate
I'm also using a template to capture things that don't show in the default output to include refs from %D -- sometimes refs is empty, which doesn't make sense because I'm pulling the commit hash from a tag range! This behavior doesn't make sense at all!
It seems that I should be able to relate every commit from a git log <tag> to its constituent tag. How do I make sure that my log output always shows the tag (s) to which a commit belongs?
