Stupid git!

Stupid git!

[Alan Mackenzie]

Hello, Emacs.

git has struck again, and another couple of hours valuable time have
been lost.

Having "staged" a change with `git add', I then tried to commit it with
`git commit'.  Somebody else had got in before me, so I had to pull
their changes first - fair enough.

So I did `git pull'.  I was then dumped into an editing session for a
merge operation for .../test/automated/file-notify-tests.el.  Eh?  I've
never touched this file in my life, and didn't even know it existed.  So
why is a merge necessary/why has a merge been (half-)done?  Why didn't
git pull simply merge the changes to this file into my repository and
working directory?

So I aborted this merge operation, in order to see what it's doing
first.  git has kindly discarded my (staged) change, leaving no record
of its existence - good job I've still got a copy of the changed file in
Emacs.  Scrabbling around in the .git directory, I found the commit
message in a file there.  So all is not lost.

How do I see what changes are in file-notify-tests.el, which is in the
staging area?  I would have thought some variety of `git diff' ought to
do the trick, but how to do this is not made obvious in the fine manual
for `git diff'.

Time to save my changed file and have a coffee.  Isn't git wonderful!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stupid git!

[Alan Mackenzie]

Hello, Emacs.

On Sat, Sep 12, 2015 at 10:15:14AM +0000, Alan Mackenzie wrote:
> git has struck again, and another couple of hours valuable time have
> been lost.

> Having "staged" a change with `git add', I then tried to commit it with
> `git commit'.  Somebody else had got in before me, so I had to pull
> their changes first - fair enough.

> So I did `git pull'.  I was then dumped into an editing session for a
> merge operation for .../test/automated/file-notify-tests.el.  Eh?  I've
> never touched this file in my life, and didn't even know it existed.  So
> why is a merge necessary/why has a merge been (half-)done?  Why didn't
> git pull simply merge the changes to this file into my repository and
> working directory?

> So I aborted this merge operation, in order to see what it's doing
> first.  git has kindly discarded my (staged) change, leaving no record
> of its existence - good job I've still got a copy of the changed file in
> Emacs.  Scrabbling around in the .git directory, I found the commit
> message in a file there.  So all is not lost.

Sorry, scrub that bit!  My commit had saved the file OK.  I'd got
confused with another situation in which git delete[sd] changes.

> How do I see what changes are in file-notify-tests.el, which is in the
> staging area?  I would have thought some variety of `git diff' ought to
> do the trick, but how to do this is not made obvious in the fine manual
> for `git diff'.

> Time to save my changed file and have a coffee.  Isn't git wonderful!

> -- 
> Alan Mackenzie (Nuremberg, Germany).

Re: Stupid git!

[Dmitry Gutov]

On 09/12/2015 01:15 PM, Alan Mackenzie wrote:

> Having "staged" a change with `git add', I then tried to commit it with
> `git commit'.  Somebody else had got in before me, so I had to pull
> their changes first - fair enough.

I don't get it. This sounds like the commit failed because someone has 
pushed to master in the upstream repo first. Which obviously can't 
happen because git doesn't have "bound branches" a la Bazaar.

But in general, you either 'git stage' and then 'git pull', or 'git 
add', 'git commit' (!), and then either rebase or merge upstream.

The fact that git allows pulling after 'git add' sounds like a bug to 
me, but apparently it sort-of fine because you can do two-way merge, or 
even abort the merge and return to the previous state.

> So I did `git pull'.  I was then dumped into an editing session for a
> merge operation for .../test/automated/file-notify-tests.el.  Eh?  I've
> never touched this file in my life, and didn't even know it existed.  So
> why is a merge necessary/why has a merge been (half-)done?  Why didn't
> git pull simply merge the changes to this file into my repository and
> working directory?

Was there a conflict in this file, or not? If yes, you can see the 
diverging changes. If not, then you don't need to merge it at all, just 
resolve the conflicts.

How were you even "dumped into an editing session"? What tool did that?

> So I aborted this merge operation, in order to see what it's doing
> first.  git has kindly discarded my (staged) change, leaving no record
> of its existence - good job I've still got a copy of the changed file in
> Emacs.

That might be a good subject for a bug report.

> How do I see what changes are in file-notify-tests.el, which is in the
> staging area?  I would have thought some variety of `git diff' ought to
> do the trick, but how to do this is not made obvious in the fine manual
> for `git diff'.

git diff --cached (or --staged, it's a synonym)

It's pretty easy to find out in the output of 'man git diff' on my 
system. Not sure what manual you've been reading.

Re: Stupid git!

[Alan Mackenzie]

Hello, Dmitry.

On Sat, Sep 12, 2015 at 01:40:03PM +0300, Dmitry Gutov wrote:
> On 09/12/2015 01:15 PM, Alan Mackenzie wrote:

> > Having "staged" a change with `git add', I then tried to commit it with
> > `git commit'.  Somebody else had got in before me, so I had to pull
> > their changes first - fair enough.

> I don't get it. This sounds like the commit failed because someone has 
> pushed to master in the upstream repo first. Which obviously can't 
> happen because git doesn't have "bound branches" a la Bazaar.

Sorry, I got confused.  I thought I'd only half-committed the change
(with `git add'), whereas I had in fact fully committed it.

> But in general, you either 'git stage' and then 'git pull', or 'git 
> add', 'git commit' (!), and then either rebase or merge upstream.

It's when first doing `git add', then `git pull' when I've lost changes
before.

> The fact that git allows pulling after 'git add' sounds like a bug to 
> me, but apparently it sort-of fine because you can do two-way merge, or 
> even abort the merge and return to the previous state.

I've always done a final `git pull' before committing in the past, so as
to avoid merges as far as possible.  This is what has lost me changes.

> > So I did `git pull'.  I was then dumped into an editing session for a
> > merge operation for .../test/automated/file-notify-tests.el.  Eh?  I've
> > never touched this file in my life, and didn't even know it existed.  So
> > why is a merge necessary/why has a merge been (half-)done?  Why didn't
> > git pull simply merge the changes to this file into my repository and
> > working directory?

> Was there a conflict in this file, or not? If yes, you can see the 
> diverging changes. If not, then you don't need to merge it at all, just 
> resolve the conflicts.

There were no conflicts, just the other contributer's changes that my
`git pull' had pulled.

> How were you even "dumped into an editing session"? What tool did that?

git did, on my `git pull'.  I think I can see what happened now - when
there's a pending push already committed, git refuses to merge in even
unrelated changes.  Instead it merged the file in my working directory,
leaving me to commit it.  I'm not sure why.

> > So I aborted this merge operation, in order to see what it's doing
> > first.  git has kindly discarded my (staged) change, leaving no record
> > of its existence - good job I've still got a copy of the changed file in
> > Emacs.

> That might be a good subject for a bug report.

That was my mistake: the commit had already been fully committed, not
just half committed like I'd thought.

> > How do I see what changes are in file-notify-tests.el, which is in the
> > staging area?  I would have thought some variety of `git diff' ought to
> > do the trick, but how to do this is not made obvious in the fine manual
> > for `git diff'.

> git diff --cached (or --staged, it's a synonym)

OK, thanks!

> It's pretty easy to find out in the output of 'man git diff' on my 
> system. Not sure what manual you've been reading.

It's not easy at all - I've got the collected edition of git man pages
in an info file.  The one for git diff is 1036 lines long.  I tried
searching for "index" and "staging", to no avail - I think I stopped the
search after getting beyond the OPTIONS section.  Now that I know that
"--cached" is the answer, that is specified in the EXAMPLES section.
"--staged" doesn't appear at all.

Anyhow, I used --staged to look at the file.  Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stupid git!

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> It's not easy at all - I've got the collected edition of git man pages
> in an info file.  The one for git diff is 1036 lines long.

Well, the conversion to Texinfo from AsciiDoc is understandably worse in
quality with regard to indices and references than stuff written
originally in Texinfo.

I still prefer that version (and you'll find that the "make info" target
is pretty much my doing).

-- 
David Kastrup

Re: Stupid git!

[Alan Mackenzie]

Hello, David.

On Sat, Sep 12, 2015 at 02:34:43PM +0200, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > It's not easy at all - I've got the collected edition of git man pages
> > in an info file.  The one for git diff is 1036 lines long.

> Well, the conversion to Texinfo from AsciiDoc is understandably worse in
> quality with regard to indices and references than stuff written
> originally in Texinfo.

But a good deal better than struggling through lots of individual man
pages.

> I still prefer that version (and you'll find that the "make info" target
> is pretty much my doing).

:-)  I take my hat off to you, sir!

> -- 
> David Kastrup

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stupid git!

[Dmitry Gutov]

On 09/12/2015 03:29 PM, Alan Mackenzie wrote:

> Sorry, I got confused.  I thought I'd only half-committed the change
> (with `git add'), whereas I had in fact fully committed it.

Then you were simply doing a merge, which is the second step of 'git 
pull' ('git fetch' + 'git merge').

> It's when first doing `git add', then `git pull' when I've lost changes
> before.

Is this about some other, older situation?

>> The fact that git allows pulling after 'git add' sounds like a bug to
>> me, but apparently it sort-of fine because you can do two-way merge, or
>> even abort the merge and return to the previous state.
>
> I've always done a final `git pull' before committing in the past, so as
> to avoid merges as far as possible.  This is what has lost me changes.

That's inadvisable: one is most likely to lose changed by not committing 
them.

Committing before pull is the Git Way.

'git pull --rebase' can also be used if you want cleaner history, but 
judiciously: if you're absolutely sure that none of the new commits on 
the current branch have ever been published (pushed to the remote). So 
don't rebase if you've done any merges, just accept the default behavior 
of 'git pull'.

>> Was there a conflict in this file, or not? If yes, you can see the
>> diverging changes. If not, then you don't need to merge it at all, just
>> resolve the conflicts.
>
> There were no conflicts, just the other contributer's changes that my
> `git pull' had pulled.

Then you didn't need to open it, just needed to resolve any remaining 
conflicts (in other files), then type 'git commit'.

>> How were you even "dumped into an editing session"? What tool did that?
>
> git did, on my `git pull'.

I'm pretty sure Git launches $EDITOR only when asking the user for the 
commit message.

> I think I can see what happened now - when
> there's a pending push already committed, git refuses to merge in even
> unrelated changes.

That's implausible. If you could write a sample scenario step by step 
using two local repos, one close of another, we'll discuss this further.

> Instead it merged the file in my working directory,
> leaving me to commit it.  I'm not sure why.

Maybe you have '--no-commit' somewhere in your .gitconfig.

> It's not easy at all - I've got the collected edition of git man pages
> in an info file.  The one for git diff is 1036 lines long.

Why don't you check out the original man page, too? Do you have it 
installed?

> I tried
> searching for "index" and "staging", to no avail - I think I stopped the
> search after getting beyond the OPTIONS section.  Now that I know that
> "--cached" is the answer, that is specified in the EXAMPLES section.
> "--staged" doesn't appear at all.

