Understanding a recent commit in emacs-25 branch [ed19f2]

Understanding a recent commit in emacs-25 branch [ed19f2]

[Kaushal Modi]

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

Hi Alan,

I was looking at a recent commit:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25&id=ed19f207449c43f7f08285ada87ae7a46c61c8d1

It's a huge commit with lots of changes in many files. But I cannot
completely understand what all changed in that commit. I was looking for
that commit's commit log but I couldn't find one.

Aren't commits in emacs-25 now limited to just bug fixes?

Also as I am not an active contributor, I do not understand the full
implication of such commits. So please forgive any misunderstanding.

--
Kaushal Modi

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

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Kaushal Modi]

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

OK, I think I need some git education.

There was one section in your commit (
http://git.savannah.gnu.org/cgit/emacs.git/diff/lisp/isearch.el?h=emacs-25&id=ed19f207449c43f7f08285ada87ae7a46c61c8d1
) which was already committed earlier (
http://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/isearch.el?h=emacs-25&id=91e667692ba1362ca1334b8d58fd16c305ad5e2a
). As I am familiar with that single commit, I know that they are identical.

Also I noted that your commit has a repeat of all the backquote/straight
quote changes in NEWS that happened recently.

But without this prior knowledge, how can one separate these duplicate
commits from the commits that actually are new?
Also, what is the reason for such duplicate commits happening?

Apologies for this git 101 question here. Please forward me to a resource,
if available, where I can understand such mega commits.

Thanks.

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

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Paul Eggert]

Kaushal Modi wrote:
> OK, I think I need some git education.
>
> There was one section in your commit (
> http://git.savannah.gnu.org/cgit/emacs.git/diff/lisp/isearch.el?h=emacs-25&id=ed19f207449c43f7f08285ada87ae7a46c61c8d1
> ) which was already committed earlier (
> http://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/isearch.el?h=emacs-25&id=91e667692ba1362ca1334b8d58fd16c305ad5e2a
> ). As I am familiar with that single commit, I know that they are identical.
>
> Also I noted that your commit has a repeat of all the backquote/straight
> quote changes in NEWS that happened recently.
>
> But without this prior knowledge, how can one separate these duplicate
> commits from the commits that actually are new?
> Also, what is the reason for such duplicate commits happening?

There aren't any duplicate commits.

When you visit 
http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25&id=ed19f207449c43f7f08285ada87ae7a46c61c8d1 
the website shows you the output of this command:

git diff 
ed19f207449c43f7f08285ada87ae7a46c61c8d1^..ed19f207449c43f7f08285ada87ae7a46c61c8d1

The commit ed19f207449c43f7f08285ada87ae7a46c61c8d1 is a merge with two parents: 
commits eabd667a9584fe5bd2422e296d256dceea67debf (which is a single incomplete 
fix for cc-mode) and 7c1802f6ffc2704ba8042c7c1c6faa73dfa210d1 (which is the main 
thread of the emacs-25 branch). The way Alan merged, the former commit is the 
first parent, so the abovementioned diff output looks large -- it contains many 
emacs-25 changes all squashed together. It might have been nicer if Alan had 
merged the other way, so that that the main thread was the first parent, but 
that's water under the bridge now. (In this particular case I would have avoided 
a merge entirely, and would have rebased instead, as that makes such changes 
easier for others to follow later; but that's also water under the bridge.)

Understanding what happened is somewhat complicated by the more-recent commit 
22443312188ff097b69d9ff4b87c2b4f7bbbc263, which finished fixing the cc-mode 
patch and undid some of the effect of the incomplete fix.

You can see all this more easily by running the shell command "gitk" in a 
directory containing a checked-out copy of the emacs-25 branch.

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Alan Mackenzie]

Hello, Kaushal.

That massive commit happened because of git.  I attempted a 'git pull'
prior to making a (moderately small) commit.  There was a one-letter
typo in one of my existing files (which I think had been committed).
Because of that, git failed to merge in all the stuff which it had just
fetched from savannah, instead prompting me to do a manual merge, which
I then did.

This is a problem with SCM systems.  There is no "undo" for a lot of
operations.  If I had been aware of what was happening, I might have
been able to adjust my copy of the repository somehow so as to avoid
that large merge.

It would also be nice if such "pseudo merges" could be handled locally,
rather than being pushed back to the remote repository, causing
confusion.

