On 01/06/2011 08:03 AM, Jim Meyering wrote:
>>> +submodule-checks = no-submodule-changes public-submodule-commit
>>
>> If someone complains about these two tests being git-centric, a solution
>> for a project using maint.mk with a different VCS would be to make
>> submodule-checks defined via ?=, s
Eric Blake wrote:
> On 01/06/2011 02:44 AM, Jim Meyering wrote:
>>> gnulib-commit-check:
>>> git submodule foreach test '$$(git rev-parse origin)' \
>>> = '"$$(git merge-base --independent origin $$sha1)"'
>>
>> Thanks again for the fine test.
>> It passed my tests, so I propose this in
On 01/06/2011 02:44 AM, Jim Meyering wrote:
>> gnulib-commit-check:
>> git submodule foreach test '$$(git rev-parse origin)' \
>>= '"$$(git merge-base --independent origin $$sha1)"'
>
> Thanks again for the fine test.
> It passed my tests, so I propose this in your name:
>
>>From 8ba
Eric Blake wrote:
> On 01/04/2011 03:01 PM, Eric Blake wrote:
>> Found one, and it even works on libvirt (where the gnulib submodule is
>> named .gnulib instead of gnulib). It should also work on a repository
>> with multiple submodules, although I have not yet tested it on bison.git.
>>
>> gnulib
Eric Blake wrote:
> On 01/04/2011 03:01 PM, Eric Blake wrote:
>> Found one, and it even works on libvirt (where the gnulib submodule is
>> named .gnulib instead of gnulib). It should also work on a repository
>> with multiple submodules, although I have not yet tested it on bison.git.
>>
>> gnuli
On 01/04/2011 03:01 PM, Eric Blake wrote:
> Found one, and it even works on libvirt (where the gnulib submodule is
> named .gnulib instead of gnulib). It should also work on a repository
> with multiple submodules, although I have not yet tested it on bison.git.
>
> gnulib-commit-check:
> g
On 01/04/2011 02:29 PM, Eric Blake wrote:
>> +# Just before tagging a release, ensure that the gnulib submodule
>> +# commit we're using is public.
>> +alpha beta stable: gnulib-commit-check
>> +.PHONY: gnulib-commit-check
>> +gnulib-commit-check:
>> +submod=gnulib; \
>> +st=$$(git submodul
Eric Blake writes:
> I'm trying to come up with some
> git submodule foreach 'command $sha1'
> formula that will allow you to make the same check without having to
> resort to wget or even to hardcoding the URL of each upstream repository.
Like git ls-remote?
Andreas.
--
Andreas Schwab, sch
On 01/04/2011 02:15 PM, Jim Meyering wrote:
>UPDATE_COPYRIGHT_MAX_LINE_LENGTH=79
> +
> +# Just before tagging a release, ensure that the gnulib submodule
> +# commit we're using is public.
> +alpha beta stable: gnulib-commit-check
> +.PHONY: gnulib-commit-check
> +gnulib-commit-check:
> + s
Jim Meyering wrote:
> In releasing coreutils-8.9, I left its gnulib submodule pointing at a
> private commit that was going to be pushed, pending an ACK... Since a
> slightly different commit was pushed, coreutils' submodule SHA1 was
> invalid for a short interval. However, I have pushed my local
On 01/04/2011 01:05 PM, Jim Meyering wrote:
>> That way, the next update of gnulib as coreutils submodule could still
>> be a fast-forward.
>
> Hi Ralf,
>
> I've done as you suggest (note that it required temporarily
> disabling the hook that prohibits pushing merge commits to master).
> That has
Eric Blake wrote:
> On 01/04/2011 01:05 PM, Jim Meyering wrote:
>>> That way, the next update of gnulib as coreutils submodule could still
>>> be a fast-forward.
>>
>> Hi Ralf,
>>
>> I've done as you suggest (note that it required temporarily
>> disabling the hook that prohibits pushing merge commi
Ralf Wildenhues wrote:
> Hi Jim,
>
> * Jim Meyering wrote on Tue, Jan 04, 2011 at 07:14:49PM CET:
>> In releasing coreutils-8.9, I left its gnulib submodule pointing at a
>> private commit that was going to be pushed, pending an ACK... Since a
>> slightly different commit was pushed, coreutils' su
Hi Jim,
* Jim Meyering wrote on Tue, Jan 04, 2011 at 07:14:49PM CET:
> In releasing coreutils-8.9, I left its gnulib submodule pointing at a
> private commit that was going to be pushed, pending an ACK... Since a
> slightly different commit was pushed, coreutils' submodule SHA1 was
> invalid for
In releasing coreutils-8.9, I left its gnulib submodule pointing at a
private commit that was going to be pushed, pending an ACK... Since a
slightly different commit was pushed, coreutils' submodule SHA1 was
invalid for a short interval. However, I have pushed my local commit
to the new gnulib br
15 matches
Mail list logo