In my git-diff man page (that comes with Git 2.1.0), the examples 
section is at the top (it's called DESCRIPTION). The third paragraph 
both includes the words "staged changes" and "--staged":

    git diff [--options] --cached [<commit>] [--] [<path>...]
      This form is to view the changes you staged for the next commit
      relative to the named <commit>. Typically you would want comparison
      with the latest commit, so if you do not give <commit>, it defaults
      to HEAD. If HEAD does not exist (e.g. unborn branches) and <commit>
      is not given, it shows all staged changes. --staged is a synonym of
      --cached.

Re: Stupid git!

[Steinar Bang]

>>>>> Alan Mackenzie <acm@muc.de>:

>> But in general, you either 'git stage' and then 'git pull', or 'git 
>> add', 'git commit' (!), and then either rebase or merge upstream.

> It's when first doing `git add', then `git pull' when I've lost changes
> before.

It happens sometimes, when you stash files that have been staged with
"git add".

It happened to me once (when I was trying to disprove Alan's claims
earlier) but I have been unable to reproduce it since.

If someone can get a reproducible case, it would be a good idea to make
a bug report with the case to git.

Re: Stupid git!

[Stefan Monnier]

> The fact that git allows pulling after 'git add' sounds like a bug to me,

In my experience, git allows pulling before as well as after "git add".
The main restriction is that it doesn't let you pull/merge if one of the
locally modified files has also been modified in the pulled/merge code.


        Stefan

Re: Stupid git!

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Emacs.
>
> git has struck again, and another couple of hours valuable time have
> been lost.
>
> Having "staged" a change with `git add', I then tried to commit it with
> `git commit'.  Somebody else had got in before me, so I had to pull
> their changes first - fair enough.

Uh, no?  git commit goes to your local repository.  There is nobody else
who could "get in before you".  You never need to pull before
committing.  You may want to rebase after pulling, depending on your
kind of change.

> So I aborted this merge operation, in order to see what it's doing
> first.  git has kindly discarded my (staged) change, leaving no record
> of its existence - good job I've still got a copy of the changed file
> in Emacs.  Scrabbling around in the .git directory, I found the commit
> message in a file there.  So all is not lost.
>
> How do I see what changes are in file-notify-tests.el, which is in the
> staging area?

git diff --cached

> Time to save my changed file and have a coffee.  Isn't git wonderful!

When things start looking fishy, don't just stumble on blindly.  Save
what you got somewhere else, and _then_ try muddling through.  That's
not particular to Git.

-- 
David Kastrup

Re: Stupid git!

[Dmitry Gutov]

On 09/12/2015 01:40 PM, David Kastrup wrote:

> When things start looking fishy, don't just stumble on blindly.  Save
> what you got somewhere else, and _then_ try muddling through.

And in the case of Git, you don't even need to go "somewhere else". 
Committing changes is a safe way to remember them. Even if you commit 
them to master, and then do something unsafe like rebase or 'reset 
--hard', 'git reflog' will still allow you to find any commit previously 
created in this local repository.

Re: Stupid git!

[Alan Mackenzie]

Hello, David.

On Sat, Sep 12, 2015 at 12:40:20PM +0200, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hello, Emacs.

> > git has struck again, and another couple of hours valuable time have
> > been lost.

> > Having "staged" a change with `git add', I then tried to commit it with
> > `git commit'.  Somebody else had got in before me, so I had to pull
> > their changes first - fair enough.

> Uh, no?  git commit goes to your local repository.  There is nobody else
> who could "get in before you".  You never need to pull before
> committing.  You may want to rebase after pulling, depending on your
> kind of change.

My mistake.  I'd committed the change, then tried to push it.  Sorry
about that.

> > So I aborted this merge operation, in order to see what it's doing
> > first.  git has kindly discarded my (staged) change, leaving no record
> > of its existence - good job I've still got a copy of the changed file
> > in Emacs.  Scrabbling around in the .git directory, I found the commit
> > message in a file there.  So all is not lost.

> > How do I see what changes are in file-notify-tests.el, which is in the
> > staging area?

> git diff --cached

Thanks!

> > Time to save my changed file and have a coffee.  Isn't git wonderful!

> When things start looking fishy, don't just stumble on blindly.  Save
> what you got somewhere else, and _then_ try muddling through.  That's
> not particular to Git.

Not totally, no.

> -- 
> David Kastrup

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stupid git!

[Giuseppe Scrivano]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Emacs.
>
> git has struck again, and another couple of hours valuable time have
> been lost.
>
> Having "staged" a change with `git add', I then tried to commit it with
> `git commit'.  Somebody else had got in before me, so I had to pull
> their changes first - fair enough.
>
> So I did `git pull'.  I was then dumped into an editing session for a
> merge operation for .../test/automated/file-notify-tests.el.  Eh?  I've
> never touched this file in my life, and didn't even know it existed.  So
> why is a merge necessary/why has a merge been (half-)done?  Why didn't
> git pull simply merge the changes to this file into my repository and
> working directory?

are you working and pulling on the same branch?  Have you used --rebase
to pull to apply your commits after you pulled all the changes from the
remote repository?

Regards,
Giuseppe

Re: Stupid git!

[Alan Mackenzie]

Hello, Giuseppe.

On Sat, Sep 12, 2015 at 01:45:38PM +0200, Giuseppe Scrivano wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hello, Emacs.
> >
> > git has struck again, and another couple of hours valuable time have
> > been lost.
> >
> > Having "staged" a change with `git add', I then tried to commit it with
> > `git commit'.  Somebody else had got in before me, so I had to pull
> > their changes first - fair enough.
> >
> > So I did `git pull'.  I was then dumped into an editing session for a
> > merge operation for .../test/automated/file-notify-tests.el.  Eh?  I've
> > never touched this file in my life, and didn't even know it existed.  So
> > why is a merge necessary/why has a merge been (half-)done?  Why didn't
> > git pull simply merge the changes to this file into my repository and
> > working directory?

> are you working and pulling on the same branch?

Yes.

> Have you used --rebase to pull to apply your commits after you pulled
> all the changes from the remote repository?

No, I didn't.  I should have done.  I don't think there are any
disadvantages to doing so.

> Regards,
> Giuseppe

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stupid git!

[Andreas Schwab]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Giuseppe.
>
> On Sat, Sep 12, 2015 at 01:45:38PM +0200, Giuseppe Scrivano wrote:
>> Have you used --rebase to pull to apply your commits after you pulled
>> all the changes from the remote repository?
>
> No, I didn't.  I should have done.  I don't think there are any
> disadvantages to doing so.

`git config pull.rebase true' to make that the default.

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: Stupid git!

[Eli Zaretskii]

> Date: Sat, 12 Sep 2015 13:02:55 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> > Have you used --rebase to pull to apply your commits after you pulled
> > all the changes from the remote repository?
> 
> No, I didn't.  I should have done.  I don't think there are any
> disadvantages to doing so.

We already considered that around the time we switched to Git, and
decided against it.  The disadvantages you don't see come up when you
are merging from a feature branch, and you have also merged from
master to that branch.

So instead of rebasing we recommend just "git pull", which will merge
the upstream changes with yours.

Re: Stupid git!

[Alan Mackenzie]

Hello, Eli.

On Sat, Sep 12, 2015 at 06:16:51PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 12 Sep 2015 13:02:55 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: emacs-devel@gnu.org

> > > Have you used --rebase to pull to apply your commits after you pulled
> > > all the changes from the remote repository?

> > No, I didn't.  I should have done.  I don't think there are any
> > disadvantages to doing so.

> We already considered that around the time we switched to Git, and
> decided against it.  The disadvantages you don't see come up when you
> are merging from a feature branch, and you have also merged from
> master to that branch.

> So instead of rebasing we recommend just "git pull", which will merge
> the upstream changes with yours.

I just did `git pull'.  This didn't merge the upstream changes into
my repository.  Instead it put the upstream file change into my working
directory, discarding the other contributer's change log.  If I
understand correctly, that is.

I think the best thing for me to do now is `git checkout <file>' to
revert that changed file, then `git pull --rebase' to get the change
again (and likely, quite a few others which have been done since), then
`git push' to get my change into savannah.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stupid git!

[Dmitry Gutov]

On 09/12/2015 11:36 PM, Alan Mackenzie wrote:

> I just did `git pull'.  This didn't merge the upstream changes into
> my repository.  Instead it put the upstream file change into my working
> directory, discarding the other contributer's change log.  If I
> understand correctly, that is.

What does 'git status' say?

> I think the best thing for me to do now is `git checkout <file>' to
> revert that changed file,

If you're in the middle of a merge, it's a recipe for disaster.

Re: Stupid git!

[Alan Mackenzie]

Hello, Dmitry.

On Sat, Sep 12, 2015 at 11:43:43PM +0300, Dmitry Gutov wrote:
> On 09/12/2015 11:36 PM, Alan Mackenzie wrote:

> > I just did `git pull'.  This didn't merge the upstream changes into
> > my repository.  Instead it put the upstream file change into my working
> > directory, discarding the other contributer's change log.  If I
> > understand correctly, that is.

> What does 'git status' say?

On branch master
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commit each, respectively.
  (use "git pull" to merge the remote branch into yours)
All conflicts fixed but you are still merging.
  (use "git commit" to conclude merge)

Changes to be committed:

        modified:   test/automated/file-notify-tests.el

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working
directory)

        modified:   .gitignore
        modified:   lisp/textmodes/paragraphs.el
        modified:   src/search.c


> > I think the best thing for me to do now is `git checkout <file>' to
> > revert that changed file,

> If you're in the middle of a merge, it's a recipe for disaster.

:-).  OK, but the immediate problem is that _I_ didn't modify
file-notify-tests.el.  Somebody else did, and git put his changes into
my working directory and `git add'ed it.  I don't have the log entry for
this change.  So am I supposed to just commit this, with my own log
entry?

I don't really understand what "you are still merging" is supposed to
mean.  How do I get out of the "merging" state cleanly, without
commiting somebody else's changes?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stupid git!

[Sven Axelsson]

On 12 September 2015 at 23:51, Alan Mackenzie <acm@muc.de> wrote:
> Hello, Dmitry.
>
> On Sat, Sep 12, 2015 at 11:43:43PM +0300, Dmitry Gutov wrote:
>> On 09/12/2015 11:36 PM, Alan Mackenzie wrote:
>
>> > I just did `git pull'.  This didn't merge the upstream changes into
>> > my repository.  Instead it put the upstream file change into my working
>> > directory, discarding the other contributer's change log.  If I
>> > understand correctly, that is.
>
>> What does 'git status' say?
>
> On branch master
> Your branch and 'origin/master' have diverged,
> and have 1 and 1 different commit each, respectively.
>   (use "git pull" to merge the remote branch into yours)
> All conflicts fixed but you are still merging.
>   (use "git commit" to conclude merge)
>
> Changes to be committed:
>
>         modified:   test/automated/file-notify-tests.el
>
> Changes not staged for commit:
>   (use "git add <file>..." to update what will be committed)
>   (use "git checkout -- <file>..." to discard changes in working
> directory)
>
>         modified:   .gitignore
>         modified:   lisp/textmodes/paragraphs.el
>         modified:   src/search.c
>
>> > I think the best thing for me to do now is `git checkout <file>' to
>> > revert that changed file,
>
>> If you're in the middle of a merge, it's a recipe for disaster.
>
> :-).  OK, but the immediate problem is that _I_ didn't modify
> file-notify-tests.el.  Somebody else did, and git put his changes into
> my working directory and `git add'ed it.  I don't have the log entry for
> this change.  So am I supposed to just commit this, with my own log
> entry?
>
> I don't really understand what "you are still merging" is supposed to
> mean.  How do I get out of the "merging" state cleanly, without
> commiting somebody else's changes?
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>

`git status` tells you if you are in a merge operation, as you can
see from the message above. To back out and undo all changes
introduced by the merge, you can use `git merge --abort`.

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

Re: Stupid git!

[Alan Mackenzie]

Hello, Sven.

On Sun, Sep 13, 2015 at 08:22:26AM +0200, Sven Axelsson wrote:

> `git status` tells you if you are in a merge operation, as you can
> see from the message above. To back out and undo all changes
> introduced by the merge, you can use `git merge --abort`.

Thanks!  I'll note that down in case I even need it in the future.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stupid git!

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Sven.
>
> On Sun, Sep 13, 2015 at 08:22:26AM +0200, Sven Axelsson wrote:
>
>> `git status` tells you if you are in a merge operation, as you can
>> see from the message above. To back out and undo all changes
>> introduced by the merge, you can use `git merge --abort`.
>
> Thanks!  I'll note that down in case I even need it in the future.

I think that if you have unstaged changes (possibly in files not touched
by the merge) and start a merge (like with git pull or something), then
do git merge --abort this may well get the changes killed for good: git
merge --abort basically has only the index and repository to return to.

I actually don't use git pull much myself: I rather use git fetch and
then decide whether I want to merge or rebase or do whatever.  And then
I can choose just how I want to keep work from getting lost, by stashing
it, or putting it in a branch or whatever else.

Pulling is not a really good thing to do if you have uncommitted work.

-- 
David Kastrup

Re: Stupid git!

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 14 Sep 2015 12:29:37 +0200
> Cc: Sven Axelsson <sven.axelsson@gmail.com>, emacs <emacs-devel@gnu.org>
> 
> Pulling is not a really good thing to do if you have uncommitted work.

I'm doing it all the time, and have yet to report a single problem.

It's the simplest way of minimizing the probability of spurious
merges, when someone else pushes before you.  If you commit then pull,
and someone else pushed in between, you will get that "merged branch
master" thing.

Re: Stupid git!

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Mon, 14 Sep 2015 12:29:37 +0200
>> Cc: Sven Axelsson <sven.axelsson@gmail.com>, emacs <emacs-devel@gnu.org>
>> 
>> Pulling is not a really good thing to do if you have uncommitted work.
>
> I'm doing it all the time, and have yet to report a single problem.
>
> It's the simplest way of minimizing the probability of spurious
> merges, when someone else pushes before you.

Nope.  The simplest way is to git fetch rather than git pull.  Then
nothing at all happens to your work directory and index and you are
completely free to choose your course of action.

> If you commit then pull, and someone else pushed in between, you will
> get that "merged branch master" thing.

It that's not what you want, git pull -r will rebase just fine.

-- 
David Kastrup

Re: Stupid git!

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: acm@muc.de,  sven.axelsson@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 14 Sep 2015 14:28:06 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Kastrup <dak@gnu.org>
> >> Date: Mon, 14 Sep 2015 12:29:37 +0200
> >> Cc: Sven Axelsson <sven.axelsson@gmail.com>, emacs <emacs-devel@gnu.org>
> >> 
> >> Pulling is not a really good thing to do if you have uncommitted work.
> >
> > I'm doing it all the time, and have yet to report a single problem.
> >
> > It's the simplest way of minimizing the probability of spurious
> > merges, when someone else pushes before you.
> 
> Nope.  The simplest way is to git fetch rather than git pull.

How is using 2 commands instead of one, and learning an additional
command, simpler?

> > If you commit then pull, and someone else pushed in between, you will
> > get that "merged branch master" thing.
> 
> It that's not what you want, git pull -r will rebase just fine.

We've concluded long ago that "pull --rebase" is trouble when you
merge from and to feature branches, so I'm trying to stay away of that
path.

Re: Stupid git!

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: acm@muc.de,  sven.axelsson@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 14 Sep 2015 14:28:06 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: David Kastrup <dak@gnu.org>
>> >> Date: Mon, 14 Sep 2015 12:29:37 +0200
>> >> Cc: Sven Axelsson <sven.axelsson@gmail.com>, emacs <emacs-devel@gnu.org>
>> >> 
>> >> Pulling is not a really good thing to do if you have uncommitted work.
>> >
>> > I'm doing it all the time, and have yet to report a single problem.
>> >
>> > It's the simplest way of minimizing the probability of spurious
>> > merges, when someone else pushes before you.
>> 
>> Nope.  The simplest way is to git fetch rather than git pull.
>
> How is using 2 commands instead of one, and learning an additional
> command, simpler?

The "simplest way of minimizing the probability of spurious merges" is
not to execute commands doing possibly unintended merges.  If you insist
on only ever using git pull, it also has an option --ff-only which will
refuse to do anything non-trivial.

>> > If you commit then pull, and someone else pushed in between, you
>> > will get that "merged branch master" thing.
>> 
>> It that's not what you want, git pull -r will rebase just fine.
>
> We've concluded long ago that "pull --rebase" is trouble when you
> merge from and to feature branches, so I'm trying to stay away of that
> path.

That's ridiculous.  What we have concluded is that setting --rebase as a
default was not likely a good idea because of feature branches.  But it
is quite absurd not to use the option for those cases where you indeed
want a rebase instead of a merge commit.

There is a reason it is available as a command line option and not just
as a configuration variable.

-- 
David Kastrup

Re: Stupid git!

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: acm@muc.de,  sven.axelsson@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 14 Sep 2015 14:47:15 +0200
> 
> >> >> Pulling is not a really good thing to do if you have uncommitted work.
> >> >
> >> > I'm doing it all the time, and have yet to report a single problem.
> >> >
> >> > It's the simplest way of minimizing the probability of spurious
> >> > merges, when someone else pushes before you.
> >> 
> >> Nope.  The simplest way is to git fetch rather than git pull.
> >
> > How is using 2 commands instead of one, and learning an additional
> > command, simpler?
> 
> The "simplest way of minimizing the probability of spurious merges" is
> not to execute commands doing possibly unintended merges.

If your recipe would have been "don't use pull", it would have been
simpler.  But that's not what it says, it says "use fetch and merge
instead", which is definitely not simpler.

> If you insist on only ever using git pull, it also has an option
> --ff-only which will refuse to do anything non-trivial.

At the cost of having to learn the option.  Not simpler.

> >> > If you commit then pull, and someone else pushed in between, you
> >> > will get that "merged branch master" thing.
> >> 
> >> It that's not what you want, git pull -r will rebase just fine.
> >
> > We've concluded long ago that "pull --rebase" is trouble when you
> > merge from and to feature branches, so I'm trying to stay away of that
> > path.
> 
> That's ridiculous.  What we have concluded is that setting --rebase as a
> default was not likely a good idea because of feature branches.  But it
> is quite absurd not to use the option for those cases where you indeed
> want a rebase instead of a merge commit.

It's not absurd when you take muscle memory into consideration.  We
are talking here about routine operations (since you don't know in
advance whether a pull will cause conflicts or a need to merge), not
about an option to be used in specific rare circumstances.

Re: Stupid git!

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: acm@muc.de,  sven.axelsson@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 14 Sep 2015 14:47:15 +0200
>> 
>> >> >> Pulling is not a really good thing to do if you have uncommitted work.
>> >> >
>> >> > I'm doing it all the time, and have yet to report a single problem.
>> >> >
>> >> > It's the simplest way of minimizing the probability of spurious
>> >> > merges, when someone else pushes before you.
>> >> 
>> >> Nope.  The simplest way is to git fetch rather than git pull.
>> >
>> > How is using 2 commands instead of one, and learning an additional
>> > command, simpler?
>> 
>> The "simplest way of minimizing the probability of spurious merges" is
>> not to execute commands doing possibly unintended merges.
>
> If your recipe would have been "don't use pull", it would have been
> simpler.  But that's not what it says, it says "use fetch and merge
> instead", which is definitely not simpler.
>
>> If you insist on only ever using git pull, it also has an option
>> --ff-only which will refuse to do anything non-trivial.
>
> At the cost of having to learn the option.  Not simpler.
>
>> >> > If you commit then pull, and someone else pushed in between, you
>> >> > will get that "merged branch master" thing.
>> >> 
>> >> It that's not what you want, git pull -r will rebase just fine.
>> >
>> > We've concluded long ago that "pull --rebase" is trouble when you
>> > merge from and to feature branches, so I'm trying to stay away of that
>> > path.
>> 
>> That's ridiculous.  What we have concluded is that setting --rebase as a
>> default was not likely a good idea because of feature branches.  But it
>> is quite absurd not to use the option for those cases where you indeed
>> want a rebase instead of a merge commit.
>
> It's not absurd when you take muscle memory into consideration.  We
> are talking here about routine operations (since you don't know in
> advance whether a pull will cause conflicts or a need to merge), not
> about an option to be used in specific rare circumstances.