On Fri, Apr 01, 2016 at 01:43:16AM -0400, Kaushal Modi wrote:
> OK, I think I need some git education.

Me, too!

> There was one section in your commit (
> http://git.savannah.gnu.org/cgit/emacs.git/diff/lisp/isearch.el?h=emacs-25&id=ed19f207449c43f7f08285ada87ae7a46c61c8d1
> ) which was already committed earlier (
> http://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/isearch.el?h=emacs-25&id=91e667692ba1362ca1334b8d58fd16c305ad5e2a
> ). As I am familiar with that single commit, I know that they are identical.

> Also I noted that your commit has a repeat of all the backquote/straight
> quote changes in NEWS that happened recently.

> But without this prior knowledge, how can one separate these duplicate
> commits from the commits that actually are new?
> Also, what is the reason for such duplicate commits happening?

See above.

> Apologies for this git 101 question here. Please forward me to a resource,
> if available, where I can understand such mega commits.

No apologies needed.  git is a complicated, difficult to learn system.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Andreas Schwab]

Alan Mackenzie <acm@muc.de> writes:

> It would also be nice if such "pseudo merges" could be handled locally,

In git, *all* operations happen locally (until you run git push).

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: Understanding a recent commit in emacs-25 branch [ed19f2]

[Ingo Lohmar]

Hi Alan,

On Sun, Apr 03 2016 11:17 (+0000), Alan Mackenzie wrote:

> That massive commit happened because of git.  I attempted a 'git pull'
> prior to making a (moderately small) commit.  There was a one-letter
> typo in one of my existing files (which I think had been committed).
> Because of that, git failed to merge in all the stuff which it had just
> fetched from savannah, instead prompting me to do a manual merge, which
> I then did.

I think 'git pull' has been discussed on this list before.  Others feel
differently about this issue, but I strongly advise anyone against using
'git pull', and instead suggest you do 'git fetch' (maybe --all).

*After* seeing what has happened to the remote branches, you can decide
whether a merge or a rebase is in order.  Or you spot an unwanted
discrepancy, and can fix it, instead of git telling you to manually
merge (although admittedly I do not quite follow that part).

> It would also be nice if such "pseudo merges" could be handled locally,
> rather than being pushed back to the remote repository, causing
> confusion.

Please note that *all* commits and merges happen locally.  The user can
only push changes back to the remote by an explicit action, with all
intended and unintended effects.

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Dmitry Gutov]

On 04/03/2016 02:17 PM, Alan Mackenzie wrote:

> That massive commit happened because of git.  I attempted a 'git pull'
> prior to making a (moderately small) commit.

It must have been after.

> There was a one-letter
> typo in one of my existing files (which I think had been committed).
> Because of that, git failed to merge in all the stuff which it had just
> fetched from savannah, instead prompting me to do a manual merge, which
> I then did.

You can ask Git not to do that in the future by passing '--ff-only' to 
'git pull'. But then you'll have to learn to rebase.

> If I had been aware of what was happening, I might have
> been able to adjust my copy of the repository somehow so as to avoid
> that large merge.

If you run 'git log --graph' before every time you push and examine the 
output, you can be aware of everything what's happening, as well as undo 
the changes you don't like.

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Alan Mackenzie]

Hello, Paul.

On Thu, Mar 31, 2016 at 11:43:14PM -0700, Paul Eggert wrote:
> Kaushal Modi wrote:
> > OK, I think I need some git education.

> > There was one section in your commit (
> > http://git.savannah.gnu.org/cgit/emacs.git/diff/lisp/isearch.el?h=emacs-25&id=ed19f207449c43f7f08285ada87ae7a46c61c8d1
> > ) which was already committed earlier (
> > http://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/isearch.el?h=emacs-25&id=91e667692ba1362ca1334b8d58fd16c305ad5e2a
> > ). As I am familiar with that single commit, I know that they are identical.

> > Also I noted that your commit has a repeat of all the backquote/straight
> > quote changes in NEWS that happened recently.

> > But without this prior knowledge, how can one separate these duplicate
> > commits from the commits that actually are new?
> > Also, what is the reason for such duplicate commits happening?

> There aren't any duplicate commits.

> When you visit 
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25&id=ed19f207449c43f7f08285ada87ae7a46c61c8d1 
> the website shows you the output of this command:

> git diff 
> ed19f207449c43f7f08285ada87ae7a46c61c8d1^..ed19f207449c43f7f08285ada87ae7a46c61c8d1

> The commit ed19f207449c43f7f08285ada87ae7a46c61c8d1 is a merge with two parents: 
> commits eabd667a9584fe5bd2422e296d256dceea67debf (which is a single incomplete 
> fix for cc-mode) and 7c1802f6ffc2704ba8042c7c1c6faa73dfa210d1 (which is the main 
> thread of the emacs-25 branch). The way Alan merged, the former commit is the 
> first parent, so the abovementioned diff output looks large -- it contains many 
> emacs-25 changes all squashed together. It might have been nicer if Alan had 
> merged the other way, so that that the main thread was the first parent, but 
> that's water under the bridge now. (In this particular case I would have avoided 
> a merge entirely, and would have rebased instead, as that makes such changes 
> easier for others to follow later; but that's also water under the bridge.)

It was git that prepared the merge, not me.  What happened was that the
"more recent" commit 22443312... created a conflict with the commits in
a git pull.  git, rather than aborting the pull operation, splurged the
contents of all the other commits in the pull into my working directory,
saying "Conflict in ....  You need to merge".  I simply merged as
directed.

Is there a better way out of this situation than just merging as
directed?  Can one somehow get out of this partially completed git pull,
then redo it with --rebase?

> Understanding what happened is somewhat complicated by the more-recent commit 
> 22443312188ff097b69d9ff4b87c2b4f7bbbc263, which finished fixing the cc-mode 
> patch and undid some of the effect of the incomplete fix.

This was what created the conflict, I think.

> You can see all this more easily by running the shell command "gitk" in a 
> directory containing a checked-out copy of the emacs-25 branch.

I haven't got gitk.  Is it supposed to be part of the main git
distribution?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Achim Gratz]

Alan Mackenzie writes:
> It was git that prepared the merge, not me.

Blaming the tools?

> What happened was that the
> "more recent" commit 22443312... created a conflict with the commits in
> a git pull.  git, rather than aborting the pull operation, splurged the
> contents of all the other commits in the pull into my working directory,
> saying "Conflict in ....  You need to merge".  I simply merged as
> directed.

Nope, you were supposed to either abort the merge or fix the conflict(s)
and then stage the resulting changes and "git commit" them.

See "git help merge", section "How to resolve conflicts".

> Is there a better way out of this situation than just merging as
> directed?  Can one somehow get out of this partially completed git pull,
> then redo it with --rebase?

git merge --abort

>> Understanding what happened is somewhat complicated by the more-recent commit 
>> 22443312188ff097b69d9ff4b87c2b4f7bbbc263, which finished fixing the cc-mode 
>> patch and undid some of the effect of the incomplete fix.
>
> This was what created the conflict, I think.

And that was the only conflict markers that should have been edited.  It
seems you really did another manual "git merge" with the arguments in
the wrong order instead.

>> You can see all this more easily by running the shell command "gitk" in a 
>> directory containing a checked-out copy of the emacs-25 branch.
>
> I haven't got gitk.  Is it supposed to be part of the main git
> distribution?

Yes, although some distributions have it in a separate package since it
requires Tk.


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

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Alan Mackenzie]

Hello, Ingo.

On Sun, Apr 03, 2016 at 01:40:10PM +0200, Ingo Lohmar wrote:
> Hi Alan,

> On Sun, Apr 03 2016 11:17 (+0000), Alan Mackenzie wrote:

> > That massive commit happened because of git.  I attempted a 'git pull'
> > prior to making a (moderately small) commit.  There was a one-letter
> > typo in one of my existing files (which I think had been committed).
> > Because of that, git failed to merge in all the stuff which it had just
> > fetched from savannah, instead prompting me to do a manual merge, which
> > I then did.

> I think 'git pull' has been discussed on this list before.  Others feel
> differently about this issue, but I strongly advise anyone against using
> 'git pull', and instead suggest you do 'git fetch' (maybe --all).

> *After* seeing what has happened to the remote branches, you can decide
> whether a merge or a rebase is in order.  Or you spot an unwanted
> discrepancy, and can fix it, instead of git telling you to manually
> merge (although admittedly I do not quite follow that part).

Is there a way of asking "if I attempt git merge, will there be any
conflicts?"?  It would be nice to find this out before one's working
directory gets lots of uncommitted changes.

Is there a way of recovering after doing git pull, when git has already
written all the pulled changes to the working directory?  Is there some
way of saying git undo-partial-pull, leaving the working directory as it
was before the pull, and cancelling the merge which git has started?

> > It would also be nice if such "pseudo merges" could be handled locally,
> > rather than being pushed back to the remote repository, causing
> > confusion.

> Please note that *all* commits and merges happen locally.  The user can
> only push changes back to the remote by an explicit action, with all
> intended and unintended effects.

Sorry, I wasn't very clear.  What I meant was, is there a way of
finishing the merge locally, then pushing real changes without the
confusing "pseudo-merge" escaping upstream with them?

When I did git pull, there were, let's say, 20 commits.  19 of these
could have been moved directly into my local repository; only one had a
conflict.  It would be nice to be able to fix the local repo, so that
the "pseudo-merge" of these 19 blameless commits remains a purely local
affair, and doesn't get pushed upstream.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Ingo Lohmar]

Hi Alan,

On Sun, Apr 03 2016 12:03 (+0000), Alan Mackenzie wrote:
>
> It was git that prepared the merge, not me.  What happened was that the
> "more recent" commit 22443312... created a conflict with the commits in
> a git pull.  git, rather than aborting the pull operation, splurged the
> contents of all the other commits in the pull into my working directory,
> saying "Conflict in ....  You need to merge".  I simply merged as
> directed.
>
> Is there a better way out of this situation than just merging as
> directed?  Can one somehow get out of this partially completed git pull,
> then redo it with --rebase?

I am not Paul, but feel competent to answer this.  You can 'git merge
--abort' to return to the previous state.  Then you can 'git rebase
<where-to>', and <where-to> might be sth like 'origin/master'.

But you can avoid all this trouble by not doing 'git pull' in the first
place.  Do 'git fetch --all', and then have a look at 'git log --graph'
as Dmitry suggested (gitk may or may not come with the git package you
use, but the information is essentially the same).

Hope this helps,
Ingo

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Ingo Lohmar]

Hi Alan,

On Sun, Apr 03 2016 12:14 (+0000), Alan Mackenzie wrote:

> Is there a way of asking "if I attempt git merge, will there be any
> conflicts?"?  It would be nice to find this out before one's working
> directory gets lots of uncommitted changes.

Just do the merge, and if you get conflicts that you do not want to
resolve, 'git merge --abort'.

Single caveat: Do NOT start a merge when you have uncommited changes.
If you want, do 'git stash' first to recover them later.

>
> Is there a way of recovering after doing git pull, when git has already
> written all the pulled changes to the working directory?  Is there some
> way of saying git undo-partial-pull, leaving the working directory as it
> was before the pull, and cancelling the merge which git has started?

See above.

> Sorry, I wasn't very clear.  What I meant was, is there a way of
> finishing the merge locally, then pushing real changes without the
> confusing "pseudo-merge" escaping upstream with them?
>
> When I did git pull, there were, let's say, 20 commits.  19 of these
> could have been moved directly into my local repository; only one had a
> conflict.  It would be nice to be able to fix the local repo, so that
> the "pseudo-merge" of these 19 blameless commits remains a purely local
> affair, and doesn't get pushed upstream.

It seems you are confused about some concepts.  The 'fetch' part of
'pull' has already dragged *all* commits into your local repository.
Now the question is about how to merge the branches (say 'master' and
'origin/master').  Here I can no longer follow your explanation.  I have
a feeling you actually want to avoid the merge commit as far as
possible.

In this case, you have to learn about rebase, as in 'git rebase
origin/master'.  This replays your commits (which should be only local)
on top of origin/master.  You will have to fix any conflict in your
commits, and you will end up with a linear history with your commits on
top of those already on origin/master.

Abort a rebase-gone-bad by 'git rebase --abort'.

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Andreas Schwab]

Ingo Lohmar <i.lohmar@gmail.com> writes:

> Single caveat: Do NOT start a merge when you have uncommited changes.

git merge will not allow overwriting uncommited changes anyway.

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: Understanding a recent commit in emacs-25 branch [ed19f2]

[Stefan Monnier]

>> It was git that prepared the merge, not me.
> Blaming the tools?

Yes.  Git makes it all too easy here to create such annoying merge
commits, and if you don't have enough experience with Git you won't
even notice it.

But even if you do notice it, it can be pretty challenging to fix it
after the fact, or to avoid it before the fact.

It's not just that Git is a sharp tool here: in this instance, it makes
it easy to do the wrong thing, and hard to do the right thing.


        Stefan

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> It was git that prepared the merge, not me.
>> Blaming the tools?
>
> Yes.  Git makes it all too easy here to create such annoying merge
> commits, and if you don't have enough experience with Git you won't
> even notice it.
>
> But even if you do notice it, it can be pretty challenging to fix it
> after the fact, or to avoid it before the fact.
>
> It's not just that Git is a sharp tool here: in this instance, it makes
> it easy to do the wrong thing, and hard to do the right thing.

I know I sound like a broken record, but if the UI of git is not
adequate for you then try other UI. I'll suggest Magit, which makes all
those operations trivial to work with. It requires Emacs to run, which
is a fat dependency, but it is worth the disk space IMHO.

The downside is that you might have much less problems with git on the
future, and hence your view about that tool could change a bit and
complain less about it on the ml. You must ponder what causes more
pleasure to you: disparage git or get the job done.

:-)

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Ingo Lohmar]

On Sun, Apr 03 2016 16:12 (+0200), Andreas Schwab wrote:

> Ingo Lohmar <i.lohmar@gmail.com> writes:
>
>> Single caveat: Do NOT start a merge when you have uncommited changes.
>
> git merge will not allow overwriting uncommited changes anyway.
>
> Andreas.

That's correct, but if the changes are in files unaffected by the merge,
git *does* start the merge.  But it will be hard to return to the exact
pre-merge state if you want to abort.

At least that's what everybody and the man page tell me, I can't
remember whether I tested it myself at some point.

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Eli Zaretskii]

> From: Ingo Lohmar <i.lohmar@gmail.com>
> Date: Sun, 03 Apr 2016 14:30:27 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>,
> 	Kaushal Modi <kaushal.modi@gmail.com>
> 
> Single caveat: Do NOT start a merge when you have uncommited changes.
> If you want, do 'git stash' first to recover them later.

I disagree with this caveat.  There's no reason to frighten people
like that, as doing such merges will work most of the time.

> In this case, you have to learn about rebase, as in 'git rebase
> origin/master'.

"git rebase" is a bad idea when merging a long-lived feature branch,
so please don't advise this to users who are evidently not Git
experts.

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Andreas Schwab]

Ingo Lohmar <i.lohmar@gmail.com> writes:

> That's correct, but if the changes are in files unaffected by the merge,
> git *does* start the merge.  But it will be hard to return to the exact
> pre-merge state if you want to abort.

git merge --abort will do.

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: Understanding a recent commit in emacs-25 branch [ed19f2]

[Eli Zaretskii]

> From: Ingo Lohmar <i.lohmar@gmail.com>
> Date: Sun, 03 Apr 2016 16:57:54 +0200
> Cc: Alan Mackenzie <acm@muc.de>, Kaushal Modi <kaushal.modi@gmail.com>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> > git merge will not allow overwriting uncommited changes anyway.
> >
> > Andreas.
> 
> That's correct, but if the changes are in files unaffected by the merge,
> git *does* start the merge.  But it will be hard to return to the exact
> pre-merge state if you want to abort.

Git stops the merge at the point where it's quite easy to abort or
stash the uncommitted changes.  When Git stops, it displays a message
with these 2 alternatives; following either alternative is easy and
safe.

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Ingo Lohmar]

On Sun, Apr 03 2016 18:01 (+0300), Eli Zaretskii wrote:

>> From: Ingo Lohmar <i.lohmar@gmail.com>
>> Date: Sun, 03 Apr 2016 14:30:27 +0200
>> Cc: Emacs developers <emacs-devel@gnu.org>,
>> 	Kaushal Modi <kaushal.modi@gmail.com>
>> 
>> Single caveat: Do NOT start a merge when you have uncommited changes.
>> If you want, do 'git stash' first to recover them later.
>
> I disagree with this caveat.  There's no reason to frighten people
> like that, as doing such merges will work most of the time.
>

This is not about frightening people; to reiterate, this is a prominent
warning on the git merge man page --- I will not tell people it's ok
when the official documentation discourages it.  Also, in my opinion it
is conceptually a bad practice to start git operations that affect the
commit graph (such as merge) from an unclean state.

