This Is The Git Help Mailing List

This Is The Git Help Mailing List

[Lars Magne Ingebrigtsen]

So, I had some locally checked-in changes that I wanted to push.  So I
said "git push".

[larsi@stories ~/src/emacs]$ git push
Warning: No xauth data; using fake authentication data for X11 forwarding.
X11 forwarding request failed on channel 0
To larsi@git.sv.gnu.org:/srv/git/emacs.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'larsi@git.sv.gnu.org:/srv/git/emacs.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Ok, so I tried what I always do in the Gnus repo when this happens,
which usually fixes everything.

[larsi@stories ~/src/emacs]$ git pull --rebase
Cannot pull with rebase: You have unstaged changes.
Please commit or stash them.

Err...

Ok, how about just "git pull" like it says?

[larsi@stories ~/src/emacs]$ git pull
Warning: No xauth data; using fake authentication data for X11 forwarding.
X11 forwarding request failed on channel 0
remote: Counting objects: 29, done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 13 (delta 10), reused 0 (delta 0)
Unpacking objects: 100% (13/13), done.
From git.sv.gnu.org:/srv/git/emacs
   38fa4bc..d856e6b  master     -> origin/master
   e18c2a5..3d08bc4  emacs-24   -> origin/emacs-24
error: Your local changes to the following files would be overwritten by merge:
        lisp/ChangeLog
Please, commit your changes or stash them before you can merge.
Aborting

Errr...

What is the magic sequence of magic git commands that I should use now?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: This Is The Git Help Mailing List

[Lars Magne Ingebrigtsen]

D'oh.  Me stupid.

I had just forgotten to commit the ChangeLog change, which is why it was
complaining about "unstaged" things.

And having this in emacs/.gitattributes helps a lot:

ChangeLog    merge=merge-changelog

You need to install the merge-changlog thingie from somewhere, though.
I think.  It's been a while since I fiddled with this.

With that in place, "git pull --rebase; git push" worked perfectly.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: This Is The Git Help Mailing List

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 13 Nov 2014 17:19:31 +0100
> 
> You need to install the merge-changlog thingie from somewhere, though.

From gnulib.

Re: This Is The Git Help Mailing List

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
>> Date: Thu, 13 Nov 2014 17:19:31 +0100
>> 
>> You need to install the merge-changlog thingie from somewhere, though.
>
> From gnulib.

Or perhaps from your distribution.

http://software.opensuse.org/package/git-merge-changelog

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: This Is The Git Help Mailing List

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org
> Date: Thu, 13 Nov 2014 18:19:14 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> >> Date: Thu, 13 Nov 2014 17:19:31 +0100
> >> 
> >> You need to install the merge-changlog thingie from somewhere, though.
> >
> > From gnulib.
> 
> Or perhaps from your distribution.

Yes, if the target platform is Windows (in which case my build also
fixes an upstream bug with EOL format).

> http://software.opensuse.org/package/git-merge-changelog

Good to know there's a distro out there.  Building from gnulib is not
for the faint at heart, IMO.

Re: This Is The Git Help Mailing List

[Juri Linkov]

> And having this in emacs/.gitattributes helps a lot:
>
> ChangeLog    merge=merge-changelog

I wonder why we still don't have in emacs/.gitattributes this line?

  *.el diff=lisp

