Re: Git migration update
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.
Partially. I mean, you can't revert single commits with SVN like you can
do with git, hence you don't really notice it even if you commit to the
changelog for every change. I'm not really into SVN so I can't say what it
can do or not, but the revert (as in git) functionality is something that I
missed several times.
> Using changelog-less commits would improve things for these cases,
> although I am not sure how often are these needed.
Sure they are not every day things, but it may happens to undo old changes
(old as "three-commits old"), or, if you are into backports, to cherry pick
changes to other branches.
> Also, what could possibly go wrong if using changelog-less commits?
The only thing I can think of is missing some commits in the changelog.
git-dch(1) gets all the commits since the last one that modified the
changelog, so if you do some commits, and than someone commits a change to
the changelog, do some other changes and runs git-dch, your changes do not
show up.
> (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.
>
> (git.pod updated)
>
> > * hooks for mailing list
> >
> > I don't know if this is on anyone's todo list but it seems that the git
> > repositories currently lack all the needed configuration to automatically
> > post all the commits, tags and similar to the pkg-perl-commits mailing list.
> >
> > Having a closer look at one of the repositories it seems that the code is
> > there but it has been disabled (or never enabled). Is there any reason to
> > not enable it, now that the migration is complete?
>
> I am not sure if these worked at all. Can someone try enabling the
> hook for a single repository and pushing to it? If everything works,
> there should be a mass-sed change plus update of the setup-repository
> script (I can do both).
Just tried with the attic/test.git repository (you should have seen the
email) and it seems to work. The changes needed are:
* git config hooks.mailinglist pkg-perl-cvs-commits.lists.alioth.debian.org
* git config hooks.announcelist pkg-perl-cvs-commits.lists.alioth.debian.org
* edit the file hooks/post-receive, uncomment the second line
For every repository.
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'
Reply to: