emacs-repository-version on MS-Windows

emacs-repository-version on MS-Windows

[Eli Zaretskii]

Would people who build the development sources from the master branch
of the git repository please check that their emacs-repository-version
value is non-nil?

There is some subtle issue with invoking git on Windows from temacs,
which prevented it from working on my machine.  I fixed it by local
changes to the way git is invoked by Emacs, but I wonder whether it's
only my local problem.

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> Date: Fri, 14 Nov 2014 11:32:42 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Would people who build the development sources from the master branch
> of the git repository please check that their emacs-repository-version
> value is non-nil?

I meant those who build Emacs on MS-Windows, of course; I see no
problems on GNU/Linux.  Sorry.

Re: emacs-repository-version on MS-Windows

[Chris Zheng]

From: Eli Zaretskii <eliz@gnu.org>
Subject: emacs-repository-version on MS-Windows
Date: Fri, 14 Nov 2014 11:32:42 +0200

Hi Eli,
> Would people who build the development sources from the master branch
> of the git repository please check that their emacs-repository-version
> value is non-nil?
> 
> There is some subtle issue with invoking git on Windows from temacs,
> which prevented it from working on my machine.  I fixed it by local
> changes to the way git is invoked by Emacs, but I wonder whether it's
> only my local problem.
For me its value is nil.  I build master branch with MSYS2/MinGW-w64
combination.

Re: emacs-repository-version on MS-Windows

[martin rudalics]

 > Would people who build the development sources from the master branch
 > of the git repository please check that their emacs-repository-version
 > value is non-nil?

With a checkout from a few hours ago:

emacs-repository-version is a variable defined in `version.el'.
Its value is "eb976992367d5b265dc779d82af5948987ec6de3"

martin

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> Date: Fri, 14 Nov 2014 17:48:22 +0800
> Cc: emacs-devel@gnu.org
> From: Chris Zheng <chriszheng99@gmail.com>
> 
> > There is some subtle issue with invoking git on Windows from temacs,
> > which prevented it from working on my machine.  I fixed it by local
> > changes to the way git is invoked by Emacs, but I wonder whether it's
> > only my local problem.
> For me its value is nil.  I build master branch with MSYS2/MinGW-w64
> combination.

Is your master current?  The change that assigns a non-nil value to
emacs-repository-version was done only today.

If you see nil with the current master, please tell how does Emacs
invoke Git on your system.  Does it use the git.cmd batch file
installed by the msysGit installer, per chance?

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> Date: Fri, 14 Nov 2014 10:57:38 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
>  > Would people who build the development sources from the master branch
>  > of the git repository please check that their emacs-repository-version
>  > value is non-nil?
> 
> With a checkout from a few hours ago:
> 
> emacs-repository-version is a variable defined in `version.el'.
> Its value is "eb976992367d5b265dc779d82af5948987ec6de3"

Thanks, this means your system configuration is not affected by the
problem I found on mine.

Re: emacs-repository-version on MS-Windows

[Chris Zheng]

From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: emacs-repository-version on MS-Windows
Date: Fri, 14 Nov 2014 12:13:05 +0200

Hi Eli,
> Is your master current?  The change that assigns a non-nil value to
> emacs-repository-version was done only today.
> 
> If you see nil with the current master, please tell how does Emacs
> invoke Git on your system.  Does it use the git.cmd batch file
> installed by the msysGit installer, per chance?
The output is
  emacs-repository-version is a variable defined in `version.el'.
  Its value is "eb976992367d5b265dc779d82af5948987ec6de3"

Now it works as expected.  Thanks.

Re: emacs-repository-version on MS-Windows

[Dani Moncayo]

>> Would people who build the development sources from the master branch
>> of the git repository please check that their emacs-repository-version
>> value is non-nil?
>
> With a checkout from a few hours ago:
>
> emacs-repository-version is a variable defined in `version.el'.
> Its value is "eb976992367d5b265dc779d82af5948987ec6de3"

Same here.

FWIW, the MSYS I'm (still) using is the (now rather old) last version from here:

  https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/

