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

[Alan Mackenzie <acm@muc.de>]

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