Re: Auto-generate debian/changelog from Git commit history
> Hi all,
> I would like to suggest some Git specific handlings in our
> development workflow now that we have migrated most D-E projects to
I'm positive to try out such workflow, but have no experience with it
myself. I agree that we should look at our workflow now that almost
all our packages are in git. :)
> 1. Make sure you always do "git pull --rebase". This will
> keep the commit history in order, even if we pull
> from origin while we already have local commits in our
> local working copy.
> The --rebase option can be put into ~/.gitconfig 
If I am not mistaken, this will make working on feature branches and
merging branches from contributors harder, as the next 'git pull' for
the contributor after a commiter merged and rebased the contributors
branch will cause problems. Is this really something we want? One
thing is rebasing local changes not yet pushed anywhere, but if one
pull from one repository and want to push it into the official
repository, I suspect rebasing is the wrong thing to do. Why is
keeping the commit history in order required?
> 2. Let's drop the habit of accompanying an entry to
> debian/changelog with each Git commit. This makes rebasing very
> hard (because every rebase step will very likely let pop up a
> conflict in debian/changelog).
In ltsp we adopted the method of commiting changes and changelog
entries separate, to make merging easier. I guess it is an
alternative if we want to ease merging between branches. It will not
affect rebasing, I suspect.
> 3. Let's use Git history to compose our later debian/changelog stanza
> With such an approach the debian/changelog file gets created just before
> the upload to unstable (the tool "git dch --auto" will be the uploader's
I have not tested this approach myself, and am unsure how good its
changelog will look.
> With such an approach (auto-generate debian/changelog just before
> upload) we ease our daily work with Git. Tasks like branching off,
> merging in branches, rebasing, non-merge pulls, etc. become much
These features definitely sound like something we should aim for. I
am just unsure if advantages outweigh the negative consequences.