No commit in vc?

No commit in vc?

[Jan Djärv]

Hi.

Maybe I'm missing something obvious, but I can't find any way of doing commit 
from vc in Emacs (for bzr).

I did what "Doing Quick Fixes" says in BzrForEmacsDevs.  I then did C-x v d 
..., and then v, <type comment> C-c C-c.

Bzr then complains it can't do single file commits for merges (whatever that 
means).


	Jan D.

Re: No commit in vc?

[Eli Zaretskii]

> Date: Thu, 28 Jan 2010 08:25:47 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> 
> Maybe I'm missing something obvious, but I can't find any way of doing commit 
> from vc in Emacs (for bzr).
> 
> I did what "Doing Quick Fixes" says in BzrForEmacsDevs.  I then did C-x v d 
> ..., and then v, <type comment> C-c C-c.
> 
> Bzr then complains it can't do single file commits for merges (whatever that 
> means).

Can you show what bzr commands are invoked by VC when you type C-x v d
and C-c C-c?

Re: No commit in vc?

[Jan Djärv]

Eli Zaretskii skrev:
>> Date: Thu, 28 Jan 2010 08:25:47 +0100
>> From: Jan Djärv <jan.h.d@swipnet.se>
>>
>> Maybe I'm missing something obvious, but I can't find any way of doing commit 
>> from vc in Emacs (for bzr).
>>
>> I did what "Doing Quick Fixes" says in BzrForEmacsDevs.  I then did C-x v d 
>> ..., and then v, <type comment> C-c C-c.
>>
>> Bzr then complains it can't do single file commits for merges (whatever that 
>> means).
> 
> Can you show what bzr commands are invoked by VC when you type C-x v d
> and C-c C-c?
> 

Here is the part from .bzr-log, the exact error message I got was 
"Selected-file commit of merges is not supported yet: files src/xfns.c".  It 
is at the bottom.  It looks like it is doing a commit.

tor 2010-01-28 08:12:28 +0100
0.027  bzr arguments: [u'commit', u'-m', u'Revert code for bug #3643.\nxfns.c 
(Fx_create_frame): Remove window size matching code 
from\n2010-01-15.\n(x_get_current_desktop, x_get_desktop_workarea): Remove\n', 
u'xfns.c']
0.041  looking for plugins in /home/jhd/.bazaar/plugins
0.041  looking for plugins in /usr/lib/python2.6/dist-packages/bzrlib/plugins
0.143  encoding stdout as osutils.get_user_encoding() 'UTF-8'
0.206  opening working tree '/home/jhd/src/emacs/trunk'
0.305  ssh implementation is OpenSSH
12.322  preparing to commit
26.054  Traceback (most recent call last):
   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 842, in 
exception_to_return_code
     return the_callable(*args, **kwargs)
   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1037, in 
run_bzr
     ret = run(*run_argv)
   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 654, in 
run_argv_aliases
     return self.run(**all_cmd_args)
   File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 3058, in run
     exclude=safe_relpath_files(tree, exclude))
   File "/usr/lib/python2.6/dist-packages/bzrlib/decorators.py", line 192, in 
write_locked
     result = unbound(self, *args, **kwargs)
   File "/usr/lib/python2.6/dist-packages/bzrlib/workingtree_4.py", line 197, 
in commit
     result = WorkingTree3.commit(self, message, revprops, *args, **kwargs)
   File "/usr/lib/python2.6/dist-packages/bzrlib/decorators.py", line 192, in 
write_locked
     result = unbound(self, *args, **kwargs)
   File "/usr/lib/python2.6/dist-packages/bzrlib/mutabletree.py", line 229, in 
commit
     *args, **kwargs)
   File "/usr/lib/python2.6/dist-packages/bzrlib/commit.py", line 339, in commit
     raise errors.CannotCommitSelectedFileMerge(self.specific_files)
CannotCommitSelectedFileMerge: Selected-file commit of merges is not supported 
yet: files src/xfns.c

26.054  return code 3


	Jan D.

Re: No commit in vc?

[Óscar Fuentes]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Maybe I'm missing something obvious, but I can't find any way of doing
> commit from vc in Emacs (for bzr).
>
> I did what "Doing Quick Fixes" says in BzrForEmacsDevs.  I then did
> C-x v d ..., and then v, <type comment> C-c C-c.
>
> Bzr then complains it can't do single file commits for merges
> (whatever that means).

Let me guess:

bzr merge
<hack hack>
bzr commit foo.c
<cannot do single file commits for merges>

On this scenario, the `merge' modifies some files and sets a `pending
merge tips' status flag (visible with `bzr st') At this point, you must
commit the whole merge, not just a subset of the modified files:

bzr merge
<resolve conflicts, if any>
bzr commit
<hack hack>
bzr commit foo.c

Re: No commit in vc?

[Eli Zaretskii]

> Date: Thu, 28 Jan 2010 09:09:50 +0100
> From: Jan_Djärv <jan.h.d@swipnet.se>
> CC: emacs-devel@gnu.org
> 
>    File "/usr/lib/python2.6/dist-packages/bzrlib/commit.py", line 339, in commit
>      raise errors.CannotCommitSelectedFileMerge(self.specific_files)
> CannotCommitSelectedFileMerge: Selected-file commit of merges is not supported 
> yet: files src/xfns.c

What do the following two commands show in the quickfixes branch
(which is where you were working, right?)?

  bzr info
  bzr status

Re: No commit in vc?

[Jan Djärv]

Eli Zaretskii skrev:
>> Date: Thu, 28 Jan 2010 09:09:50 +0100
>> From: Jan_Djärv <jan.h.d@swipnet.se>
>> CC: emacs-devel@gnu.org
>>
>>    File "/usr/lib/python2.6/dist-packages/bzrlib/commit.py", line 339, in commit
>>      raise errors.CannotCommitSelectedFileMerge(self.specific_files)
>> CannotCommitSelectedFileMerge: Selected-file commit of merges is not supported 
>> yet: files src/xfns.c
> 
> What do the following two commands show in the quickfixes branch
> (which is where you were working, right?)?
> 
>   bzr info
>   bzr status
> 

% bzr info
Repository tree (format: 2a)
Location:
   shared repository: /home/jhd/src/emacs
   repository branch: .

Related branches:
   parent branch: /home/jhd/src/emacs/trunk
% bzr status
unknown:
   cmd
   upd
   src/.BAK.xterm.c
   src/.gdb_history
   src/tag-files
   src/xx.el

	Jan D.

Re: No commit in vc?

[Jan Djärv]

Óscar Fuentes skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Maybe I'm missing something obvious, but I can't find any way of doing
>> commit from vc in Emacs (for bzr).
>>
>> I did what "Doing Quick Fixes" says in BzrForEmacsDevs.  I then did
>> C-x v d ..., and then v, <type comment> C-c C-c.
>>
>> Bzr then complains it can't do single file commits for merges
>> (whatever that means).
> 
> Let me guess:
> 
> bzr merge
> <hack hack>
> bzr commit foo.c
> <cannot do single file commits for merges>

No.  I used vc from inside Emacs.  vc did a commit according to .bzr-log.  I 
never commited a single file.

	Jan D.

Re: No commit in vc?

