-=| Salvatore Bonaccorso, Wed, Aug 03, 2011 at 01:50:12PM +0200 |=-
> On Wed, Aug 03, 2011 at 01:56:58PM +0300, Damyan Ivanov wrote:
> > -=| Alessandro Ghedini, Mon, Aug 01, 2011 at 05:32:35PM +0200 |=-
> > > Having worked with git for some time, I find that the first
> > > option (updating d/changelog at each commit) makes way harder to
> > > cherry pick, revert, bisect, and backport changes. Given that
> > > subversion misses many of the features that git has, this was
> > > not a problem in the svn days, but now
> > > I think it would ease the maintainance of the packages if everyone goes for
> > > option 2 and use git-dch(1) before releasing.
> >
> > I personally am very much found of option 2 too. However, while your
> > observations about difficulties with cherry-picking/backporting and
> > reverting are all true, they were also true in the SVN days, so we
> > don't really have a regression here.
> >
> > Using changelog-less commits would improve things for these cases,
> > although I am not sure how often are these needed.
> >
> > Also, what could possibly go wrong if using changelog-less commits?
> >
> > (RFC also included in git.pod)
> >
> > > For the same reasons I think it should be preferred and made clear in the
> > > docs the "one change per commit" policy.
> >
> > This was aways preferred anyway, but stressing it again won't hurt.
>
> I agree completely on 'one change per commit' part. However, I'm not
> sure in having 'one line in changelog per commit'.
I am not sure I follow. There is no 'one line per changelog entry'
policy. Ah, this must be the default git-dch setting. I just happen to
have
[git-dch]
full = True
in ~/.gbp.conf, which causes git-dch to use the full commit messages.
> For example if I
> modify debian/control, I often use then the following schema:
>
> * debian/control:
> - Add libfoo-perl to (Build-)Depends(-Indep) (Closes: #12345)
> - Add libbar-perl to Suggests
This is better written as:
update (build)-dependencied
- Add libfoo-perl to (Build-)Depends(-Indep) (Closes: #12345)
- Add libbar-perl to Suggests
if it is one commit. If there are two, then only the lines starting
with a dash. One can unite them later, during the normal adjustments
made to the changelog after git-dch.
> I would like to see this remaining instead of then having related
> changes mixed over the debian/changelog file. For example
> git-buildpackage changelog is done the other way. The first in my
> opinion gives a better overview where changes in the packaging
> happened.
git-dch is only a handy tool to populate debian/changelog. Adjusting
it it later for one's taste is perfectly normal.
> One question: If someone does a masscomit for some packaging
> changes, it is then intended too, to not do a changelog entry? But
> only on release time with git-dch?
I think this depends on the policy we adopt. So far (in SVN) we did
add changelog entry, but if conclusion is made that for normal work
changelog should be updated at release time only, then I see no
problem using that policy for mass-commits too.
Attachment:
signature.asc
Description: Digital signature