That pre-built MSYS comes also with a version of git (git version
1.8.1.msysgit.1) which as you see seems to work fine.

-- 
Dani Moncayo

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> Date: Fri, 14 Nov 2014 18:53:55 +0800
> Cc: emacs-devel@gnu.org
> From: Chris Zheng <chriszheng99@gmail.com>
> 
> The output is
>   emacs-repository-version is a variable defined in `version.el'.
>   Its value is "eb976992367d5b265dc779d82af5948987ec6de3"
> 
> Now it works as expected.  Thanks.

OK, thanks.

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> Date: Fri, 14 Nov 2014 11:57:07 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs development discussions <emacs-devel@gnu.org>
> 
> > emacs-repository-version is a variable defined in `version.el'.
> > Its value is "eb976992367d5b265dc779d82af5948987ec6de3"
> 
> Same here.

Thanks.

> FWIW, the MSYS I'm (still) using is the (now rather old) last version from here:
> 
>   https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/
> 
> That pre-built MSYS comes also with a version of git (git version
> 1.8.1.msysgit.1) which as you see seems to work fine.

The problem I had on my system was not with MSYS, it was with git.cmd
batch file that is installed by msysgit.

Re: emacs-repository-version on MS-Windows

[Fabrice Popineau]

Eli Zaretskii <eliz <at> gnu.org> writes:

> 
> > Date: Fri, 14 Nov 2014 18:53:55 +0800
> > Cc: emacs-devel <at> gnu.org
> > From: Chris Zheng <chriszheng99 <at> gmail.com>
> > 
> > The output is
> >   emacs-repository-version is a variable defined in `version.el'.
> >   Its value is "eb976992367d5b265dc779d82af5948987ec6de3"
> > 
> > Now it works as expected.  Thanks.
> 
> OK, thanks.
> 
> 

I don't understand. I'm still getting a nil value for emacs-repository-version.
If I look into version.el I read that the git command run to get the version is:

git log -1 --pretty=format:%N

which returns nothing to me.
However, if I ask for:
git log -1 --pretty=format:%H
658b768a6534ae6e77a8547a56fc31b46b63710b

So I feel something is wrong here but I don't know what.

Hoping that I am tracking the right master url:

git remote show origin
* remote origin
  Fetch URL: http://git.savannah.gnu.org/r/emacs.git/
  Push  URL: http://git.savannah.gnu.org/r/emacs.git/
  HEAD branch: master

Regards,

Fabrice

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sat, 15 Nov 2014 11:27:57 +0000 (UTC)
> 
> > > The output is
> > >   emacs-repository-version is a variable defined in `version.el'.
> > >   Its value is "eb976992367d5b265dc779d82af5948987ec6de3"
> > > 
> > > Now it works as expected.  Thanks.
> > 
> > OK, thanks.
> > 
> > 
> 
> I don't understand. I'm still getting a nil value for emacs-repository-version.
> If I look into version.el I read that the git command run to get the version is:
> 
> git log -1 --pretty=format:%N
> 
> which returns nothing to me.
> However, if I ask for:
> git log -1 --pretty=format:%H
> 658b768a6534ae6e77a8547a56fc31b46b63710b
> 
> So I feel something is wrong here but I don't know what.
> 
> Hoping that I am tracking the right master url:
> 
> git remote show origin
> * remote origin
>   Fetch URL: http://git.savannah.gnu.org/r/emacs.git/
>   Push  URL: http://git.savannah.gnu.org/r/emacs.git/
>   HEAD branch: master

The URLs don't look correct to me, although with all the aliases
around I could be wrong.

What does this show in the master branch after you "git pull":

  git rev-parse HEAD

Re: emacs-repository-version on MS-Windows

[Fabrice Popineau]

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

>
> >
> > git remote show origin
> > * remote origin
> >   Fetch URL: http://git.savannah.gnu.org/r/emacs.git/
> >   Push  URL: http://git.savannah.gnu.org/r/emacs.git/
> >   HEAD branch: master
>
> The URLs don't look correct to me, although with all the aliases
> around I could be wrong.
>
>
Ouch.
The first URL posted by Eric Raymond was
git.sv.gnu.org:/srv/git/emacs.git
and it gave me a 'permission denied' error when trying to clone it.


