git:

git:

[Gregor Zattler]

I build emacs from sources.  From time to  time I do git pull and then
there is an error message like:

error: Your local changes to the following files would be overwritten
by merge:
        lisp/mail/rmail.el


$ git diff
diff --git a/lisp/mail/rmail.el b/lisp/mail/rmail.el
index 855a4c2..9d5f6de 100644
--- a/lisp/mail/rmail.el
+++ b/lisp/mail/rmail.el
@@ -4810,7 +4810,7 @@ If prefix argument REVERSE is non-nil, sorts in reverse order.
 
 ;;;***
 ^L
-;;;### (autoloads nil "rmailsum" "rmailsum.el" "e3943ef45946f10b9b5cab8097d7f271")
+;;;### (autoloads nil "rmailsum" "rmailsum.el" "e41d88a5c472a084090c2aad1ef4971f")
 ;;; Generated autoloads from rmailsum.el
 
 (autoload 'rmail-summary "rmailsum" "\

   


how is this possible while I do not modify the sources, using git only
as a transport for the sources (I'm no developer)?

Any idea why this happens and what to do aginst this?



Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: git:

[J. David Boyd]

Gregor Zattler <telegraph@gmx.net> writes:

> I build emacs from sources.  From time to  time I do git pull and then
> there is an error message like:
>
> error: Your local changes to the following files would be overwritten
> by merge:
>         lisp/mail/rmail.el
>
>
> $ git diff
> diff --git a/lisp/mail/rmail.el b/lisp/mail/rmail.el
> index 855a4c2..9d5f6de 100644
> --- a/lisp/mail/rmail.el
> +++ b/lisp/mail/rmail.el
> @@ -4810,7 +4810,7 @@ If prefix argument REVERSE is non-nil, sorts in reverse order.
>  
>  ;;;***
>  ^L
> -;;;### (autoloads nil "rmailsum" "rmailsum.el" "e3943ef45946f10b9b5cab8097d7f271")
> +;;;### (autoloads nil "rmailsum" "rmailsum.el" "e41d88a5c472a084090c2aad1ef4971f")
>  ;;; Generated autoloads from rmailsum.el
>  
>  (autoload 'rmail-summary "rmailsum" "\
>
>    
>
>
> how is this possible while I do not modify the sources, using git only
> as a transport for the sources (I'm no developer)?
>
> Any idea why this happens and what to do aginst this?
>
>
>
> Ciao, Gregor


I have the same thing happen occasionally .

I just go up a level, mv my 'emacs' to 'emacs.xxx' or something, and reclone
the directory.

Much faster than trying to figure out why, since I don't care really.

Dave

Re: git:

[Michael Heerdegen]

Gregor Zattler <telegraph@gmx.net> writes:

> Any idea why this happens and what to do aginst this?

The Rmail sources seem to use rmail.el as source file and autoloads file
at the same time.

Obviously that's the cause why rmail.el is touched when compiling.

The hash in the diff is an md5 checksum generated by
`autoload-generate-file-autoloads'.  I'm not sure why the md5 hashes
differ, but this happened to me too.

I suggest to make a bug report please - this is more than confusing.


Thanks,

Michael.

Re: git:

[Gregor Zattler]

Hi Michael,
* Michael Heerdegen <michael_heerdegen@web.de> [28. Feb. 2015]:
[...]
> I suggest to make a bug report please - this is more than confusing.

I'll do so when it happens next.  I don't know any more at which
point in the repo this did happen.

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: git:

[Bob Proulx]

J. David Boyd wrote:
> Gregor Zattler writes:
> > -;;;### (autoloads nil "rmailsum" "rmailsum.el" "e3943ef45946f10b9b5cab8097d7f271")
> > +;;;### (autoloads nil "rmailsum" "rmailsum.el" "e41d88a5c472a084090c2aad1ef4971f")
> > Any idea why this happens and what to do aginst this?
>
> I have the same thing happen occasionally .

Like Michael suggested in his response this feels like a bug to me.
It isn't reasonable to have things modifying source files all of the
time.  It would be good to get it reported and fixed.

> I just go up a level, mv my 'emacs' to 'emacs.xxx' or something, and reclone
> the directory.
> 
> Much faster than trying to figure out why, since I don't care really.

Much simpler would be to simply reset and overwrite the "bad" file
with the good one.  No need to re-clone the entire directory.

Re-cloning the entire directory isn't very bandwidth friendly since
emacs is quite large.  Downloading the entire thing again is rather
hard on the upstream vcs.savannah server.  (Especially for a few hours
before it was compressed when it was 13G!  It is now 343M compacted
and much more reasonable but that is still large.)  Saving that
bandwidth is significant.  And the entire point of having a
distributed version control system.

This following will overwrite the current copy of rmail.el with the
copy from version control.  If that was the only file modified then at
that point a subsequent git pull should work since the working copy
was then clean and not locally modified.

  git checkout lisp/mail/rmail.el b/lisp/mail/rmail.el

Or alternatively if you want to reset *everything* then use the git
reset command to reset everything.

  git reset --hard

Warning!  Both of those commands overwrite your local copy of those
files.  That is what you want in this case.  But if I don't include
this warning someone will use git reset --hard and then complain that
their local changes were destroyed.  If I put in this warning then I
can say that they were told that was going to happen.

Please use version control for the purpose it is intended.  You have a
clone of the repository.  Having that clone means that you already
have a way to reset your working copy back to the pristine state.
Please don't download the hundreds of megs of data again and again.
Think of the kittens! :-)

Bob

Re: git:

[Glenn Morris]

Michael Heerdegen wrote:

> The hash in the diff is an md5 checksum generated by
> `autoload-generate-file-autoloads'.  I'm not sure why the md5 hashes
> differ, but this happened to me too.

Because the autoload source file, rmailsum.el, got modified.
The autoload hashes are updated once a day by a cron job that checks in
a new rmail.el (etc). If you happen to build before that runs, then git
pull after, you might see this issue.

> I suggest to make a bug report please [...]

I disagree. It's been like this for many years and is behaving as
designed.

It's a shame git is less user-friendly (refusing to pull if you have
uncommitted changs, even if the changes are identical to what you want
to pull) than eg bzr or svn, which just do the sensible thing (pull and
resolve conflicts automatically where possible).

Re: git:

[Glenn Morris]

Glenn Morris wrote:

> It's a shame git is less user-friendly (refusing to pull if you have
> uncommitted changs, even if the changes are identical to what you want
> to pull) than eg bzr or svn, which just do the sensible thing (pull and
> resolve conflicts automatically where possible).

PS just to throw yet another thing out there, the generally advertised
solution for this problem seems to be: git stash; git pull; git stash
pop. Obviously this makes us look cool by playing with "stashes" and is
far superior to things Just Working like they used to. Yours grumpily...