It's useful to show function names in diffs such as

   @@ -1781,7 +1782,7 @@ (defun comint-send-input (&optional no-newline artificial)

when .git/config contains

  [diff "lisp"]
          xfuncname = "^(\\(.*)$"

Re: This Is The Git Help Mailing List

[Stefan Monnier]

> I wonder why we still don't have in emacs/.gitattributes this line?

Probably because noone did it.


        Stefan "who knows nothing about .gitattributes"

Re: This Is The Git Help Mailing List

[Ted Zlatanov]

On Thu, 04 Dec 2014 21:04:47 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I wonder why we still don't have in emacs/.gitattributes this line?
SM> Probably because noone did it.

SM>         Stefan "who knows nothing about .gitattributes"

For general use (not just inside Emacs) put this in ~/.gitconfig :

[core]
        attributesfile = ~/.gitattributes

[diff "lisp"]
        xfuncname = "^(\\(.*)$"

[merge "merge-changelog"]
        name = GNU-style ChangeLog merge driver
        driver = /usr/local/bin/git-merge-changelog %O %A %B

and then in ~/.gitattributes :

ChangeLog       merge=merge-changelog
*.el diff=lisp

That has been helpful for me.  The core.attributesfile setting is fairly
new, though, so get the latest git.

Ted

Re: This Is The Git Help Mailing List

[Rüdiger Sonderfeld]

On Thursday 04 December 2014 23:26:38 Ted Zlatanov wrote:
> and then in ~/.gitattributes :
> 
> ChangeLog       merge=merge-changelog
> *.el diff=lisp

You can also add custom hunk headers for C code (builtin: diff=cpp) and 
texinfo (requires another xfuncname).  See:

http://www.emacswiki.org/emacs/GitForEmacsDevs#UsefulAddOns

(A collection of other xfuncname and gitattributes, I started: 
https://gist.github.com/ruediger/5647207 )

> That has been helpful for me.  The core.attributesfile setting is fairly
> new, though, so get the latest git.

The default value is $XDG_CONFIG_HOME/git/attributes (with XDG_CONFIG_HOME 
defaulting to ~/.config if unset).  That way there are less files polluting ~

Regards,
Rüdiger

Re: This Is The Git Help Mailing List

[Rüdiger Sonderfeld]

On Friday 05 December 2014 02:45:10 Juri Linkov wrote:
> I wonder why we still don't have in emacs/.gitattributes this line?

Because:

> when .git/config contains
> 
>   [diff "lisp"]
>           xfuncname = "^(\\(.*)$"

The diff driver for lisp is not part of git and the xfuncname has to be 
defined in the User's config.  There is no way for us to set it project-wide.  
That's why I added the instructions to do it manually to the EmacsWiki.  
Besides *.el, there are also instructions for texinfo (requires another 
xfuncname) and C code (has builtin support).

http://www.emacswiki.org/emacs/GitForEmacsDevs#UsefulAddOns

Regards,
Rüdiger

Re: This Is The Git Help Mailing List

[Karl Fogel]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>So, I had some locally checked-in changes that I wanted to push.  So I
>said "git push".
>
>[larsi@stories ~/src/emacs]$ git push
>Warning: No xauth data; using fake authentication data for X11 forwarding.
>X11 forwarding request failed on channel 0
>To larsi@git.sv.gnu.org:/srv/git/emacs.git
> ! [rejected]        master -> master (non-fast-forward)
>error: failed to push some refs to 'larsi@git.sv.gnu.org:/srv/git/emacs.git'
>hint: Updates were rejected because the tip of your current branch is behind
>hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
>hint: before pushing again.
>hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>
>Ok, so I tried what I always do in the Gnus repo when this happens,
>which usually fixes everything.
>
>[larsi@stories ~/src/emacs]$ git pull --rebase
>Cannot pull with rebase: You have unstaged changes.
>Please commit or stash them.
>
>Err...
>
>Ok, how about just "git pull" like it says?
>
>[larsi@stories ~/src/emacs]$ git pull
>Warning: No xauth data; using fake authentication data for X11 forwarding.
>X11 forwarding request failed on channel 0
>remote: Counting objects: 29, done.
>remote: Compressing objects: 100% (13/13), done.
>remote: Total 13 (delta 10), reused 0 (delta 0)
>Unpacking objects: 100% (13/13), done.
>>From git.sv.gnu.org:/srv/git/emacs
>   38fa4bc..d856e6b  master     -> origin/master
>   e18c2a5..3d08bc4  emacs-24   -> origin/emacs-24
>error: Your local changes to the following files would be overwritten by merge:
>        lisp/ChangeLog
>Please, commit your changes or stash them before you can merge.
>Aborting
>
>Errr...
>
>What is the magic sequence of magic git commands that I should use now?

What does 'git status' say?  You're positive you have no
uncommitted/unstaged local changes?  It looks from the above like
lisp/ChangeLog has local mods... (cue our usual ISO-standard discussion
of about why we version change data in files instead of solely in commit
logs, of course, but that is another matter).

Best,
-K

Re: This Is The Git Help Mailing List

[Paul Eggert]

On 11/13/2014 08:20 AM, Karl Fogel wrote:
> (cue our usual ISO-standard discussion
> of about why we version change data in files instead of solely in commit
> logs, of course, but that is another matter).

The ChangeLog-vs-commitlog business slowed me down within my first 
couple of commits to the git repository for Emacs.  It's only a minor 
annoyance, but it is an annoyance.  As I recall there was consensus to 
wait for a bit after the transition and then change our ChangeLog 
practice so that the ChangeLog is derived automatically from the git 
commit log.  Other GNU projects do that (coreutils, for example) and 
Emacs could surely do the same.

Re: This Is The Git Help Mailing List

[Lars Magne Ingebrigtsen]

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

> As I recall there was consensus to wait for a bit after the transition
> and then change our ChangeLog practice so that the ChangeLog is
> derived automatically from the git commit log.  Other GNU projects do
> that (coreutils, for example) and Emacs could surely do the same.

Is there any practical reason we have to wait?  Since other GNU projects
do this already, presumably the tools necessary already exist, and we
could just use them...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: This Is The Git Help Mailing List

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> What is the magic sequence of magic git commands that I should use now?

Please commit your changes or stash them.

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."