The simplest option taking muscle memory into account is throwing the
computer against the wall.  If you are not interested in actually
achieving the objective ("minimizing the probability of spurious
merges"), that seems by far the simplest action.

I just don't see the point in discussing the simplest action you can
take without actually achieving the objective at the same point of time.

-- 
David Kastrup

Re: Stupid git!

[Stefan Monnier]

> I think that if you have unstaged changes (possibly in files not touched
> by the merge) and start a merge (like with git pull or something), then
> do git merge --abort this may well get the changes killed for good: git
> merge --abort basically has only the index and repository to return to.

I don't think this problem exists: the merge code never tries to merge
changes into local uncommitted changes (staged or not).  The merge
doesn't even start if a file has both uncommitted changes and incoming
changes.


        Stefan


PS: At least that's my experience, based on looking for ways to do
exactly that, since I like to live dangerously and would be really happy
if git let me do this.  Instead I wrote a "git-merge-force" script which
does stash+merge+unstash, with the major downside that the stash+unstash
ends up "touch"ing all the locally modified files.  So if I have many of
them and the merge only touches a could files, that's a lot of wasted
work in the subsequent "make".

Re: Stupid git!

[Eli Zaretskii]

> Date: Sat, 12 Sep 2015 21:51:14 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, gscrivano@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > What does 'git status' say?
> 
> On branch master
> Your branch and 'origin/master' have diverged,
> and have 1 and 1 different commit each, respectively.
>   (use "git pull" to merge the remote branch into yours)
> All conflicts fixed but you are still merging.
>   (use "git commit" to conclude merge)
> 
> Changes to be committed:
> 
>         modified:   test/automated/file-notify-tests.el
> 
> Changes not staged for commit:
>   (use "git add <file>..." to update what will be committed)
>   (use "git checkout -- <file>..." to discard changes in working
> directory)
> 
>         modified:   .gitignore
>         modified:   lisp/textmodes/paragraphs.el
>         modified:   src/search.c
> 
> 
> > > I think the best thing for me to do now is `git checkout <file>' to
> > > revert that changed file,
> 
> > If you're in the middle of a merge, it's a recipe for disaster.
> 
> :-).  OK, but the immediate problem is that _I_ didn't modify
> file-notify-tests.el.  Somebody else did, and git put his changes into
> my working directory and `git add'ed it.

That's what happens when there are merge conflicts: Git suspends the
merge in its middle.

> I don't have the log entry for this change.  So am I supposed to
> just commit this, with my own log entry?

Commit everything in one go, with "git commit", and give it a single
log entry, something like "resolve merge conflicts".

> I don't really understand what "you are still merging" is supposed to
> mean.  How do I get out of the "merging" state cleanly, without
> commiting somebody else's changes?

You _must_ commit.  A successful merge in Git always ends in a commit,
and in this case you need to do it manually, because the automatic
merge failed due to diverging.

Re: Stupid git!

[Alan Mackenzie]

Hello, Eli.

On Sun, Sep 13, 2015 at 09:49:43AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 12 Sep 2015 21:51:14 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, gscrivano@gnu.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> > > If you're in the middle of a merge, it's a recipe for disaster.

> > :-).  OK, but the immediate problem is that _I_ didn't modify
> > file-notify-tests.el.  Somebody else did, and git put his changes into
> > my working directory and `git add'ed it.

> That's what happens when there are merge conflicts: Git suspends the
> merge in its middle.

Yes.  I had misunderstood "conflict".  I had thought it meant a merge
conflict in some file, whereas it just meant that other, possibly
unrelated, changes had taken place.

> > I don't have the log entry for this change.  So am I supposed to
> > just commit this, with my own log entry?

Acutally, I did have this log entry, but `git log' didn't display it.  It
needed `git log --all' to see it.

> Commit everything in one go, with "git commit", and give it a single
> log entry, something like "resolve merge conflicts".

Thanks, I've done this.

> > I don't really understand what "you are still merging" is supposed to
> > mean.  How do I get out of the "merging" state cleanly, without
> > commiting somebody else's changes?

> You _must_ commit.  A successful merge in Git always ends in a commit,
> and in this case you need to do it manually, because the automatic
> merge failed due to diverging.

OK.  I suppose there's a good reason for git aborting the merge rather
than completing it in the obvious manner, but I can't see it at the
moment.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stupid git!

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Yes.  I had misunderstood "conflict".  I had thought it meant a merge
 > conflict in some file, whereas it just meant that other, possibly
 > unrelated, changes had taken place.

No, "conflict" means that there are conflicts in a file so that the
expected outcome of the merge is indeterminate, just like every other
VCS.  There could be a bug in git's implementation, but this
terminology is standard in git as in other VCSes.

Re: Stupid git!

[Dmitry Gutov]

On 09/13/2015 12:51 AM, Alan Mackenzie wrote:

> On branch master
> Your branch and 'origin/master' have diverged,
> and have 1 and 1 different commit each, respectively.
>    (use "git pull" to merge the remote branch into yours)
> All conflicts fixed but you are still merging.
>    (use "git commit" to conclude merge)

I think what Git says here is pretty transparent: commit to conclude the 
merge.

> :-).  OK, but the immediate problem is that _I_ didn't modify
> file-notify-tests.el.  Somebody else did, and git put his changes into
> my working directory and `git add'ed it.

Yes, it did. Have you done any non-trivial merges before? That's how 
they usually look.

The merge commit shouldn't, generally, include any non-mergy changes, so 
you're not expected to stage any of the files you've been working on, 
before committing.

> I don't have the log entry for
> this change.  So am I supposed to just commit this, with my own log
> entry?

