Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Yuri Khan]

On Tue, 18 Aug 2020 at 23:48, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> The question then becomes: how does Magit do that?  (or does it come
> with the same caveats that I mentioned regarding execution time,
> treatment of non-committed changes, the set of files whose mtime is
> affected, ...)

I think it checks out the other branch, then merges the current
branch, then does whatever cleanup necessary. (That does not include
restoring mtimes and recovering spent time.)

Generally speaking, merging while the working copy is dirty is not
recommended, the reason being, if the merge results in conflicts,
you’d probably like to be able to use the working copy to resolve
them. Having uncommitted changes there makes things confusing,
especially if they themselves conflict with the changes in any of the
branches being merged.

Mtime probably changes for every file that changes during the
intermediate checkout and the subsequent merge.

Raymond Chen of Microsoft once described a technique to craft commits
in a Git repository without ever touching the working copy, because
that would change the mtimes of some files and subsequently trigger a
rebuild, and/or be slow due to updating the working copy:

1. [Building a commit manually out of a
tree](https://devblogs.microsoft.com/oldnewthing/20190506-00/?p=102478)
2. [Building a merge commit manually out of a
tree](https://devblogs.microsoft.com/oldnewthing/20190507-00/?p=102480)

That assumes that the hard part of the merge (i.e. actual merge and
conflict resolution) is already done and the result recorded in a tree
somewhere in Git, though.