> (It shouldn't be necessary to save the buffer too -- see > `git-blame-mode' (from the git contrib directory) that works fine with > unsaved modifications.)
The buffer has to be saved, or this might happen: On disk: added in first commit added in second commit In buffer: new line new line added in first commit added in second commit Blame result: abcdef first commit new line uvwxyz second commit new line added in first commit added in second commit Which means that setting `magit-save-repository-buffers' to `nil', *does* break `magit-blame'. I'll fix that soon. Patrick: I'll let you know when I am done. >> Finally you could redefine `magit-save-repository-buffers' to only >> save the current buffer, but again that would affect [a lot] of code, >> which assumes every buffer that visits a file in the current >> repository [does get refreshed]. So you probably shouldn't do that >> either. > > I can't parse the first sentence above: are you saying that there is > code that would break when buffers are *not* saved? In other words, is > there any code that will *break* when `magit-save-repository-buffers' is > set to nil, or when it's set to t and when asked I refuse to save some > buffer? I have inserted some missing words. Additionally I should have said "features" instead of "code". But I did use the word "affect", as in "things will behave differently", and not "break". (I wasn't aware of the above issue, when I wrote that paragraph.) >> And you probably don't have to anyway. This saving happens a lot >> (e.g. every time you refresh the status buffer using either "C-g" or >> from that buffer just "g" and you only just noticed this now, > > Um, my understanding is that the default t value (of > `magit-save-repository-buffers') means that I'll be asked before some > buffer is saved. That's correct. > Are you saying that there are some buffers that can be saved *without* > such a question? No, that wasn't my intention. If you request to be asked then you will be asked. > (No! This is repeating the same auto-revert story... Thanks for the reminder. I added a safety net for your benefit and some other hypothetical users who also rely on unsaved buffers as a sort of staging area. And you were very much not satisfied with the approach I took, because it did not go far enough in your opinion. I instead settled for a compromise. At the same time *many* other users were very dissatisfied by that compromise because it went *too* far. In their eyes I was "needlessly forcing them to set an option" when the "old default obviously was the right behavior in the first place" and you were "using a very odd work flow" and "wrong about the safety of the old default" and I "should therefore just have ignored you". Yes, these things were said. This is not over, users are still being inconvenient by having to set the option and by unavoidable side-effects of the change I made in response to you request. Never-the-less I think compromising was the right decision, unfortunately it doesn't make anyone happy. >> And you probably don't have to anyway. This saving happens a lot >> (e.g. every time you refresh the status buffer using either "C-g" or >> from that buffer just "g" and you only just noticed this now, >> which probably means that the saving is not something that leads to >> undesirable results in your case (except that it "happens to early"). > > You should *never* assume that having some feature around when people > don't notice it is any kind of justification for its validity!) I didn't try to justify anything. I was just saying that, it appears that Patrick does not very often have unsaved buffers when he invokes commands which, depending on the setting, would then ask to save these buffers, or not. And that it might therefore not to be necessary for him to change the setting. I might be wrong about that, he might find it disturbing enough for this to happen even just occasionally to want to change the setting, but I wasn't trying to *justify* anything. Also I really don't want to get into a discussion about such things with you again. It was unpleasant enough the first time around. -- You received this message because you are subscribed to the Google Groups "magit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