[Jan Djärv]

Jan Djärv skrev:
> Eli Zaretskii skrev:
>>> Date: Thu, 28 Jan 2010 09:09:50 +0100
>>> From: Jan_Djärv <jan.h.d@swipnet.se>
>>> CC: emacs-devel@gnu.org
>>>
>>>    File "/usr/lib/python2.6/dist-packages/bzrlib/commit.py", line 
>>> 339, in commit
>>>      raise errors.CannotCommitSelectedFileMerge(self.specific_files)
>>> CannotCommitSelectedFileMerge: Selected-file commit of merges is not 
>>> supported yet: files src/xfns.c
>>
>> What do the following two commands show in the quickfixes branch
>> (which is where you were working, right?)?
>>
>>   bzr info
>>   bzr status
>>

The info below is probably not useful, I commited on the command line when vc 
failed, so the state where the error occurred is gone.

	Jan D.

> 
> % bzr info
> Repository tree (format: 2a)
> Location:
>   shared repository: /home/jhd/src/emacs
>   repository branch: .
> 
> Related branches:
>   parent branch: /home/jhd/src/emacs/trunk
> % bzr status
> unknown:
>   cmd
>   upd
>   src/.BAK.xterm.c
>   src/.gdb_history
>   src/tag-files
>   src/xx.el
> 
>     Jan D.
> 
> 
> 

Re: No commit in vc?

[Jason Rumney]

Jan Djärv <jan.h.d@swipnet.se> writes:

>>> Maybe I'm missing something obvious, but I can't find any way of doing
>>> commit from vc in Emacs (for bzr).
>>>
>>> I did what "Doing Quick Fixes" says in BzrForEmacsDevs.  I then did
>>> C-x v d ..., and then v, <type comment> C-c C-c.
>>>
>>> Bzr then complains it can't do single file commits for merges
>>> (whatever that means).

The same happened to me yesterday.  My sequence was

Edit in local branch, as recommended. Commit.

In trunk:
bzr update
bzr merge ../branch

From Emacs C-x v d

Mark all edited files. Type v.
Use vc specialised functions to pull the Changelog into the commit
message, add an extra one liner at the top.
C-c C-c
Bzr complains about single file commits.


Really, this needs to be made to work, and the frequent respondants to
queries such as this need to be less condescending toward the people
reporting these problems and admit that the tools need improving to
match the workflow expected by the users, not the other way around!

Re: No commit in vc?

[Óscar Fuentes]

Jason Rumney <jasonr@gnu.org> writes:

> The same happened to me yesterday.  My sequence was
>
> Edit in local branch, as recommended. Commit.
>
> In trunk:
> bzr update
> bzr merge ../branch
>
> From Emacs C-x v d
>
> Mark all edited files. Type v.
> Use vc specialised functions to pull the Changelog into the commit
> message, add an extra one liner at the top.
> C-c C-c
> Bzr complains about single file commits.

When you are committing after `merge', don't mark files in VC-dir. With
the point on the `./' entry of VC-dir, press `v'. This does a bare `bzr
commit', which comprises all changes on the working tree. Apparently,
bzr complains if you ask to commit specific files even when those files
are everything which is pending.

> Really, this needs to be made to work, and the frequent respondants to
> queries such as this need to be less condescending toward the people
> reporting these problems

Uh? Condescending how?

> and admit that the tools need improving to match the workflow expected
> by the users, not the other way around!

I have nothing to admit. I wrote a guide for working with bzr on a way
that is very similar to CVS, so people that just want to contribute with
the minimal hassle can keep doing it. I'm not affiliated to Bazaar or
Canonical in any way. I'm just trying to help. If you know what's the
"workflow expected by users" (whatever that means) describe it and I'll
try to see what's possible to match it.

I find your claims uncalled-for and almost offensive.

Re: No commit in vc?

[Óscar Fuentes]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Óscar Fuentes skrev:
>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>
>>> Maybe I'm missing something obvious, but I can't find any way of doing
>>> commit from vc in Emacs (for bzr).
>>>
>>> I did what "Doing Quick Fixes" says in BzrForEmacsDevs.  I then did
>>> C-x v d ..., and then v, <type comment> C-c C-c.
>>>
>>> Bzr then complains it can't do single file commits for merges
>>> (whatever that means).
>>
>> Let me guess:
>>
>> bzr merge
>> <hack hack>
>> bzr commit foo.c
>> <cannot do single file commits for merges>
>
> No.  I used vc from inside Emacs.  vc did a commit according to
> .bzr-log.  I never commited a single file.

Well, I was trying to describe on terms of bzr commands what you VC did
at your request. After reading your other messages, I guess that this is
what happened:

cd trunk
bzr merge ../other-branch
<in VC-dir, mark the modified files>
<commit from VC-dir>

As mentioned on my response to Jason, it seems that bzr does not admit a
`commit' comand with a list of files when there is a pending merge. The
solution for this is to not mark files in VC-dir, but put the point on
the `./' entry at the top and press `v' there. This commits all changes
on the current working tree, which keeps bzr happy.

Re: No commit in vc?

[Jan Djärv]

Óscar Fuentes skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Óscar Fuentes skrev:
>>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>>
>>>> Maybe I'm missing something obvious, but I can't find any way of doing
>>>> commit from vc in Emacs (for bzr).
>>>>
>>>> I did what "Doing Quick Fixes" says in BzrForEmacsDevs.  I then did
>>>> C-x v d ..., and then v, <type comment> C-c C-c.
>>>>
>>>> Bzr then complains it can't do single file commits for merges
>>>> (whatever that means).
>>> Let me guess:
>>>
>>> bzr merge
>>> <hack hack>
>>> bzr commit foo.c
>>> <cannot do single file commits for merges>
>> No.  I used vc from inside Emacs.  vc did a commit according to
>> .bzr-log.  I never commited a single file.
> 
> Well, I was trying to describe on terms of bzr commands what you VC did
> at your request. After reading your other messages, I guess that this is
> what happened:
> 
> cd trunk
> bzr merge ../other-branch
> <in VC-dir, mark the modified files>
> <commit from VC-dir>
> 
> As mentioned on my response to Jason, it seems that bzr does not admit a
> `commit' comand with a list of files when there is a pending merge. The
> solution for this is to not mark files in VC-dir, but put the point on
> the `./' entry at the top and press `v' there. This commits all changes
> on the current working tree, which keeps bzr happy.
> 
> 


I didn't mark any files.   Probably vc takes that to mean the same as marking 
edited files.  This is a bug in vc that it tries to check in individual files.

	Jan D.

Re: No commit in vc?

[Óscar Fuentes]

Jan Djärv <jan.h.d@swipnet.se> writes:

>> As mentioned on my response to Jason, it seems that bzr does not admit a
>> `commit' comand with a list of files when there is a pending merge. The
>> solution for this is to not mark files in VC-dir, but put the point on
>> the `./' entry at the top and press `v' there. This commits all changes
>> on the current working tree, which keeps bzr happy.
>
> I didn't mark any files.   Probably vc takes that to mean the same as
> marking edited files.  This is a bug in vc that it tries to check in
> individual files.

But was the point over a file or on the top of the VC-dir buffer? If the
point was over a file, VC-dir commits that file.

