[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Git migration update



Hi Damyan

On Wed, Aug 03, 2011 at 01:56:58PM +0300, Damyan Ivanov wrote:
> -=| Alessandro Ghedini, Mon, Aug 01, 2011 at 05:32:35PM +0200 |=-
> > I do have a couple of notes that I think are worth discussing.
> 
> Thank you for the comments!
> 
> > * commit policy
> > 
> > > Some prefer to update debian/changelog with each commit, others leave 
> > > this to the git-dch(1) tool at package release time.
> > 
> > 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'. 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
 * debian/copyright:
   - ...

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.

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?

Regards
Salvatore

Attachment: signature.asc
Description: Digital signature


Reply to: