No rule to make target `../../build-aux/snippet/arg-nonnull.h'

No rule to make target `../../build-aux/snippet/arg-nonnull.h'

[martin rudalics]

Building today's master on Windows XP gets me

   GEN    alloca.h
   GEN    byteswap.h
   GEN    errno.h
   GEN    execinfo.h
make[1]: *** No rule to make target `../../build-aux/snippet/arg-nonnull.h', needed by `arg-nonnull.h'.  Stop.
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/c/emacs-git/trunk/dbg/lib'
make: *** [lib] Error 2
make: *** Waiting for unfinished jobs....

How shall I proceed?

Thanks, martin

Re: No rule to make target `../../build-aux/snippet/arg-nonnull.h'

[Eli Zaretskii]

> Date: Fri, 17 Mar 2017 09:33:47 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
> Building today's master on Windows XP gets me
> 
>    GEN    alloca.h
>    GEN    byteswap.h
>    GEN    errno.h
>    GEN    execinfo.h
> make[1]: *** No rule to make target `../../build-aux/snippet/arg-nonnull.h', needed by `arg-nonnull.h'.  Stop.
> make[1]: *** Waiting for unfinished jobs....
> make[1]: Leaving directory `/c/emacs-git/trunk/dbg/lib'
> make: *** [lib] Error 2
> make: *** Waiting for unfinished jobs....
> 
> How shall I proceed?

Run autogen.sh followed by configure, then try saying "make" again.

The files in build-aux/snippet/ were moved to lib/ a couple of days
ago.  It looks like some of your Makefile's are stale, and still
mention the old places.

Re: No rule to make target `../../build-aux/snippet/arg-nonnull.h'

[martin rudalics]

 > Run autogen.sh followed by configure, then try saying "make" again.
 >
 > The files in build-aux/snippet/ were moved to lib/ a couple of days
 > ago.  It looks like some of your Makefile's are stale, and still
 > mention the old places.

Did that - still the same issue.  Can this

configure: WARNING: This configuration installs a 'movemail' program
that retrieves POP3 email via only insecure channels.
To fix this you can install GNU Mailutils
<http://mailutils.org> and use '../configure --with-mailutils'.

be related?

martin

Re: No rule to make target `../../build-aux/snippet/arg-nonnull.h'

[Paul Eggert]

martin rudalics wrote:
> Did that - still the same issue.

Weird. Master contains no references to build-aux/snippet/arg-nonnull.h other 
than in msdos/autogen/Makefile.in (which I assume you are not using). So there 
must be something old lying in your directory. Does it fix things to remove 
nt/gnulib.mk and then rebuild? If not, what does this output?

grep -FRl build-aux/snippet/arg-nonnull.h .

> Can this
>
> configure: WARNING: This configuration installs a 'movemail' program
> that retrieves POP3 email via only insecure channels.
> To fix this you can install GNU Mailutils
> <http://mailutils.org> and use '../configure --with-mailutils'.
>
> be related?

No, that should be an independent issue.

Re: No rule to make target `../../build-aux/snippet/arg-nonnull.h'

[martin rudalics]

 > Weird. Master contains no references to
 > build-aux/snippet/arg-nonnull.h other than in
 > msdos/autogen/Makefile.in (which I assume you are not using). So there
 > must be something old lying in your directory. Does it fix things to
 > remove nt/gnulib.mk and then rebuild?

Yes.  The build succeeded.

 > If not, what does this output?
 > grep -FRl build-aux/snippet/arg-nonnull.h .

I had two (didn't check now).  One in /nt/gnulib.mk

BUILT_SOURCES += arg-nonnull.h
# The arg-nonnull.h that gets inserted into generated .h files is the same as
# build-aux/snippet/arg-nonnull.h, except that it has the copyright header cut
# off.
arg-nonnull.h: $(top_srcdir)/build-aux/snippet/arg-nonnull.h
	$(AM_V_GEN)rm -f $@-t $@ && \
	sed -n -e '/GL_ARG_NONNULL/,$$p' \
	  < $(top_srcdir)/build-aux/snippet/arg-nonnull.h \
	  > $@-t && \
	mv $@-t $@

@BUILDING_FOR_WINDOWSNT_TRUE@	$(top_srcdir)/build-aux/snippet/arg-nonnull.h \

and one in /lib/Makefile.in

# The arg-nonnull.h that gets inserted into generated .h files is the same as
# build-aux/snippet/arg-nonnull.h, except that it has the copyright header cut
# off.
@BUILDING_FOR_WINDOWSNT_TRUE@arg-nonnull.h: $(top_srcdir)/build-aux/snippet/arg-nonnull.h
@BUILDING_FOR_WINDOWSNT_TRUE@	$(AM_V_GEN)rm -f $@-t $@ && \
@BUILDING_FOR_WINDOWSNT_TRUE@	sed -n -e '/GL_ARG_NONNULL/,$$p' \
@BUILDING_FOR_WINDOWSNT_TRUE@	  < $(top_srcdir)/build-aux/snippet/arg-nonnull.h \
@BUILDING_FOR_WINDOWSNT_TRUE@	  > $@-t && \
@BUILDING_FOR_WINDOWSNT_TRUE@	mv $@-t $@

Thanks for helping, martin

Re: No rule to make target `../../build-aux/snippet/arg-nonnull.h'

[Paul Eggert]

>> Does it fix things to remove nt/gnulib.mk and then rebuild?
>
> Yes.  The build succeeded.

OK. I'm planning to remove nt/gnulib.mk from the build process soon (see 
Bug#26100), and this should fix whatever build-process bug you just experienced.

Re: No rule to make target `../../build-aux/snippet/arg-nonnull.h'

[martin rudalics]

I'll keep my fingers crossed.

Thanks, martin

master has switched from Automake to GNU Make

[Paul Eggert]

On 03/17/2017 08:55 AM, Paul Eggert wrote:
> I'm planning to remove nt/gnulib.mk from the build process soon (see 
> Bug#26100), and this should fix whatever build-process bug you just 
> experienced.

I installed this change into Emacs master. It discontinues the use of 
Automake and moves some makefiles around, so you'll have to run 
'./autogen.sh' and then './configure'. Although there's a bit of pain 
now (and there will probably be some shakeout bugs), I hope that the new 
approach causes fewer gnulib.mk etc. glitches in the future.

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 17 Mar 2017 11:58:34 -0700
> Cc: emacs-devel@gnu.org
> 
> I installed this change into Emacs master. It discontinues the use of 
> Automake and moves some makefiles around, so you'll have to run 
> './autogen.sh' and then './configure'. Although there's a bit of pain 
> now (and there will probably be some shakeout bugs), I hope that the new 
> approach causes fewer gnulib.mk etc. glitches in the future.

Not sure this is related, but autogen.sh now says after it finishes

  You can now run './autogen.sh git'.

I expected it to say something about running ./configure.

Re: master has switched from Automake to GNU Make

[Paul Eggert]

On 03/17/2017 12:26 PM, Eli Zaretskii wrote:
> Not sure this is related, but autogen.sh now says after it finishes
>
>    You can now run './autogen.sh git'.
>
> I expected it to say something about running ./configure.

That's longstanding behavior, a reminder to run './autogen.sh git' to 
obtain the usual Git settings. If you run './autogen.sh git' to adjust 
your Git settings, it will then suggest running ./configure.

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> Cc: rudalics@gmx.at, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 17 Mar 2017 12:33:30 -0700
> 
> >    You can now run './autogen.sh git'.
> >
> > I expected it to say something about running ./configure.
> 
> That's longstanding behavior, a reminder to run './autogen.sh git' to 
> obtain the usual Git settings. If you run './autogen.sh git' to adjust 
> your Git settings, it will then suggest running ./configure.

That's a weird way of suggesting an optional feature.  How about
something like this instead:

  You can now run './autogen.sh git' or './configure'.

Re: master has switched from Automake to GNU Make

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

Hi Glenn,

The build worked fine on RHEL 6.6.

Also I use a wrapper script that does

./autogen.sh all
./configure ..

And it worked just fine.

Do I need the autogen + configure steps for each build?

On Fri, Mar 17, 2017 at 3:52 PM Eli Zaretskii <eliz@gnu.org> wrote:

That's a weird way of suggesting an optional feature.  How about
something like this instead:

  You can now run './autogen.sh git' or './configure'.


-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1373 bytes --]

Re: master has switched from Automake to GNU Make

[Paul Eggert]

On 03/17/2017 01:21 PM, Kaushal Modi wrote:
>
> Also I use a wrapper script that does
>
> ./autogen.sh all
> ./configure ..
>
> And it worked just fine.
>
> Do I need the autogen + configure steps for each build?

Not usually, as the resulting Makefile attempts to deduce when it is 
out-of-date with respect to the inputs to 'autoconf', and it re-runs the 
equivalent of ./autogen.sh and ./configure when necessary.

That being said, the self-update procedure works only for "minor" 
changes to the build procedure - which is understandable, as updates 
cannot possibly work in general due to the procedure's 
self-referentiality. So when we make "major" changes one sometimes needs 
to start over from scratch, as in your wrapper script. (Unfortunately, 
the only definition of "major" is, "you need to start over from scratch".)

Re: master has switched from Automake to GNU Make

[Paul Eggert]

On 03/17/2017 12:51 PM, Eli Zaretskii wrote:
> How about something like this instead:
>
>    You can now run './autogen.sh git' or './configure'.

That would add complexity to a process that is already overly 
complicated. Plus, at that point there are other plausible things to do 
(i.e., other than './autogen.sh git' and './configure'); why list just 
those two possibilities?

Better would be to have plain './autogen.sh' default './autogen.sh all' 
instead of to './autogen.sh autoconf', so that the trailing message 
would simply say:

   You can now run './configure'.

That way, developers ordinarily wouldn't need to worry about running 
'./autogen.sh git'. The rare developers who prefer unusual Git settings 
could use './autogen.sh autoconf' instead of plain './autogen.sh', or 
they could run plain './autogen.sh' and then apply their preferred 
settings atop the standard settings.

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> Cc: rudalics@gmx.at, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 17 Mar 2017 14:33:44 -0700
> 
> On 03/17/2017 12:51 PM, Eli Zaretskii wrote:
> > How about something like this instead:
> >
> >    You can now run './autogen.sh git' or './configure'.
> 
> That would add complexity to a process that is already overly 
> complicated.

What process?  This is just a message, it changes nothing in the
process.

> Better would be to have plain './autogen.sh' default './autogen.sh all' 
> instead of to './autogen.sh autoconf'

AFAIR, last time you tried this, some people here objected to forcing
them install Git hooks.

Re: master has switched from Automake to GNU Make

[Paul Eggert]

Eli Zaretskii wrote:

> What process?  This is just a message, it changes nothing in the
> process.

The process that includes people reading and understanding and acting on 
messages. Complicating the messages complicates the process.

>> Better would be to have plain './autogen.sh' default './autogen.sh all'
>> instead of to './autogen.sh autoconf'
>
> AFAIR, last time you tried this, some people here objected to forcing
> them install Git hooks.

They would not be forced under my most recent proposal. They could run 
'./autogen.sh autoconf' rather than plain './autogen.sh'. All that would be 
changed would be a minor simplification in the default.

Had you typed './autogen.sh all' instead of './autogen.sh' you wouldn't have 
needed to read and understand and act on its final diagnostic, and this would 
have saved a bit of time. The idea is to make 'all' the default for 
./autogen.sh, as a timesaver for the typical process.

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> Cc: rudalics@gmx.at, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 18 Mar 2017 09:26:55 -0700
> 
> Eli Zaretskii wrote:
> 
> > What process?  This is just a message, it changes nothing in the
> > process.
> 
> The process that includes people reading and understanding and acting on 
> messages. Complicating the messages complicates the process.

I think calling my proposal "complicating the messages" is an
exaggeration, to say the least.

> > AFAIR, last time you tried this, some people here objected to forcing
> > them install Git hooks.
> 
> They would not be forced under my most recent proposal. They could run 
> './autogen.sh autoconf' rather than plain './autogen.sh'. All that would be 
> changed would be a minor simplification in the default.

We will have to ask those people, won't we?

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > I installed this change into Emacs master. It discontinues the use of
 > Automake and moves some makefiles around, so you'll have to run
 > './autogen.sh' and then './configure'. Although there's a bit of pain
 > now (and there will probably be some shakeout bugs), I hope that the
 > new approach causes fewer gnulib.mk etc. glitches in the future.

Building currently stalls thusly:


config.status: creating src/config.h
config.status: executing src/epaths.h commands
config.status: executing src/.gdbinit commands
config.status: executing doc/emacs/emacsver.texi commands
config.status: executing etc-refcards-emacsver.tex commands
configure: WARNING: This configuration installs a 'movemail' program
that retrieves POP3 email via only insecure channels.
To fix this you can use '../configure --without-pop'.

c:\emacs-git\trunk>c:/Programme/MinGW/msys/1.0/bin/bash.exe --login -i -c  "cd /c/emacs-git/trunk/dbg/ ; make -j2"
make -C nt all
make -C lib all
make[1]: Entering directory `/c/emacs-git/trunk/dbg/lib'
Makefile:60: /../nt/gnulib-cfg.mk: No such file or directory
make[1]: *** No rule to make target `/../nt/gnulib-cfg.mk'.  Stop.
make[1]: Leaving directory `/c/emacs-git/trunk/dbg/lib'
make: *** [lib] Error 2
make: *** Waiting for unfinished jobs....
make[1]: Entering directory `/c/emacs-git/trunk/dbg/nt'
   RC       emacs.res
   CCLD     runemacs.exe
make[1]: Leaving directory `/c/emacs-git/trunk/dbg/nt'


I do have a file

c:/emacs-git/trunk/nt/gnulib-cfg.mk

but it seems that 'make' tries to find

c:/emacs-git/trunk/dbg/nt/gnulib-cfg.mk

Thanks for any suggestions, martin

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> Date: Sat, 18 Mar 2017 09:11:15 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org
> 
> Makefile:60: /../nt/gnulib-cfg.mk: No such file or directory
> make[1]: *** No rule to make target `/../nt/gnulib-cfg.mk'.  Stop.

Should be fixed now.

Re: master has switched from Automake to GNU Make

[martin rudalics]

 >> Makefile:60: /../nt/gnulib-cfg.mk: No such file or directory
 >> make[1]: *** No rule to make target `/../nt/gnulib-cfg.mk'.  Stop.
 >
 > Should be fixed now.

Thank you - built successfully now.  This warning ...


configure: WARNING: This configuration installs a 'movemail' program
that retrieves POP3 email via only insecure channels.
To fix this you can use '../configure --without-pop'.


... is slightly misleading.  It doesn't specify whether "To fix this"
stands for "to install something that retrieves POP3 email via secure
channels", "to not install POP3 support" or "to just suppress the
warning".  "without-pop" obviously hints at the second but "fix" seems
hardly the right term for not installing a (mis-)feature.

Thanks again, martin

Re: master has switched from Automake to GNU Make

[Robert Marshall]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 03/17/2017 08:55 AM, Paul Eggert wrote:
>> I'm planning to remove nt/gnulib.mk from the build process soon (see
>> Bug#26100), and this should fix whatever build-process bug you just
>> experienced.
>
> I installed this change into Emacs master. It discontinues the use of
> Automake and moves some makefiles around, so you'll have to run
> './autogen.sh' and then './configure'. Although there's a bit of pain
> now (and there will probably be some shakeout bugs), I hope that the
> new approach causes fewer gnulib.mk etc. glitches in the future.

I've run both those but am getting a build failure

make[1]: Entering directory '/home/robertmarshall/emacs/lib'
make[1]: *** No rule to make target 'c++defs.h', needed by 'stdio.h'.
make[1]: *** No rule to make target 'arg-nonnull.h', needed by 'stdio.h'.
make[1]: *** No rule to make target 'warn-on-use.h', needed by 'stdio.h'.
make[1]: Target 'all' not remade because of errors.
make[1]: Leaving directory '/home/robertmarshall/emacs/lib'
Makefile:403: recipe for target 'lib' failed
make: *** [lib] Error 2

Robert

Re: master has switched from Automake to GNU Make

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On 03/20/2017 04:26 AM, Robert Marshall wrote:
>> './autogen.sh' and then './configure'. Although there's a bit of pain
>> now (and there will probably be some shakeout bugs), I hope that the
>> new approach causes fewer gnulib.mk etc. glitches in the future.
> I've run both those but am getting a build failure

Thanks for reporting that. I installed the attached, which I hope fixes 
things; please try it again.


[-- Attachment #2: 0001-Fix-problem-with-out-of-date-dependencies.patch --]
[-- Type: application/x-patch, Size: 1135 bytes --]

Re: master has switched from Automake to GNU Make

[Robert Marshall]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 03/20/2017 04:26 AM, Robert Marshall wrote:
>>> './autogen.sh' and then './configure'. Although there's a bit of pain
>>> now (and there will probably be some shakeout bugs), I hope that the
>>> new approach causes fewer gnulib.mk etc. glitches in the future.
>> I've run both those but am getting a build failure
>
> Thanks for reporting that. I installed the attached, which I hope
> fixes things; please try it again.

Thanks, unfortunately I can't now try this as I eventually got it to build
by checking out an older tag rerunning autogen.sh and configure and then
switching back to head.

Robert

Re: master has switched from Automake to GNU Make

[Tom Tromey]

>>>>> "Paul" == Paul Eggert <eggert@cs.ucla.edu> writes:

Paul> On 03/20/2017 04:26 AM, Robert Marshall wrote:
>>> './autogen.sh' and then './configure'. Although there's a bit of pain
>>> now (and there will probably be some shakeout bugs), I hope that the
>>> new approach causes fewer gnulib.mk etc. glitches in the future.
>> I've run both those but am getting a build failure

Paul> Thanks for reporting that. I installed the attached, which I hope
Paul> fixes things; please try it again.

This change seems too aggressive to me.  IIUC it will cause a full
rebuild for any re-run of configure, no matter now innocuous.

FWIW Automake implements a solution to the "deleted header file"
problem, just to deal with situations like this.  In particular it
arranges to emit a dummy "whatever.h:" target for any referenced header.
This allows dependencies to work without breaking the build if the
header is changed.  GCC's "-MP" option is used for this when available.

I hope that's relevant :), as I'm not 100% sure this was the problem
that lead to this particular patch.

If not, is there some other way to fix the problem, whatever it was?

thanks,
Tom

Re: master has switched from Automake to GNU Make

[Paul Eggert]

On 03/21/2017 10:42 AM, Tom Tromey wrote:
> IIUC it will cause a full
> rebuild for any re-run of configure, no matter now innocuous.

Yes, it does require recompiling to rebuild *.o files and executables. 
Though that isn't a full build, it can take quite some time. On my aging 
desktop, 'configure' takes 58 seconds, and the followup 'make' takes 61 
seconds.

There is a tradeoff between speed and correctness, since 'configure' can 
change Makefiles, which means a full rebuild might be needed no matter 
what. But you're right, the change I installed was probably too 
aggressive for typical use. So I changed 'configure' back, so that it no 
longer removes *.o and dependency files. This means Robert Marshall will 
probably have to do a full rebuild by hand.

> FWIW Automake implements a solution to the "deleted header file"
> problem, just to deal with situations like this.

That solution wouldn't have worked for this particular problem even if 
we were still using Automake, as the dependencies in question were not 
generated by GCC or by Automake. Sometimes after a big change, one must 
simply do the full './autogen.sh; ./configure; make' dance, as our 
default shortcuts are not safe in general.

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Date: Tue, 21 Mar 2017 11:42:43 -0600
> Cc: Robert Marshall <robert.marshall@codethink.co.uk>, emacs-devel@gnu.org
> 
> This change seems too aggressive to me.  IIUC it will cause a full
> rebuild for any re-run of configure, no matter now innocuous.

IME, re-running configure triggered a full rebuild of C code even
before this change.

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > I installed this change into Emacs master. It discontinues the use of
 > Automake and moves some makefiles around, so you'll have to run
 > './autogen.sh' and then './configure'. Although there's a bit of pain
 > now (and there will probably be some shakeout bugs), I hope that the
 > new approach causes fewer gnulib.mk etc. glitches in the future.

I currently have the following files as "untracked" here:

	build-aux/ar-lib
	build-aux/compile
	build-aux/depcomp
	build-aux/missing
	nt/gnulib.mk
	src/stamp-h.in

Shouldn't we add them to the files ignored by git?  Or should these be
deleted?


Also I'm recently often getting things like

  + 917ce99...5aa9a80 scratch/record -> origin/scratch/record  (forced update)

Couldn't we recommend that people don't use forced pushes - even on
scratch branches?

martin

Re: master has switched from Automake to GNU Make

[Stefan Monnier]

> Also I'm recently often getting things like
>
>  + 917ce99...5aa9a80 scratch/record -> origin/scratch/record  (forced update)
>
> Couldn't we recommend that people don't use forced pushes - even on
> scratch branches?

Why?


        Stefan

Re: master has switched from Automake to GNU Make

[martin rudalics]

 >>   + 917ce99...5aa9a80 scratch/record -> origin/scratch/record  (forced update)
 >>
 >> Couldn't we recommend that people don't use forced pushes - even on
 >> scratch branches?
 >
 > Why?

It's distracting for people like me who don't understand git.  Today it
confused me enough that I messed up the ChangeLog of my commit and did
not notice it before pushing.  Also reading about it on the net is not
very reassuring either.  But if you think that it's essential I'll have
to get used to it.

martin

Re: master has switched from Automake to GNU Make

[Stefan Monnier]

>>> + 917ce99...5aa9a80 scratch/record -> origin/scratch/record  (forced update)
>>> Couldn't we recommend that people don't use forced pushes - even on
>>> scratch branches?
>> Why?
> It's distracting for people like me who don't understand git.  Today it
> confused me enough that I messed up the ChangeLog of my commit and did
> not notice it before pushing.

Hmmm... I can't see how that could happen if you don't actually use that
branch, so I guess you've merged from that branch and tried to re-merge?

> Also reading about it on the net is not very reassuring either.
> But if you think that it's essential I'll have to get used to it.

It's not essential, but some people like to keep branches as a clean set
of patches on top of master, so they regularly rebase (and reorganize
the set of patches), so in the end it doesn't give you the path that was
followed to get there (which, while historically accurate, tends to be
messy and hard to follow) but only "a nice path to get there", which is
basically a single patch divided into a few commented logical steps.


        Stefan

Re: master has switched from Automake to GNU Make

[martin rudalics]

 >> It's distracting for people like me who don't understand git.  Today it
 >> confused me enough that I messed up the ChangeLog of my commit and did
 >> not notice it before pushing.
 >
 > Hmmm... I can't see how that could happen if you don't actually use that
 > branch, so I guess you've merged from that branch and tried to re-merge?

No.  I started to read about forced updates and didn't check the
status of my commit thoroughly.

 > It's not essential, but some people like to keep branches as a clean set
 > of patches on top of master, so they regularly rebase (and reorganize
 > the set of patches), so in the end it doesn't give you the path that was
 > followed to get there (which, while historically accurate, tends to be
 > messy and hard to follow) but only "a nice path to get there", which is
 > basically a single patch divided into a few commented logical steps.

Isn't one of the primary purposes of a branch (besides of sharing) to
record the historically accurate picture of how its authors arrived at
the present state?  If not I really am an idiot wrt version controlling.

martin

Re: master has switched from Automake to GNU Make

[Stefan Monnier]

> Isn't one of the primary purposes of a branch (besides of sharing) to
> record the historically accurate picture of how its authors arrived at
> the present state?

AFAIK the primary purpose of branches to allow the two codes to
evolve independently.


        Stefan

Re: master has switched from Automake to GNU Make

[martin rudalics]

 >> Isn't one of the primary purposes of a branch (besides of sharing) to
 >> record the historically accurate picture of how its authors arrived at
 >> the present state?
 >
 > AFAIK the primary purpose of branches to allow the two codes to
 > evolve independently.

So we have different semantics of "evolve" - one for master and one for
branches?  Still confused.

martin

Re: master has switched from Automake to GNU Make

[Stefan Monnier]

> So we have different semantics of "evolve" - one for master and one for
> branches?  Still confused.

The difference is with scratch/FOO branches where we tolerate more random crap.
As compared to feature/FOO branches where we expect commits to come with
properly formatted messages so we know we can just "merge" them when
they're ready.


        Stefan

Re: master has switched from Automake to GNU Make

[Lars Brinkhoff]

Stefan Monnier wrote:
>> but some people like to keep branches as a clean set of patches on
>> top of master, so they regularly rebase (and reorganize the set of
>> patches), so in the end it doesn't give you the path that was
>> followed to get there

I'm one of those people, so I offer a rant below.

martin rudalics wrote:
> Isn't one of the primary purposes of a branch (besides of sharing) to
> record the historically accurate picture of how its authors arrived at
> the present state?

That is one view of version control.  If you talk about version history,
it's kind of almost implied that it's an accurate record of historical
events.  Many version control tools support this model and make it
difficult to go outside it.

But version control tools can also support another model.  Git in
particular isn't big on enforcing historical accuracy.  In this other
view, version control is just about files, and their contents and
changes.  Files can be rewritten, and so can the changes.  It's just as
natural as editing files without recording every single change in the
final version.

Remember when you submitted changes as a series of patches?  Maybe not,
it was some years ago.  Anyway, in many projects, the way changes were
propsed were to email a series of patches to a mailing list.  Of course,
all patches were required to apply cleanly to the current version of the
software.  Also, every individual patch was required to do one atomic,
logical change.

When the base version of the software changed, you were supposed to
reapply all your patches against the new version.  Also, the maintainers
probably requested you to modify your patches based on their input.
They certainly weren't interested in every little edit you made along
the way, only the final result.

Git "history" rewriting is the modern version of this game.  Only, git
automates much of the minutiae to track changes in the base version,
reapply patches, move changes around between commits etc.

Re: master has switched from Automake to GNU Make

[martin rudalics]

 >> Isn't one of the primary purposes of a branch (besides of sharing) to
 >> record the historically accurate picture of how its authors arrived at
 >> the present state?
 >
 > That is one view of version control.  If you talk about version history,
 > it's kind of almost implied that it's an accurate record of historical
 > events.  Many version control tools support this model and make it
 > difficult to go outside it.
 >
 > But version control tools can also support another model.  Git in
 > particular isn't big on enforcing historical accuracy.  In this other
 > view, version control is just about files, and their contents and
 > changes.  Files can be rewritten, and so can the changes.  It's just as
 > natural as editing files without recording every single change in the
 > final version.

But a branch in scratch does not represent a final version.  It
represents work in progress.  And it should be open to collaborate
modifications.  Why else would you make your branch public?

 > Remember when you submitted changes as a series of patches?  Maybe not,
 > it was some years ago.  Anyway, in many projects, the way changes were
 > propsed were to email a series of patches to a mailing list.  Of course,
 > all patches were required to apply cleanly to the current version of the
 > software.  Also, every individual patch was required to do one atomic,
 > logical change.
 >
 > When the base version of the software changed, you were supposed to
 > reapply all your patches against the new version.  Also, the maintainers
 > probably requested you to modify your patches based on their input.
 > They certainly weren't interested in every little edit you made along
 > the way, only the final result.
 >
 > Git "history" rewriting is the modern version of this game.  Only, git
 > automates much of the minutiae to track changes in the base version,
 > reapply patches, move changes around between commits etc.

All this is about the final result of what a branch was supposed to
accomplish and I agree with you here.  My concerns were with what
happens in the branch as long as it is not final.  Why throw away its
history when pushing?  Because it contains silly code its author would
be ashamed of?

martin

Re: master has switched from Automake to GNU Make

[Stephen Leake]

martin rudalics <rudalics@gmx.at> writes:

> All this is about the final result of what a branch was supposed to
> accomplish and I agree with you here.  

Ok.

> My concerns were with what happens in the branch as long as it is not
> final. Why throw away its history when pushing? Because it contains
> silly code its author would be ashamed of?

Yes, but I would phrase it "it contained a failed approach, so here's a
better approach".

Or, "the sequence of commits is too hard to follow, since it has false
starts and back-tracking, so here's a cleaner sequence".

One could argue that new approach should have yet another branch. Which
is a good idea if you are not _really_ sure the second approach is
better, or will work.

Partly it depends on how closely people are cooperating on the branch.
If it's two or more developers actively working on all the code, then
pushing a totally new set of commits is a Bad Idea; the other developers
will lose work (or time in recovering).

But our presumed use case is one developer actively working on the code,
and asking for reviews. In which case, a clean sequence of
understandable commits is a big plus.

-- 
-- Stephe

Re: master has switched from Automake to GNU Make

[martin rudalics]

 >> My concerns were with what happens in the branch as long as it is not
 >> final. Why throw away its history when pushing? Because it contains
 >> silly code its author would be ashamed of?
 >
 > Yes, but I would phrase it "it contained a failed approach, so here's a
 > better approach".
 >
 > Or, "the sequence of commits is too hard to follow, since it has false
 > starts and back-tracking, so here's a cleaner sequence".

How often I wished to see on master the dirty sequence of how someone
came to the conclusion that the last version is the correct one.  How
often would this have prevent me from entering precisely the same false
starts and back-tracking, saving me many, many hours of silly work.

martin

Re: master has switched from Automake to GNU Make

[Stephen Leake]

martin rudalics <rudalics@gmx.at> writes:

>>> My concerns were with what happens in the branch as long as it is not
>>> final. Why throw away its history when pushing? Because it contains
>>> silly code its author would be ashamed of?
>>
>> Yes, but I would phrase it "it contained a failed approach, so here's a
>> better approach".
>>
>> Or, "the sequence of commits is too hard to follow, since it has false
>> starts and back-tracking, so here's a cleaner sequence".
>
> How often I wished to see on master the dirty sequence of how someone
> came to the conclusion that the last version is the correct one.  How
> often would this have prevent me from entering precisely the same false
> starts and back-tracking, saving me many, many hours of silly work.

That's what design docs are for; either in .texi or code comments. But
the Emacs culture isn't good at capturing that information.

-- 
-- Stephe

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Sun, 26 Mar 2017 07:58:40 -0500
> 
> > How often I wished to see on master the dirty sequence of how someone
> > came to the conclusion that the last version is the correct one.  How
> > often would this have prevent me from entering precisely the same false
> > starts and back-tracking, saving me many, many hours of silly work.
> 
> That's what design docs are for; either in .texi or code comments.

Design docs are about the future design, they are almost never updated
to reflect the actual design post-factum.  And it's impossible in
practice to tell the development story in comments.

Re: master has switched from Automake to GNU Make

[Filipp Gunbin]

On 24/03/2017 10:03 +0100, martin rudalics wrote:

> Isn't one of the primary purposes of a branch (besides of sharing) to
> record the historically accurate picture of how its authors arrived at
> the present state?  If not I really am an idiot wrt version controlling.

Sometimes I just commit and push to not lose my changes if something
goes bad with my computer.  So there may be total mess at the end of
task.  Then I rebase and reorganize commits and usually merge it as a
single commit into master.

Filipp

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > Sometimes I just commit and push to not lose my changes if something
 > goes bad with my computer.  So there may be total mess at the end of
 > task.  Then I rebase and reorganize commits and usually merge it as a
 > single commit into master.

That's what I do locally.  But why throw away the mess before merging it
to master?

martin

Re: master has switched from Automake to GNU Make

[Stephen Leake]

martin rudalics <rudalics@gmx.at> writes:

>>> It's distracting for people like me who don't understand git.  Today it
>>> confused me enough that I messed up the ChangeLog of my commit and did
>>> not notice it before pushing.
>>
>> Hmmm... I can't see how that could happen if you don't actually use that
>> branch, so I guess you've merged from that branch and tried to re-merge?
>
> No.  I started to read about forced updates and didn't check the
> status of my commit thoroughly.
>
>> It's not essential, but some people like to keep branches as a clean set
>> of patches on top of master, so they regularly rebase (and reorganize
>> the set of patches), so in the end it doesn't give you the path that was
>> followed to get there (which, while historically accurate, tends to be
>> messy and hard to follow) but only "a nice path to get there", which is
>> basically a single patch divided into a few commented logical steps.
>
> Isn't one of the primary purposes of a branch (besides of sharing) to
> record the historically accurate picture of how its authors arrived at
> the present state?  If not I really am an idiot wrt version controlling.

It depends.

The "monotone" version control system absolutely forbids tampering with
past history; the history increments "monotonically".

But git is more flexible; it allows editing history.

One reason to edit history is because you used the tool wrong (happens a
lot :).

Another reason is the scenario Stefan mentioned; you are messing around
in a branch, finally get it right, and rewrite history to pretend you
knew where you would end up all along.

It might make sense to keep the messy branch for history, and create a
new branch that has the clean sequence of commits. But we officially
only care about history on the main branch.

-- 
-- Stephe

Re: master has switched from Automake to GNU Make

[Stefan Monnier]

> Another reason is the scenario Stefan mentioned; you are messing around
> in a branch, finally get it right, and rewrite history to pretend you
> knew where you would end up all along.
> It might make sense to keep the messy branch for history, and create a
> new branch that has the clean sequence of commits. But we officially
> only care about history on the main branch.

FWIW, I consider Git's solution to be unsatisfactory.

IMO, when we do a "rebase", Git should also keep the previous history, tho
only as a kind of "weak reference", so you wouldn't see that
"truthful&messy" history unless you cared about it: the rebased
revision wouldn't be enough to recover that messy history, but it would
be enough to relate the new revision with some past "messy" revision you
happened to have lying about.


        Stefan

Re: master has switched from Automake to GNU Make

[Andreas Schwab]

On Mär 24 2017, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> IMO, when we do a "rebase", Git should also keep the previous history, tho
> only as a kind of "weak reference",

That kind of weak reference is the reflog.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: master has switched from Automake to GNU Make

[Stefan Monnier]

>> IMO, when we do a "rebase", Git should also keep the previous history, tho
>> only as a kind of "weak reference",
> That kind of weak reference is the reflog.

No, reflog doesn't keep parent-info about relationship between
commits, so it's a completely different beast.

The kind of ref I'm thinking of would be more like a commit-id embedded
in the commit message of every commit created by a rebase, together with
a tweak to "git merge" so that it uses those commit ids as additional
parents when looking for a common ancestor.


        Stefan

Re: master has switched from Automake to GNU Make

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

On 26 Mar 2017 1:37 AM, "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:


The kind of ref I'm thinking of would be more like a commit-id embedded
in the commit message of every commit created by a rebase, together with
a tweak to "git merge" so that it uses those commit ids as additional
parents when looking for a common ancestor.


There are times I read old mailing list messages where some development was
discussed and they mention something in some particular commit. If the
history has been rewritten (or a branch was deleted) I can't get the full
picture.

For this reason I'm personally very much against the idea of modifying or
deleting anything from a repository.

I know me saying this will do little to change anyone's mind, but I felt
the need to justify the position of someone like me who sees the repository
as a very strong record of the history.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1463 bytes --]

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > IMO, when we do a "rebase", Git should also keep the previous history, tho
 > only as a kind of "weak reference", so you wouldn't see that
 > "truthful&messy" history unless you cared about it: the rebased
 > revision wouldn't be enough to recover that messy history, but it would
 > be enough to relate the new revision with some past "messy" revision you
 > happened to have lying about.

That would be perfect, indeed.

martin

Re: master has switched from Automake to GNU Make

[martin rudalics]

 >> Isn't one of the primary purposes of a branch (besides of sharing) to
 >> record the historically accurate picture of how its authors arrived at
 >> the present state?  If not I really am an idiot wrt version controlling.
 >
 > It depends.

Whether I'm an idiot ;-)

 > The "monotone" version control system absolutely forbids tampering with
 > past history; the history increments "monotonically".
 >
 > But git is more flexible; it allows editing history.
 >
 > One reason to edit history is because you used the tool wrong (happens a
 > lot :).

That's why I initially asked

   "Couldn't we recommend that people don't use forced pushes - even on
    scratch branches?"

With that recommendation people could tell themselves "who cares anyway"
and leave the history alone.  But if we supply a tool that allows people
to hide that they used that tool wrong, then we also supply the social
pressure on people to hide whatever they've done wrong.  Look what clean
history the others got.

Here git frequently pesters me with the message that it cannot complete
my pull request because files I fetched from the repository (and never
touched myself) contain trailing whitespace (usually loaddefs or ldefs
files but otheres as well).  I then remove that whitespace manually and
commit the changes with some crude message text.  Now if I left such
text in a more public place maybe someone would do something about this
annoying whitespeace treatment ...

 > Another reason is the scenario Stefan mentioned; you are messing around
 > in a branch, finally get it right, and rewrite history to pretend you
 > knew where you would end up all along.

That's "finally" once more.  No pretensions here.

martin

Re: master has switched from Automake to GNU Make

[Paul Eggert]

On 03/25/2017 04:26 AM, martin rudalics wrote:
> Here git frequently pesters me with the message that it cannot complete
> my pull request because files I fetched from the repository (and never
> touched myself) contain trailing whitespace (usually loaddefs or ldefs
> files but otheres as well).

That sounds wrong. It never happens to me, I expect because my workflow 
differs. Can you give a way to reproduce your problem? Perhaps there's a 
way we can fix the Git configuration so that it doesn't happen to you in 
the future.

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 25 Mar 2017 10:24:47 -0500
> 
> On 03/25/2017 04:26 AM, martin rudalics wrote:
> > Here git frequently pesters me with the message that it cannot complete
> > my pull request because files I fetched from the repository (and never
> > touched myself) contain trailing whitespace (usually loaddefs or ldefs
> > files but otheres as well).
> 
> That sounds wrong. It never happens to me, I expect because my workflow 
> differs.

FWIW, it never happened to me, either.

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > FWIW, it never happened to me, either.

It usually happens to me on local branches and GNU/Linux only.

martin

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> Date: Sun, 26 Mar 2017 10:39:18 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: stephen_leake@stephe-leake.org, emacs-devel@gnu.org
> 
>  > FWIW, it never happened to me, either.
> 
> It usually happens to me on local branches and GNU/Linux only.

I'm not sure I follow: are you saying that you use "git pull" into
local branches that don't track the master branch?  If so, why are you
doing that?

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > I'm not sure I follow: are you saying that you use "git pull" into
 > local branches that don't track the master branch?  If so, why are you
 > doing that?

Doing what?  I have three versions of master - one pristine, one used
for development with changes I eventually intend to push, and a private
one with changes I don't intend to push.  For the non-pristine ones I
practically always pull into the branch and only occasionally pull into
the master, usually when I want to make a diff.  Is that bad?

martin

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> Date: Sun, 26 Mar 2017 21:01:48 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: eggert@cs.ucla.edu, stephen_leake@stephe-leake.org, 
>  emacs-devel@gnu.org
> 
>  > I'm not sure I follow: are you saying that you use "git pull" into
>  > local branches that don't track the master branch?  If so, why are you
>  > doing that?
> 
> Doing what?  I have three versions of master - one pristine, one used
> for development with changes I eventually intend to push, and a private
> one with changes I don't intend to push.  For the non-pristine ones I
> practically always pull into the branch and only occasionally pull into
> the master, usually when I want to make a diff.  Is that bad?

Are the non-pristine branches tracking master, or are they different
branches forked from master?  If the latter, you shouldn't be pulling
into them, I think, you should be merging from master.

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > Are the non-pristine branches tracking master, or are they different
 > branches forked from master?

They are tracking master.  git branch -vv for one of them tells
me for example

* fast            e08b161 [origin/master: ahead 18] Minor improvement in frameset.el
   master          03f64eb [origin/master: behind 108] * src/fns.c (Fbuffer_hash): Doc fix.
   slow            13cf940 [origin/master: ahead 87, behind 511] Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs into slow

martin

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> Date: Sun, 26 Mar 2017 21:33:35 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: eggert@cs.ucla.edu, stephen_leake@stephe-leake.org, 
>  emacs-devel@gnu.org
> 
>  > Are the non-pristine branches tracking master, or are they different
>  > branches forked from master?
> 
> They are tracking master.  git branch -vv for one of them tells
> me for example
> 
> * fast            e08b161 [origin/master: ahead 18] Minor improvement in frameset.el
>    master          03f64eb [origin/master: behind 108] * src/fns.c (Fbuffer_hash): Doc fix.
>    slow            13cf940 [origin/master: ahead 87, behind 511] Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs into slow

Then I don't understand why Git would force you to commit.  IME, it
happens only when the pulled changes modify the same places as your
uncommitted changes.  And even then I'm given a choice of committing
or stashing; the latter will allow to leave your changes uncommitted,
if you "git stash pop" after pulling.

What version of Git do you have installed?

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > Then I don't understand why Git would force you to commit.  IME, it
 > happens only when the pulled changes modify the same places as your
 > uncommitted changes.  And even then I'm given a choice of committing
 > or stashing; the latter will allow to leave your changes uncommitted,
 > if you "git stash pop" after pulling.

That's been my experience too.  For some reason either the merge or the
autocommit fails.  Sometimes because git detects trailing whitespace in
the pulled code.  Other times without telling me any reason but that my
terminal is dumb.

 > What version of Git do you have installed?

1.7.10.4

martin

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> Date: Mon, 27 Mar 2017 21:29:43 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: eggert@cs.ucla.edu, stephen_leake@stephe-leake.org, 
>  emacs-devel@gnu.org
> 
>  > What version of Git do you have installed?
> 
> 1.7.10.4

That's quite old, I suggest to upgrade.

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > That sounds wrong. It never happens to me, I expect because my
 > workflow differs. Can you give a way to reproduce your problem?
 > Perhaps there's a way we can fix the Git configuration so that it
 > doesn't happen to you in the future.

It might be related to the fact that I use git entirely from within
Emacs, git tells me that my terminal is dumb and explicitly asks me to
commit what I pulled even when there were no conflicts.  I eventually
got around the problem by using --no-verify when doing such commits.

martin

Re: master has switched from Automake to GNU Make

[Stephen Leake]

martin rudalics <rudalics@gmx.at> writes:

>> That sounds wrong. It never happens to me, I expect because my
>> workflow differs. Can you give a way to reproduce your problem?
>> Perhaps there's a way we can fix the Git configuration so that it
>> doesn't happen to you in the future.
>
> It might be related to the fact that I use git entirely from within
> Emacs, git tells me that my terminal is dumb and explicitly asks me to
> commit what I pulled even when there were no conflicts.  

That sounds like line ending mismatch.


-- 
-- Stephe

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Sun, 26 Mar 2017 08:03:01 -0500
> 
> > It might be related to the fact that I use git entirely from within
> > Emacs, git tells me that my terminal is dumb and explicitly asks me to
> > commit what I pulled even when there were no conflicts.  
> 
> That sounds like line ending mismatch.

On Unix? unlikely.

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > That sounds wrong. It never happens to me, I expect because my
 > workflow differs. Can you give a way to reproduce your problem?
 > Perhaps there's a way we can fix the Git configuration so that it
 > doesn't happen to you in the future.

Today again git complained about my dumb terminal and when I tried to
commit manually it told me:

martin@NOREST:~/emacs-git/slow$ git commit -m "Dumb"
admin/unidata/SpecialCasing.txt:200: trailing whitespace.
+# The remainder of this file provides conditional casing data used to produce
admin/unidata/SpecialCasing.txt:281: new blank line at EOF.

I don't understand our policy wrt trailing whitespace.  Even without
that dumb terminal issue I occasionally will have to commit manually
after a pull, for example, when fixing conflicts.

martin

Re: master has switched from Automake to GNU Make

[Andreas Schwab]

On Apr 11 2017, martin rudalics <rudalics@gmx.at> wrote:

> Today again git complained about my dumb terminal

What does that mean?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: master has switched from Automake to GNU Make

[Yuri Khan]

On Tue, Apr 11, 2017 at 7:13 PM, Andreas Schwab <schwab@suse.de> wrote:
> On Apr 11 2017, martin rudalics <rudalics@gmx.at> wrote:
>
>> Today again git complained about my dumb terminal

Martin, you’re trying to solve three problems at once.


> What does that mean?

Normally, Git pipes its output through ‘less -FRX’, so that the user
can scroll through long logs or diffs at his or her pace. However,
that requires a terminal that supports cursor addressing, so that
less(1) could erase the previous screen and re-draw the new one.

In my Emacs, less(1) invoked from ‘shell’ says “WARNING: terminal is
not fully functional”. It then sort-of works but is ugly and a bit
pointless within Emacs which implements its own scrolling.

To tell Git not to use paging:

$ git config --global core.pager cat

or:

$ export GIT_PAGER=cat

The latter would be a good configuration for ‘shell’ buffers in Emacs.

See ‘git help config’ for more technical details.


Paging is, however, entirely independent of trailing whitespace
checking. Git by default does not treat trailing whitespace as errors,
but provides an easy way to enable that as a sample pre-commit hook.
In the Emacs repository, running ‘autogen.sh git’ installs a
pre-commit hook from build-aux/git-hooks that actually invokes the
check in its last line. The file admin/unidata/SpecialCasing.txt does
in fact fail this check. But that’s okay because it has been committed
once and you’re not likely to need to commit it again unless you’re
upgrading Emacs to a newer version of the Unicode standard.


Why you are getting in the situation where you need to commit
SpecialCasing.txt when pulling is a different issue.

What is your workflow, starting with a checkout and up to pulling? Do
you by any chance try to pull while your working tree has uncommitted
changes? (That has a high confusion potential. Commit first, pull
later.)

(Also, I always suggest to ‘git fetch’ first, see if your local branch
and the upstream have diverged, and then decide consciously whether
you want a merge, a rebase, or something else entirely. ‘git pull’
makes the decision for you.)

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > Martin, you’re trying to solve three problems at once.

Aha.. thanks in advance for your attention.

 >> What does that mean?
 >
 > Normally, Git pipes its output through ‘less -FRX’, so that the user
 > can scroll through long logs or diffs at his or her pace. However,
 > that requires a terminal that supports cursor addressing, so that
 > less(1) could erase the previous screen and re-draw the new one.
 >
 > In my Emacs, less(1) invoked from ‘shell’ says “WARNING: terminal is
 > not fully functional”. It then sort-of works but is ugly and a bit
 > pointless within Emacs which implements its own scrolling.
 >
 > To tell Git not to use paging:
 >
 > $ git config --global core.pager cat
 >
 > or:
 >
 > $ export GIT_PAGER=cat

OK.  That looks like a good idea.  I suppose this could also help me
with git's help which currently always redirects me to my browsers.  I
have never tried to delve into git's options because I usually get lost
in its documentation.

 > The latter would be a good configuration for ‘shell’ buffers in Emacs.
 >
 > See ‘git help config’ for more technical details.
 >
 >
 > Paging is, however, entirely independent of trailing whitespace
 > checking. Git by default does not treat trailing whitespace as errors,
 > but provides an easy way to enable that as a sample pre-commit hook.
 > In the Emacs repository, running ‘autogen.sh git’ installs a
 > pre-commit hook from build-aux/git-hooks that actually invokes the
 > check in its last line. The file admin/unidata/SpecialCasing.txt does
 > in fact fail this check. But that’s okay because it has been committed
 > once and you’re not likely to need to commit it again unless you’re
 > upgrading Emacs to a newer version of the Unicode standard.

OK.

 > Why you are getting in the situation where you need to commit
 > SpecialCasing.txt when pulling is a different issue.
 >
 > What is your workflow, starting with a checkout and up to pulling? Do
 > you by any chance try to pull while your working tree has uncommitted
 > changes? (That has a high confusion potential. Commit first, pull
 > later.)

No.  It just happens on a branch where occasionally conflicts may occur.
In the particular case there were no uncommitted and no stashed changes
(to my knowledge).

 > (Also, I always suggest to ‘git fetch’ first, see if your local branch
 > and the upstream have diverged, and then decide consciously whether
 > you want a merge, a rebase, or something else entirely. ‘git pull’
 > makes the decision for you.)

I always want a merge.  So what do you recommend?  In particular what do
you recommend when there are conflicts?  IIUC in that case git does not
merge anything but waits till I have resolved the conflicts and tells me
to commit them when I'm done.  If, at that moment, I do commit I'm in
the same situation with SpecialCasing.txt as before.  Or is there any
difference?

martin

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> Date: Tue, 11 Apr 2017 15:53:42 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: Andreas Schwab <schwab@suse.de>, Paul Eggert <eggert@cs.ucla.edu>,
> 	emacs-devel <emacs-devel@gnu.org>
> 
>  > $ git config --global core.pager cat
>  >
>  > or:
>  >
>  > $ export GIT_PAGER=cat
> 
> OK.  That looks like a good idea.

IMO, "git config --global core.pager ''" should be better.  More
honest, too.

Re: master has switched from Automake to GNU Make

[Yuri Khan]

On Tue, Apr 11, 2017 at 8:23 PM, martin rudalics <rudalics@gmx.at> wrote:

> IIRC it tells me that
>
> error: Terminal is dumb, but EDITOR unset
> Not committing merge; use 'git commit' to complete the merge.

Aha! Error messages are important.

In a capable terminal, Git would start a text editor in which you
could compose a commit message for the merge. Under an Emacs shell
buffer, it can’t, so it defers to you to provide a commit message via
-m or -F.

It tries first the $GIT_EDITOR variable;
if that is not set, then the core.editor configuration setting;
if that is not set either, then $VISUAL but only if the terminal is not dumb;
if it has not yet found anything, then $EDITOR;
and if nothing yet, then it ultimately falls back to "vi", but again
only if the terminal is not dumb.

(And it detects terminal dumbness by the fact that the $TERM variable
is not set or is set to the string "dumb".)

As an Emacs user you’d probably want this:

$ git config --global core.editor emacsclient

or possibly 'emacsclient -t'.


On Tue, Apr 11, 2017 at 8:53 PM, martin rudalics <rudalics@gmx.at> wrote:

> I suppose this could also help me
> with git's help which currently always redirects me to my browsers.

Browsers? Oh, you’re on Windows. On other systems, git-help uses
man(1) by default. (Seriously, I should configure my Git to show
manuals in the browser.)

> I have never tried to delve into git's options because I usually get lost
> in its documentation.

Git’s manual is like that, yes, unfortunately. The change of viewing
tool is unlikely to help much with that.

But seriously, find some time to read the ‘git help config’ page once.
It’s full of useful options and less useful defaults (core.pager,
core.editor, and merge.conflictstyle to name just a few).


>> (Also, I always suggest to ‘git fetch’ first, see if your local branch
>> and the upstream have diverged, and then decide consciously whether
>> you want a merge, a rebase, or something else entirely. ‘git pull’
>> makes the decision for you.)
>
> I always want a merge.  So what do you recommend?  In particular what do
> you recommend when there are conflicts?  IIUC in that case git does not
> merge anything but waits till I have resolved the conflicts and tells me
> to commit them when I'm done.  If, at that moment, I do commit I'm in
> the same situation with SpecialCasing.txt as before.  Or is there any
> difference?

Well, I would recommend rebasing, which would solve the
SpecialCasing.txt problem because your rebased branch would start
after the problematic file has been committed.

But if you insist on merging, it’s doable, too. Then I guess you
get a merge conflict,
resolve it,
stage the resolved files,
attempt to commit,
get a whitespace policy violation,
say an expletive of your choice,
see that the violation was not your doing,
optionally confirm that by looking at the history of the problematic
file in the branch you’re merging,
then say “Oh well” and commit bypassing the check.
(You can bypass the check by temporarily commenting out the last line
in .git/hooks/pre-commit or uninstalling that hook altogether.)

Re: master has switched from Automake to GNU Make

[Sven Axelsson]

On 11 April 2017 at 17:13, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> (You can bypass the check by temporarily commenting out the last line
> in .git/hooks/pre-commit or uninstalling that hook altogether.)

Fwiw, you can use `git commit --no-verify` to temporarily skip any
pre-commit and commit-msg hooks.

-- 
Sven Axelsson
++++++++++[>++++++++++>+++++++++++>++++++++++>++++++
>++++<<<<<-]>++++.+.++++.>+++++.>+.<<-.>>+.>++++.<<.
+++.>-.<<++.>>----.<++.>>>++++++.<<<<.>>++++.<----.

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > Fwiw, you can use `git commit --no-verify` to temporarily skip any
 > pre-commit and commit-msg hooks.

If you had read all my posts in this thread you would have also found
that

   I eventually
   got around the problem by using --no-verify when doing such commits.

;-)

martin

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > In a capable terminal, Git would start a text editor in which you
 > could compose a commit message for the merge.

But this would not have helped me in the case at hand, I suppose.  The
whitespace complaint would not have vanished.  Right?

 > Under an Emacs shell
 > buffer, it can’t, so it defers to you to provide a commit message via
 > -m or -F.
 >
 > It tries first the $GIT_EDITOR variable;
 > if that is not set, then the core.editor configuration setting;
 > if that is not set either, then $VISUAL but only if the terminal is not dumb;
 > if it has not yet found anything, then $EDITOR;
 > and if nothing yet, then it ultimately falls back to "vi", but again
 > only if the terminal is not dumb.
 >
 > (And it detects terminal dumbness by the fact that the $TERM variable
 > is not set or is set to the string "dumb".)
 >
 > As an Emacs user you’d probably want this:
 >
 > $ git config --global core.editor emacsclient
 >
 > or possibly 'emacsclient -t'.

Which might confuse me totally because the Emacs I'm just using for
pulling might be another Emacs than the one specified as emacsclient.
That's the reason why I have no set $GIT_EDITOR.

 >> I suppose this could also help me
 >> with git's help which currently always redirects me to my browsers.
 >
 > Browsers? Oh, you’re on Windows. On other systems, git-help uses
 > man(1) by default.

I forgot.  On GNU/Linux it indeed tells me that my terminal is not fully
functional and starts paging unless I used tee.

 > (Seriously, I should configure my Git to show
 > manuals in the browser.)

It's a serious pain for me.

 >> I have never tried to delve into git's options because I usually get lost
 >> in its documentation.
 >
 > Git’s manual is like that, yes, unfortunately. The change of viewing
 > tool is unlikely to help much with that.
 >
 > But seriously, find some time to read the ‘git help config’ page once.
 > It’s full of useful options and less useful defaults (core.pager,
 > core.editor, and merge.conflictstyle to name just a few).

I'll do that in the next days and when there are still issues I'll get
back to you (if you don't mind).

 > Well, I would recommend rebasing, which would solve the
 > SpecialCasing.txt problem because your rebased branch would start
 > after the problematic file has been committed.

If and when I'm convinced that rebasing doesn't do any harm, I might
follow that path.  So far the opinions about rebasing are too
contradictory for my humble mind.

 > But if you insist on merging, it’s doable, too. Then I guess you
 > get a merge conflict,
 > resolve it,
 > stage the resolved files,
 > attempt to commit,
 > get a whitespace policy violation,
 > say an expletive of your choice,
 > see that the violation was not your doing,
 > optionally confirm that by looking at the history of the problematic
 > file in the branch you’re merging,
 > then say “Oh well” and commit bypassing the check.
 > (You can bypass the check by temporarily commenting out the last line
 > in .git/hooks/pre-commit or uninstalling that hook altogether.)

In one out of 100 cases fixing a conflict will then introduce another
trailing whitespace which passes by undetected.

martin

Re: master has switched from Automake to GNU Make

[Sven Joachim]

On 2017-04-11 15:53 +0200, martin rudalics wrote:

>> Martin, you’re trying to solve three problems at once.
>
> Aha.. thanks in advance for your attention.
>
>>> What does that mean?
>>
>> Normally, Git pipes its output through ‘less -FRX’, so that the user
>> can scroll through long logs or diffs at his or her pace. However,
>> that requires a terminal that supports cursor addressing, so that
>> less(1) could erase the previous screen and re-draw the new one.
>>
>> In my Emacs, less(1) invoked from ‘shell’ says “WARNING: terminal is
>> not fully functional”. It then sort-of works but is ugly and a bit
>> pointless within Emacs which implements its own scrolling.
>>
>> To tell Git not to use paging:
>>
>> $ git config --global core.pager cat
>>
>> or:
>>
>> $ export GIT_PAGER=cat
>
> OK.  That looks like a good idea.  I suppose this could also help me
> with git's help which currently always redirects me to my browsers.  I
> have never tried to delve into git's options because I usually get lost
> in its documentation.

FWIW, I have (setenv "PAGER" "/bin/cat") in my .emacs for ages.  Works
great for any program which uses a pager by default.

Cheers,
       Sven

Re: master has switched from Automake to GNU Make

[martin rudalics]

 >> Today again git complained about my dumb terminal
 >
 > What does that mean?

IIRC it tells me that

error: Terminal is dumb, but EDITOR unset
Not committing merge; use 'git commit' to complete the merge.

martin

Re: master has switched from Automake to GNU Make

[Andreas Schwab]

On Apr 11 2017, martin rudalics <rudalics@gmx.at> wrote:

>>> Today again git complained about my dumb terminal
>>
>> What does that mean?
>
> IIRC it tells me that
>
> error: Terminal is dumb, but EDITOR unset
> Not committing merge; use 'git commit' to complete the merge.

Where?  There is no context.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > Where?  There is no context.

The context is ‘eshell’ invoked from within one of my Emacs 26 builds in
the top directory of one of my Emacs 26 branches followed by ‘git pull’.

martin

Re: master has switched from Automake to GNU Make

[martin rudalics]

> The context is ‘eshell’ invoked from within one of my Emacs 26 builds in
                   ^^^^^^
                  `shell´

> the top directory of one of my Emacs 26 branches followed by ‘git pull’.

martin

Re: master has switched from Automake to GNU Make

[Noam Postavsky]

On Tue, Apr 11, 2017 at 6:55 AM, martin rudalics <rudalics@gmx.at> wrote:
>> That sounds wrong. It never happens to me, I expect because my
>> workflow differs. Can you give a way to reproduce your problem?
>> Perhaps there's a way we can fix the Git configuration so that it
>> doesn't happen to you in the future.
>
> Today again git complained about my dumb terminal and when I tried to
> commit manually it told me:
>
> martin@NOREST:~/emacs-git/slow$ git commit -m "Dumb"
> admin/unidata/SpecialCasing.txt:200: trailing whitespace.
> +# The remainder of this file provides conditional casing data used to
> produce
> admin/unidata/SpecialCasing.txt:281: new blank line at EOF.
>
> I don't understand our policy wrt trailing whitespace.  Even without
> that dumb terminal issue I occasionally will have to commit manually
> after a pull, for example, when fixing conflicts.

I can reproduce this. [1: b3b9b258c4] introduced the trailing
whitespace. If you merge that commit any child of it without
conflicts, then the whitespace check is not triggered. If you rebase
over that commit or any child of it, then the whitespace check is not
triggered. If you merge that commit or any child of it *with*
conflicts (the conflicts can be unrelated) then the whitespace check
is triggered when you commit the resolution.

Furthermore, I believe the whitespace check is only installed if you
run './autogen git' or './autogen all'. If you just plain './autogen'
then the git hooks are not installed.

I guess most people are rebasing instead of merging or didn't install
the git hooks and hence don't see this kind of failure.

1: 2017-04-06 20:54:58 +0200 b3b9b258c4026baa1cad3f2e617f1a637fc8d205
  Support casing characters which map into multiple code points  (bug#24603)

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > If you merge that commit or any child of it *with*
 > conflicts (the conflicts can be unrelated) then the whitespace check
 > is triggered when you commit the resolution.

I have definitively encountered this case before too.

 > Furthermore, I believe the whitespace check is only installed if you
 > run './autogen git' or './autogen all'. If you just plain './autogen'
 > then the git hooks are not installed.

I always run './autogen.sh' because IIRC that is (or at least was) the
recommended way.

 > I guess most people are rebasing instead of merging or didn't install
 > the git hooks and hence don't see this kind of failure.

I never rebase.  Whether and how I installed the hooks is beyond my
knowledge.  But IIUC Michael who committed the changes in
SpecialCasing.txt did not install the hook.

martin

Re: master has switched from Automake to GNU Make

[Noam Postavsky]

On Tue, Apr 11, 2017 at 9:54 AM, martin rudalics <rudalics@gmx.at> wrote:
>> If you merge that commit or any child of it *with*
>> conflicts (the conflicts can be unrelated) then the whitespace check
>> is triggered when you commit the resolution.
>
> I have definitively encountered this case before too.
>
>> Furthermore, I believe the whitespace check is only installed if you
>> run './autogen git' or './autogen all'. If you just plain './autogen'
>> then the git hooks are not installed.
>
> I always run './autogen.sh' because IIRC that is (or at least was) the
> recommended way.

Before [1: aca31e3815] a plain './autogen.sh' installed the hooks
(that commit also updates the recommended way to './autogen.sh all').
You probably just still have them (they're installed under .git/hooks
and so they don't get removed by any usual cleaning procedure).

1: 2016-02-02 23:14:30 -0800 aca31e3815b9bd9c696cf0c74cc4a80ad7e35ec9
  autogen.sh now configures git only on request

Re: master has switched from Automake to GNU Make

[martin rudalics]

 > Before [1: aca31e3815] a plain './autogen.sh' installed the hooks
 > (that commit also updates the recommended way to './autogen.sh all').
 > You probably just still have them (they're installed under .git/hooks
 > and so they don't get removed by any usual cleaning procedure).
 >
 > 1: 2016-02-02 23:14:30 -0800 aca31e3815b9bd9c696cf0c74cc4a80ad7e35ec9
 >    autogen.sh now configures git only on request

I'm confused.  Doesn't this mean that many people don't really care about
trailing whitespace?

martin

Re: master has switched from Automake to GNU Make

[Michal Nazarewicz]

On Wed, Apr 12 2017, martin rudalics wrote:
>  > Before [1: aca31e3815] a plain './autogen.sh' installed the hooks
>  > (that commit also updates the recommended way to './autogen.sh all').
>  > You probably just still have them (they're installed under .git/hooks
>  > and so they don't get removed by any usual cleaning procedure).
>  >
>  > 1: 2016-02-02 23:14:30 -0800 aca31e3815b9bd9c696cf0c74cc4a80ad7e35ec9
>  >    autogen.sh now configures git only on request
>
> I'm confused.  Doesn't this mean that many people don't really care about
> trailing whitespace?

In case of SpecialCasing.txt the file comes from outside so I cared more
about having it byte-for-byte identical with the source than removing
trailing white space.

At the same time, I’m sure many people indeed don’t care about trailing
white space.  I would wager that it’s also true within Emacs
contributors.  I care but not enough to write a pre-commit hook.

In general I find commit errors emitted by the hooks too strict.  This
is one example.

Another is length limit in commit messages.  While it makes sense for
description, it also prevents error messages to be included verbatim.
For example in 4b3db0daa65 I¹ had to edit the message to fit in the
limit.

¹ If you’re confused, the code was authored by Noam but I’ve written the
message and committed the patch.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

Re: master has switched from Automake to GNU Make

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]


() Michal Nazarewicz <mina86@mina86.com>
() Wed, 12 Apr 2017 14:18:39 +0200

   At the same time, I’m sure many people indeed don’t care
   about trailing white space.  I would wager that it’s also
   true within Emacs contributors.  I care but not enough to
   write a pre-commit hook.

Last time i paid attention to this, the general vibe was against
trailing whitespace -- see admin/notes/trailing-whitespace for
the blurb.  Personally, i abhor trailing whitespace, and have
‘delete-trailing-whitespace’ in ‘before-save-hook’ since 2009.

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)
   (pcase (context query)
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: master has switched from Automake to GNU Make

[Paul Eggert]

On 04/12/2017 02:28 AM, martin rudalics wrote:
> Doesn't this mean that many people don't really care about
> trailing whitespace?

No, as I recall the Git configuration was made optional because some 
developers objected to autogen.sh automatically setting 
transfer.fsckObjects in the Git configuration. I do not know the basis 
for these objections.

autogen.sh reflects a compromise among various viewpoints. Lots of 
people (including me) don't particularly like it in its current form, 
which is a common property of compromises.

Re: master has switched from Automake to GNU Make

[Michal Nazarewicz]

On Tue, Apr 11 2017, martin rudalics wrote:
>  > If you merge that commit or any child of it *with*
>  > conflicts (the conflicts can be unrelated) then the whitespace check
>  > is triggered when you commit the resolution.
>
> I have definitively encountered this case before too.
>
>  > Furthermore, I believe the whitespace check is only installed if you
>  > run './autogen git' or './autogen all'. If you just plain './autogen'
>  > then the git hooks are not installed.
>
> I always run './autogen.sh' because IIRC that is (or at least was) the
> recommended way.
>
>  > I guess most people are rebasing instead of merging or didn't install
>  > the git hooks and hence don't see this kind of failure.
>
> I never rebase.  Whether and how I installed the hooks is beyond my
> knowledge.  But IIUC Michael who committed the changes in
> SpecialCasing.txt did not install the hook.

$ ll .git/hooks/
total 16
-rwx------ 1 mpn eng  452 Dec  3  2014 applypatch-msg*
-rwx------ 1 mpn eng 4002 Jan 28  2016 commit-msg*
-rwx------ 1 mpn eng  398 Dec  3  2014 pre-applypatch*
-rwx------ 1 mpn eng 1419 Jul 27  2016 pre-commit*
$ grep -ve ^# -e ^\$ .git/hooks/pre-commit 
LC_ALL=C
export LC_ALL
exec >&2
. git-sh-setup
git_diff='git diff --cached --name-only --diff-filter=A'
ok_chars='\0+[=-=]./0-9A-Z_a-z'
nbadchars=`$git_diff -z HEAD | tr -d "$ok_chars" | wc -c`
if test "$nbadchars" -ne 0; then
  echo "File name does not consist of -+./_ or ASCII letters or digits."
  exit 1
fi
for new_name in `$git_diff HEAD`; do
  case $new_name in
    -* | */-*)
      echo "$new_name: File name component begins with '-'."
      exit 1;;
    ChangeLog | */ChangeLog)
      echo "$new_name: Please use git commit messages, not ChangeLog files."
      exit 1;;
  esac
done
$ grep -ve ^# -e ^\$ .git/hooks/pre-applypatch 
. git-sh-setup
test -x "$GIT_DIR/hooks/pre-commit" &&
	exec "$GIT_DIR/hooks/pre-commit" ${1+"$@"}
:

I cannot confirm that those were there when I was pushing
SpecialCasing.txt but my guess would be yes.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

Re: master has switched from Automake to GNU Make

[Noam Postavsky]

On Tue, Apr 11, 2017 at 12:21 PM, Michal Nazarewicz <mina86@mina86.com> wrote:
>> I never rebase.  Whether and how I installed the hooks is beyond my
>> knowledge.  But IIUC Michael who committed the changes in
>> SpecialCasing.txt did not install the hook.
>
> $ ll .git/hooks/
> total 16
> -rwx------ 1 mpn eng  452 Dec  3  2014 applypatch-msg*
> -rwx------ 1 mpn eng 4002 Jan 28  2016 commit-msg*
> -rwx------ 1 mpn eng  398 Dec  3  2014 pre-applypatch*
> -rwx------ 1 mpn eng 1419 Jul 27  2016 pre-commit*
> $ grep -ve ^# -e ^\$ .git/hooks/pre-commit
> LC_ALL=C
> export LC_ALL
> exec >&2
> . git-sh-setup
> git_diff='git diff --cached --name-only --diff-filter=A'
> ok_chars='\0+[=-=]./0-9A-Z_a-z'
> nbadchars=`$git_diff -z HEAD | tr -d "$ok_chars" | wc -c`
> if test "$nbadchars" -ne 0; then
>   echo "File name does not consist of -+./_ or ASCII letters or digits."
>   exit 1
> fi
> for new_name in `$git_diff HEAD`; do
>   case $new_name in
>     -* | */-*)
>       echo "$new_name: File name component begins with '-'."
>       exit 1;;
>     ChangeLog | */ChangeLog)
>       echo "$new_name: Please use git commit messages, not ChangeLog files."
>       exit 1;;
>   esac
> done
> $ grep -ve ^# -e ^\$ .git/hooks/pre-applypatch

It looks like you're missing the whitespace check in pre-commit, this line:

  exec git diff-index --check --cached HEAD --

Perhaps you installed the hooks before that was added?

Re: master has switched from Automake to GNU Make

[Michal Nazarewicz]

On Tue, Apr 11 2017, Noam Postavsky wrote:
> On Tue, Apr 11, 2017 at 12:21 PM, Michal Nazarewicz <mina86@mina86.com> wrote:
>>> I never rebase.  Whether and how I installed the hooks is beyond my
>>> knowledge.  But IIUC Michael who committed the changes in
>>> SpecialCasing.txt did not install the hook.
>>
>> $ ll .git/hooks/
>> total 16
>> -rwx------ 1 mpn eng  452 Dec  3  2014 applypatch-msg*
>> -rwx------ 1 mpn eng 4002 Jan 28  2016 commit-msg*
>> -rwx------ 1 mpn eng  398 Dec  3  2014 pre-applypatch*
>> -rwx------ 1 mpn eng 1419 Jul 27  2016 pre-commit*
>> $ grep -ve ^# -e ^\$ .git/hooks/pre-commit
>> LC_ALL=C
>> export LC_ALL
>> exec >&2
>> . git-sh-setup
>> git_diff='git diff --cached --name-only --diff-filter=A'
>> ok_chars='\0+[=-=]./0-9A-Z_a-z'
>> nbadchars=`$git_diff -z HEAD | tr -d "$ok_chars" | wc -c`
>> if test "$nbadchars" -ne 0; then
>>   echo "File name does not consist of -+./_ or ASCII letters or digits."
>>   exit 1
>> fi
>> for new_name in `$git_diff HEAD`; do
>>   case $new_name in
>>     -* | */-*)
>>       echo "$new_name: File name component begins with '-'."
>>       exit 1;;
>>     ChangeLog | */ChangeLog)
>>       echo "$new_name: Please use git commit messages, not ChangeLog files."
>>       exit 1;;
>>   esac
>> done
>> $ grep -ve ^# -e ^\$ .git/hooks/pre-applypatch
>
> It looks like you're missing the whitespace check in pre-commit, this line:
>
>   exec git diff-index --check --cached HEAD --
>
> Perhaps you installed the hooks before that was added?