The log entry should describe the merge (you could leave the default 
message there, unless it's necessary to add more info).

> I don't really understand what "you are still merging" is supposed to
> mean.  How do I get out of the "merging" state cleanly, without
> commiting somebody else's changes?

The merge commit is *supposed to* include all the changes that have been 
merged in. If you take it upon yourself to remove those changes from the 
staging area, as a result Emacs won't include them, and it won't be 
obvious to most of the people who read emacs-diffs, and then someone 
will have to find out the hard way that something's missing.

Re: Stupid git!

[Stephen J. Turnbull]

Dmitry Gutov writes:
 > On 09/13/2015 12:51 AM, Alan Mackenzie wrote:

 > > :-).  OK, but the immediate problem is that _I_ didn't modify
 > > file-notify-tests.el.  Somebody else did, and git put his changes into
 > > my working directory and `git add'ed it.
 > 
 > Yes, it did. Have you done any non-trivial merges before? That's how 
 > they usually look.

@Dmitry: Weren't you here for the last "git is a screw" thread?  Yes,
he's seen this before.  He doesn't understand it yet.

@Alan:  In "DAGgy" systems that emphasize branching[1], the first step in
a "pull" to include external changes is to fetch them.  The changes are
stored in the local database and constitute a complete tree including all
your commits as well as those fetched from the other repo, but the
workspace doesn't change during the fetch.

Next the system conducts the merge.  Conceptually, the VCS traces each
branch back to a common ancestor, and checks that version out into the
workspace.  Then it applies your commits[2] and those of the external
branch to each file.  For each file with changes, if there are no
lines in common between your changes and the outside changes, the file
is marked "done".  If a conflict exists, the file is marked "pending".

Note that since no commit has take place but both branch's changes
have been applied, the other branch's changes will be present in your
workspace, as files needing commit (or conflicts).  This is normal,
and occurs in all DAGgy VCSes, including bzr.  What may differ is how
the situation is reported.

 > The merge commit shouldn't, generally, include any non-mergy changes, so 
 > you're not expected to stage any of the files you've been working on, 
 > before committing.

@Dmitry: I have no idea what you mean by this, especially not in the
context of helping someone who probably thinks[3] of a merge as
equivalent to

    git fetch origin
    git diff last-synced-rev > /tmp/patch
    git reset --hard origin/master
    patch -p1 < /tmp/patch

(that's my guess because that's like what CVS does, except that CVS's
patch is actually "git diff last-synced-rev origin/master" applied to
the current workspace).

@Alan: Back to the merge process.  After the process above, git does
the equivalent of

    if test -z "$CONFLICTED_FILES"; then
        git commit -m "Merge from origin/master."
    fi

Other systems (hg, bzr) require an explicit commit here, because
"review after commit and uncommit if bad" is philosophically
distasteful, so they recommend a careful review before committing a
merge.  git's philosophy is that if on review, you don't like the
commit, you can just reset to a commit you do like, with or without
reverting the the workspace.  (Of course you shouldn't do this after
pushing the merge commit!)

 > > I don't have the log entry for this change.  So am I supposed to
 > > just commit this, with my own log entry?
 > 
 > The log entry should describe the merge (you could leave the default 
 > message there, unless it's necessary to add more info).

There should be a file in .git/ named "MERGE_MSG" or something like
that with a preformatted message you can use with the -F option.
Lines beginning with "#" are comments, and stripped from the message
actually used.  In most cases, something like "merge from
origin/master" is sufficient.  If you found that you had to do "real
work" to resolve a conflict, that should be described here too.  Most
of the time conflicts are trivial, though (eg, somebody fixed a typo
in a comment you changed to reflect reality), and that kind of change
doesn't need to be mentioned, or can be disposed of en masse with
"fixed trivial conflicts."

 > > I don't really understand what "you are still merging" is
 > > supposed to mean.

It means that the workspace has not yet been committed to the
repository, and that you need to resolve any remaining conflicts
before git will allow you to commit.

 > > How do I get out of the "merging" state cleanly, without
 > > commiting somebody else's changes?
 > 
 > The merge commit is *supposed to* include all the changes that have
 > been merged in.

@Dmitry: This probably doesn't help Alan because his mental model of
merging differs from what git is reporting.  Alan seems to be thinking
of the post-merge commit as recording a diff of his workspace against
current upstream master.  The changes on master should *already be
there* (in some sense), and it doesn't make sense to Alan that changes
that are already in master are reported as changes in *his* workspace.

@Alan: But git doesn't think of master as "canonical" or whatever.
git puts your changes on an equal footing with the changes in master,
and so reports *all* changes on *both* branches since last-synced-rev.
Those files that were successfully merged from either branch will
already be in the "to be committed" list.  You primarily care about
the "conflicted" files.  You should also check "your" files to make
sure they all make sense -- in particular, other people may have made
changes to "your" files that conflict with what you're doing
semantically, but not syntactically.  If one of "your" files is listed
but you didn't change it, that should be a red flag.  (Of course I'm
sure you also review the diff, and should see it there.  Call YAGNI if
you like on this "feature".)  But you can ignore all the "other"
files, unless they're conflicted -- in that case something is odd in
*your* pre-merge workspace, because git thinks you changed that file
but you don't remember doing so.

(To be precise, git doesn't commit diffs, it commits snapshots of
workspaces.  To git, your workspace after merge is just a snapshot
that hasn't yet been recorded in the DAG.  From git's point of view,
there is no diff, only the revisions and the parent-child
relationships among them.  "diff" is a derived concept that humans
find useful in thinking about traversing the DAG, not a fundamental
part of the git machinery.[4]  But you may not need to think about
this; it may be sufficient to think of git as "unnecessarily" --
"stupidly", if you like -- reporting all changes since
last-synced-rev.)


Footnotes: 
[1]  These systems include git and hg.  bzr is also DAGgy, but it's
schizoid about branching.  It can be operated in a mode that tries to
hide the fact that multiple branches are present in your local repo
as much as possible, giving a UX like CVS and Subversion where
branches exist only in the server.

[2]  Note that this process implies you will lose any changes that you
haven't committed -- that's why it's best practice to be "committed up"
before merging.

[3]  @Alan: Here and below I am *guessing* what you think in order to
phrase things consistently with what you think is happening, or what I
call your "model" of the merge process.  I'm not telling you what to
think, I'm trying to give you a reference point to understand what I'm
saying.  If I'm wrong, but close enough, good.  If not, tell me where
I'm wrong and maybe I can come up with a better way to express what's
actually happening and how to interpret what you are seeing.

[4]  Of course git provides the "diff" subcommand, and uses "diff
compression" when packing objects.  But neither is necessary to the
fundamental processes of commit and checkout.

Re: Stupid git!

[Dmitry Gutov]

On 09/14/2015 06:11 AM, Stephen J. Turnbull wrote:

> @Dmitry: Weren't you here for the last "git is a screw" thread?  Yes,
> he's seen this before.  He doesn't understand it yet.

It was Richard's thread, and it was quite a while ago. Plenty of time to 
learn and play around.

>   > The merge commit shouldn't, generally, include any non-mergy changes, so
>   > you're not expected to stage any of the files you've been working on,
>   > before committing.
>
> @Dmitry: I have no idea what you mean by this, especially not in the
> context of helping someone who probably thinks[3] of a merge as
> equivalent to

I have a feeling that a person that did 'git add xyz' before 'git pull' 
might try to make xyz a part of the ensuing merge commit. They shouldn't 
do that.

> There should be a file in .git/ named "MERGE_MSG" or something like
> that with a preformatted message you can use with the -F option.

'git commit' will pre-fill it for you automatically.

Re: Stupid git!

[Alan Mackenzie]

Hello, Dmitry.

On Sun, Sep 13, 2015 at 11:28:25PM +0300, Dmitry Gutov wrote:
> On 09/13/2015 12:51 AM, Alan Mackenzie wrote:

> > On branch master
> > Your branch and 'origin/master' have diverged,
> > and have 1 and 1 different commit each, respectively.
> >    (use "git pull" to merge the remote branch into yours)
> > All conflicts fixed but you are still merging.
> >    (use "git commit" to conclude merge)

> I think what Git says here is pretty transparent: commit to conclude the 
> merge.

What confused me is that git aborted the merge despite there being no
conflicts (i.e., nothing requiring the use of an editor to resolve).
git could quite easily have just completed the merge itself instead of
aborting it then requiring me to take mechanical actions to complete it.

> > :-).  OK, but the immediate problem is that _I_ didn't modify
> > file-notify-tests.el.  Somebody else did, and git put his changes into
> > my working directory and `git add'ed it.

> Yes, it did. Have you done any non-trivial merges before? That's how 
> they usually look.

No, I've never done a non-trivial merge in git.  This one presumably
must count as a trivial merge.

> The merge commit shouldn't, generally, include any non-mergy changes, so 
> you're not expected to stage any of the files you've been working on, 
> before committing.

