Avoiding the three-windows merging with Git

Avoiding the three-windows merging with Git

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Has anyone figured out why merge conflicts go into a mode
with three windows, and some way to turn that off
without breaking anything else?

I would really appreciate that help, since with it I could make
another attempt to use Git, and perhaps this time understand how to
cope with the conflicts.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Avoiding the three-windows merging with Git

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 24 Nov 2019 22:14:27 -0500
> 
> Has anyone figured out why merge conflicts go into a mode
> with three windows, and some way to turn that off
> without breaking anything else?

No.  The only idea was that you somehow inadvertently started Ediff.
That shouldn't be necessary, and doesn't happen automatically, so it's
unclear how it happened, if it did.

> I would really appreciate that help, since with it I could make
> another attempt to use Git, and perhaps this time understand how to
> cope with the conflicts.

I suggest that you try, and if something goes wrong, describe what you
see, and the output of "C-h l" at that point.

Re: Avoiding the three-windows merging with Git

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Has anyone figured out why merge conflicts go into a mode
  > > with three windows, and some way to turn that off
  > > without breaking anything else?

  > No.  The only idea was that you somehow inadvertently started Ediff.
  > That shouldn't be necessary, and doesn't happen automatically, so it's
  > unclear how it happened, if it did.

I never use it, so unless I started it by typo, I don't think I started it.
And ISTR it happened more than once.

I don't know how to provoke a conflict intentionally.
I'd have to ask someone to install a patch that conflicts
with something I want to install.  However, doing that in
a Git repo where it will be impossible to remove later
seems like a bad idea.

Can someone help me create a conflict to test handling it?

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Avoiding the three-windows merging with Git

[Kévin Le Gouguec]

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

Richard Stallman <rms@gnu.org> writes:

> I don't know how to provoke a conflict intentionally.
> I'd have to ask someone to install a patch that conflicts
> with something I want to install.  However, doing that in
> a Git repo where it will be impossible to remove later
> seems like a bad idea.
>
> Can someone help me create a conflict to test handling it?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: create-conflict.sh --]
[-- Type: text/x-sh, Size: 502 bytes --]

#!/bin/bash

set -ex

git init --bare server-hosted-repo
git clone server-hosted-repo hacker-repo

cd hacker-repo/
echo "foo" > README
git add README ; git commit -m "Add README" 
git push --set-upstream ../server-hosted-repo/ master

cd ..
git clone server-hosted-repo hacker2-repo

cd hacker2-repo
echo foobaz > README 
git commit -m "Change to foobaz" -- README
git push --set-upstream ../server-hosted-repo/ master

cd ../hacker-repo
echo foobar > README
git commit -m "Change to foobar" -- README

[-- Attachment #3: Type: text/plain, Size: 1349 bytes --]


Attached is a silly script to create a conflict on a temporary
repository.  The script creates 3 folders in the current directory:

- hacker-repo: the folder where one hacker is working,
- hacker2-repo: the folder where another hacker is working,
- server-hosted-repo: the "central repository" where both hackers
  update from and commit to.

The script runs the following operations:

- create the central repository,
- make the first hacker commit a one-line file,
- make the second hacker update this file and commit the changes,
- make the first hacker update the file without updating from the
  central repository first.

(Some of these operations could probably have been expressed in terms
of vc commands; apologies for not taking the time to do so.)

From there one can start emacs -Q to observe the conflict:

$ emacs -Q hacker-repo
C-x v +

That gets me a log buffer from vc saying:

> Running "git pull --stat"...
> From ../server-hosted-repo
>  * branch            master     -> FETCH_HEAD
> Auto-merging README
> CONFLICT (content): Merge conflict in README
> Automatic merge failed; fix conflicts and then commit the result.

And indeed, visiting the README, I see conflict markers, and the
Smerge minor mode enabled (see attached screenshot).

C-h b tells me that C-c ^ E runs smerge-ediff, which spawns Ediff's
3-window merge UI.


[-- Attachment #4: vc-update-conflict.png --]
[-- Type: image/png, Size: 65337 bytes --]

Re: Re: Avoiding the three-windows merging with Git

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Attached is a silly script to create a conflict on a temporary
  > repository.  The script creates 3 folders in the current directory:

Does it operate purely locally?  No connection to any remote site?

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Avoiding the three-windows merging with Git

[Marcin Borkowski]

On 2019-11-27, at 07:45, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Attached is a silly script to create a conflict on a temporary
>   > repository.  The script creates 3 folders in the current directory:
>
> Does it operate purely locally?  No connection to any remote site?

Why should it connect to any remote site?  Besides, Kévin said
explicitly that it operates in the _current directory_, and a cursory
scan of the script confirms that.

In fact, it would be probably even simpler to use branches instead of
clones for creating artificial conflicts like this.

Best,

--
Marcin Borkowski
http://mbork.pl

Re: Avoiding the three-windows merging with Git

[Kévin Le Gouguec]

Marcin Borkowski <mbork@mbork.pl> writes:

> Why should it connect to any remote site?

To be fair, cloning/fetching/pushing from/to local repos is not a
feature I've seen advertised often, though obviously it's All There In
The Manual :)

> In fact, it would be probably even simpler to use branches instead of
> clones for creating artificial conflicts like this.

Sure, that is a rather heavy-handed way to create conflicts.

What I like about this setup is that it allows someone unfamiliar with
Git "remotes" to experiment locally, either to learn the basics of the
push-pull-whoops-conflict workflow, or to tinker with more advanced
stuff (server hooks, being on the wrong end of git push --force…)

Re: Avoiding the three-windows merging with Git

[Marcin Borkowski]

On 2019-11-27, at 21:15, Kévin Le Gouguec <kevin.legouguec@gmail.com> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> Why should it connect to any remote site?
>
> To be fair, cloning/fetching/pushing from/to local repos is not a
> feature I've seen advertised often, though obviously it's All There In
> The Manual :)

Fair enough.  OTOH, I came to Git from (early) Mercurial, where creating
local clones was a standard way of doing branches.  Also, I sometimes
create local clones to perform experiments with Git.  (There is another,
not very well known feature of Git called "worktrees", which is kind of
similar.  Basically, worktrees allow one to have several working
directories, all corresponding to a single .git directory.)

>> In fact, it would be probably even simpler to use branches instead of
>> clones for creating artificial conflicts like this.
>
> Sure, that is a rather heavy-handed way to create conflicts.
>
> What I like about this setup is that it allows someone unfamiliar with
> Git "remotes" to experiment locally, either to learn the basics of the
> push-pull-whoops-conflict workflow, or to tinker with more advanced
> stuff (server hooks, being on the wrong end of git push --force…)

Good point.  (BTW, a few months ago I studied a nice online course on
Git, which used exactly this approach to teach remotes.)

Best,

--
Marcin Borkowski
http://mbork.pl

Re: Avoiding the three-windows merging with Git

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Does it operate purely locally?  No connection to any remote site?

  > Why should it connect to any remote site?

I don't know what it is likely to do.  That is why I asked for
a factual answer.


-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Avoiding the three-windows merging with Git

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> Date: Wed, 27 Nov 2019 01:45:50 -0500
> 
>   > Attached is a silly script to create a conflict on a temporary
>   > repository.  The script creates 3 folders in the current directory:
> 
> Does it operate purely locally?  No connection to any remote site?

Yes, it arranges for the upstream repository to be on your local
machine, just in another directory.

Re: Avoiding the three-windows merging with Git

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Cc: eliz@gnu.org, emacs-devel@gnu.org
>> Date: Wed, 27 Nov 2019 01:45:50 -0500
>> 
>> Does it operate purely locally?  No connection to any remote site?
>
> Yes, it arranges for the upstream repository to be on your local
> machine, just in another directory.

Right.  Git commands that interact with remote repositories work just as
well with local copies of a repository.  It's not something I've seen
used much, but I find it useful for messing ar^W^Weducative purposes.

That's why I put quotes around "central repository"; nothing actually
leaves the machine the script runs on.  The server-hosted-repo folder
(whose name might be confusing; I should have simply called it
"upstream-repo") is only "central" insofar as the other two repositories
are set up to synchronize with it when running vc-update and vc-push.