>> In this case, you have to learn about rebase, as in 'git rebase
>> origin/master'.
>
> "git rebase" is a bad idea when merging a long-lived feature branch,
> so please don't advise this to users who are evidently not Git
> experts.

It is my understanding (and I made it clear that it was partly
guesswork) that Alan asked precisely for that functionality.  I am not
sufficiently patronizing to tell intelligent people they are not ready
for something when they explicitly ask for it. :)

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Eli Zaretskii]

> From: Ingo Lohmar <i.lohmar@gmail.com>
> Cc: acm@muc.de, emacs-devel@gnu.org, kaushal.modi@gmail.com
> Date: Sun, 03 Apr 2016 17:23:03 +0200
> 
> On Sun, Apr 03 2016 18:01 (+0300), Eli Zaretskii wrote:
> 
> >> From: Ingo Lohmar <i.lohmar@gmail.com>
> >> Date: Sun, 03 Apr 2016 14:30:27 +0200
> >> Cc: Emacs developers <emacs-devel@gnu.org>,
> >> 	Kaushal Modi <kaushal.modi@gmail.com>
> >> 
> >> Single caveat: Do NOT start a merge when you have uncommited changes.
> >> If you want, do 'git stash' first to recover them later.
> >
> > I disagree with this caveat.  There's no reason to frighten people
> > like that, as doing such merges will work most of the time.
> >
> 
> This is not about frightening people; to reiterate, this is a prominent
> warning on the git merge man page --- I will not tell people it's ok
> when the official documentation discourages it.

I think your documentation might be outdated.  Here's what the "git
pull" man page I have says:

  In Git 1.7.0 or later, to cancel a conflicting merge, use git reset
  --merge. Warning: In older versions of Git, running git pull with
  uncommitted changes is discouraged: while possible, it leaves you in a
  state that may be hard to back out of in the case of a conflict.

  If any of the remote changes overlap with local uncommitted changes,
  the merge will be automatically cancelled and the work tree
  untouched. It is generally best to get any local changes in working
  order before pulling or stash them away with git-stash(1).

This is with Git 2.8.0.

IOW, for a recent enough Git, they _recommend_ stashing, but no longer
_warn_ about merging in this situation.  Which is exactly my
experience.

> Also, in my opinion it is conceptually a bad practice to start git
> operations that affect the commit graph (such as merge) from an
> unclean state.

I agree that it's preferable to have a clean repo, but in practice it
doesn't always work to have it.  Being able to pull when you have
uncommitted changes is an important feature; a VCS that doesn't
support it is IMO severely broken, because it will get in the way.

> >> In this case, you have to learn about rebase, as in 'git rebase
> >> origin/master'.
> >
> > "git rebase" is a bad idea when merging a long-lived feature branch,
> > so please don't advise this to users who are evidently not Git
> > experts.
> 
> It is my understanding (and I made it clear that it was partly
> guesswork) that Alan asked precisely for that functionality.  I am not
> sufficiently patronizing to tell intelligent people they are not ready
> for something when they explicitly ask for it. :)

You may wish re-reading some of Alan's past messages about his
adventures with Git, to get a better idea about that.

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Ingo Lohmar]

On Sun, Apr 03 2016 18:40 (+0300), Eli Zaretskii wrote:
> I think your documentation might be outdated.  Here's what the "git
> pull" man page I have says:
>
>   In Git 1.7.0 or later, to cancel a conflicting merge, use git reset
>   --merge. Warning: In older versions of Git, running git pull with
>   uncommitted changes is discouraged: while possible, it leaves you in a
>   state that may be hard to back out of in the case of a conflict.
>
>   If any of the remote changes overlap with local uncommitted changes,
>   the merge will be automatically cancelled and the work tree
>   untouched. It is generally best to get any local changes in working
>   order before pulling or stash them away with git-stash(1).
>
> This is with Git 2.8.0.
>
> IOW, for a recent enough Git, they _recommend_ stashing, but no longer
> _warn_ about merging in this situation.  Which is exactly my
> experience.

For the sake of completeness, my 'git merge' man page for 2.8.0.rc3 says
(in the DESCRIPTION section):

       Warning: Running git merge with non-trivial uncommitted changes
       is discouraged: while possible, it may leave you in a state that
       is hard to back out of in the case of a conflict.