The file is from December 2014 so that sounds likely.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

Re: master has switched from Automake to GNU Make

[Andreas Politz]

martin rudalics <rudalics@gmx.at> writes:

> With that recommendation people could tell themselves "who cares anyway"
> and leave the history alone.  But if we supply a tool that allows people
> to hide that they used that tool wrong, then we also supply the social
> pressure on people to hide whatever they've done wrong.  Look what clean
> history the others got.

I already feel the pressure ;-)

I frequently create an experimental branch, where I, at least initially,
just commit everything with a message of WIP (sometimes I use sdfkd),
e.g. in case I need to checkout a different branch.

-ap

Re: master has switched from Automake to GNU Make

[Stephen Leake]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>>> + 917ce99...5aa9a80 scratch/record -> origin/scratch/record  (forced update)
>>>> Couldn't we recommend that people don't use forced pushes - even on
>>>> scratch branches?
>>> Why?
>> It's distracting for people like me who don't understand git.  Today it
>> confused me enough that I messed up the ChangeLog of my commit and did
>> not notice it before pushing.

> It's not essential, but some people like to keep branches as a clean set
> of patches on top of master, so they regularly rebase (and reorganize
> the set of patches), so in the end it doesn't give you the path that was
> followed to get there (which, while historically accurate, tends to be
> messy and hard to follow) but only "a nice path to get there", which is
> basically a single patch divided into a few commented logical steps.

+1

People can do whatever they want on a "scratch" branch; that's what the
name means.

-- 
-- Stephe

Re: master has switched from Automake to GNU Make

[Eli Zaretskii]

> Date: Thu, 23 Mar 2017 09:02:07 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org
> 
> I currently have the following files as "untracked" here:
> 
> 	build-aux/ar-lib
> 	build-aux/compile
> 	build-aux/depcomp
> 	build-aux/missing
> 	nt/gnulib.mk
> 	src/stamp-h.in
> 
> Shouldn't we add them to the files ignored by git?  Or should these be
> deleted?

Delete them.  They are remnants of the previous file tree, no longer
pertinent.

Re: master has switched from Automake to GNU Make

[martin rudalics]

 >> I currently have the following files as "untracked" here:
 >>
 >> 	build-aux/ar-lib
 >> 	build-aux/compile
 >> 	build-aux/depcomp
 >> 	build-aux/missing
 >> 	nt/gnulib.mk
 >> 	src/stamp-h.in
 >>
 >> Shouldn't we add them to the files ignored by git?  Or should these be
 >> deleted?
 >
 > Delete them.  They are remnants of the previous file tree, no longer
 > pertinent.

Thanks for the information.

martin