Re: No commit in vc?

[Jan Djärv]

Óscar Fuentes skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>>> As mentioned on my response to Jason, it seems that bzr does not admit a
>>> `commit' comand with a list of files when there is a pending merge. The
>>> solution for this is to not mark files in VC-dir, but put the point on
>>> the `./' entry at the top and press `v' there. This commits all changes
>>> on the current working tree, which keeps bzr happy.
>> I didn't mark any files.   Probably vc takes that to mean the same as
>> marking edited files.  This is a bug in vc that it tries to check in
>> individual files.
> 
> But was the point over a file or on the top of the VC-dir buffer? If the
> point was over a file, VC-dir commits that file.
> 
> 

As can be seen in the log i sent, it tried to commit two files, so point 
wasn't over one file.  I really don't know where point was, I just did C-x v d 
  and immediatly after, v.

	Jan D.

Re: No commit in vc?

[Óscar Fuentes]

Jan Djärv <jan.h.d@swipnet.se> writes:

>> But was the point over a file or on the top of the VC-dir buffer? If the
>> point was over a file, VC-dir commits that file.
>>
> As can be seen in the log i sent, it tried to commit two files, so
> point wasn't over one file.  I really don't know where point was, I
> just did C-x v d and immediatly after, v.

I see just one file, xfns.c:

0.027  bzr arguments: [u'commit', u'-m', u'Revert code for bug
#3643.\nxfns.c (Fx_create_frame): Remove window size matching code
from\n2010-01-15.\n(x_get_current_desktop, x_get_desktop_workarea):
Remove\n', u'xfns.c']

What's the other file you see on the log?

Re: No commit in vc?

[Eli Zaretskii]

> Date: Thu, 28 Jan 2010 15:57:02 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: emacs-devel@gnu.org
> 
> I didn't mark any files.   Probably vc takes that to mean the same as marking 
> edited files.  This is a bug in vc that it tries to check in individual files.

What does VC do with other back ends when no files are marked?

Re: No commit in vc?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 28 Jan 2010 14:49:19 +0100
> 
> cd trunk
> bzr merge ../other-branch
> <in VC-dir, mark the modified files>
> <commit from VC-dir>
> 
> As mentioned on my response to Jason, it seems that bzr does not admit a
> `commit' comand with a list of files when there is a pending merge.

Óscar, could you please ask on the Bazaar list if this is true, and
what can be done to work around that, so that VC could DTRT?

I'd ask myself, but I'm not sure I understand the details well enough
to describe them in clear terms.

TIA

Re: No commit in vc?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Thu, 28 Jan 2010 14:49:19 +0100
>> 
>> cd trunk
>> bzr merge ../other-branch
>> <in VC-dir, mark the modified files>
>> <commit from VC-dir>
>> 
>> As mentioned on my response to Jason, it seems that bzr does not admit a
>> `commit' comand with a list of files when there is a pending merge.
>
> Óscar, could you please ask on the Bazaar list if this is true, and
> what can be done to work around that, so that VC could DTRT?

From `bzr help commit' :

>>>>>>>>>
Selective commits:
  If selected files are specified, only changes to those files are
  committed.  If a directory is specified then the directory and
  everything within it is committed.

...

  A selective commit after a merge is not yet supported.
<<<<<<<<<

So it is documented. Maybe VC could detect if there are pending merges
parsing the output of `bzr st', or parse the error message returned by
`bzr commit somefile' and detect that the failure was due to a pending
merge, hoping it is not translated to the local language etc. In any
case, it would require an ugly Bazaar-specific hack.

What bzr shouldn't do is to output a backtrace. I'll file a bug report
for that.

[snip]

Re: No commit in vc?

[Jan Djärv]

Óscar Fuentes skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>>> But was the point over a file or on the top of the VC-dir buffer? If the
>>> point was over a file, VC-dir commits that file.
>>>
>> As can be seen in the log i sent, it tried to commit two files, so
>> point wasn't over one file.  I really don't know where point was, I
>> just did C-x v d and immediatly after, v.
> 
> I see just one file, xfns.c:
> 
> 0.027  bzr arguments: [u'commit', u'-m', u'Revert code for bug
> #3643.\nxfns.c (Fx_create_frame): Remove window size matching code
> from\n2010-01-15.\n(x_get_current_desktop, x_get_desktop_workarea):
> Remove\n', u'xfns.c']
> 
> What's the other file you see on the log?
> 
> 

Hmm, i tried it twice.  The first time the log said:

0.027  bzr arguments: [u'commit', u'-m', u'Revert code for bug #3643.\nxfns.c 
(Fx_create_frame): Remove window size matching code 
from\n2010-01-15.\n(x_get_current_desktop, x_get_desktop_workarea): Remove\n', 
u'ChangeLog', u'xfns.c']

i.e. ChangeLog also.

I mailed the log from the second try.  I may have moved point at that time.

	Jan D.

Re: No commit in vc?

[Jan Djärv]

Eli Zaretskii skrev:
>> Date: Thu, 28 Jan 2010 15:57:02 +0100
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Cc: emacs-devel@gnu.org
>>
>> I didn't mark any files.   Probably vc takes that to mean the same as marking 
>> edited files.  This is a bug in vc that it tries to check in individual files.
> 
> What does VC do with other back ends when no files are marked?
> 
> 

If all modified files are in the same state (i.e. edited, as they where in 
this case), vc commits them all.  This is true for Git and CVS at least.

	Jan D.

Re: No commit in vc?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 28 Jan 2010 19:52:44 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Óscar Fuentes <ofv@wanadoo.es>
> >> Date: Thu, 28 Jan 2010 14:49:19 +0100
> >> 
> >> cd trunk
> >> bzr merge ../other-branch
> >> <in VC-dir, mark the modified files>
> >> <commit from VC-dir>
> >> 
> >> As mentioned on my response to Jason, it seems that bzr does not admit a
> >> `commit' comand with a list of files when there is a pending merge.
> >
> > Óscar, could you please ask on the Bazaar list if this is true, and
> > what can be done to work around that, so that VC could DTRT?
> 
> From `bzr help commit' :
> 
> >>>>>>>>>
> Selective commits:
>   If selected files are specified, only changes to those files are
>   committed.  If a directory is specified then the directory and
>   everything within it is committed.
> 
> ...
> 
>   A selective commit after a merge is not yet supported.
> <<<<<<<<<

Are you saying that this happened because a "merge" was not followed
by a "commit", and only because of that?  That means people are not
following the recommended workflow.  AFAIU, with Bazaar, failing to
commit after a merge is asking for trouble.

> So it is documented. Maybe VC could detect if there are pending merges
> parsing the output of `bzr st', or parse the error message returned by
> `bzr commit somefile' and detect that the failure was due to a pending
> merge

And then do what?

> What bzr shouldn't do is to output a backtrace. I'll file a bug report
> for that.

That was a backtrace in .bzr.log, no?  What's wrong with that?

Re: No commit in vc?

[Dan Nicolaescu]

Jan Djärv <jan.h.d@swipnet.se> writes:

  > Eli Zaretskii skrev:
  > >> Date: Thu, 28 Jan 2010 15:57:02 +0100
  > >> From: Jan Djärv <jan.h.d@swipnet.se>
  > >> Cc: emacs-devel@gnu.org
  > >>
  > >> I didn't mark any files.   Probably vc takes that to mean the same
  > >> as marking edited files.  This is a bug in vc that it tries to
  > >> check in individual files.
  > >
  > > What does VC do with other back ends when no files are marked?
  > >
  > >
  > 
  > If all modified files are in the same state (i.e. edited, as they
  > where in this case), vc commits them all.  This is true for Git and
  > CVS at least.

No, that's not how things are committed.

If any entry is marked, then it tries to commit the set of marked
entries.

If no entry is marked, then it tries to commit the entry the cursor is on. 
  - If the cursor is on a file, it will commit that file
  - If the cursor is on "./", or on any of the lines preceding
  "./" it will commit the current directory

Re: No commit in vc?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Are you saying that this happened because a "merge" was not followed
> by a "commit", and only because of that?

Jan tried to commit after the merge, but somehow VC-dir passed some
file names to the command instead of doing a non-selective commit as he
intended.

[snip]

>> So it is documented. Maybe VC could detect if there are pending merges
>> parsing the output of `bzr st', or parse the error message returned by
>> `bzr commit somefile' and detect that the failure was due to a pending
>> merge
>
> And then do what?

Report that circumstance to the user?

But probably showing the error msg reported by bzr is enough, and IIRC
VC already does this.

>> What bzr shouldn't do is to output a backtrace. I'll file a bug report
>> for that.
>
> That was a backtrace in .bzr.log, no?  What's wrong with that?

Nothing. I checked that the backtrace does not show in the console, so
it is fine.

Re: No commit in vc?

[Eli Zaretskii]

> Date: Thu, 28 Jan 2010 20:14:21 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> Eli Zaretskii skrev:
> >> Date: Thu, 28 Jan 2010 15:57:02 +0100
> >> From: Jan Djärv <jan.h.d@swipnet.se>
> >> Cc: emacs-devel@gnu.org
> >>
> >> I didn't mark any files.   Probably vc takes that to mean the same as marking 
> >> edited files.  This is a bug in vc that it tries to check in individual files.
> > 
> > What does VC do with other back ends when no files are marked?
> > 
> > 
> 
> If all modified files are in the same state (i.e. edited, as they where in 
> this case), vc commits them all.  This is true for Git and CVS at least.

Then it sounds like the bzr back end has a bug.

Re: No commit in vc?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 28 Jan 2010 20:57:24 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Are you saying that this happened because a "merge" was not followed
> > by a "commit", and only because of that?
> 
> Jan tried to commit after the merge, but somehow VC-dir passed some
> file names to the command instead of doing a non-selective commit as he
> intended.

And the merge was done from VC or from the command line?  If the
former, perhaps VC should suggest a commit right after the merge, and
then do it without paying attention to point position.

Re: No commit in vc?

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Óscar Fuentes <ofv@wanadoo.es>
  > > Date: Thu, 28 Jan 2010 20:57:24 +0100
  > > 
  > > Eli Zaretskii <eliz@gnu.org> writes:
  > > 
  > > > Are you saying that this happened because a "merge" was not followed
  > > > by a "commit", and only because of that?
  > > 
  > > Jan tried to commit after the merge, but somehow VC-dir passed some
  > > file names to the command instead of doing a non-selective commit as he
  > > intended.
  > 
  > And the merge was done from VC or from the command line?  If the
  > former, perhaps VC should suggest a commit right after the merge, and
  > then do it without paying attention to point position.

I am not sure that's easy/good/feasible.

Can this condition be detected somehow?
If yes, then vc-dir can insert a header to tell the user to do a commit
with no arguments.

Re: No commit in vc?

[Eli Zaretskii]

> Date: Thu, 28 Jan 2010 18:00:00 -0800 (PST)
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
>   > And the merge was done from VC or from the command line?  If the
>   > former, perhaps VC should suggest a commit right after the merge, and
>   > then do it without paying attention to point position.
> 
> I am not sure that's easy/good/feasible.
> 
> Can this condition be detected somehow?

You mean, the condition that there are pending uncommitted merges?  Or
the condition that the user is committing changes in specific files
when there are pending uncommitted merges?

Re: No commit in vc?

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > Date: Thu, 28 Jan 2010 18:00:00 -0800 (PST)
  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
  > > 
  > >   > And the merge was done from VC or from the command line?  If the
  > >   > former, perhaps VC should suggest a commit right after the merge, and
  > >   > then do it without paying attention to point position.
  > > 
  > > I am not sure that's easy/good/feasible.
  > > 
  > > Can this condition be detected somehow?
  > 
  > You mean, the condition that there are pending uncommitted merges?  Or

Yep

Re: No commit in vc?

[Óscar Fuentes]

Dan Nicolaescu <dann@ics.uci.edu> writes:

>   > >   > And the merge was done from VC or from the command line?  If the
>   > >   > former, perhaps VC should suggest a commit right after the merge, and
>   > >   > then do it without paying attention to point position.
>   > > 
>   > > I am not sure that's easy/good/feasible.
>   > > 
>   > > Can this condition be detected somehow?
>   > 
>   > You mean, the condition that there are pending uncommitted merges?  Or
>
> Yep

`bzr st' tells you:

removed:                                      
  admin/revdiff                               
modified:                                     
  .bzrignore                                  
  ChangeLog                                   
  admin/ChangeLog
[...some output elided...]
pending merge tips: (use -v to see all merge revisions)
  Chong Yidong 2010-01-28 * fileio.c (Frename_file): Fix last change (Bug#5487).

or the short version, `bzr st -S' :

 M  .bzrignore                                                         
 M  ChangeLog                                                          
 M  configure                                                          
 M  configure.in
[...some output elided...]
P   Chong Yidong 2010-01-28 * fileio.c (Frename_file): Fix last change (Bug#5487).

Maybe it is a good idea to display the condition that there are pending
merges (after all, you get that information along with the rest of the
working tree state.) IMHO it is not a good idea to change VC-dir's
behavior wrt point position for that state.

Re: No commit in vc?

[Eli Zaretskii]

> Date: Fri, 29 Jan 2010 01:40:00 -0800 (PST)
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>   > > Date: Thu, 28 Jan 2010 18:00:00 -0800 (PST)
>   > > From: Dan Nicolaescu <dann@ics.uci.edu>
>   > > Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
>   > > 
>   > >   > And the merge was done from VC or from the command line?  If the
>   > >   > former, perhaps VC should suggest a commit right after the merge, and
>   > >   > then do it without paying attention to point position.
>   > > 
>   > > I am not sure that's easy/good/feasible.
>   > > 
>   > > Can this condition be detected somehow?
>   > 
>   > You mean, the condition that there are pending uncommitted merges?
> 
> Yep

Seems like one of these will do:

 . "bzr status" says, among other things, "pending merge tips"

 . "bzr status -v" shows all the pending merges, 1 line per merge.

 . "bzr status -S" shows the pending merges in a shorter format.

Note that "bzr status FILE1 FILE2 ...", i.e. if you name some files
explicitly, does not show the pending merges, even if those files are
part of the uncommitted revisions merged from the other branch.

Here're the examples:

    eliz@fencepost:~/bzr/emacs/bidi$ bzr status
    modified:
      admin/notes/bugtracker
      doc/lispref/ChangeLog
      doc/lispref/display.texi
      ...
      src/xfns.c
    unknown:
      src/TAGS-LISP
    pending merge tips: (use -v to see all merge revisions) <<<<<<<<<<<
      Glenn Morris 2010-01-28 Explain mbox folder links.

    eliz@fencepost:~/bzr/emacs/bidi$ bzr status -v
    modified:
      admin/notes/bugtracker
      doc/lispref/ChangeLog
      doc/lispref/display.texi
      ...
      src/xfns.c
    unknown:
      src/TAGS-LISP
    pending merges:   <<<<<<<<<<<<<<<<<<<<<<<<<
      Glenn Morris 2010-01-28 Explain mbox folder links.
	Stefan Monnier 2010-01-28 Fix up spurious execute-bit on net/tramp.el
	Michael Albinus 2010-01-28 * net/ange-ftp.el (ange-ftp-insert-directory)...
	Chong Yidong 2010-01-28 * arc-mode.el (archive-zip-extract): Quote the a...
	...
	Chong Yidong 2010-01-25 Fix erc reconnection via non-default connectors ...
    eliz@fencepost:~/bzr/emacs/bidi$

    eliz@fencepost:~/bzr/emacs/bidi$ bzr status -S
     M  admin/notes/bugtracker
     M  doc/lispref/ChangeLog
     M  doc/lispref/display.texi
     ...
     M  src/m/mips.h
    P   Glenn Morris 2010-01-28 Explain mbox folder links.  <<<<<<<<<<<<

Re: No commit in vc?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 29 Jan 2010 11:48:00 +0100
> Cc: Dan Nicolaescu <dann@ics.uci.edu>
> 
> Maybe it is a good idea to display the condition that there are pending
> merges

Display how?  If in the modeline, then that indicator might not be
prominent enough to draw the attention.

I would like to repeat my suggestion to explicitly ask whether to
commit after a merge that results in pending merges, with the answer
defaulting to "yes".  If the user says "no", they know what they are
doing, and will not forget to commit after they do whatever it was
that caused them not to commit right away.  For others, it is a safe
bet that they don't have enough bzr flowing in their blood to
understand that they will be in trouble if they don't commit soon, so
we will be doing them a favor by suggesting to commit.

> IMHO it is not a good idea to change VC-dir's behavior wrt point
> position for that state.

Agreed.

Re: No commit in vc?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Maybe it is a good idea to display the condition that there are pending
>> merges
>
> Display how?  If in the modeline, then that indicator might not be
> prominent enough to draw the attention.

Perhaps on the top of the buffer, using a prominent face.

> I would like to repeat my suggestion to explicitly ask whether to
> commit after a merge that results in pending merges, with the answer
> defaulting to "yes".

Well, in bzr (contrary to git) all merge operations result in pending
merges. Added to this, you are supposed to review the results, not only
in case there are conflicts, but in general (that's what bzr people say
to explain why all merges require an explicit commit). Finally, AFAIK
VC-dir has no support for executing a `bzr merge'.

>  If the user says "no", they know what they are
> doing, and will not forget to commit after they do whatever it was
> that caused them not to commit right away.  For others, it is a safe
> bet that they don't have enough bzr flowing in their blood to
> understand that they will be in trouble if they don't commit soon, so
> we will be doing them a favor by suggesting to commit.

What VC-dir could do is to warn the user if there is a pending merge
and he tries to do a selective commit. For me it is good enough what it
does now: try to execute the command and show the error message reported
by bzr.

Re: No commit in vc?

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Óscar Fuentes <ofv@wanadoo.es>
  > > Date: Fri, 29 Jan 2010 11:48:00 +0100
  > > Cc: Dan Nicolaescu <dann@ics.uci.edu>
  > > 
  > > Maybe it is a good idea to display the condition that there are pending
  > > merges
  > 
  > Display how?  If in the modeline, then that indicator might not be
  > prominent enough to draw the attention.

I've already said that in a previous message:
"If yes, then vc-dir can insert a header to tell the user to do a commit
with no arguments."

Here's an untested p

Index: vc-bzr.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/vc-bzr.el,v
retrieving revision 1.94
diff -u -3 -p -u -p -r1.94 vc-bzr.el
--- vc-bzr.el	9 Dec 2009 06:04:12 -0000	1.94
+++ vc-bzr.el	29 Jan 2010 17:20:25 -0000
@@ -663,6 +657,8 @@ stream.  Standard error output is discar
 		       ;; FIXME: maybe this warning can be put in the vc-dir header...
 		       ("wor" . not-found)
                        ;; Ignore "P " and "P." for pending patches.
-		       ("P  " . not-found)
-		       ("P. " . not-found)
+		       ("P  " . pending-merge)
+		       ("P. " . pending-merge)
                        ))
 	(translated nil)
 	(result nil))
