You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Paul Davis <pa...@gmail.com> on 2012/06/17 21:29:27 UTC
Re: git commit: Automate maintenance of the THANKS file
I'm not sure I like this so much. Playing around with it, its a bit
prone to screw ups. It also breaks if AUTHORS.gz exists before you
pull in new commits. We could solve that by forcing it to build every
time but that's a bit of a hack for not much gain.
Its also got Benoit in there twice since he made commits with slightly
different author/committer names which also seems awkward.
On Sun, Jun 17, 2012 at 1:29 PM, <ja...@apache.org> wrote:
> Updated Branches:
> refs/heads/master 9514ed3f5 -> 7646794ea
>
>
> Automate maintenance of the THANKS file
>
> THANKS now is automatically maintained for you. It uses git author
> data to append people who submitted patches in the past.
>
> For non-commit THANKS, you can still manually edit this file.
>
> This commit removes from the THANKS file the people that appear
> as git commit authors since we started committing them after
> commit 6c976bd. These removed entries get automatically re-
> added by `make`.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
> Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/7646794e
> Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/7646794e
> Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/7646794e
>
> Branch: refs/heads/master
> Commit: 7646794ea7a30d41a64c873d8b27ae830397d94a
> Parents: 9514ed3
> Author: Jan Lehnardt <ja...@apache.org>
> Authored: Sun Jun 17 20:06:21 2012 +0200
> Committer: Jan Lehnardt <ja...@apache.org>
> Committed: Sun Jun 17 20:11:31 2012 +0200
>
> ----------------------------------------------------------------------
> Makefile.am | 10 +++++++++-
> THANKS | 13 +++++--------
> 2 files changed, 14 insertions(+), 9 deletions(-)
> ----------------------------------------------------------------------
>
>
> http://git-wip-us.apache.org/repos/asf/couchdb/blob/7646794e/Makefile.am
> ----------------------------------------------------------------------
> diff --git a/Makefile.am b/Makefile.am
> index 9dd22b8..1cbd865 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -79,7 +79,15 @@ README.gz: $(top_srcdir)/README
> -gzip -9 < $< > $@
>
> THANKS.gz: $(top_srcdir)/THANKS
> - -gzip -9 < $< > $@
> + sed -e 's/^#.*//' $< > $<.tmp # strip comments
> + sed -e '/^$$/d' $<.tmp > $<.tmp2 # strip empty lines
> + git shortlog -se 6c976bd..HEAD \
> + | grep -v @apache.org \
> + | sed -E 's/^[[:blank:]]{5}[[:digit:]]+[[:blank:]]/ * /' \
> + >> $<.tmp2 # inject git authors
> + echo '\nFor a list of authors see the `AUTHORS` file.\n' >> $<.tmp2
> + -gzip -9 < $<.tmp2 > $@ # zip
> + rm $<.tmp $<.tmp2 # cleanup
>
> check: dev check-js
> $(top_builddir)/test/etap/run $(top_srcdir)/test/etap
>
> http://git-wip-us.apache.org/repos/asf/couchdb/blob/7646794e/THANKS
> ----------------------------------------------------------------------
> diff --git a/THANKS b/THANKS
> index f0dccb8..1e065f8 100644
> --- a/THANKS
> +++ b/THANKS
> @@ -66,7 +66,6 @@ suggesting improvements or submitting changes. Some of these people are:
> * Lim Yue Chuan <sh...@gmail.com>
> * David Davis <xa...@xantus.org>
> * Klaus Trainer <kl...@web.de>
> - * Dale Harvey <da...@arandomurl.com>
> * Juuso Väänänen <ju...@vaananen.org>
> * Jeff Zellner <je...@gmail.com>
> * Benjamin Young <by...@bigbluehat.com>
> @@ -92,12 +91,10 @@ suggesting improvements or submitting changes. Some of these people are:
> * Simon Leblanc <si...@gmail.com>
> * Rogutės Sparnuotos <ro...@googlemail.com>
> * Gavin McDonald <gm...@apache.org>
> - * Ronny Pfannschmidt <Ro...@gmx.de>
> - * Magnus Hoff <ma...@gmail.com>
> - * Alexander Dorofeev <ak...@gmail.com>
> - * Anthony S Baker <an...@gmail.com>
> - * Ewan McDougall <in...@mrloop.com>
> - * Adam Lofts <Ad...@gmail.com>
>
> -For a list of authors see the `AUTHORS` file.
> +# Dear committer who merges a commit from a non-committer:
> +# You don't have to manually maintain the THANKS file anymore (yay!).
> +# Non-committer authors get automatically appended to THANKS and
> +# moved into THANKS.gz by `make`. This note will be stripped as well.
> +# Authors from commit 6c976bd and onwards are auto-inserted.
>
>
Re: git commit: Automate maintenance of the THANKS file
Posted by Jan Lehnardt <ja...@apache.org>.
Thanks :)
On Jun 21, 2012, at 16:40 , Fedor Indutny wrote:
> Done ;)
>
> Cheers,
> Fedor.
>
>
>
> On Thu, Jun 21, 2012 at 6:37 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On Jun 18, 2012, at 12:29 , Fedor Indutny wrote:
>>
>>> Speaking of that, can I ask to add me to THANKS file? ;)
>>
>> Done, can you in turn close your PR on GitHub? :)
>>
>> Cheers
>> Jan
>> --
>>
>>
>>>
>>> Cheers,
>>> Fedor.
>>>
>>>
>>>
>>> On Mon, Jun 18, 2012 at 12:09 AM, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>>>
>>>> On Jun 17, 2012, at 22:05 , Paul Davis wrote:
>>>>
>>>>> On Sun, Jun 17, 2012 at 3:02 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>>
>>>>>> On Jun 17, 2012, at 21:56 , Paul Davis wrote:
>>>>>>
>>>>>>> On Sun, Jun 17, 2012 at 2:44 PM, Jan Lehnardt <ja...@apache.org>
>> wrote:
>>>>>>>>
>>>>>>>> On Jun 17, 2012, at 21:29 , Paul Davis wrote:
>>>>>>>>
>>>>>>>>> I'm not sure I like this so much. Playing around with it, its a bit
>>>>>>>>> prone to screw ups.
>>>>>>>>
>>>>>>>> I just don't want to maintain this file manually any more. It is
>>>>>>>> error-prone and makes merging user-contributions a pain. I'm happy
>>>>>>>> to have this implemented in any other way, but I think we should
>>>>>>>> try to remove any mechanical steps from maintaining our source if
>>>>>>>> we can. I hope you agree! :)
>>>>>>>>
>>>>>>>
>>>>>>> Its an extra step but not one that I find to be particularly onerous.
>>>>>>> Given that we're already working on codifying merge practices I don't
>>>>>>> see why we don't just add a check box for "includes commit adding
>>>>>>> yourself to the THANKS file if this is your first contribution" that
>>>>>>> we look for.
>>>>>>
>>>>>> That's a fair point, but this has annoyed me forever.
>>>>>>
>>>>>>>>> It also breaks if AUTHORS.gz exists before you
>>>>>>>>> pull in new commits. We could solve that by forcing it to build
>> every
>>>>>>>>> time but that's a bit of a hack for not much gain.
>>>>>>>>
>>>>>>>> Can you explain how it breaks if AUTHORS.gz exists before the merge?
>>>>>>>> If you mean THANKS.gz, my idea was that this is only relevant on
>>>>>>>> packaging time (make distcheck) where THANKS.gz by definition does
>>>>>>>> not exist.
>>>>>>>>
>>>>>>>
>>>>>>> I'm not sure its a good idea to have a file that is only built
>>>>>>> correctly in special circumstances.
>>>>>>
>>>>>> I'm happy to add an rm -f $< to the target.
>>>>>>
>>>>>>
>>>>>>>>> Its also got Benoit in there twice since he made commits with
>>>> slightly
>>>>>>>>> different author/committer names which also seems awkward.
>>>>>>>>
>>>>>>>> The subsequent .mailmap commit fixes the dupes. The push emails seem
>>>>>>>> to be delayed atm, I reported this to danielsh on #asfinfra.
>>>>>>>>
>>>>>>>
>>>>>>> I'm confused. You've removed one manually curated file only to add a
>>>>>>> new one that just modifies the build of the first? Seems like a lot
>> of
>>>>>>> gymnastics.
>>>>>>
>>>>>> .mailmap solves more than just this.
>>>>>>
>>>>>>
>>>>>>> In a perfect world I would be all in with you on this but
>>>>>>> unfortunately a large number of people don't spend time checking
>> their
>>>>>>> user settings before pushing commits around. Instead of just adding
>>>>>>> people to a file the first time they make a commit this means I have
>>>>>>> to go and check that the THANKS file is generated properly and then
>>>>>>> maybe update .mailmap if not and recheck that I got it correct.
>>>>>>
>>>>>> Fair enough, wanna revert?
>>>>>>
>>>>>> Cheers
>>>>>> Jan
>>>>>> --
>>>>>>
>>>>>>
>>>>>
>>>>> Playing with it a bit to see if I can make it build correctly and also
>>>>> just build the AUTHORS file. I'll leave it around for a bit but won't
>>>>> promise that the first time I spend more than 30s screwing with
>>>>> mailmap that I revert it.
>>>>
>>>> Heh, that took me a while to get right :)
>>>>
>>>> Cheers
>>>> Jan
>>>> --
>>>>
>>>>
>>>>
>>
>>
Re: git commit: Automate maintenance of the THANKS file
Posted by Fedor Indutny <fe...@indutny.com>.
Done ;)
Cheers,
Fedor.
On Thu, Jun 21, 2012 at 6:37 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Jun 18, 2012, at 12:29 , Fedor Indutny wrote:
>
> > Speaking of that, can I ask to add me to THANKS file? ;)
>
> Done, can you in turn close your PR on GitHub? :)
>
> Cheers
> Jan
> --
>
>
> >
> > Cheers,
> > Fedor.
> >
> >
> >
> > On Mon, Jun 18, 2012 at 12:09 AM, Jan Lehnardt <ja...@apache.org> wrote:
> >
> >>
> >> On Jun 17, 2012, at 22:05 , Paul Davis wrote:
> >>
> >>> On Sun, Jun 17, 2012 at 3:02 PM, Jan Lehnardt <ja...@apache.org> wrote:
> >>>>
> >>>> On Jun 17, 2012, at 21:56 , Paul Davis wrote:
> >>>>
> >>>>> On Sun, Jun 17, 2012 at 2:44 PM, Jan Lehnardt <ja...@apache.org>
> wrote:
> >>>>>>
> >>>>>> On Jun 17, 2012, at 21:29 , Paul Davis wrote:
> >>>>>>
> >>>>>>> I'm not sure I like this so much. Playing around with it, its a bit
> >>>>>>> prone to screw ups.
> >>>>>>
> >>>>>> I just don't want to maintain this file manually any more. It is
> >>>>>> error-prone and makes merging user-contributions a pain. I'm happy
> >>>>>> to have this implemented in any other way, but I think we should
> >>>>>> try to remove any mechanical steps from maintaining our source if
> >>>>>> we can. I hope you agree! :)
> >>>>>>
> >>>>>
> >>>>> Its an extra step but not one that I find to be particularly onerous.
> >>>>> Given that we're already working on codifying merge practices I don't
> >>>>> see why we don't just add a check box for "includes commit adding
> >>>>> yourself to the THANKS file if this is your first contribution" that
> >>>>> we look for.
> >>>>
> >>>> That's a fair point, but this has annoyed me forever.
> >>>>
> >>>>>>> It also breaks if AUTHORS.gz exists before you
> >>>>>>> pull in new commits. We could solve that by forcing it to build
> every
> >>>>>>> time but that's a bit of a hack for not much gain.
> >>>>>>
> >>>>>> Can you explain how it breaks if AUTHORS.gz exists before the merge?
> >>>>>> If you mean THANKS.gz, my idea was that this is only relevant on
> >>>>>> packaging time (make distcheck) where THANKS.gz by definition does
> >>>>>> not exist.
> >>>>>>
> >>>>>
> >>>>> I'm not sure its a good idea to have a file that is only built
> >>>>> correctly in special circumstances.
> >>>>
> >>>> I'm happy to add an rm -f $< to the target.
> >>>>
> >>>>
> >>>>>>> Its also got Benoit in there twice since he made commits with
> >> slightly
> >>>>>>> different author/committer names which also seems awkward.
> >>>>>>
> >>>>>> The subsequent .mailmap commit fixes the dupes. The push emails seem
> >>>>>> to be delayed atm, I reported this to danielsh on #asfinfra.
> >>>>>>
> >>>>>
> >>>>> I'm confused. You've removed one manually curated file only to add a
> >>>>> new one that just modifies the build of the first? Seems like a lot
> of
> >>>>> gymnastics.
> >>>>
> >>>> .mailmap solves more than just this.
> >>>>
> >>>>
> >>>>> In a perfect world I would be all in with you on this but
> >>>>> unfortunately a large number of people don't spend time checking
> their
> >>>>> user settings before pushing commits around. Instead of just adding
> >>>>> people to a file the first time they make a commit this means I have
> >>>>> to go and check that the THANKS file is generated properly and then
> >>>>> maybe update .mailmap if not and recheck that I got it correct.
> >>>>
> >>>> Fair enough, wanna revert?
> >>>>
> >>>> Cheers
> >>>> Jan
> >>>> --
> >>>>
> >>>>
> >>>
> >>> Playing with it a bit to see if I can make it build correctly and also
> >>> just build the AUTHORS file. I'll leave it around for a bit but won't
> >>> promise that the first time I spend more than 30s screwing with
> >>> mailmap that I revert it.
> >>
> >> Heh, that took me a while to get right :)
> >>
> >> Cheers
> >> Jan
> >> --
> >>
> >>
> >>
>
>
Re: git commit: Automate maintenance of the THANKS file
Posted by Jan Lehnardt <ja...@apache.org>.
On Jun 18, 2012, at 12:29 , Fedor Indutny wrote:
> Speaking of that, can I ask to add me to THANKS file? ;)
Done, can you in turn close your PR on GitHub? :)
Cheers
Jan
--
>
> Cheers,
> Fedor.
>
>
>
> On Mon, Jun 18, 2012 at 12:09 AM, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On Jun 17, 2012, at 22:05 , Paul Davis wrote:
>>
>>> On Sun, Jun 17, 2012 at 3:02 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>>
>>>> On Jun 17, 2012, at 21:56 , Paul Davis wrote:
>>>>
>>>>> On Sun, Jun 17, 2012 at 2:44 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>>
>>>>>> On Jun 17, 2012, at 21:29 , Paul Davis wrote:
>>>>>>
>>>>>>> I'm not sure I like this so much. Playing around with it, its a bit
>>>>>>> prone to screw ups.
>>>>>>
>>>>>> I just don't want to maintain this file manually any more. It is
>>>>>> error-prone and makes merging user-contributions a pain. I'm happy
>>>>>> to have this implemented in any other way, but I think we should
>>>>>> try to remove any mechanical steps from maintaining our source if
>>>>>> we can. I hope you agree! :)
>>>>>>
>>>>>
>>>>> Its an extra step but not one that I find to be particularly onerous.
>>>>> Given that we're already working on codifying merge practices I don't
>>>>> see why we don't just add a check box for "includes commit adding
>>>>> yourself to the THANKS file if this is your first contribution" that
>>>>> we look for.
>>>>
>>>> That's a fair point, but this has annoyed me forever.
>>>>
>>>>>>> It also breaks if AUTHORS.gz exists before you
>>>>>>> pull in new commits. We could solve that by forcing it to build every
>>>>>>> time but that's a bit of a hack for not much gain.
>>>>>>
>>>>>> Can you explain how it breaks if AUTHORS.gz exists before the merge?
>>>>>> If you mean THANKS.gz, my idea was that this is only relevant on
>>>>>> packaging time (make distcheck) where THANKS.gz by definition does
>>>>>> not exist.
>>>>>>
>>>>>
>>>>> I'm not sure its a good idea to have a file that is only built
>>>>> correctly in special circumstances.
>>>>
>>>> I'm happy to add an rm -f $< to the target.
>>>>
>>>>
>>>>>>> Its also got Benoit in there twice since he made commits with
>> slightly
>>>>>>> different author/committer names which also seems awkward.
>>>>>>
>>>>>> The subsequent .mailmap commit fixes the dupes. The push emails seem
>>>>>> to be delayed atm, I reported this to danielsh on #asfinfra.
>>>>>>
>>>>>
>>>>> I'm confused. You've removed one manually curated file only to add a
>>>>> new one that just modifies the build of the first? Seems like a lot of
>>>>> gymnastics.
>>>>
>>>> .mailmap solves more than just this.
>>>>
>>>>
>>>>> In a perfect world I would be all in with you on this but
>>>>> unfortunately a large number of people don't spend time checking their
>>>>> user settings before pushing commits around. Instead of just adding
>>>>> people to a file the first time they make a commit this means I have
>>>>> to go and check that the THANKS file is generated properly and then
>>>>> maybe update .mailmap if not and recheck that I got it correct.
>>>>
>>>> Fair enough, wanna revert?
>>>>
>>>> Cheers
>>>> Jan
>>>> --
>>>>
>>>>
>>>
>>> Playing with it a bit to see if I can make it build correctly and also
>>> just build the AUTHORS file. I'll leave it around for a bit but won't
>>> promise that the first time I spend more than 30s screwing with
>>> mailmap that I revert it.
>>
>> Heh, that took me a while to get right :)
>>
>> Cheers
>> Jan
>> --
>>
>>
>>
Re: git commit: Automate maintenance of the THANKS file
Posted by Fedor Indutny <fe...@indutny.com>.
Speaking of that, can I ask to add me to THANKS file? ;)
Cheers,
Fedor.
On Mon, Jun 18, 2012 at 12:09 AM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Jun 17, 2012, at 22:05 , Paul Davis wrote:
>
> > On Sun, Jun 17, 2012 at 3:02 PM, Jan Lehnardt <ja...@apache.org> wrote:
> >>
> >> On Jun 17, 2012, at 21:56 , Paul Davis wrote:
> >>
> >>> On Sun, Jun 17, 2012 at 2:44 PM, Jan Lehnardt <ja...@apache.org> wrote:
> >>>>
> >>>> On Jun 17, 2012, at 21:29 , Paul Davis wrote:
> >>>>
> >>>>> I'm not sure I like this so much. Playing around with it, its a bit
> >>>>> prone to screw ups.
> >>>>
> >>>> I just don't want to maintain this file manually any more. It is
> >>>> error-prone and makes merging user-contributions a pain. I'm happy
> >>>> to have this implemented in any other way, but I think we should
> >>>> try to remove any mechanical steps from maintaining our source if
> >>>> we can. I hope you agree! :)
> >>>>
> >>>
> >>> Its an extra step but not one that I find to be particularly onerous.
> >>> Given that we're already working on codifying merge practices I don't
> >>> see why we don't just add a check box for "includes commit adding
> >>> yourself to the THANKS file if this is your first contribution" that
> >>> we look for.
> >>
> >> That's a fair point, but this has annoyed me forever.
> >>
> >>>>> It also breaks if AUTHORS.gz exists before you
> >>>>> pull in new commits. We could solve that by forcing it to build every
> >>>>> time but that's a bit of a hack for not much gain.
> >>>>
> >>>> Can you explain how it breaks if AUTHORS.gz exists before the merge?
> >>>> If you mean THANKS.gz, my idea was that this is only relevant on
> >>>> packaging time (make distcheck) where THANKS.gz by definition does
> >>>> not exist.
> >>>>
> >>>
> >>> I'm not sure its a good idea to have a file that is only built
> >>> correctly in special circumstances.
> >>
> >> I'm happy to add an rm -f $< to the target.
> >>
> >>
> >>>>> Its also got Benoit in there twice since he made commits with
> slightly
> >>>>> different author/committer names which also seems awkward.
> >>>>
> >>>> The subsequent .mailmap commit fixes the dupes. The push emails seem
> >>>> to be delayed atm, I reported this to danielsh on #asfinfra.
> >>>>
> >>>
> >>> I'm confused. You've removed one manually curated file only to add a
> >>> new one that just modifies the build of the first? Seems like a lot of
> >>> gymnastics.
> >>
> >> .mailmap solves more than just this.
> >>
> >>
> >>> In a perfect world I would be all in with you on this but
> >>> unfortunately a large number of people don't spend time checking their
> >>> user settings before pushing commits around. Instead of just adding
> >>> people to a file the first time they make a commit this means I have
> >>> to go and check that the THANKS file is generated properly and then
> >>> maybe update .mailmap if not and recheck that I got it correct.
> >>
> >> Fair enough, wanna revert?
> >>
> >> Cheers
> >> Jan
> >> --
> >>
> >>
> >
> > Playing with it a bit to see if I can make it build correctly and also
> > just build the AUTHORS file. I'll leave it around for a bit but won't
> > promise that the first time I spend more than 30s screwing with
> > mailmap that I revert it.
>
> Heh, that took me a while to get right :)
>
> Cheers
> Jan
> --
>
>
>
Re: git commit: Automate maintenance of the THANKS file
Posted by Jan Lehnardt <ja...@apache.org>.
On Jun 17, 2012, at 22:05 , Paul Davis wrote:
> On Sun, Jun 17, 2012 at 3:02 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>
>> On Jun 17, 2012, at 21:56 , Paul Davis wrote:
>>
>>> On Sun, Jun 17, 2012 at 2:44 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>>
>>>> On Jun 17, 2012, at 21:29 , Paul Davis wrote:
>>>>
>>>>> I'm not sure I like this so much. Playing around with it, its a bit
>>>>> prone to screw ups.
>>>>
>>>> I just don't want to maintain this file manually any more. It is
>>>> error-prone and makes merging user-contributions a pain. I'm happy
>>>> to have this implemented in any other way, but I think we should
>>>> try to remove any mechanical steps from maintaining our source if
>>>> we can. I hope you agree! :)
>>>>
>>>
>>> Its an extra step but not one that I find to be particularly onerous.
>>> Given that we're already working on codifying merge practices I don't
>>> see why we don't just add a check box for "includes commit adding
>>> yourself to the THANKS file if this is your first contribution" that
>>> we look for.
>>
>> That's a fair point, but this has annoyed me forever.
>>
>>>>> It also breaks if AUTHORS.gz exists before you
>>>>> pull in new commits. We could solve that by forcing it to build every
>>>>> time but that's a bit of a hack for not much gain.
>>>>
>>>> Can you explain how it breaks if AUTHORS.gz exists before the merge?
>>>> If you mean THANKS.gz, my idea was that this is only relevant on
>>>> packaging time (make distcheck) where THANKS.gz by definition does
>>>> not exist.
>>>>
>>>
>>> I'm not sure its a good idea to have a file that is only built
>>> correctly in special circumstances.
>>
>> I'm happy to add an rm -f $< to the target.
>>
>>
>>>>> Its also got Benoit in there twice since he made commits with slightly
>>>>> different author/committer names which also seems awkward.
>>>>
>>>> The subsequent .mailmap commit fixes the dupes. The push emails seem
>>>> to be delayed atm, I reported this to danielsh on #asfinfra.
>>>>
>>>
>>> I'm confused. You've removed one manually curated file only to add a
>>> new one that just modifies the build of the first? Seems like a lot of
>>> gymnastics.
>>
>> .mailmap solves more than just this.
>>
>>
>>> In a perfect world I would be all in with you on this but
>>> unfortunately a large number of people don't spend time checking their
>>> user settings before pushing commits around. Instead of just adding
>>> people to a file the first time they make a commit this means I have
>>> to go and check that the THANKS file is generated properly and then
>>> maybe update .mailmap if not and recheck that I got it correct.
>>
>> Fair enough, wanna revert?
>>
>> Cheers
>> Jan
>> --
>>
>>
>
> Playing with it a bit to see if I can make it build correctly and also
> just build the AUTHORS file. I'll leave it around for a bit but won't
> promise that the first time I spend more than 30s screwing with
> mailmap that I revert it.
Heh, that took me a while to get right :)
Cheers
Jan
--
Re: git commit: Automate maintenance of the THANKS file
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Jun 17, 2012 at 3:02 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Jun 17, 2012, at 21:56 , Paul Davis wrote:
>
>> On Sun, Jun 17, 2012 at 2:44 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>> On Jun 17, 2012, at 21:29 , Paul Davis wrote:
>>>
>>>> I'm not sure I like this so much. Playing around with it, its a bit
>>>> prone to screw ups.
>>>
>>> I just don't want to maintain this file manually any more. It is
>>> error-prone and makes merging user-contributions a pain. I'm happy
>>> to have this implemented in any other way, but I think we should
>>> try to remove any mechanical steps from maintaining our source if
>>> we can. I hope you agree! :)
>>>
>>
>> Its an extra step but not one that I find to be particularly onerous.
>> Given that we're already working on codifying merge practices I don't
>> see why we don't just add a check box for "includes commit adding
>> yourself to the THANKS file if this is your first contribution" that
>> we look for.
>
> That's a fair point, but this has annoyed me forever.
>
>>>> It also breaks if AUTHORS.gz exists before you
>>>> pull in new commits. We could solve that by forcing it to build every
>>>> time but that's a bit of a hack for not much gain.
>>>
>>> Can you explain how it breaks if AUTHORS.gz exists before the merge?
>>> If you mean THANKS.gz, my idea was that this is only relevant on
>>> packaging time (make distcheck) where THANKS.gz by definition does
>>> not exist.
>>>
>>
>> I'm not sure its a good idea to have a file that is only built
>> correctly in special circumstances.
>
> I'm happy to add an rm -f $< to the target.
>
>
>>>> Its also got Benoit in there twice since he made commits with slightly
>>>> different author/committer names which also seems awkward.
>>>
>>> The subsequent .mailmap commit fixes the dupes. The push emails seem
>>> to be delayed atm, I reported this to danielsh on #asfinfra.
>>>
>>
>> I'm confused. You've removed one manually curated file only to add a
>> new one that just modifies the build of the first? Seems like a lot of
>> gymnastics.
>
> .mailmap solves more than just this.
>
>
>> In a perfect world I would be all in with you on this but
>> unfortunately a large number of people don't spend time checking their
>> user settings before pushing commits around. Instead of just adding
>> people to a file the first time they make a commit this means I have
>> to go and check that the THANKS file is generated properly and then
>> maybe update .mailmap if not and recheck that I got it correct.
>
> Fair enough, wanna revert?
>
> Cheers
> Jan
> --
>
>
Playing with it a bit to see if I can make it build correctly and also
just build the AUTHORS file. I'll leave it around for a bit but won't
promise that the first time I spend more than 30s screwing with
mailmap that I revert it.
Re: git commit: Automate maintenance of the THANKS file
Posted by Jan Lehnardt <ja...@apache.org>.
On Jun 17, 2012, at 21:56 , Paul Davis wrote:
> On Sun, Jun 17, 2012 at 2:44 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>
>> On Jun 17, 2012, at 21:29 , Paul Davis wrote:
>>
>>> I'm not sure I like this so much. Playing around with it, its a bit
>>> prone to screw ups.
>>
>> I just don't want to maintain this file manually any more. It is
>> error-prone and makes merging user-contributions a pain. I'm happy
>> to have this implemented in any other way, but I think we should
>> try to remove any mechanical steps from maintaining our source if
>> we can. I hope you agree! :)
>>
>
> Its an extra step but not one that I find to be particularly onerous.
> Given that we're already working on codifying merge practices I don't
> see why we don't just add a check box for "includes commit adding
> yourself to the THANKS file if this is your first contribution" that
> we look for.
That's a fair point, but this has annoyed me forever.
>>> It also breaks if AUTHORS.gz exists before you
>>> pull in new commits. We could solve that by forcing it to build every
>>> time but that's a bit of a hack for not much gain.
>>
>> Can you explain how it breaks if AUTHORS.gz exists before the merge?
>> If you mean THANKS.gz, my idea was that this is only relevant on
>> packaging time (make distcheck) where THANKS.gz by definition does
>> not exist.
>>
>
> I'm not sure its a good idea to have a file that is only built
> correctly in special circumstances.
I'm happy to add an rm -f $< to the target.
>>> Its also got Benoit in there twice since he made commits with slightly
>>> different author/committer names which also seems awkward.
>>
>> The subsequent .mailmap commit fixes the dupes. The push emails seem
>> to be delayed atm, I reported this to danielsh on #asfinfra.
>>
>
> I'm confused. You've removed one manually curated file only to add a
> new one that just modifies the build of the first? Seems like a lot of
> gymnastics.
.mailmap solves more than just this.
> In a perfect world I would be all in with you on this but
> unfortunately a large number of people don't spend time checking their
> user settings before pushing commits around. Instead of just adding
> people to a file the first time they make a commit this means I have
> to go and check that the THANKS file is generated properly and then
> maybe update .mailmap if not and recheck that I got it correct.
Fair enough, wanna revert?
Cheers
Jan
--
Re: git commit: Automate maintenance of the THANKS file
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Jun 17, 2012 at 2:44 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Jun 17, 2012, at 21:29 , Paul Davis wrote:
>
>> I'm not sure I like this so much. Playing around with it, its a bit
>> prone to screw ups.
>
> I just don't want to maintain this file manually any more. It is
> error-prone and makes merging user-contributions a pain. I'm happy
> to have this implemented in any other way, but I think we should
> try to remove any mechanical steps from maintaining our source if
> we can. I hope you agree! :)
>
Its an extra step but not one that I find to be particularly onerous.
Given that we're already working on codifying merge practices I don't
see why we don't just add a check box for "includes commit adding
yourself to the THANKS file if this is your first contribution" that
we look for.
>
>> It also breaks if AUTHORS.gz exists before you
>> pull in new commits. We could solve that by forcing it to build every
>> time but that's a bit of a hack for not much gain.
>
> Can you explain how it breaks if AUTHORS.gz exists before the merge?
> If you mean THANKS.gz, my idea was that this is only relevant on
> packaging time (make distcheck) where THANKS.gz by definition does
> not exist.
>
I'm not sure its a good idea to have a file that is only built
correctly in special circumstances.
>
>> Its also got Benoit in there twice since he made commits with slightly
>> different author/committer names which also seems awkward.
>
> The subsequent .mailmap commit fixes the dupes. The push emails seem
> to be delayed atm, I reported this to danielsh on #asfinfra.
>
I'm confused. You've removed one manually curated file only to add a
new one that just modifies the build of the first? Seems like a lot of
gymnastics.
In a perfect world I would be all in with you on this but
unfortunately a large number of people don't spend time checking their
user settings before pushing commits around. Instead of just adding
people to a file the first time they make a commit this means I have
to go and check that the THANKS file is generated properly and then
maybe update .mailmap if not and recheck that I got it correct.
Re: git commit: Automate maintenance of the THANKS file
Posted by Jan Lehnardt <ja...@apache.org>.
On Jun 17, 2012, at 21:29 , Paul Davis wrote:
> I'm not sure I like this so much. Playing around with it, its a bit
> prone to screw ups.
I just don't want to maintain this file manually any more. It is
error-prone and makes merging user-contributions a pain. I'm happy
to have this implemented in any other way, but I think we should
try to remove any mechanical steps from maintaining our source if
we can. I hope you agree! :)
> It also breaks if AUTHORS.gz exists before you
> pull in new commits. We could solve that by forcing it to build every
> time but that's a bit of a hack for not much gain.
Can you explain how it breaks if AUTHORS.gz exists before the merge?
If you mean THANKS.gz, my idea was that this is only relevant on
packaging time (make distcheck) where THANKS.gz by definition does
not exist.
> Its also got Benoit in there twice since he made commits with slightly
> different author/committer names which also seems awkward.
The subsequent .mailmap commit fixes the dupes. The push emails seem
to be delayed atm, I reported this to danielsh on #asfinfra.
Cheers
Jan
--
>
> On Sun, Jun 17, 2012 at 1:29 PM, <ja...@apache.org> wrote:
>> Updated Branches:
>> refs/heads/master 9514ed3f5 -> 7646794ea
>>
>>
>> Automate maintenance of the THANKS file
>>
>> THANKS now is automatically maintained for you. It uses git author
>> data to append people who submitted patches in the past.
>>
>> For non-commit THANKS, you can still manually edit this file.
>>
>> This commit removes from the THANKS file the people that appear
>> as git commit authors since we started committing them after
>> commit 6c976bd. These removed entries get automatically re-
>> added by `make`.
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/7646794e
>> Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/7646794e
>> Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/7646794e
>>
>> Branch: refs/heads/master
>> Commit: 7646794ea7a30d41a64c873d8b27ae830397d94a
>> Parents: 9514ed3
>> Author: Jan Lehnardt <ja...@apache.org>
>> Authored: Sun Jun 17 20:06:21 2012 +0200
>> Committer: Jan Lehnardt <ja...@apache.org>
>> Committed: Sun Jun 17 20:11:31 2012 +0200
>>
>> ----------------------------------------------------------------------
>> Makefile.am | 10 +++++++++-
>> THANKS | 13 +++++--------
>> 2 files changed, 14 insertions(+), 9 deletions(-)
>> ----------------------------------------------------------------------
>>
>>
>> http://git-wip-us.apache.org/repos/asf/couchdb/blob/7646794e/Makefile.am
>> ----------------------------------------------------------------------
>> diff --git a/Makefile.am b/Makefile.am
>> index 9dd22b8..1cbd865 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -79,7 +79,15 @@ README.gz: $(top_srcdir)/README
>> -gzip -9 < $< > $@
>>
>> THANKS.gz: $(top_srcdir)/THANKS
>> - -gzip -9 < $< > $@
>> + sed -e 's/^#.*//' $< > $<.tmp # strip comments
>> + sed -e '/^$$/d' $<.tmp > $<.tmp2 # strip empty lines
>> + git shortlog -se 6c976bd..HEAD \
>> + | grep -v @apache.org \
>> + | sed -E 's/^[[:blank:]]{5}[[:digit:]]+[[:blank:]]/ * /' \
>> + >> $<.tmp2 # inject git authors
>> + echo '\nFor a list of authors see the `AUTHORS` file.\n' >> $<.tmp2
>> + -gzip -9 < $<.tmp2 > $@ # zip
>> + rm $<.tmp $<.tmp2 # cleanup
>>
>> check: dev check-js
>> $(top_builddir)/test/etap/run $(top_srcdir)/test/etap
>>
>> http://git-wip-us.apache.org/repos/asf/couchdb/blob/7646794e/THANKS
>> ----------------------------------------------------------------------
>> diff --git a/THANKS b/THANKS
>> index f0dccb8..1e065f8 100644
>> --- a/THANKS
>> +++ b/THANKS
>> @@ -66,7 +66,6 @@ suggesting improvements or submitting changes. Some of these people are:
>> * Lim Yue Chuan <sh...@gmail.com>
>> * David Davis <xa...@xantus.org>
>> * Klaus Trainer <kl...@web.de>
>> - * Dale Harvey <da...@arandomurl.com>
>> * Juuso Väänänen <ju...@vaananen.org>
>> * Jeff Zellner <je...@gmail.com>
>> * Benjamin Young <by...@bigbluehat.com>
>> @@ -92,12 +91,10 @@ suggesting improvements or submitting changes. Some of these people are:
>> * Simon Leblanc <si...@gmail.com>
>> * Rogutės Sparnuotos <ro...@googlemail.com>
>> * Gavin McDonald <gm...@apache.org>
>> - * Ronny Pfannschmidt <Ro...@gmx.de>
>> - * Magnus Hoff <ma...@gmail.com>
>> - * Alexander Dorofeev <ak...@gmail.com>
>> - * Anthony S Baker <an...@gmail.com>
>> - * Ewan McDougall <in...@mrloop.com>
>> - * Adam Lofts <Ad...@gmail.com>
>>
>> -For a list of authors see the `AUTHORS` file.
>> +# Dear committer who merges a commit from a non-committer:
>> +# You don't have to manually maintain the THANKS file anymore (yay!).
>> +# Non-committer authors get automatically appended to THANKS and
>> +# moved into THANKS.gz by `make`. This note will be stripped as well.
>> +# Authors from commit 6c976bd and onwards are auto-inserted.
>>
>>