> What does this show in the master branch after you "git pull":
>
>   git rev-parse HEAD
>
>
git rev-parse HEAD
658b768a6534ae6e77a8547a56fc31b46b63710b

Fabrice

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

Re: emacs-repository-version on MS-Windows

[Fabrice Popineau]

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

>
>
>> What does this show in the master branch after you "git pull":
>>
>>   git rev-parse HEAD
>>
>>
> git rev-parse HEAD
> 658b768a6534ae6e77a8547a56fc31b46b63710b
>
>
Seems to me that the url is right, and so is this latest commit.

And for the problem with invoking git, my bad, I compiled in a branch where
I missed a merge.

Sorry for the noise,

Fabrice

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

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sat, 15 Nov 2014 12:58:17 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
>     What does this show in the master branch after you "git pull":
>     
>     git rev-parse HEAD
>     
>     
> 
> git rev-parse HEAD
> 658b768a6534ae6e77a8547a56fc31b46b63710b

This is the latest commit on master.  So you should have the change
below, which switched the git command used in
emacs-repository-get-version to use %H instead of %N.  Do you have
that change?  If so, how come your Emacs still uses %N?

$ git show 7169391^..7169391
commit 7169391ddb735892a8463aa96407e0448a3820a0
Author: Ulrich Müller <ulm@gentoo.org>
Date:   Fri Nov 14 05:03:32 2014 +0100

    (emacs-repository-get-version): Call `git log' with proper format argument

    Fixes: debbugs:19049

    * version.el (emacs-repository-get-version): Call `git log'
    command with proper format argument (bug#19049).

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 8238dc5..7674e78 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,8 @@
+2014-11-13  Ulrich M?ller  <ulm@gentoo.org>
+
+       * version.el (emacs-repository-get-version): Call `git log'
+       command with proper format argument (bug#19049).
+
 2014-11-14  Lars Magne Ingebrigtsen  <larsi@gnus.org>

        * bindings.el (search-map): Bind M-s M-s to `eww-search-words'.
diff --git a/lisp/version.el b/lisp/version.el
index 68b502c..1ea38da 100644
--- a/lisp/version.el
+++ b/lisp/version.el
@@ -188,7 +188,7 @@ only ask the VCS if we cannot find any information ourselves
             (and (eq 0
                      (condition-case nil
                          (call-process "git" nil '(t nil) nil "log"
-                                       "-1" "--pretty=format:%N")
+                                       "-1" "--pretty=format:%H")
                        (error nil)))
                  (not (zerop (buffer-size)))
                  (replace-regexp-in-string "\n" "" (buffer-string))))))))

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

JFYI, let me for the record publish the one finding from digging into
this, that is relevant to all platforms, not only Windows.