@@ -685,5 +681,7 @@ stream.  Standard error output is discar
 		 (entry (assoc file result)))
 	    (when entry
 	      (setf (nth 1 entry) 'conflict))))
+	 ((eq translated 'pending-merge)
+	  (setq vc-bzr-dir-pending-merge t))
 	 ((eq translated 'renamed)
 	  (re-search-forward "R   \\(.*\\) => \\(.*\\)$" (line-end-position) t)
@@ -702,6 +701,7 @@
       (funcall update-function result)))
 
 (defun vc-bzr-dir-status (dir update-function)
   "Return a list of conses (file . state) for DIR."
+  (set (make-local-variable 'vc-bzr-dir-pending-merge) nil)
   (vc-bzr-command "status" (current-buffer) 'async dir "-v" "-S")
   (vc-exec-after
@@ -749,6 +766,8 @@ stream.  Standard error output is discar
 
 (defun vc-bzr-extra-status-menu () vc-bzr-extra-menu-map)
 
+(defvar vc-bzr-dir-pending-merge nil)
+
 (defun vc-bzr-dir-extra-headers (dir)
   (let*
       ((str (with-temp-buffer
@@ -798,7 +817,14 @@ stream.  Standard error output is discar
 		    'help-echo shelve-help-echo)
 	(propertize "No shelved changes"
 		    'help-echo shelve-help-echo
-		    'face 'font-lock-variable-name-face))))))
+		    'face 'font-lock-variable-name-face)))
+     (when vc-bzr-dir-pending-merge
+       (concat
+	(propertize "Warning            : " 'face 'font-lock-warning-face
+		    'help-echo shelve-help-echo)
+	(propertize "Pending merges, commit recommended before any other action"
+		    'help-echo "Explain here what is going on"
+		    'face 'font-lock-warning-face))))))
 
 (defun vc-bzr-shelve (name)
   "Create a shelve."

Re: No commit in vc?

[Óscar Fuentes]

Dan Nicolaescu <dann@ics.uci.edu> writes:

>   > > Maybe it is a good idea to display the condition that there are
>   > > pending merges
>   > 
>   > Display how?  If in the modeline, then that indicator might not be
>   > prominent enough to draw the attention.
>
> I've already said that in a previous message:
> "If yes, then vc-dir can insert a header to tell the user to do a commit
> with no arguments."
>
> Here's an untested p

[snip]

> +	(propertize "Pending merges, commit recommended before any other action"
> +		    'help-echo "Explain here what is going on"
> +		    'face 'font-lock-warning-face))))))

