Writes only the first commit on every run about auto-changelog HOT 14 CLOSED

@levaigabor Do you have an example or a test case where this happens?

from auto-changelog.

Maybe @levaigabor stumbled over the following too:
We internally merge branches into master for each new module version.
This comes with parent commit (the merge itself) and assigned sub-commits. Only the parent one is listed in change log. But in case multiple devs are working on such a branch, having the child commits also listed would be very great as every dev could have been working on a different task.

from auto-changelog.

The auto-changelog works pretty fine except the fact that it only writes the first commit on every run, although there are 5 commits after that.

@levaigabor I've just published 1.0.0, which lists up to 3 commits by default, so this should be sorted now.

This comes with parent commit (the merge itself) and assigned sub-commits. Only the parent one is listed in change log. But in case multiple devs are working on such a branch, having the child commits also listed would be very great as every dev could have been working on a different task.

@Papakai This sounds like a pretty specific use case but I'm interested. Do you have an example squashed merge commit message? I could maybe add a --expand-squash-merge option or similar, that attempts to parse any commits listed in a merge commit message.

from auto-changelog.

This sounds like a pretty specific use case

No, that's a very common and known way. Actually I do not have a public example. But I can provide you a kind of step by step guide:

• create a branch out of current master e.g. called "mergetest"
• check that branch out locally
• make some commits and push them to remote
• let another person do also one or more commits and push them to remote
• the commits have to be merged per developer (as far as possible).
• the branch needs to get rebased to current head of master before merging it

So how to handle the last to steps?

• Rebase to current head of master (can be done anytime)

git fetch origin --prune
git checkout master
git pull
git checkout mergetest
git rebase master
git push -f

• merge commits per dev (after rebase to master)

git rev-list --count HEAD ^master
git rebase -i HEAD~<amount of commits returned by prev command>
// then use `pick` / `squash` accordingly
git push -f

if you need help by a 2nd person here, I can support with some commits.

HTH

from auto-changelog.

This sounds like a pretty specific use case

No, that's a very common and known way. Actually I do not have a public example. But I can provide you a kind of step by step guide:

Sorry, I wasn't very clear: I understand that squash-merging or rebase-merging is common, but normally you would not want a full list of commits in a changelog. Even keepachangelog recommends against it:

Using commit log diffs as changelogs is a bad idea: they're full of noise. Things like merge commits, commits with obscure titles, documentation changes, etc.

The purpose of a commit is to document a step in the evolution of the source code. Some projects clean up commits, some don't.

The purpose of a changelog entry is to document the noteworthy difference, often across multiple commits, to communicate them clearly to end users.

http://keepachangelog.com/en/1.0.0/#bad-practices

I think the usual use case is that the merge commit is enough, and there is always the link to the commit for interested parties to view more information, including the full commit message. Also, the default templates will limit the commit list to a max of 3 anyway.

Actually I do not have a public example.

Can you provide an example of the format of the merge commit message, with the list of commits in? Even if the messages are changed to placeholders.

from auto-changelog.

Even keepachangelog recommends against it

hmm, I understand the arguments - but in case we are on of the teams that clean up commits :), it would at least for us something useful. Maybe just an idea to make it available through a configuration option / command line flag?

If not and you'll follow standards, then I'm pretty ok with that too. Don't worry. I just wanted to provide my thoughts on how this issue could have happened.

Can you provide an example of the format of the merge commit message, with the list of commits in? Even if the messages are changed to placeholders.

That would be possible, but no idea how to produce that format or how you request it.

from auto-changelog.

hmm, I understand the arguments - but in case we are on of the teams that clean up commits :), it would at least for us something useful. Maybe just an idea to make it available through a configuration option / command line flag?

I like the idea of supporting it through a command line flag.

That would be possible, but no idea how to produce that format or how you request it.

What I mean is, do your merge commits look like this?
https://github.com/xtuple/merge-squash-merge/commit/73042c52b0478e2be91e95e9bdf61c865d3956a9

If so, I see a couple of problems:

• The sub-commits are just basic text in a list, with no author, hash or link to the individual commit details (because that commit does not exist on the repo)
• Considering the limit of 3 commits per release, the likelihood of the sub-commits showing up in the changelog are pretty small, assuming you have other merges/fixes per release.

from auto-changelog.

hmm.. hard to say as the gitlab interface looks very different compared to the git web interface.
At least I can say that in gitlab, there's always an author assigned to a subcommit. No idea what's behind there (gitlab specifics or some special git commands).

Basically a detailed description added to the merge request makes more sense and that would then appear in changelog? (sorry I had not yet tried that out...)
So the person that performs the merge needs simply to care about having that description reviewed nicely and that's it.

from auto-changelog.

Ah yes, I forgot you are using GitLab.

What displays when you run git log --format=%B -n 1 [gitlab merge commit hash]? It should output the raw merge commit message.

from auto-changelog.

Merge branch 'FCP3-2839-testClaimFactory' into 'master'

FCP3-2839-testClaimFactory

See merge request front-end-team/fnode!2322

that's about a merge request with a single commit. I have currently no example available for a merge with multiple commits (thus multiple devs)

from auto-changelog.

Ok cool. If you can get me an example with multiple commits, then I can probably parse it and include those commits in the changelog when using a certain flag 👍

Probably worth opening a new issue when you do.

from auto-changelog.

ok, thanks I will check if we can get that realized internally. the most of the projects are no teamwork, so maybe I just need to create an example repository for it. I'll keep you updated.

from auto-changelog.

https://github.com/papakai/auto-changelog-merged/commits/master

as example for this. Even though I was the only person comitting, this still reflects it. The 3rd sub-commit of that merged PR is a merged commit (not sure if that changes things for you, but fyi).

from auto-changelog.

Let me know if you also need a version / tag commit.

from auto-changelog.