On Mon, Oct 28, 2013 at 4:30 PM, Eric Blake wrote:
> On 10/28/2013 05:10 PM, Jim Meyering wrote:
>>
>> * gnulib-tool: Some "cd" built-in functions print a directory name
>> to stdout when CDPATH is set, e.g.,
>
> More precisely, _all_ posix-conforming cd implementations are required
> to write to
On 10/28/2013 05:10 PM, Jim Meyering wrote:
>
> * gnulib-tool: Some "cd" built-in functions print a directory name
> to stdout when CDPATH is set, e.g.,
More precisely, _all_ posix-conforming cd implementations are required
to write to stdout if CDPATH had an effect. It's more than just "some".
On Mon, Oct 28, 2013 at 8:45 AM, Bruce Korb wrote:
> On 10/27/13 17:46, Pádraig Brady wrote:
>>>
>>> gnulib_dir ?= $(srcdir)/gnulib
>>> -gnulib-version = $$(cd $(gnulib_dir) && git describe)
>>> +gnulib-version = $$(cd $(gnulib_dir) && git rev-parse --short HEAD)
>>> bootstrap-tools ?= autocon
Hi Jim,
On Oct 29, 2013, at 11:54 AM, Jim Meyering wrote:
> I will soon push the following change, followed by another that will add
> this line
>
> (unset CDPATH) >/dev/null 2>&1 && unset CDPATH
>
> near the top of gnulib-tool. That CDPATH-unsetting change is the accepted
> approach to rend
I will soon push the following change, followed by another that will add
this line
(unset CDPATH) >/dev/null 2>&1 && unset CDPATH
near the top of gnulib-tool. That CDPATH-unsetting change is the accepted
approach to rendering "cd" sensible, i.e., making it emit nothing
to stdout. Thus, there
Hi Bruce,
On Oct 29, 2013, at 4:45 AM, Bruce Korb wrote:
> On 10/27/13 17:46, Pádraig Brady wrote:
>>> gnulib_dir ?= $(srcdir)/gnulib
>>> -gnulib-version = $$(cd $(gnulib_dir) && git describe)
>>> +gnulib-version = $$(cd $(gnulib_dir) && git rev-parse --short HEAD)
>>> bootstrap-tools ?= autoc
On Oct 29, 2013, at 4:09 AM, Jim Meyering wrote:
> Hi Gary,
Hi Jim,
> I think your patch is based on an invalid premise:
> That somehow "git describe" is at fault.
> Actually, the diagnostic you reported suggests that your gnulib
> repository has no tag, which means your environment is the cause
On 10/27/13 17:46, Pádraig Brady wrote:
gnulib_dir ?= $(srcdir)/gnulib
-gnulib-version = $$(cd $(gnulib_dir) && git describe)
+gnulib-version = $$(cd $(gnulib_dir) && git rev-parse --short HEAD)
bootstrap-tools ?= autoconf,automake,gnulib
...
This would change the announce message from:
Hi Gary,
I think your patch is based on an invalid premise:
That somehow "git describe" is at fault.
Actually, the diagnostic you reported suggests that your gnulib
repository has no tag, which means your environment is the cause, not git.
A full clone of gnulib always has at least the v0.0 tag th
On 10/26/2013 11:21 PM, Gary V. Vaughan wrote:
> Further to my earlier bug report. Okay to push?
>
> * top/maint.mk (gnulib-version): Use git rev-parse to get the
> current HEAD revision.
>
> Signed-off-by: Gary V. Vaughan
> ---
> top/maint.mk | 2 +-
> 1 file changed, 1 insertion(+), 1 deleti
On Oct 27, 2013, at 1:06 PM, Paul Eggert wrote:
> Thanks, that looks good, please push.
Thanks. Pushed.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
signature.asc
Description: Message signed with OpenPGP using GPGMail
Thanks, that looks good, please push.
Further to my earlier bug report. Okay to push?
* top/maint.mk (gnulib-version): Use git rev-parse to get the
current HEAD revision.
Signed-off-by: Gary V. Vaughan
---
top/maint.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/top/maint.mk b/top/maint.mk
index c1b786f..c9
13 matches
Mail list logo