> I agree that it's preferable to have a clean repo, but in practice it
> doesn't always work to have it.  Being able to pull when you have
> uncommitted changes is an important feature; a VCS that doesn't
> support it is IMO severely broken, because it will get in the way.

We'll just have to disagree about the "severely broken" part.

>> It is my understanding (and I made it clear that it was partly
>> guesswork) that Alan asked precisely for that functionality.  I am not
>> sufficiently patronizing to tell intelligent people they are not ready
>> for something when they explicitly ask for it. :)
>
> You may wish re-reading some of Alan's past messages about his
> adventures with Git, to get a better idea about that.

I assume you mean a better idea about Alan's wishes..  Well, I actually
followed those threads, but what was asked for here does not remind me
of them.  Sorry if I was missing the point.

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Eli Zaretskii]

> From: Ingo Lohmar <i.lohmar@gmail.com>
> Cc: acm@muc.de, emacs-devel@gnu.org, kaushal.modi@gmail.com
> Date: Sun, 03 Apr 2016 18:00:38 +0200
> 
> On Sun, Apr 03 2016 18:40 (+0300), Eli Zaretskii wrote:
> > I think your documentation might be outdated.  Here's what the "git
> > pull" man page I have says:
> >
> >   In Git 1.7.0 or later, to cancel a conflicting merge, use git reset
> >   --merge. Warning: In older versions of Git, running git pull with
> >   uncommitted changes is discouraged: while possible, it leaves you in a
> >   state that may be hard to back out of in the case of a conflict.
> >
> >   If any of the remote changes overlap with local uncommitted changes,
> >   the merge will be automatically cancelled and the work tree
> >   untouched. It is generally best to get any local changes in working
> >   order before pulling or stash them away with git-stash(1).
> >
> > This is with Git 2.8.0.
> >
> > IOW, for a recent enough Git, they _recommend_ stashing, but no longer
> > _warn_ about merging in this situation.  Which is exactly my
> > experience.
> 
> For the sake of completeness, my 'git merge' man page for 2.8.0.rc3 says
> (in the DESCRIPTION section):
> 
>        Warning: Running git merge with non-trivial uncommitted changes
>        is discouraged: while possible, it may leave you in a state that
>        is hard to back out of in the case of a conflict.

But we were talking about "git pull", not about merge.

> > I agree that it's preferable to have a clean repo, but in practice it
> > doesn't always work to have it.  Being able to pull when you have
> > uncommitted changes is an important feature; a VCS that doesn't
> > support it is IMO severely broken, because it will get in the way.
> 
> We'll just have to disagree about the "severely broken" part.

Yes, let's do that.

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> But we were talking about "git pull", not about merge.

pull == fetch+merge.

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: Understanding a recent commit in emacs-25 branch [ed19f2]

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Ingo Lohmar <i.lohmar@gmail.com>,  acm@muc.de,  kaushal.modi@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 03 Apr 2016 18:24:33 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But we were talking about "git pull", not about merge.
> 
> pull == fetch+merge.

But "git help pull" != "git help fetch"+"git help merge".

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Ingo Lohmar <i.lohmar@gmail.com>,  acm@muc.de,  kaushal.modi@gmail.com,  emacs-devel@gnu.org
>> Date: Sun, 03 Apr 2016 18:24:33 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > But we were talking about "git pull", not about merge.
>> 
>> pull == fetch+merge.
>
> But "git help pull" != "git help fetch"+"git help merge".

What's your point?  pull has additional options.

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: Understanding a recent commit in emacs-25 branch [ed19f2]

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: i.lohmar@gmail.com,  acm@muc.de,  kaushal.modi@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 03 Apr 2016 19:35:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Cc: Ingo Lohmar <i.lohmar@gmail.com>,  acm@muc.de,  kaushal.modi@gmail.com,  emacs-devel@gnu.org
> >> Date: Sun, 03 Apr 2016 18:24:33 +0200
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > But we were talking about "git pull", not about merge.
> >> 
> >> pull == fetch+merge.
> >
> > But "git help pull" != "git help fetch"+"git help merge".
> 
> What's your point?  pull has additional options.

My point is that we were talking about "git pull", and therefore the
relevant documentation is the man page of "pull", not of "merge".  The
man page of "pull" no longer warns about pulling when there are
uncommitted changes.

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Achim Gratz]

