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

Re: Git migration update



Hi Damyan

On Wed, Aug 03, 2011 at 03:33:25PM +0300, Damyan Ivanov wrote:
> -=| 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.

Sorry about that. I was not clear. I meant, that in final changelog
(In my opinion) the entries should be reorganized into 'groups', e.g. 

 * debian/control:
  - change 1
  - chagne 3
 * debian/rules:
  - change 2
...

instead of

 * debian/control: change 1
 * debian/rules: change 2
 * debian/control: change 3


But this is my opinion. And as you said, this can be adjusted later
before uploading the package.

We should simply agree in the group how we want to manage
debian/changelog overall. I'm too fine to use git-dch only. Important
thing is to be consistent in the group to not loose any changes which
belong to debian/changelog.

One example where this can happen, was mentioned by Alessandro, if
someone commits a change to debian/changelog in between.

To resume as non-git-expert: I'm both fine to update changelog on each
commit, as too using git-dch and reordering the entries, as log we are
consistent in using git-dch in the Group.

Regards
Salvatore

Attachment: signature.asc
Description: Digital signature


Reply to: