Merge conflict cookie in dired.el (current HEAD in bzr)

Merge conflict cookie in dired.el (current HEAD in bzr)

[Bastien]

Hi,

There is this merge conflict indication in dired.el
which prevents Emacs from building:

<<<<<<< TREE
;;;;;;  dired-diff) "dired-aux" "dired-aux.el" "cab4c9952dac1073157ff3fa23cd93b8")
=======
;;;;;;  dired-diff) "dired-aux" "dired-aux.el" "244227ae609852d3dc10ab3fc40ba9ab")
>>>>>>> MERGE-SOURCE

-- 
 Bastien

Re: Merge conflict cookie in dired.el (current HEAD in bzr)

[Glenn Morris]

Bastien wrote:

> There is this merge conflict indication in dired.el
> which prevents Emacs from building:

That is local to your copy.

bzr revert lisp/dired.el

Re: Merge conflict cookie in dired.el (current HEAD in bzr)

[Bastien]

Glenn Morris <rgm@gnu.org> writes:

> Bastien wrote:
>
>> There is this merge conflict indication in dired.el
>> which prevents Emacs from building:
>
> That is local to your copy.

Indeed.  No idea how this ended up here.

> bzr revert lisp/dired.el

Done.   I could install the latest Emacs fine.  Thanks,

-- 
 Bastien

Re: Merge conflict cookie in dired.el (current HEAD in bzr)

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Date: Fri, 28 Sep 2012 00:56:50 +0200
> Cc: emacs-devel@gnu.org
> 
> Glenn Morris <rgm@gnu.org> writes:
> 
> > Bastien wrote:
> >
> >> There is this merge conflict indication in dired.el
> >> which prevents Emacs from building:
> >
> > That is local to your copy.
> 
> Indeed.  No idea how this ended up here.

Probably like this:

  . "bzr up"
  . build Emacs, which changed dired.el due to autoloads
  . "bzr up", which brought in dired.el where the same autoloads were
    already updated, but the time stamp was different.  Bzr told you
    that there text conflicts, but you didn't notice that.

In general, it is advisable to run "bzr st" from time to time,
preferably after the build that you do after "bzr up", to see if any
versioned files changed due to autoloads.  If some of them did, either
commit those files (preferred), or "bzr revert" and rebuild, then wait
for someone else to commit the modified autoloads.

Re: Merge conflict cookie in dired.el (current HEAD in bzr)

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

>> Glenn Morris <rgm@gnu.org> writes:
>> 
>> > Bastien wrote:
>> >
>> >> There is this merge conflict indication in dired.el
>> >> which prevents Emacs from building:
>> >
>> > That is local to your copy.
>> 
>> Indeed.  No idea how this ended up here.
>
> Probably like this:
>
>   . "bzr up"
>   . build Emacs, which changed dired.el due to autoloads
>   . "bzr up", which brought in dired.el where the same autoloads were
>     already updated, but the time stamp was different.  Bzr told you
>     that there text conflicts, but you didn't notice that.
>
> In general, it is advisable to run "bzr st" from time to time,
> preferably after the build that you do after "bzr up", to see if any
> versioned files changed due to autoloads.  If some of them did, either
> commit those files (preferred), or "bzr revert" and rebuild, then wait
> for someone else to commit the modified autoloads.

Thanks for the info Eli, will check this when I build again.

-- 
 Bastien

Re: Merge conflict cookie in dired.el (current HEAD in bzr)

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> If some of them did, either commit those files (preferred),

Glenn already does that, automagically.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Merge conflict cookie in dired.el (current HEAD in bzr)

[Juri Linkov]

> In general, it is advisable to run "bzr st" from time to time,
> preferably after the build that you do after "bzr up", to see if any
> versioned files changed due to autoloads.  If some of them did, either
> commit those files (preferred), or "bzr revert" and rebuild, then wait
> for someone else to commit the modified autoloads.

There is a related problem.  When "bzr merge" says there are conflicts,
I rush to edit reported files to fix conflicts, but this puts the repository
into a broken state, because when I start editing, the "bzr merge" command
is not yet finished.  Bzr is so slow that it reports conflicts and
continues its work for another 10-20 seconds.  When I edit files
during this time and save them, vc-bzr.el reports an error, after that
only manually running "bzr resolve" helps to resolve this situation.

Maybe like compile.el displays the running process status in the mode line
with the `compilation-mode-line-run' face, comint-mode could use the same
face in the mode line to highlight the process status ":run" (if there are
no better ideas).

Re: Merge conflict cookie in dired.el (current HEAD in bzr)

[Paul Eggert]

On 09/28/2012 08:30 AM, Juri Linkov wrote:
> When "bzr merge" says there are conflicts,
> I rush to edit reported files to fix conflicts

Eeuuw.  Don't do that!  The right way to think about
'bzr' is that it's a good time to get a cup of coffee.
Or tea.  Or think.  Or maybe just look out the window, if
you have a window.  But don't modify source files while
'bzr' is doing its thing -- that'll just cause trouble.

I often get some of my best little hacking ideas
while waiting for bzr to finish.