GNU bug report logs -
#3860
vc-svn calls "svn resolved" without permission
Previous Next
Reported by: James Y Knight <jknight <at> fuhm.net>
Date: Wed, 15 Jul 2009 20:30:03 UTC
Severity: normal
Fixed in version 31.1
Done: Mauro Aranda <maurooaranda <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3860 in the body.
You can then email your comments to 3860 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#3860; Package
emacs.
(Wed, 15 Jul 2009 20:30:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
James Y Knight <jknight <at> fuhm.net>:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
(Wed, 15 Jul 2009 20:30:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
Hi, I recently just switched to from Emacs 21 to Emacs 22 (22.2.1, on
Debian Lenny), and was a bit disappointed to discover that vc-svn is
now automatically calling "svn resolved" on files when I save them
after removing conflict markers.
I use svn's list of conflicted files while working on merges, and tend
to only call "resolved" on them when I'm *actually done* fixing a
group of files. I'll note that emacs automatically calling "svn
resolved" also destroys the .mine, .rOLD, and .rNEW files, which I
wasn't actually done with yet. Having them disappear out from under me
just because I've *partly* fixed things and saved is very
counterintuitive!
There's a reason that svn makes you run "svn resolved" on files to
note them as resolved instead of just checking for the lack of
conflict markers, and vc-svn is totally destroying that nice behavior
of svn. If it was a good idea to autoresolve when there's no conflict
marker in the file, then "svn commit" would already do that!
IMO, the function "vc-svn-resolve-when-done" should just be removed
entirely. But if not, it really should *at least* be asking for
confirmation first before causing the merge working data to be deleted.
Relatedly, it would also be great if there was a key to run svn
resolved. I've had this addition in my .emacs for a while to achieve
that:
(defun svn-resolved ()
"Resolve conflict on current buffer"
(interactive)
(shell-command (concat "svn resolved " (buffer-file-name))))
(define-key 'vc-prefix-map "R" 'svn-resolved)
James
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Thu, 21 Jan 2021 16:42:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 3860 <at> debbugs.gnu.org (full text, mbox):
James Y Knight <jknight <at> fuhm.net> writes:
> Hi, I recently just switched to from Emacs 21 to Emacs 22 (22.2.1, on
> Debian Lenny), and was a bit disappointed to discover that vc-svn is
> now automatically calling "svn resolved" on files when I save them
> after removing conflict markers.
(I'm going through old bug reports that unfortunately got no response at
the time.)
This behaviour still seems to be present in Emacs 28, as far as I can
see.
> I use svn's list of conflicted files while working on merges, and tend
> to only call "resolved" on them when I'm *actually done* fixing a
> group of files. I'll note that emacs automatically calling "svn
> resolved" also destroys the .mine, .rOLD, and .rNEW files, which I
> wasn't actually done with yet. Having them disappear out from under me
> just because I've *partly* fixed things and saved is very
> counterintuitive!
I haven't used SVN myself in ages, and I don't even recall what my work
flow used to be. However, adding a variable to suppress
`vc-svn-resolve-when-done' might make sense? Anybody who actually uses
SVN still got an opinion here?
That this bug report is 11 years old and there doesn't seem to be any
other bug reports about this does perhaps indicate that people are fine
with how it works, and nothing should be done here.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 21 Jan 2021 16:42:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Thu, 21 Jan 2021 19:34:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 3860 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Thu, 21 Jan 2021 17:41:08 +0100
> Cc: 3860 <at> debbugs.gnu.org, spiegel <at> gnu.org
>
> > I use svn's list of conflicted files while working on merges, and tend
> > to only call "resolved" on them when I'm *actually done* fixing a
> > group of files. I'll note that emacs automatically calling "svn
> > resolved" also destroys the .mine, .rOLD, and .rNEW files, which I
> > wasn't actually done with yet. Having them disappear out from under me
> > just because I've *partly* fixed things and saved is very
> > counterintuitive!
>
> I haven't used SVN myself in ages, and I don't even recall what my work
> flow used to be. However, adding a variable to suppress
> `vc-svn-resolve-when-done' might make sense? Anybody who actually uses
> SVN still got an opinion here?
I think if we are going to make this optional with SVN, we should make
it optional with the other back-ends as well. VC always presented a
uniform UI and user experience with all back-ends, as far as possible
and reasonable. In this case, I think automatically marking the
conflicts as resolved makes a lot of sense, but I won't object to make
it opt-out, as long as it's done for every VCS that can support it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Thu, 21 Jan 2021 22:36:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 3860 <at> debbugs.gnu.org (full text, mbox):
On 21.01.2021 21:33, Eli Zaretskii wrote:
> I think if we are going to make this optional with SVN, we should make
> it optional with the other back-ends as well. VC always presented a
> uniform UI and user experience with all back-ends, as far as possible
> and reasonable. In this case, I think automatically marking the
> conflicts as resolved makes a lot of sense, but I won't object to make
> it opt-out, as long as it's done for every VCS that can support it.
So someone might want to generalize the Git-specific variable:
vc-git-resolve-conflicts.
But they'd have to consider what to do with the special value
'unstage-maybe', which doesn't really make sense for other backends.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Fri, 22 Jan 2021 07:30:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 3860 <at> debbugs.gnu.org (full text, mbox):
> Cc: 3860 <at> debbugs.gnu.org, jknight <at> fuhm.net, spiegel <at> gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 22 Jan 2021 00:35:07 +0200
>
> On 21.01.2021 21:33, Eli Zaretskii wrote:
> > I think if we are going to make this optional with SVN, we should make
> > it optional with the other back-ends as well. VC always presented a
> > uniform UI and user experience with all back-ends, as far as possible
> > and reasonable. In this case, I think automatically marking the
> > conflicts as resolved makes a lot of sense, but I won't object to make
> > it opt-out, as long as it's done for every VCS that can support it.
>
> So someone might want to generalize the Git-specific variable:
> vc-git-resolve-conflicts.
Yes, I think so.
> But they'd have to consider what to do with the special value
> 'unstage-maybe', which doesn't really make sense for other backends.
Right.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Fri, 22 Jan 2021 17:26:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 3860 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> So someone might want to generalize the Git-specific variable:
> vc-git-resolve-conflicts.
Yeah, makes sense.
> But they'd have to consider what to do with the special value
> 'unstage-maybe', which doesn't really make sense for other backends.
Yup.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Removed tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Fri, 22 Jan 2021 17:26:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Mon, 25 Jan 2021 01:09:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 3860 <at> debbugs.gnu.org (full text, mbox):
On Thu, January 21, 2021 11:41 am, Lars Ingebrigtsen wrote:
> James Y Knight <jknight <at> fuhm.net> writes:
>
>> Hi, I recently just switched to from Emacs 21 to Emacs 22 (22.2.1, on
>> Debian Lenny), and was a bit disappointed to discover that vc-svn is
>> now automatically calling "svn resolved" on files when I save them
>> after removing conflict markers.
>
> (I'm going through old bug reports that unfortunately got no response at
> the time.)
>
> This behaviour still seems to be present in Emacs 28, as far as I can
> see.
>
>> I use svn's list of conflicted files while working on merges, and tend
>> to only call "resolved" on them when I'm *actually done* fixing a
>> group of files. I'll note that emacs automatically calling "svn
>> resolved" also destroys the .mine, .rOLD, and .rNEW files, which I
>> wasn't actually done with yet. Having them disappear out from under me
>> just because I've *partly* fixed things and saved is very
>> counterintuitive!
>
> I haven't used SVN myself in ages, and I don't even recall what my work
> flow used to be. However, adding a variable to suppress
> `vc-svn-resolve-when-done' might make sense? Anybody who actually uses
> SVN still got an opinion here?
>
> That this bug report is 11 years old and there doesn't seem to be any
> other bug reports about this does perhaps indicate that people are fine
> with how it works, and nothing should be done here.
I haven't used svn in years at this point, so I really don't care what
happens with vc-svn anymore. But I had personally long ago worked around
this bug with:
(defadvice vc-svn-resolve-when-done (around dont-svn-resolve activate)
nil)
However, I will mention that I find the equivalent behavior in Emacs's Git
integration just as bad -- for the same reason of it discarding important
information! There's a reason that "git add" is a separate operation, and
having emacs silently run that when doing a "save" operation destroys
information, unexpectedly.
I really think this behavior should _never_ have been made default
behavior in _any_ VC mode. Discarding data is quite a bad default, and
extremely unexpected from "save". But, hey, at least vc-git can be
configured, so that's nice.
(And, I'll note that it took me at least a _year_ to figure out that the
broken behavior after resolving conflicts in Git was an emacs vc-git bug,
and not Git itself having lost the ability to 3-way-conflict-diff the
conflict resolution! It's incredibly non-obvious that emacs is breaking
this!)
I'm not the only one to complain about this, e.g.
https://emacs.stackexchange.com/questions/51206/disabling-automatic-add-after-resolving-git-conflict
For that matter, bug 20292 which added the emacs config option has
multiple complaints about this behavior, as well...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Mon, 25 Jan 2021 01:58:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 3860 <at> debbugs.gnu.org (full text, mbox):
On 25.01.2021 00:36, James Y Knight wrote:
> I haven't used svn in years at this point, so I really don't care what
> happens with vc-svn anymore. But I had personally long ago worked around
> this bug with:
> (defadvice vc-svn-resolve-when-done (around dont-svn-resolve activate)
> nil)
Fair enough.
> However, I will mention that I find the equivalent behavior in Emacs's Git
> integration just as bad -- for the same reason of it discarding important
> information! There's a reason that "git add" is a separate operation, and
> having emacs silently run that when doing a "save" operation destroys
> information, unexpectedly.
>
> I really think this behavior should _never_ have been made default
> behavior in _any_ VC mode. Discarding data is quite a bad default, and
> extremely unexpected from "save". But, hey, at least vc-git can be
> configured, so that's nice.
>
> (And, I'll note that it took me at least a _year_ to figure out that the
> broken behavior after resolving conflicts in Git was an emacs vc-git bug,
> and not Git itself having lost the ability to 3-way-conflict-diff the
> conflict resolution! It's incredibly non-obvious that emacs is breaking
> this!)
>
> I'm not the only one to complain about this, e.g.
> https://emacs.stackexchange.com/questions/51206/disabling-automatic-add-after-resolving-git-conflict
>
> For that matter, bug 20292 which added the emacs config option has
> multiple complaints about this behavior, as well...
"Multiple complaints" seems to be an overstatement: we have one question
of SE, and one disagreement in the bug comments. The disagreement is
from the current Git maintainer, which is significant, but still not a
gospel, since VC tries to provide a "unified" interface to many VCSes,
not just Git.
That said, I personally customize vc-git-resolve-conflicts to nil, and
'C-x v v' now does resolve the conflicts all right (even though it
doesn't refresh the vc-state of such buffers automatically). So nil
works okay, and it would be my vote.
But the current behavior of that variable and its default value have
been requested by Emacs maintainers, one former and one current. As
such, I'll let the maintainers decide on whether the default can be
changed here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Tue, 26 Jan 2021 00:29:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 3860 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> But the current behavior of that variable and its default value have
> been requested by Emacs maintainers, one former and one current. As
> such, I'll let the maintainers decide on whether the default can be
> changed here.
I have found the way Emacs handles conflicts somewhat confusing a few
times, but I'm not sure whether this is due to the automatic resolving
or not. I'll try to pay more attention next time. :-/
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Thu, 13 Mar 2025 12:06:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 3860 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: 3860 <at> debbugs.gnu.org, jknight <at> fuhm.net, spiegel <at> gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Fri, 22 Jan 2021 00:35:07 +0200
>>
>> On 21.01.2021 21:33, Eli Zaretskii wrote:
>> > I think if we are going to make this optional with SVN, we should make
>> > it optional with the other back-ends as well. VC always presented a
>> > uniform UI and user experience with all back-ends, as far as possible
>> > and reasonable. In this case, I think automatically marking the
>> > conflicts as resolved makes a lot of sense, but I won't object to make
>> > it opt-out, as long as it's done for every VCS that can support it.
>>
>> So someone might want to generalize the Git-specific variable:
>> vc-git-resolve-conflicts.
>
> Yes, I think so.
>
>> But they'd have to consider what to do with the special value
>> 'unstage-maybe', which doesn't really make sense for other backends.
>
> Right.
I took a shot at it. Please review the attached patch.
[0001-Make-marking-conflicted-files-as-resolved-upon-savin.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Thu, 13 Mar 2025 14:50:01 GMT)
Full text and
rfc822 format available.
Message #39 received at 3860 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 13 Mar 2025 09:04:52 -0300
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Dmitry Gutov <dgutov <at> yandex.ru>,
> Lars Ingebrigtsen <larsi <at> gnus.org>, spiegel <at> gnu.org, jknight <at> fuhm.net
> From: Mauro Aranda <maurooaranda <at> gmail.com>
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Cc: 3860 <at> debbugs.gnu.org, jknight <at> fuhm.net, spiegel <at> gnu.org
> >> From: Dmitry Gutov <dgutov <at> yandex.ru>
> >> Date: Fri, 22 Jan 2021 00:35:07 +0200
> >>
> >> On 21.01.2021 21:33, Eli Zaretskii wrote:
> >> > I think if we are going to make this optional with SVN, we should make
> >> > it optional with the other back-ends as well. VC always presented a
> >> > uniform UI and user experience with all back-ends, as far as possible
> >> > and reasonable. In this case, I think automatically marking the
> >> > conflicts as resolved makes a lot of sense, but I won't object to make
> >> > it opt-out, as long as it's done for every VCS that can support it.
> >>
> >> So someone might want to generalize the Git-specific variable:
> >> vc-git-resolve-conflicts.
> >
> > Yes, I think so.
> >
> >> But they'd have to consider what to do with the special value
> >> 'unstage-maybe', which doesn't really make sense for other backends.
> >
> > Right.
>
> I took a shot at it. Please review the attached patch.
Thanks.
> +(defcustom vc-bzr-resolve-conflicts 'default
> + "When non-nil, mark conflicted file as resolved upon saving.
"If non-nil" is better, IMO.
> +If this is non-nil and there are no more conflict markers in the file,
> +VC will mark the saved file as resolved.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
"VC will mark the conflicts in the saved file as resolved."
Same comments for doc strings of all the other options, since this
text is repeated in all of them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Thu, 13 Mar 2025 15:12:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 3860 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Thu, 13 Mar 2025 09:04:52 -0300
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, Dmitry Gutov <dgutov <at> yandex.ru>,
>> Lars Ingebrigtsen <larsi <at> gnus.org>, spiegel <at> gnu.org, jknight <at> fuhm.net
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> Cc: 3860 <at> debbugs.gnu.org, jknight <at> fuhm.net, spiegel <at> gnu.org
>> >> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> >> Date: Fri, 22 Jan 2021 00:35:07 +0200
>> >>
>> >> On 21.01.2021 21:33, Eli Zaretskii wrote:
>> >> > I think if we are going to make this optional with SVN, we
should make
>> >> > it optional with the other back-ends as well. VC always
presented a
>> >> > uniform UI and user experience with all back-ends, as far as
possible
>> >> > and reasonable. In this case, I think automatically marking the
>> >> > conflicts as resolved makes a lot of sense, but I won't object
to make
>> >> > it opt-out, as long as it's done for every VCS that can
support it.
>> >>
>> >> So someone might want to generalize the Git-specific variable:
>> >> vc-git-resolve-conflicts.
>> >
>> > Yes, I think so.
>> >
>> >> But they'd have to consider what to do with the special value
>> >> 'unstage-maybe', which doesn't really make sense for other backends.
>> >
>> > Right.
>>
>> I took a shot at it. Please review the attached patch.
>
> Thanks.
>
>> +(defcustom vc-bzr-resolve-conflicts 'default
>> + "When non-nil, mark conflicted file as resolved upon saving.
>
> "If non-nil" is better, IMO.
I was going to change it to that, but I realized the text was
misleading. So I rephrased it.
>> +If this is non-nil and there are no more conflict markers in the file,
>> +VC will mark the saved file as resolved.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> "VC will mark the conflicts in the saved file as resolved."
>
> Same comments for doc strings of all the other options, since this
> text is repeated in all of them.
Thanks. Revised patch attached.
[0001-Make-marking-conflicted-files-as-resolved-upon-savin.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Sat, 15 Mar 2025 12:15:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 3860 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 13 Mar 2025 12:11:21 -0300
> Cc: 3860 <at> debbugs.gnu.org, dgutov <at> yandex.ru, larsi <at> gnus.org, spiegel <at> gnu.org,
> jknight <at> fuhm.net
> From: Mauro Aranda <maurooaranda <at> gmail.com>
>
> Thanks. Revised patch attached.
Thanks, this LGTM.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Mon, 17 Mar 2025 09:59:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 3860 <at> debbugs.gnu.org (full text, mbox):
close 3860 31.1
quit
On 15/3/25 09:13, Eli Zaretskii wrote:
>> Date: Thu, 13 Mar 2025 12:11:21 -0300
>> Cc: 3860 <at> debbugs.gnu.org, dgutov <at> yandex.ru, larsi <at> gnus.org,
spiegel <at> gnu.org,
>> jknight <at> fuhm.net
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>>
>> Thanks. Revised patch attached.
>
> Thanks, this LGTM.
Thanks. Installed on master, and closing the bug.
bug marked as fixed in version 31.1, send any further explanations to
3860 <at> debbugs.gnu.org and James Y Knight <jknight <at> fuhm.net>
Request was from
Mauro Aranda <maurooaranda <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Mon, 17 Mar 2025 09:59:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Sat, 29 Mar 2025 13:43:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 3860 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 17 Mar 2025 06:57:54 -0300
> From: Mauro Aranda <maurooaranda <at> gmail.com>
> Cc: 3860 <at> debbugs.gnu.org, larsi <at> gnus.org, jknight <at> fuhm.net, spiegel <at> gnu.org,
> dgutov <at> yandex.ru
>
> On 15/3/25 09:13, Eli Zaretskii wrote:
> >> Date: Thu, 13 Mar 2025 12:11:21 -0300
> >> Cc: 3860 <at> debbugs.gnu.org, dgutov <at> yandex.ru, larsi <at> gnus.org,
> spiegel <at> gnu.org,
> >> jknight <at> fuhm.net
> >> From: Mauro Aranda <maurooaranda <at> gmail.com>
> >>
> >> Thanks. Revised patch attached.
> >
> > Thanks, this LGTM.
>
> Thanks. Installed on master, and closing the bug.
I've just been bitten by this change. Its effect is that any package
that loads or 'require's vc-SOMETHING, without also loading 'vc', will
likely signal an error:
void variable vc-resolve-conflicts
In my case, the victim was admin/gitmerge.el, which only loads
vc-git.el,
The various vc-FOO.el files only 'require' vc when compiling, which
doesn't solve the run-time problem.
So we will need either to make vc-resolve-conflicts autoloaded (which
is generally discouraged for defcustom's), or manually 'require' vc in
the various functions that reference vc-resolve-conflicts.
Are there any other solutions?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Sat, 29 Mar 2025 14:42:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 3860 <at> debbugs.gnu.org (full text, mbox):
On 29/3/25 10:42, Eli Zaretskii wrote:
>> Date: Mon, 17 Mar 2025 06:57:54 -0300
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>> Cc: 3860 <at> debbugs.gnu.org, larsi <at> gnus.org, jknight <at> fuhm.net,
spiegel <at> gnu.org,
>> dgutov <at> yandex.ru
>>
>> On 15/3/25 09:13, Eli Zaretskii wrote:
>> >> Date: Thu, 13 Mar 2025 12:11:21 -0300
>> >> Cc: 3860 <at> debbugs.gnu.org, dgutov <at> yandex.ru, larsi <at> gnus.org,
>> spiegel <at> gnu.org,
>> >> jknight <at> fuhm.net
>> >> From: Mauro Aranda <maurooaranda <at> gmail.com>
>> >>
>> >> Thanks. Revised patch attached.
>> >
>> > Thanks, this LGTM.
>>
>> Thanks. Installed on master, and closing the bug.
>
> I've just been bitten by this change. Its effect is that any package
> that loads or 'require's vc-SOMETHING, without also loading 'vc', will
> likely signal an error:
>
> void variable vc-resolve-conflicts
>
> In my case, the victim was admin/gitmerge.el, which only loads
> vc-git.el,
Ouch. I mistakenly thought that this could work like the vc-*-switches
options, but now I see that, for example, vc-git.el autoloads
vc-switches.
> The various vc-FOO.el files only 'require' vc when compiling, which
> doesn't solve the run-time problem.
>
> So we will need either to make vc-resolve-conflicts autoloaded (which
> is generally discouraged for defcustom's), or manually 'require' vc in
> the various functions that reference vc-resolve-conflicts.
>
> Are there any other solutions?
I don't know. Can the defcustom be moved to another file where there
are "generic" vc options, and that it gets loaded at run-time? I see
some options in vc-hooks.el, but I don't know if (featurep 'vc-hooks)
evaluates to t in the case you encountered.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Sat, 29 Mar 2025 15:21:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 3860 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 29 Mar 2025 11:41:00 -0300
> Cc: 3860 <at> debbugs.gnu.org, larsi <at> gnus.org, jknight <at> fuhm.net, spiegel <at> gnu.org,
> dgutov <at> yandex.ru, Sean Whitton <spwhitton <at> spwhitton.name>
> From: Mauro Aranda <maurooaranda <at> gmail.com>
>
> > void variable vc-resolve-conflicts
> >
> > In my case, the victim was admin/gitmerge.el, which only loads
> > vc-git.el,
>
> Ouch. I mistakenly thought that this could work like the vc-*-switches
> options, but now I see that, for example, vc-git.el autoloads
> vc-switches.
>
> > The various vc-FOO.el files only 'require' vc when compiling, which
> > doesn't solve the run-time problem.
> >
> > So we will need either to make vc-resolve-conflicts autoloaded (which
> > is generally discouraged for defcustom's), or manually 'require' vc in
> > the various functions that reference vc-resolve-conflicts.
> >
> > Are there any other solutions?
>
> I don't know. Can the defcustom be moved to another file where there
> are "generic" vc options, and that it gets loaded at run-time? I see
> some options in vc-hooks.el, but I don't know if (featurep 'vc-hooks)
> evaluates to t in the case you encountered.
vc-hooks is preloaded, so perhaps moving the variable there is the
best option.
Adding Stefan, in case he has better suggestions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Sun, 30 Mar 2025 01:56:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 3860 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sat 29 Mar 2025 at 04:42pm +03, Eli Zaretskii wrote:
> The various vc-FOO.el files only 'require' vc when compiling, which
> doesn't solve the run-time problem.
Do you know why this is? The obvious thing is for them to all require
vc but it seems likely there is some specific reason they don't.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Sun, 30 Mar 2025 05:28:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 3860 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: Mauro Aranda <maurooaranda <at> gmail.com>, 3860 <at> debbugs.gnu.org,
> larsi <at> gnus.org, spiegel <at> gnu.org, jknight <at> fuhm.net, dgutov <at> yandex.ru
> Date: Sun, 30 Mar 2025 09:55:32 +0800
>
> Hello,
>
> On Sat 29 Mar 2025 at 04:42pm +03, Eli Zaretskii wrote:
>
> > The various vc-FOO.el files only 'require' vc when compiling, which
> > doesn't solve the run-time problem.
>
> Do you know why this is? The obvious thing is for them to all require
> vc but it seems likely there is some specific reason they don't.
It might be that the stuff we need to always be available should be in
vc-hooks.el instead, which is preloaded.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Mon, 31 Mar 2025 16:52:03 GMT)
Full text and
rfc822 format available.
Message #68 received at 3860 <at> debbugs.gnu.org (full text, mbox):
> vc-hooks is preloaded, so perhaps moving the variable there is the
> best option.
Sounds fine to me, yes.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Tue, 01 Apr 2025 11:09:03 GMT)
Full text and
rfc822 format available.
Message #71 received at 3860 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Mauro Aranda <maurooaranda <at> gmail.com>, 3860 <at> debbugs.gnu.org,
> larsi <at> gnus.org, jknight <at> fuhm.net, spiegel <at> gnu.org, dgutov <at> yandex.ru,
> spwhitton <at> spwhitton.name
> Date: Mon, 31 Mar 2025 12:51:23 -0400
>
> > vc-hooks is preloaded, so perhaps moving the variable there is the
> > best option.
>
> Sounds fine to me, yes.
Thanks.
Mauro, would you please move the variable to vc-hooks.el?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#3860; Package
emacs.
(Tue, 01 Apr 2025 17:18:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 3860 <at> debbugs.gnu.org (full text, mbox):
On 1/4/25 08:07, Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Cc: Mauro Aranda <maurooaranda <at> gmail.com>, 3860 <at> debbugs.gnu.org,
>> larsi <at> gnus.org, jknight <at> fuhm.net, spiegel <at> gnu.org, dgutov <at> yandex.ru,
>> spwhitton <at> spwhitton.name
>> Date: Mon, 31 Mar 2025 12:51:23 -0400
>>
>>> vc-hooks is preloaded, so perhaps moving the variable there is the
>>> best option.
>>
>> Sounds fine to me, yes.
>
> Thanks.
>
> Mauro, would you please move the variable to vc-hooks.el?
Thanks, done.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 30 Apr 2025 11:24:15 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.