Saying that there are pending merges is enough. It is not VC-dir
business to recommend what the user should or should not do, just
provide the relevant information. And in this case the recommendation is
misleading because, apart from commit, there are operations which are
acceptable and useful when there is a pending merge: diff, revert,
resolve, editing the changes, etc. What is not acceptable is a selective
commit, and bzr already blocks that.

Knowing that there is a pending merge is important, so this patch is
very useful.

Re: No commit in vc?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 29 Jan 2010 19:29:12 +0100
> 
> > +	(propertize "Pending merges, commit recommended before any other action"
> > +		    'help-echo "Explain here what is going on"
> > +		    'face 'font-lock-warning-face))))))
> 
> Saying that there are pending merges is enough. It is not VC-dir
> business to recommend what the user should or should not do, just
> provide the relevant information.

I disagree.  I think this recommendation is a good idea.  Maybe just
change the wording slightly:

  Pending merges, commit recommended before any further development

> And in this case the recommendation is misleading because, apart
> from commit, there are operations which are acceptable and useful
> when there is a pending merge: diff, revert, resolve, editing the
> changes, etc.

Well, the modified wording covers that, I think.

Re: No commit in vc?

[Thien-Thi Nguyen]

() Eli Zaretskii <eliz@gnu.org>
() Fri, 29 Jan 2010 21:56:47 +0200

   Pending merges, commit recommended before any further development

I don't think it should be Emacs' business to recommend stuff like this.

thi

Re: No commit in vc?

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnuvola.org>
> Date: Sat, 30 Jan 2010 16:52:50 +0100
> 
> () Eli Zaretskii <eliz@gnu.org>
> () Fri, 29 Jan 2010 21:56:47 +0200
> 
>    Pending merges, commit recommended before any further development
> 
> I don't think it should be Emacs' business to recommend stuff like this.

Whose business is that, then?  People are getting burned by this time
and again.

Re: No commit in vc?

[Thien-Thi Nguyen]

() Eli Zaretskii <eliz@gnu.org>
() Sat, 30 Jan 2010 18:44:00 +0200

   Whose business is that, then?
   People are getting burned by this time and again.

It's a policy issue.  Thus, the business belongs to
whoever purports to follow the (purported) policy,
that being, the people getting burned.

In this case the people getting burned are Emacs
programmers (trying to follow/hammer out a new workflow),
so it is tempting to hardcode the resolution of hard-won
wisdom in the primary programming tool at hand (Emacs).

However, that is not the case universally.  I can imagine
a workflow (policy) whereby a programmer needs to do several
"bzr merge" operations prior to the "bzr commit".  This
programmer would view Emacs' recommendation as irrelevant
at best.

By avoiding that recommendation, we sidestep this problem.

But turning (back) inward: To stop us being burned time and time
again requires our understanding to grow, and that is no-one's
business but ours.

thi

Re: No commit in vc?

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Óscar Fuentes <ofv@wanadoo.es>
  > > Date: Fri, 29 Jan 2010 19:29:12 +0100
  > > 
  > > > +	(propertize "Pending merges, commit recommended before any other action"
  > > > +		    'help-echo "Explain here what is going on"
  > > > +		    'face 'font-lock-warning-face))))))
  > > 
  > > Saying that there are pending merges is enough. It is not VC-dir
  > > business to recommend what the user should or should not do, just
  > > provide the relevant information.
  > 
  > I disagree.  I think this recommendation is a good idea.  Maybe just
  > change the wording slightly:
  > 
  >   Pending merges, commit recommended before any further development
  > 
  > > And in this case the recommendation is misleading because, apart
  > > from commit, there are operations which are acceptable and useful
  > > when there is a pending merge: diff, revert, resolve, editing the
  > > changes, etc.
  > 
  > Well, the modified wording covers that, I think.

It's still too terse.  The goal is to explain what is going on to people
that are not used to bzr, and will get confused by getting an error on a
subsequent selective commit.
What's the reason not to have a very clear and unambiguous explanation?
If it avoids reading help/ searching for clues, user will only be happy.

Here's a new version of this, just replace this function in vc-bzr.el
Please feel free to improve the text.