I take it that by "shouldn't .. include include .. non-mergy changes"
you mean that when initiating a merge commit, git won't include any
non-merge changes in the commit.  (The alternative interpretation is
that in a merge commit, the user shouldn't include any other changes.)

> > I don't have the log entry for
> > this change.  So am I supposed to just commit this, with my own log
> > entry?

> The log entry should describe the merge (you could leave the default 
> message there, unless it's necessary to add more info).

I did actually have this log entry, but `git log' didn't display it.
The flag --all was needed for that.

> > I don't really understand what "you are still merging" is supposed to
> > mean.  How do I get out of the "merging" state cleanly, without
> > commiting somebody else's changes?

> The merge commit is *supposed to* include all the changes that have been 
> merged in. If you take it upon yourself to remove those changes from the 
> staging area, as a result Emacs won't include them, and it won't be 
> obvious to most of the people who read emacs-diffs, and then someone 
> will have to find out the hard way that something's missing.

OK, I've got it now.  For some reason, git choses to abort the merge,
despite there being no conflicts between the changes from upstream and
the changes I've committed locally - indeed, to complete the merge is a
fully mechanical action, `git commit'.  This seeming illogicality is
what confused me in the first place.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Stupid git!

[Eli Zaretskii]

> Date: Mon, 14 Sep 2015 11:09:20 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, gscrivano@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > The merge commit is *supposed to* include all the changes that have been 
> > merged in. If you take it upon yourself to remove those changes from the 
> > staging area, as a result Emacs won't include them, and it won't be 
> > obvious to most of the people who read emacs-diffs, and then someone 
> > will have to find out the hard way that something's missing.
> 
> OK, I've got it now.  For some reason, git choses to abort the merge,
> despite there being no conflicts between the changes from upstream and
> the changes I've committed locally - indeed, to complete the merge is a
> fully mechanical action, `git commit'.  This seeming illogicality is
> what confused me in the first place.

I think this was because you did a "git add" before pulling.  But I'm
not sure.  (I almost never use "git add", except when adding new
files.)

Re: Stupid git!

[Dmitry Gutov]

Hi Alan,

On 09/14/2015 02:09 PM, Alan Mackenzie wrote:

> What confused me is that git aborted the merge despite there being no
> conflicts (i.e., nothing requiring the use of an editor to resolve).

Indeed, I don't usually see that. Hence my question about --no-commit in 
your gitconfig.

But others' suggestion that it might be because of 'git add' beforehand 
is also plausible. I never do that, because it makes little sense.

>> Yes, it did. Have you done any non-trivial merges before? That's how
>> they usually look.
>
> No, I've never done a non-trivial merge in git.  This one presumably
> must count as a trivial merge.

I any case, a merge with maybe just one tiny conflict, looks similar to 
this if there are also non-conflicting changes in it: it shows you 
staged changes from files *you* didn't modify.

> I take it that by "shouldn't .. include include .. non-mergy changes"
> you mean that when initiating a merge commit, git won't include any
> non-merge changes in the commit.  (The alternative interpretation is
> that in a merge commit, the user shouldn't include any other changes.)

Kinda both.

It means that you shouldn't 'git add' any changes that you've worked on 
just now, before committing. Leave them for a following, non-merge commit.

> I did actually have this log entry, but `git log' didn't display it.
> The flag --all was needed for that.

Apparently, you will be able to see the log entries for the commits 
you're merging, after you conclude the merge, and so the current branch 
includes them. Makes sense, doesn't it?

> OK, I've got it now.  For some reason, git choses to abort the merge,
> despite there being no conflicts between the changes from upstream and
> the changes I've committed locally - indeed, to complete the merge is a
> fully mechanical action, `git commit'.  This seeming illogicality is
> what confused me in the first place.

I agree.

Re: Stupid git!

[Steinar Bang]

>>>>> Dmitry Gutov <dgutov@yandex.ru>:

> Hi Alan,
> On 09/14/2015 02:09 PM, Alan Mackenzie wrote:

>> What confused me is that git aborted the merge despite there being no
>> conflicts (i.e., nothing requiring the use of an editor to resolve).

> Indeed, I don't usually see that.

Actually, I've never seen that.

> Hence my question about --no-commit in your gitconfig.

> But others' suggestion that it might be because of 'git add'
> beforehand is also plausible. I never do that, because it makes little
> sense.

Hm... easy enough to try.

 cd ~/git
 mkdir add-test
 cd add-test
 git init
 echo "Hello" >hello.txt
 git add hello.txt
 git commit -m "Added hello file"
 mkdir ../add-test.git
 cd ../add-test.git
 git init --bare
 cd ../add-test
 git remote add origin ../add-test.git
 git push -u origin HEAD
 cd ..
 git clone ./add-test.git add-test2
 cd add-test
 echo "Hello world!" >hello.txt
 git add hello.txt
 git commit -m "Add a new commit that can be pulled in the other clone"
 git push
 cd ../add-test2
 git add hello.txt
 git pull

Nah... the result of the final command:

~/git/add-test2$ git pull
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From c:/Users/sbang/git/./add-test
   1887bde..446444d  master     -> origin/master
Updating 1887bde..446444d
Fast-forward
 hello.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Ie. no conflict.

~/git/add-test2$ git --version
git version 1.9.4.msysgit.1

I tried a variant with "git add ." before pull, but I got the same
result, ie. no conflict, no merge.

Re: Stupid git!

[Steinar Bang]

>>>>> Alan Mackenzie <acm@muc.de>:
> :-).  OK, but the immediate problem is that _I_ didn't modify
> file-notify-tests.el.  Somebody else did, and git put his changes into
> my working directory and `git add'ed it.  I don't have the log entry for
> this change.

Don't worry about it.  That log message is in the history of
origin/master, and "git log" will display it, and "git blame" will bind
the correct modified lines to the git commit.

The changes you see, are the changes that has been upstream since your
last pull.  Your "incoming changes", so to speak.

> So am I supposed to just commit this, with my own log entry?

Yes, since this is the commit of a merge, git will usually suggest a
message for you.  I usually go with that, and maybe add some comments on
the merges I've resolved.

> I don't really understand what "you are still merging" is supposed to
> mean.

It means that the merge operation in "git pull" needs a "git commit" to
complete. 

> How do I get out of the "merging" state cleanly,

"git commit"

> without commiting somebody else's changes?

You won't be committing somebody else's changes... or rather: you won't
be commiting somebody else's changes in a way that will mess up the git
history (which is something that _may_ happen when rebase is involved)

Re: Stupid git!

[Eli Zaretskii]

> Date: Sat, 12 Sep 2015 20:36:58 +0000
> Cc: gscrivano@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > So instead of rebasing we recommend just "git pull", which will merge
> > the upstream changes with yours.
> 
> I just did `git pull'.  This didn't merge the upstream changes into
> my repository.  Instead it put the upstream file change into my working
> directory, discarding the other contributer's change log.  If I
> understand correctly, that is.

You must be misunderstanding, then, because "git pull" never does that
kind of atrocities.

> I think the best thing for me to do now is `git checkout <file>' to
> revert that changed file, then `git pull --rebase' to get the change
> again (and likely, quite a few others which have been done since), then
> `git push' to get my change into savannah.

Not sure this is the best way.  But if you want to start from a clean
slate, then this is the sequence of commands:

  git checkout <file>
  git status

If the last command says that only that your branch is ahead of
origin/master, then continue:

  git pull

If this causes merge conflicts, resolve them by editing and issuing
"git add" for each file whose conflicts you resolved (Emacs should do
this automatically when you save the file).  Finally:

  git commit
  git pull
  git push

The final "git pull" is for the slim chance that someone pushed to
savannah while you were resolving the conflicts.  If that pull
produces conflicts (highly unlikely), repeat the whole process, and
only then push.