When we invoke subprocesses from temacs, we do that with an empty
process-environment (it doesn't get set when we are dumping).  So the
subprocess gets an almost empty environment: not even PATH is there.
Not sure if this can cause trouble, but it surely is worth keeping in
mind.

Re: emacs-repository-version on MS-Windows

[Glenn Morris]

Eli Zaretskii wrote:

> When we invoke subprocesses from temacs, we do that with an empty
> process-environment (it doesn't get set when we are dumping).  So the
> subprocess gets an almost empty environment: not even PATH is there.
> Not sure if this can cause trouble, but it surely is worth keeping in
> mind.

The bzr version of this intentionally avoided calling external executables.
(Apparently not possible with git.)

Re: emacs-repository-version on MS-Windows

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> Eli Zaretskii wrote:
>
>> When we invoke subprocesses from temacs, we do that with an empty
>> process-environment (it doesn't get set when we are dumping).  So the
>> subprocess gets an almost empty environment: not even PATH is there.
>> Not sure if this can cause trouble, but it surely is worth keeping in
>> mind.
>
> The bzr version of this intentionally avoided calling external executables.
> (Apparently not possible with git.)

You can do that with git as well, the repository structure is fully
documented (gitrepository-layout(5)).  Of course, you have to be
prepared to update the procedure in case of future extensions.

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: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 15 Nov 2014 16:44:18 -0500
> 
> Eli Zaretskii wrote:
> 
> > When we invoke subprocesses from temacs, we do that with an empty
> > process-environment (it doesn't get set when we are dumping).  So the
> > subprocess gets an almost empty environment: not even PATH is there.
> > Not sure if this can cause trouble, but it surely is worth keeping in
> > mind.
> 
> The bzr version of this intentionally avoided calling external executables.

Which was a good thing.

> (Apparently not possible with git.)

If there is, we should do that instead.

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 15 Nov 2014 23:42:46 +0100
> 
> > The bzr version of this intentionally avoided calling external executables.
> > (Apparently not possible with git.)
> 
> You can do that with git as well, the repository structure is fully
> documented (gitrepository-layout(5)).  Of course, you have to be
> prepared to update the procedure in case of future extensions.

So is the following algorithm correct?

  . visit the file .git/HEAD
  . if the contents is a SHA1 checksum, we are done: return that SHA1
  . otherwise:
    . parse the contents of .git/HEAD that should have the form
      "ref: refs/heads/BRANCH" where BRANCH is the name of the active
      branch
    . try visiting the file .git/refs/heads/BRANCH
    . if the file exists, its contents should be the SHA1 checksum we
      are looking for
    . otherwise:
      . visit the file .git/packed-refs, whose contents should be
      	lines of the form "SHA1 REF"
      . find the line in that file whose REF part is "refs/heads/BRANCH"
      . the SHA1 part of that line is the checksum we are looking for

Does this cover all the possible arrangements of the repository and
all the possible workflows?

Btw, I think the packed-refs part is unnecessary, since the active
branch will never be packed -- is that right?

Question: Can .git/HEAD specify a branch in refs/remotes/?  If so,
what do we do in the above algorithm? punt and return nil?

Re: emacs-repository-version on MS-Windows

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> Btw, I think the packed-refs part is unnecessary, since the active
> branch will never be packed -- is that right?

Not right.

> Question: Can .git/HEAD specify a branch in refs/remotes/?

Don't think so.

-- 
David Kastrup

Re: emacs-repository-version on MS-Windows

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> So is the following algorithm correct?
>
>   . visit the file .git/HEAD
>   . if the contents is a SHA1 checksum, we are done: return that SHA1
>   . otherwise:
>     . parse the contents of .git/HEAD that should have the form
>       "ref: refs/heads/BRANCH" where BRANCH is the name of the active
>       branch
>     . try visiting the file .git/refs/heads/BRANCH
>     . if the file exists, its contents should be the SHA1 checksum we
>       are looking for
>     . otherwise:
>       . visit the file .git/packed-refs, whose contents should be
>       	lines of the form "SHA1 REF"
>       . find the line in that file whose REF part is "refs/heads/BRANCH"
>       . the SHA1 part of that line is the checksum we are looking for
>
> Does this cover all the possible arrangements of the repository and
> all the possible workflows?

.git can also be a gitdir file.

> Btw, I think the packed-refs part is unnecessary, since the active
> branch will never be packed -- is that right?

No, any ref can be packed.

> Question: Can .git/HEAD specify a branch in refs/remotes/?  If so,
> what do we do in the above algorithm? punt and return nil?

There is nothing wrong with that.  You should not assume any meaning in
the ref namespaces.

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: emacs-repository-version on MS-Windows

[Achim Gratz]

Eli Zaretskii writes:
> Does this cover all the possible arrangements of the repository and
> all the possible workflows?

For starters, .git might actually be a file rather than a directory with
contents pointing to actual the actual repo.  Objects might be found in
alternates.  And if you're really trying to cover all bases, the
location of the Git directory and the working tree might be determined
by environment variables GIT_DIR and GIT_WORKTREE.

I may be missing something, but why not let GNU make deal with Git and
keep this out of temacs?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sun, 16 Nov 2014 17:27:29 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Btw, I think the packed-refs part is unnecessary, since the active
> > branch will never be packed -- is that right?
> 
> Not right.

Thanks.  I guess I've misunderstood the documentation, which seems to
say that, even if all the refs has been packed, checking out a branch
will immediately re-create the refs/heads/BRANCH file that was deleted
by packing.

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: rgm@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 16 Nov 2014 17:33:09 +0100
> 
> .git can also be a gitdir file.

Right, missed that part.  Thanks.

> > Question: Can .git/HEAD specify a branch in refs/remotes/?  If so,
> > what do we do in the above algorithm? punt and return nil?
> 
> There is nothing wrong with that.  You should not assume any meaning in
> the ref namespaces.

Sorry, I don't follow.  refs/remotes/ means the active branch is not
on the local machine, right?  So how can Emacs get the tip SHA1 in
that case?

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Sun, 16 Nov 2014 17:47:36 +0100
> 
> I may be missing something, but why not let GNU make deal with Git and
> keep this out of temacs?

I guess that's another possibility.

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: rgm@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 16 Nov 2014 17:33:09 +0100
> 
> > Question: Can .git/HEAD specify a branch in refs/remotes/?  If so,
> > what do we do in the above algorithm? punt and return nil?
> 
> There is nothing wrong with that.  You should not assume any meaning in
> the ref namespaces.

Oh, I see what you mean: those refs/remotes/ are also on the local
disk.  Sorry for the noise.

Re: emacs-repository-version on MS-Windows

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sun, 16 Nov 2014 17:27:29 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Btw, I think the packed-refs part is unnecessary, since the active
>> > branch will never be packed -- is that right?
>> 
>> Not right.
>
> Thanks.  I guess I've misunderstood the documentation, which seems to
> say that, even if all the refs has been packed, checking out a branch
> will immediately re-create the refs/heads/BRANCH file that was deleted
> by packing.

The head ref? Could be.

-- 
David Kastrup

Re: emacs-repository-version on MS-Windows

[Glenn Morris]

Andreas Schwab wrote:

> You can do that with git as well, the repository structure is fully
> documented (gitrepository-layout(5)).  

Maybe someone should do that then. (I don't intend to.)

> Of course, you have to be prepared to update the procedure in case of
> future extensions.

Of course, the same was true for bzr, and would be true for any VCS.

Re: emacs-repository-version on MS-Windows

[Andy Moreton]

On Sun 16 Nov 2014, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Sat, 15 Nov 2014 23:42:46 +0100
>> 
>> > The bzr version of this intentionally avoided calling external executables.
>> > (Apparently not possible with git.)
>> 
>> You can do that with git as well, the repository structure is fully
>> documented (gitrepository-layout(5)).  Of course, you have to be
>> prepared to update the procedure in case of future extensions.
>
> So is the following algorithm correct?
>
>   . visit the file .git/HEAD
>   . if the contents is a SHA1 checksum, we are done: return that SHA1
>   . otherwise:
>     . parse the contents of .git/HEAD that should have the form
>       "ref: refs/heads/BRANCH" where BRANCH is the name of the active
>       branch
>     . try visiting the file .git/refs/heads/BRANCH
>     . if the file exists, its contents should be the SHA1 checksum we
>       are looking for
>     . otherwise:
>       . visit the file .git/packed-refs, whose contents should be
>       	lines of the form "SHA1 REF"
>       . find the line in that file whose REF part is "refs/heads/BRANCH"
>       . the SHA1 part of that line is the checksum we are looking for
>
> Does this cover all the possible arrangements of the repository and
> all the possible workflows?

The descripriton of .git/HEAD in gitrepository-layout(5) suggests that
it can also be a symlink rather than a git symref.

    AndyM

Re: emacs-repository-version on MS-Windows

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Sun, 16 Nov 2014 23:41:12 +0000
> 
> The descripriton of .git/HEAD in gitrepository-layout(5) suggests that
> it can also be a symlink rather than a git symref.

Yes, but that's already covered by visiting it and examining its
contents, right?