(defun vc-bzr-dir-extra-headers (dir)
  (let*
      ((str (with-temp-buffer
              (vc-bzr-command "info" t 0 dir)
              (buffer-string)))
       (shelve (vc-bzr-shelve-list))
       (shelve-help-echo "Use M-x vc-bzr-shelve to create shelves")
       (root-dir (vc-bzr-root dir))
       (pending-merge
        (file-exists-p
         (expand-file-name ".bzr/checkout/merge-hashes" root-dir)))
       (light-checkout
        (when (string-match ".+light checkout root: \\(.+\\)$" str)
          (match-string 1 str)))
       (light-checkout-branch
        (when light-checkout
          (when (string-match ".+checkout of branch: \\(.+\\)$" str)
            (match-string 1 str)))))
    (concat
     (propertize "Parent branch      : " 'face 'font-lock-type-face)
     (propertize
      (if (string-match "parent branch: \\(.+\\)$" str)
          (match-string 1 str)
        "None")
       'face 'font-lock-variable-name-face)
     "\n"
      (when light-checkout
        (concat
         (propertize "Light checkout root: " 'face 'font-lock-type-face)
         (propertize light-checkout 'face 'font-lock-variable-name-face)
         "\n"))
      (when light-checkout-branch
        (concat
         (propertize "Checkout of branch : " 'face 'font-lock-type-face)
         (propertize light-checkout-branch 'face 'font-lock-variable-name-face)
         "\n"))
      (when pending-merge
        (concat
         (propertize "Warning            : " 'face 'font-lock-warning-face
                     'help-echo shelve-help-echo)
         (propertize "Pending merges, commit recommended before any other action"
                     'help-echo (format "A merge has been performed.\nA commit from the top-level directory (%s)\nis required before being able to check in anything else" root-dir)
                     'face 'font-lock-warning-face)
         "\n"))
      (if shelve
          (concat
           (propertize "Shelves            :\n" 'face 'font-lock-type-face
                       'help-echo shelve-help-echo)
           (mapconcat
            (lambda (x)
              (propertize x
                          'face 'font-lock-variable-name-face
                          'mouse-face 'highlight
                          'help-echo "mouse-3: Show shelve menu\nA: Apply and keep shelf\nP: Apply and remove shelf (pop)\nS: Snapshot to a shelf\nC-k: Delete shelf"
                          'keymap vc-bzr-shelve-map))
            shelve "\n"))
        (concat
         (propertize "Shelves            : " 'face 'font-lock-type-face
                     'help-echo shelve-help-echo)
         (propertize "No shelved changes"
                     'help-echo shelve-help-echo
                     'face 'font-lock-variable-name-face))))))

Re: No commit in vc?

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnuvola.org>
> Date: Sat, 30 Jan 2010 20:02:53 +0100
> 
> However, that is not the case universally.  I can imagine
> a workflow (policy) whereby a programmer needs to do several
> "bzr merge" operations prior to the "bzr commit".  This
> programmer would view Emacs' recommendation as irrelevant
> at best.

This programmer knows what she is doing, and won't be averted by the
recommendation.  It's the same as "File FOO already exists; overwrite
anyway?": I can imagine a workflow whereby a programmer needs to
overwrite an existing file.  In fact, it happened to me just today.

Re: No commit in vc?

[Eli Zaretskii]

> Date: Sat, 30 Jan 2010 11:49:11 -0800 (PST)
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> It's still too terse.  The goal is to explain what is going on to people
> that are not used to bzr, and will get confused by getting an error on a
> subsequent selective commit.

I agree.

> What's the reason not to have a very clear and unambiguous explanation?
> If it avoids reading help/ searching for clues, user will only be happy.
> 
> Here's a new version of this, just replace this function in vc-bzr.el
> Please feel free to improve the text.

I'm fine with it, I would just replace

      before being able to check in anything else
with

      before being able to check in any further changes

because technically, "commit" and "check in" are synonyms.

Re: No commit in vc?

[Thien-Thi Nguyen]

() Eli Zaretskii <eliz@gnu.org>
() Sat, 30 Jan 2010 23:28:48 +0200

   > From: Thien-Thi Nguyen <ttn@gnuvola.org>
   > Date: Sat, 30 Jan 2010 20:02:53 +0100
   > 
   > However, that is not the case universally.  I can imagine a
   > workflow (policy) whereby a programmer needs to do several
   > "bzr merge" operations prior to the "bzr commit".  This
   > programmer would view Emacs' recommendation as irrelevant at
   > best.

   This programmer knows what she is doing, and won't be averted
   by the recommendation.  It's the same as "File FOO already
   exists; overwrite anyway?":

The "overwrite anyway?" blurb is not the same:
- It is not a recommendation.
- It influences (via the user's response) Emacs' behavior.

If you want it to be the same, drop "we recommend", implement
"commit now?", and arrange to have that query as part of the
command that produces the "pending merges" state.

In the context of the proposal (as an adjunct to the status text,
rather than a decision requiring user input), however, a "pending
merges" blurb is sufficient: It accurately reflects the status
without gratuitously presuming any particular workflow.

thi

Re: No commit in vc?

[Juri Linkov]

>     unknown:
>       src/TAGS-LISP

Any reason src/TAGS-LISP is omitted from .bzrignore?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: No commit in vc?

[Juri Linkov]

>       (when pending-merge
>         (concat
>          (propertize "Warning            : " 'face 'font-lock-warning-face
>                      'help-echo shelve-help-echo)
>          (propertize "Pending merges, commit recommended before any other action"
>                      'help-echo (format "A merge has been performed.\nA commit from the top-level directory (%s)\nis required before being able to check in anything else" root-dir)
>                      'face 'font-lock-warning-face)
>          "\n"))
>       (if shelve
>           (concat
>            (propertize "Shelves            :\n" 'face 'font-lock-type-face
>                        'help-echo shelve-help-echo)
>            (mapconcat
>             (lambda (x)
>               (propertize x
>                           'face 'font-lock-variable-name-face
>                           'mouse-face 'highlight
>                           'help-echo "mouse-3: Show shelve menu\nA: Apply and keep shelf\nP: Apply and remove shelf (pop)\nS: Snapshot to a shelf\nC-k: Delete shelf"
>                           'keymap vc-bzr-shelve-map))
>             shelve "\n"))
>         (concat
>          (propertize "Shelves            : " 'face 'font-lock-type-face
>                      'help-echo shelve-help-echo)
>          (propertize "No shelved changes"
>                      'help-echo shelve-help-echo
>                      'face 'font-lock-variable-name-face))))))

I recommend to not display inactive features because "No shelved changes"
adds more noise as there will be no "No pending merges".

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: No commit in vc?

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: Dan Nicolaescu <dann@ics.uci.edu>,  emacs-devel@gnu.org
> Date: Sun, 31 Jan 2010 00:52:07 +0200
> 
> >     unknown:
> >       src/TAGS-LISP
> 
> Any reason src/TAGS-LISP is omitted from .bzrignore?

None that I could think of.

Re: No commit in vc?

[Stefan Monnier]

> However, that is not the case universally.  I can imagine
> a workflow (policy) whereby a programmer needs to do several
> "bzr merge" operations prior to the "bzr commit".  This
> programmer would view Emacs' recommendation as irrelevant
> at best.

This is discouraged and poorly supported by `bzr', so at least for
vc-bzr.el it makes sense.

This said, it's OK to replace "recommend" with some other formulation,
like "pending merges: you may want to commit before any further development"
if that soothes you,


        Stefan

Re: No commit in vc?

[Thien-Thi Nguyen]

() Stefan Monnier <monnier@iro.umontreal.ca>
() Sun, 31 Jan 2010 10:00:37 -0500

   This is discouraged and poorly supported by `bzr', so at least
   for vc-bzr.el it makes sense.

Now, perhaps, but who knows if a future bzr might be improved?

   This said, it's OK to replace "recommend" with some other
   formulation, like "pending merges: you may want to commit
   before any further development" if that soothes you,

I think any forumalation is fine, in the right place.
However, the status message is not the right place.

What this thread has taught me is that for bzr, "merge" does
not imply "commit".  To DTRT, VC "merge" should allow for
this split in all backends, and (perhaps with a prefix arg)
do a (perhaps confirmed by y-or-n-p) commit.  That is, VC
"merge" should not assume backend "merge" implies "commit".

If VC "merge" MUST imply a "commit" for hysterical raisons
(i don't know, never tried VC "merge"), we can always coin
an operation that means "apply changes from a branch but
don't commit", and make VC "merge" for bzr do "bzr merge;
bzr commit".

In this way, there is no more need to recommend anything.
If the user might want to do something, that can be expressed
directly to Emacs.

thi

Re: No commit in vc?

[David De La Harpe Golden]

Thien-Thi Nguyen wrote:


> What this thread has taught me is that for bzr, "merge" does
> not imply "commit".  To DTRT, VC "merge" should allow for
> this split in all backends, 

Yeah, merge doesn't necessarily imply commit in git either, e.g. when 
there's conflicts... and you can in fact suppress automagic stuff with 
"git merge --no-commit --no-ff"

(the --no-ff stops it doing a fastforward even if a fastforward
is possible. Actually, you'd seldom want to not do it, but the option's
there in vaguely recent git, contrary to what bzr folk seemed to think IIRC)

Re: No commit in vc?

[Stefan Monnier]

> What this thread has taught me is that for bzr, "merge" does
> not imply "commit".

AFAIK this is indeed the case for most VCS.


        Stefan

Re: No commit in vc?

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > >       (when pending-merge
  > >         (concat
  > >          (propertize "Warning            : " 'face 'font-lock-warning-face
  > >                      'help-echo shelve-help-echo)
  > >          (propertize "Pending merges, commit recommended before any other action"
  > >                      'help-echo (format "A merge has been performed.\nA commit from the top-level directory (%s)\nis required before being able to check in anything else" root-dir)
  > >                      'face 'font-lock-warning-face)
  > >          "\n"))
  > >       (if shelve
  > >           (concat
  > >            (propertize "Shelves            :\n" 'face 'font-lock-type-face
  > >                        'help-echo shelve-help-echo)
  > >            (mapconcat
  > >             (lambda (x)
  > >               (propertize x
  > >                           'face 'font-lock-variable-name-face
  > >                           'mouse-face 'highlight
  > >                           'help-echo "mouse-3: Show shelve menu\nA: Apply and keep shelf\nP: Apply and remove shelf (pop)\nS: Snapshot to a shelf\nC-k: Delete shelf"
  > >                           'keymap vc-bzr-shelve-map))
  > >             shelve "\n"))
  > >         (concat
  > >          (propertize "Shelves            : " 'face 'font-lock-type-face
  > >                      'help-echo shelve-help-echo)
  > >          (propertize "No shelved changes"
  > >                      'help-echo shelve-help-echo
  > >                      'face 'font-lock-variable-name-face))))))
  > 
  > I recommend to not display inactive features because "No shelved changes"
  > adds more noise as there will be no "No pending merges".

It's not inactive, it has a tooltip, and the plan is that it will get a
menu and probably some buttons to create a shelf and put a snapshot on a shelf.

Re: No commit in vc?

[Dan Nicolaescu]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

  > () Stefan Monnier <monnier@iro.umontreal.ca>
  > () Sun, 31 Jan 2010 10:00:37 -0500
  > 
  >    This is discouraged and poorly supported by `bzr', so at least
  >    for vc-bzr.el it makes sense.
  > 
  > Now, perhaps, but who knows if a future bzr might be improved?
  > 
  >    This said, it's OK to replace "recommend" with some other
  >    formulation, like "pending merges: you may want to commit
  >    before any further development" if that soothes you,
  > 
  > I think any forumalation is fine, in the right place.
  > However, the status message is not the right place.
  > 
  > What this thread has taught me is that for bzr, "merge" does
  > not imply "commit".  To DTRT, VC "merge" should allow for
  > this split in all backends, and (perhaps with a prefix arg)
  > do a (perhaps confirmed by y-or-n-p) commit.  That is, VC
  > "merge" should not assume backend "merge" implies "commit".

There's no VC merge for bzr.

Re: No commit in vc?

[Juri Linkov]

> It's not inactive, it has a tooltip, and the plan is that it will get a
> menu and probably some buttons to create a shelf and put a snapshot on a shelf.

Then with a button it makes sense to shelve/unshelve using only keyboard
since there is no key binding for vc-bzr-shelve.  Maybe `merge' (when implemented)
should have a button as well on the "Parent branch" text?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: No commit in vc?

[Thien-Thi Nguyen]

() Dan Nicolaescu <dann@ics.uci.edu>
() Sun, 31 Jan 2010 20:34:26 -0800 (PST)

   There's no VC merge for bzr.

Would current VC "merge" semantics for other backends be
incompatible with an explicit split between "merge" and "commit"?

thi

Re: No commit in vc?

[Stefan Monnier]

> Would current VC "merge" semantics for other backends be
> incompatible with an explicit split between "merge" and "commit"?

Not at all.


        Stefan

Re: No commit in vc?

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > > It's not inactive, it has a tooltip, and the plan is that it will get a
  > > menu and probably some buttons to create a shelf and put a snapshot on a shelf.
  > 
  > Then with a button it makes sense to shelve/unshelve using only keyboard
  > since there is no key binding for vc-bzr-shelve.  Maybe `merge' (when implemented)
  > should have a button as well on the "Parent branch" text?

Probably, and maybe push, pull, list branches, switch branch too.

Re: No commit in vc?

[Juri Linkov]

>>       (when pending-merge
>>         (concat
>>          (propertize "Warning            : " 'face 'font-lock-warning-face
>>                      'help-echo shelve-help-echo)
>>          (propertize "Pending merges, commit recommended before any other action"

This warning is permanent and displayed even when there are no pending
merges regardless whether the branch is lightweight or bound heavyweight.
It seems .bzr/checkout/merge-hashes contains some old information from
previous merges.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: No commit in vc?

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>>>       (when pending-merge
>>>         (concat
>>>          (propertize "Warning            : " 'face 'font-lock-warning-face
>>>                      'help-echo shelve-help-echo)
>>>          (propertize "Pending merges, commit recommended before any other action"
>
> This warning is permanent and displayed even when there are no pending
> merges regardless whether the branch is lightweight or bound heavyweight.
> It seems .bzr/checkout/merge-hashes contains some old information from
> previous merges.

I am seeing this useless "warning" popping up every single time I use
VC-dir, on the bound heavyweight branch on which I work.

Unless there is a way to detect if a branch is bound and disable this
warning, I think the change should be reverted.

Re: No commit in vc?

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Juri Linkov <juri@jurta.org> writes:
  > 
  > >>>       (when pending-merge
  > >>>         (concat
  > >>>          (propertize "Warning            : " 'face 'font-lock-warning-face
  > >>>                      'help-echo shelve-help-echo)
  > >>>          (propertize "Pending merges, commit recommended before any other action"
  > >
  > > This warning is permanent and displayed even when there are no pending
  > > merges regardless whether the branch is lightweight or bound heavyweight.
  > > It seems .bzr/checkout/merge-hashes contains some old information from
  > > previous merges.
  > 
  > I am seeing this useless "warning" popping up every single time I use
  > VC-dir, on the bound heavyweight branch on which I work.
  > 
  > Unless there is a way to detect if a branch is bound and disable this
  > warning, I think the change should be reverted.

Sorry, I somehow missed Juri's message.   It seems that this is not
related to bound branches.  It looks like using the existence of
.bzr/checkout/merge-hashes to detect pending merges is not reliable.
I'll disable this as soon as I get a chance (if nobody beats me to it).

A better method to figure out the pending merge is needed, otherwise
this the header is just annoying.

Re: No commit in vc?

[Eli Zaretskii]

> Date: Thu, 4 Feb 2010 21:07:08 -0800 (PST)
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: Juri Linkov <juri@jurta.org>, Óscar Fuentes <ofv@wanadoo.es>,
>         Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> Sorry, I somehow missed Juri's message.   It seems that this is not
> related to bound branches.  It looks like using the existence of
> .bzr/checkout/merge-hashes to detect pending merges is not reliable.
> I'll disable this as soon as I get a chance (if nobody beats me to it).
> 
> A better method to figure out the pending merge is needed, otherwise
> this the header is just annoying.

I didn't track this thread, either, so I may be missing something: why
.bzr/checkout/merge-hashes?  I thought we agreed to use the flags
displayed by "bzr status" for the fact that there are pending
uncommitted merges.

Re: No commit in vc?

[Juri Linkov]

>> A better method to figure out the pending merge is needed, otherwise
>> this the header is just annoying.
>
> I didn't track this thread, either, so I may be missing something: why
> .bzr/checkout/merge-hashes?  I thought we agreed to use the flags
> displayed by "bzr status" for the fact that there are pending
> uncommitted merges.

Yes, just (search-forward "pending merge") in the output of `bzr status`.

-- 
Juri Linkov
http://www.jurta.org/emacs/