GNU bug report logs -
#9503
24.0.50; (vc-git): After applying a stash, refresh of *vc-dir* is a must
Previous Next
Reported by: Jambunathan K <kjambunathan <at> gmail.com>
Date: Wed, 14 Sep 2011 10:26:01 UTC
Severity: minor
Found in versions 24.0.50, 24.3
Done: Jambunathan K <kjambunathan <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 9503 in the body.
You can then email your comments to 9503 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#9503
; Package
emacs
.
(Wed, 14 Sep 2011 10:26:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jambunathan K <kjambunathan <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 14 Sep 2011 10:26:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
(vc-git): After applying a stash, refresh of *vc-dir* is a must.
Currently I do this manually.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#9503
; Package
emacs
.
(Wed, 14 Sep 2011 11:15:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 9503 <at> debbugs.gnu.org (full text, mbox):
> (vc-git): After applying a stash, refresh of *vc-dir* is a must.
>
> Currently I do this manually.
Refreshing *vc-dir* can be slow. What if you apply several stashes
consecutively?
Juanma
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#9503
; Package
emacs
.
(Wed, 14 Sep 2011 18:24:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 9503 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero <lekktu <at> gmail.com> writes:
>> (vc-git): After applying a stash, refresh of *vc-dir* is a must.
>>
>> Currently I do this manually.
>
> Refreshing *vc-dir* can be slow. What if you apply several stashes
> consecutively?
I would prefer to have some sort of visual feedback that confirms that
the application of stash has succeeded. Otherwise I just keep staring at
the screen hoping something would happen.
I do have `vc-command-messages' set to t. I see OK in the echo area. If
I turn that setting off the only visible feedback is the
hour-glass->normal cursor.
Under the absence of any visual cue in the echo area, I just keep
staring at the screen. This has happened even after I filed this report.
Do you think a prefix arg or a customization variable is in order?
Couple of tangential remarks:
1. Any reason why `vc-git-stash-delete-at-point' runs
`vc-dir-refresh'. (I believe this is an unwanted side-effect of stash
menu sharing the same space as the modified file list)
2. I have been using vc-git for quite sometime (> 10 months) now. It's
only a few days back that I realized that the stash lines have
keymaps associated with them (I always thought that they were zombie
informational lines). Anyway the stash lines could be highlighted if
the point moves to that line or permanently use a different (keymap?)
face. (I don't use mouse that often and I noticed the highlight
behaviour only after doing a C-u C-x =)
3. Apropos applying several stashes, it seems that at some point in
distant future someone would cookup a way to mark and re-order
stashes (much like interactive rebase menu in the git command line).
I think the most `intuitive' interface for re-ordering stashes would
be killing and yanking (Think of C-k and C-y in gnus-topic mode).
IMHO, In that case the current binding of using C-k to delete the
stash would come in the way.
You can close this bug if you think it is too frivolous.
> Juanma
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#9503
; Package
emacs
.
(Wed, 14 Sep 2011 18:50:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 9503 <at> debbugs.gnu.org (full text, mbox):
> I would prefer to have some sort of visual feedback that confirms that
> the application of stash has succeeded. Otherwise I just keep staring at
> the screen hoping something would happen.
Agreed. We should do our best to keep the *vc-dir* display up-to-date,
and in the case in point we know the display to be out of date, so
we're not doing our best.
Stefan
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#9503
; Package
emacs
.
(Wed, 14 Sep 2011 18:55:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 9503 <at> debbugs.gnu.org (full text, mbox):
On Wed, Sep 14, 2011 at 20:18, Jambunathan K <kjambunathan <at> gmail.com> wrote:
> I would prefer to have some sort of visual feedback that confirms that
> the application of stash has succeeded. Otherwise I just keep staring at
> the screen hoping something would happen.
Agreed.
> Do you think a prefix arg or a customization variable is in order?
A prefix arg, for the case that you *don't* want the autoupdate,
perhaps. Your case is surely more common that the one where the user
wants to apply several stashes at once. As for the variable, it
wouldn't be useful if you usually apply one stash, and in a few cases
you want to apply several.
> You can close this bug if you think it is too frivolous.
No, not at all. I just wondered about the other use case, because it
isn't uncommon for me.
Juanma
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#9503
; Package
emacs
.
(Thu, 15 Sep 2011 04:41:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 9503 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero <lekktu <at> gmail.com> writes:
>> (vc-git): After applying a stash, refresh of *vc-dir* is a must.
>>
>> Currently I do this manually.
>
> Refreshing *vc-dir* can be slow. What if you apply several stashes
> consecutively?
Applying stash on a dirty tree produces the following error message from
git:
--8<---------------cut here---------------start------------->8---
"Cannot apply to a dirty working tree, please stage your changes"
--8<---------------cut here---------------end--------------->8---
Even if one is applyin stashes serially, one HAS to always commit the
stash before applying the next one.
>
> Juanma
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#9503
; Package
emacs
.
(Thu, 15 Sep 2011 04:57:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 9503 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero <lekktu <at> gmail.com> writes:
> On Wed, Sep 14, 2011 at 20:18, Jambunathan K <kjambunathan <at> gmail.com> wrote:
>
>> I would prefer to have some sort of visual feedback that confirms that
>> the application of stash has succeeded. Otherwise I just keep staring at
>> the screen hoping something would happen.
>
> Agreed.
>
>> Do you think a prefix arg or a customization variable is in order?
>
> A prefix arg, for the case that you *don't* want the autoupdate,
> perhaps. Your case is surely more common that the one where the user
> wants to apply several stashes at once. As for the variable, it
> wouldn't be useful if you usually apply one stash, and in a few cases
> you want to apply several.
Considering that stashes cannot be applied on a dirty tree, refreshing
the *vc-dir* would invariably follow (if one is committing from within
Emacs)
There seem to be only two options after a clean application of stash
1. Continue modify the working tree.
2. Commit the stash.
May be the prefix arg could be used to mean (2) above? I am more likely
to do (1) than (2).
Now I believe there is a strong case for refreshing *vc-dir*.
>> You can close this bug if you think it is too frivolous.
>
> No, not at all. I just wondered about the other use case, because it
> isn't uncommon for me.
> Juanma
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#9503
; Package
emacs
.
(Thu, 15 Sep 2011 07:39:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 9503 <at> debbugs.gnu.org (full text, mbox):
Jambunathan K <kjambunathan <at> gmail.com> writes:
> Applying stash on a dirty tree produces the following error message from
> git:
>
> "Cannot apply to a dirty working tree, please stage your changes"
>
> Even if one is applyin stashes serially, one HAS to always commit the
> stash before applying the next one.
Only if the stashes overlap.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#9503
; Package
emacs
.
(Thu, 15 Sep 2011 08:13:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 9503 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
> Jambunathan K <kjambunathan <at> gmail.com> writes:
>
>> Applying stash on a dirty tree produces the following error message from
>> git:
>>
>> "Cannot apply to a dirty working tree, please stage your changes"
>>
>> Even if one is applyin stashes serially, one HAS to always commit the
>> stash before applying the next one.
>
> Only if the stashes overlap.
That is what I would have expected but that is not what I observed with
a little test that stashed *two different* files on the same HEAD.
My git version is 1.7.2.3. The release notes for git 1.7.5.1 has the
following entry
,----
| * "git stash apply" used to refuse to work if there was any change in
| the working tree, even when the change did not overlap with the
| change the stash recorded.
`----
So I would (favorably) assume that the above bug is also present in
1.7.2.3 version of git. I agree that I shouldn't have based my opinions
on a buggy behaviour and trusted my instincts.
Anyways, the maintainers have agreed to the change I requested. So the
above note is only to clarify my eariler comments.
Forcibly Merged 9503 13960.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Thu, 14 Mar 2013 17:43:01 GMT)
Full text and
rfc822 format available.
Reply sent
to
Jambunathan K <kjambunathan <at> gmail.com>
:
You have taken responsibility.
(Fri, 15 Nov 2013 05:09:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Jambunathan K <kjambunathan <at> gmail.com>
:
bug acknowledged by developer.
(Fri, 15 Nov 2013 05:09:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 9503-done <at> debbugs.gnu.org (full text, mbox):
OP here. Closed.
Reply sent
to
Jambunathan K <kjambunathan <at> gmail.com>
:
You have taken responsibility.
(Fri, 15 Nov 2013 05:09:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Tom Tromey <tromey <at> redhat.com>
:
bug acknowledged by developer.
(Fri, 15 Nov 2013 05:09:04 GMT)
Full text and
rfc822 format available.
Disconnected #13960 from all other report(s).
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Fri, 15 Nov 2013 08:07:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 13 Dec 2013 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 242 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.