Stefan Monnier writes:
>>> It was git that prepared the merge, not me.
>> Blaming the tools?
>
> Yes.  Git makes it all too easy here to create such annoying merge
> commits, and if you don't have enough experience with Git you won't
> even notice it.

Git actually stopped and asked to fix the conflicts I must assume.  I
don't know which Git version Alan is using under what localization, but
here an intentionally created merge conflict will create this message
(I've set LC_MESSAGES=POSIX to avoid the localization):

Auto-merging lisp/net/tramp-sh.el
CONFLICT (content): Merge conflict in lisp/net/tramp-sh.el
Automatic merge failed; fix conflicts and then commit the result.

Note that nothing there even suggests you should do a manual merge,
which is what Alan tells us he has done (I don't know if that's what he
did).

> But even if you do notice it, it can be pretty challenging to fix it
> after the fact, or to avoid it before the fact.

Either of

git merge --abort
git --reset merge

would have put you back on square one to try again.  Also, based on what
Alan said I believe there was just a single conflict, which would
presumably have been easy to fix and commit.  And there's alway the
possibility to branch just before any operation you think might fail
(and if you forgot to do that there's the reflog).

> It's not just that Git is a sharp tool here: in this instance, it makes
> it easy to do the wrong thing, and hard to do the right thing.

I don't think so.  For an upstream-tracking branch rebase=true should be
the default.  For feature-branches that merge from some other branch,
you can still rebase, but should preserve the merges from the other
branch (rebase=preserve).  Both settings can be made the default on a
per-branch basis to save you the bother of typing and remebering.

I'd like to recommend again to anyone using a DVCS to just play around
with a few throwaway clones of a reasonably sized repository.  Once you
think that you understand what's going on, try to break things:
introduce conflicts, delete files from the worktree, commit to the wrong
branch, whatever.  Then find out what exactly broke and how to fix it.
This doesn't take all that long, about an hour or two should cover a lot
of ground already.


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: Understanding a recent commit in emacs-25 branch [ed19f2]

[Andreas Schwab]

Achim Gratz <Stromeko@nexgo.de> writes:

> I don't think so.  For an upstream-tracking branch rebase=true should be
> the default.

Rebase should never be the default, because it is more complicated and
harder to get right.  It creates new commits that each must be retested.

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: Understanding a recent commit in emacs-25 branch [ed19f2]

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Sun, 03 Apr 2016 20:45:40 +0200
> Cc: emacs-devel@gnu.org
> 
> Achim Gratz <Stromeko@nexgo.de> writes:
> 
> > I don't think so.  For an upstream-tracking branch rebase=true should be
> > the default.
> 
> Rebase should never be the default, because it is more complicated and
> harder to get right.  It creates new commits that each must be retested.

Agreed.

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Paul Eggert]

Andreas Schwab wrote:
> Rebase should never be the default, because it is more complicated and
> harder to get right.  It creates new commits that each must be retested.

Rebasing makes sense for Alan's use case. He was working on the fix anyway, so 
retesting was not that big a deal for him. Conversely, he's more of an Emacs 
expert than a Git expert and merge conflicts are more of an hassle for him. This 
particular case did not benefit much from the advantages of merging over 
rebasing; quite the contrary.

As one becomes more of a Git expert, merging becomes more attractive. It does 
take some getting used to, though.

Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Andreas Schwab]

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

> Rebasing makes sense for Alan's use case. He was working on the fix
> anyway, so retesting was not that big a deal for him. Conversely, he's
> more of an Emacs expert than a Git expert and merge conflicts are more of
> an hassle for him.

If you get a merge conflict then you also get rebase conflicts.

> As one becomes more of a Git expert, merging becomes more attractive. It
> does take some getting used to, though.

Merging is much easier to handle.

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: Understanding a recent commit in emacs-25 branch [ed19f2]

[John Wiegley]

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

> Rebasing makes sense for Alan's use case. He was working on the fix anyway,
> so retesting was not that big a deal for him. Conversely, he's more of an
> Emacs expert than a Git expert and merge conflicts are more of an hassle for
> him. This particular case did not benefit much from the advantages of
> merging over rebasing; quite the contrary.

I agree that when working on a focused change, like a bug fix, that rebasing
is much more preferable, as it avoids these unnecessary merge commits.

However, we can't reasonably make this a requirement, because Git makes it
very different to "get things right", nor do you always want rebasing if your
feature work is longer than an easily retested commit-or-two.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2