Avoiding the three-windows merging with Git

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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)



Reply | Threaded
Open this post in threaded view
|

Re: Avoiding the three-windows merging with Git

Eli Zaretskii
> From: Richard Stallman <[hidden email]>
> 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.

Reply | Threaded
Open this post in threaded view
|

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)



Reply | Threaded
Open this post in threaded view
|

Re: Avoiding the three-windows merging with Git

Kévin Le Gouguec
Richard Stallman <[hidden email]> 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?



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.


create-conflict.sh (525 bytes) Download Attachment
vc-update-conflict.png (87K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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)



Reply | Threaded
Open this post in threaded view
|

Re: Avoiding the three-windows merging with Git

Marcin Borkowski-3

On 2019-11-27, at 07:45, Richard Stallman <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Avoiding the three-windows merging with Git

Eli Zaretskii
In reply to this post by Richard Stallman
> From: Richard Stallman <[hidden email]>
> Cc: [hidden email], [hidden email]
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Avoiding the three-windows merging with Git

Kévin Le Gouguec
Eli Zaretskii <[hidden email]> writes:

>> From: Richard Stallman <[hidden email]>
>> Cc: [hidden email], [hidden email]
>> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Avoiding the three-windows merging with Git

Kévin Le Gouguec
In reply to this post by Marcin Borkowski-3
Marcin Borkowski <[hidden email]> 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…)

Reply | Threaded
Open this post in threaded view
|

Re: Avoiding the three-windows merging with Git

Marcin Borkowski-3

On 2019-11-27, at 21:15, Kévin Le Gouguec <[hidden email]> wrote:

> Marcin Borkowski <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Avoiding the three-windows merging with Git

Richard Stallman
In reply to this post by Marcin Borkowski-3
[[[ 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)