unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Avoiding the three-windows merging with Git
@ 2019-11-25  3:14 Richard Stallman
  2019-11-25  3:32 ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Stallman @ 2019-11-25  3:14 UTC (permalink / raw)
  To: emacs-devel

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Avoiding the three-windows merging with Git
  2019-11-25  3:14 Avoiding the three-windows merging with Git Richard Stallman
@ 2019-11-25  3:32 ` Eli Zaretskii
  2019-11-26  3:46   ` Richard Stallman
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2019-11-25  3:32 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Avoiding the three-windows merging with Git
  2019-11-25  3:32 ` Eli Zaretskii
@ 2019-11-26  3:46   ` Richard Stallman
  2019-11-26  7:16     ` Kévin Le Gouguec
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Stallman @ 2019-11-26  3:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Avoiding the three-windows merging with Git
  2019-11-26  3:46   ` Richard Stallman
@ 2019-11-26  7:16     ` Kévin Le Gouguec
  2019-11-27  6:45       ` Richard Stallman
  0 siblings, 1 reply; 11+ messages in thread
From: Kévin Le Gouguec @ 2019-11-26  7:16 UTC (permalink / raw)
  To: Richard Stallman; +Cc: Eli Zaretskii, emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Re: Avoiding the three-windows merging with Git
  2019-11-26  7:16     ` Kévin Le Gouguec
@ 2019-11-27  6:45       ` Richard Stallman
  2019-11-27  9:39         ` Marcin Borkowski
  2019-11-27 15:45         ` Eli Zaretskii
  0 siblings, 2 replies; 11+ messages in thread
From: Richard Stallman @ 2019-11-27  6:45 UTC (permalink / raw)
  To: Kévin Le Gouguec; +Cc: eliz, emacs-devel

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Avoiding the three-windows merging with Git
  2019-11-27  6:45       ` Richard Stallman
@ 2019-11-27  9:39         ` Marcin Borkowski
  2019-11-27 20:15           ` Kévin Le Gouguec
  2019-11-28  4:17           ` Richard Stallman
  2019-11-27 15:45         ` Eli Zaretskii
  1 sibling, 2 replies; 11+ messages in thread
From: Marcin Borkowski @ 2019-11-27  9:39 UTC (permalink / raw)
  To: rms; +Cc: eliz, emacs-devel, Kévin Le Gouguec


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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Avoiding the three-windows merging with Git
  2019-11-27  6:45       ` Richard Stallman
  2019-11-27  9:39         ` Marcin Borkowski
@ 2019-11-27 15:45         ` Eli Zaretskii
  2019-11-27 19:45           ` Kévin Le Gouguec
  1 sibling, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2019-11-27 15:45 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel, kevin.legouguec

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Avoiding the three-windows merging with Git
  2019-11-27 15:45         ` Eli Zaretskii
@ 2019-11-27 19:45           ` Kévin Le Gouguec
  0 siblings, 0 replies; 11+ messages in thread
From: Kévin Le Gouguec @ 2019-11-27 19:45 UTC (permalink / raw)
  To: Eli Zaretskii, rms; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Avoiding the three-windows merging with Git
  2019-11-27  9:39         ` Marcin Borkowski
@ 2019-11-27 20:15           ` Kévin Le Gouguec
  2019-11-27 22:48             ` Marcin Borkowski
  2019-11-28  4:17           ` Richard Stallman
  1 sibling, 1 reply; 11+ messages in thread
From: Kévin Le Gouguec @ 2019-11-27 20:15 UTC (permalink / raw)
  To: Marcin Borkowski; +Cc: eliz, rms, emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Avoiding the three-windows merging with Git
  2019-11-27 20:15           ` Kévin Le Gouguec
@ 2019-11-27 22:48             ` Marcin Borkowski
  0 siblings, 0 replies; 11+ messages in thread
From: Marcin Borkowski @ 2019-11-27 22:48 UTC (permalink / raw)
  To: Kévin Le Gouguec; +Cc: eliz, rms, emacs-devel


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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Avoiding the three-windows merging with Git
  2019-11-27  9:39         ` Marcin Borkowski
  2019-11-27 20:15           ` Kévin Le Gouguec
@ 2019-11-28  4:17           ` Richard Stallman
  1 sibling, 0 replies; 11+ messages in thread
From: Richard Stallman @ 2019-11-28  4:17 UTC (permalink / raw)
  To: Marcin Borkowski; +Cc: eliz, kevin.legouguec, emacs-devel

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2019-11-28  4:17 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-25  3:14 Avoiding the three-windows merging with Git Richard Stallman
2019-11-25  3:32 ` Eli Zaretskii
2019-11-26  3:46   ` Richard Stallman
2019-11-26  7:16     ` Kévin Le Gouguec
2019-11-27  6:45       ` Richard Stallman
2019-11-27  9:39         ` Marcin Borkowski
2019-11-27 20:15           ` Kévin Le Gouguec
2019-11-27 22:48             ` Marcin Borkowski
2019-11-28  4:17           ` Richard Stallman
2019-11-27 15:45         ` Eli Zaretskii
2019-11-27 19:45           ` Kévin Le Gouguec

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).