In the "+/-" diff view for a file on the right, it used to be the case that, when there were changes that only involved the number of spaces and tabulation at the beginning of lines, they wouldn't be shown.
Now, they are shown as a deleted and an added line.
So, if I add an if() statement to wrap a block of code, and consequently indent the whole block, I will see a diff in which the whole block is replaced by a new block (with only the indentation changed).
If there is a setting for this, which I don't know of and never touched, then either the setting is new and the default value is wrong, or the default was changed to the wrong default value.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
I made changes that only involved indentation, and they wrongly showed up in the diff view as described in the report
I committed them. I think I saw them in the diff view of the commit as well, though I'm not 100% sure. What I'm sure of, is that I saw them in the diff view of the working directory before I committed them.
I repeated steps 1 and 2 with more indentation-only changes (again, I can tell for sure I saw them wrongly in the diff view of the working directory, but I'm not totally sure I saw them in the diff view of the commit afterwards, though I think I did).
I restarted thg
Now I'm looking at the diff views of both commits and no diffs show up, as expected.
"Ignore White Spaces" is set to true (I haven't changed, I couldn't even if I wanted to because some package is missing in my installation and settings are read-only)
I have re-tested now and it seems that (unlike I thought) I get the diff systematically wrong (i.e. not ignoring whitespaces) for the working directory, and systematically right (ignoring ws) for commits. I don't think that would make sense under any combination of settings.
And didn't the missing package issue get solved by installing iniparse==0.5?
I still haven't.
That shouldn't be relevant here, right? If I understand correctly, that only has to do with being unable to edit the settings via the GUI.
What does hg config annotate.ignorews --debug say?
Of the listed files that actually exist (apart from resource:... which I don't know what is, but doesn't seem like the path of an actual file) none seems to contain that setting.
what version had a different behavior?
I have no way of telling, sorry. I haven't kept track of when I upgraded to what version. I'm using 02adbb8791d9 now and the previous time I updated was a few days or weeks earlier, but I'm not sure how long ago the issue could have appeared without me noticing, thought that can't be very long while using thg on a daily basis.
Of the listed files that actually exist (apart from resource:... which I don't know what is, but doesn't seem like the path of an actual file) none seems to contain that setting.
The resource: thing is from core hg in preparation for py3 support and stuffing the default config files into the executable. It falls back to where the *.pyc files are stored, so don't worry about that.
If you had that setting, it would have printed out and --debug would print the file it's in next to it. You mentioned Settings -> Diff and Annotate -> "Ignore White Spaces" is True. That's the setting that got written out when I selected that option. Do you have anything set if you hg config diff --debug?
It's got to be some config setting you used to have, because I don't ever recall the behavior where it ignores whitespace. See hg config diff for config options related to ignoring whitespace. Maybe that will get you what you want.
And didn't the missing package issue get solved by installing iniparse==0.5?
I still haven't.
That shouldn't be relevant here, right? If I understand correctly, that only has to do with being unable to edit the settings via the GUI.
It's not. I didn't know if you didn't see the mention to upgrade in the other bug, since you said you still couldn't do it.
Is it possible that when you asked me to look for annotate.ignorews you meant diff.ignorews?
Now that's True as expected, but it seems like it only works when viewing diffs of commits, but not those of the working directory. Are there two separate settings for the two cases? I can't think of a reasonable usecase for wanting to ignore whitespaces in commits but not in the working directory, or viceversa.
because I don't ever recall the behavior where it ignores whitespace.
Do you mean that whenever you have a changeset where a block of code gets indented, you normally see a whole bunch of deleted and added lines? And when you change the line endings in a file it looks like the whole file was changed? And you are happy with that? You actually use thg for real work and you are happy with that?
I can't imagine working with diffs that don't ignore whitespace in a normal workflow with source code in a common programming language. The diff view becomes basically useless.
Is it possible that when you asked me to look for annotate.ignorews you meant diff.ignorews
I hit the wrong button when I tried it.
Now that's True as expected, but it seems like it only works when viewing diffs of commits, but not those of the working directory. Are there two separate settings for the two cases?
That seems like a bug, since the command line doesn't behave that way- it will ignore added whitespace in both cases with that config. What's strange is that I would expect it to delegate to mercurial to generate the diff in both cases. The only thing I can think is that it's purposeful so that the diff shows in the commit widget.
Do you mean that whenever you have a changeset where a block of code gets indented, you normally see a whole bunch of deleted and added lines? And when you change the line endings in a file it looks like the whole file was changed? And you are happy with that? You actually use thg for real work and you are happy with that?
Yes. Python cases about whitespace, and line ending changes or space <--> tab changes usually means someone has something misconfigured. If the diff is more than a couple of lines, I'm using an external diff to that lets me toggle whitespace changes on/off anyway.
I understand that for those of you who only code in Python this isn't a big deal because of how indentation is treated in Python, but for those of us who code in practically every other language this is a completely crippling issue.
I'm basically unable to inspect the diff of the working directory, I alwaya have to commit the changes just to visualize them properly in the diff view. If I forget to rollback immediately after (which is a painful and unmanageable workaround anyway), I end up polluting the history of my repos with a lot of garbage.
Basically, when somebody who wants it implements it.
You mean when somebody who wants it fixed fixes it. We are not talking about a feature request but a bug, and more specifically, a regression. This used to work.
I'm not sure why the diff window would be any different before and after a commit.
Because the regression only affect the diff window of the current working directory, that is, the one that shows the diff between a file as it is in the working directory and the file in the parent commit.
When I commit the changes, and go back to the commit I've just made and look at the diff view, luckily it works as expected. Obviously the two (before and after the commit) should be identical, but they aren't.
That's difficult to do, because when I go back a few releases, I start getting errors due to incompatibility with the version of mercurial.
I even went as far as editing some files in thg to relax the constraints (i.e. have it run despite having a mercuial version outside of the range it wants), but then I got to a point where it would stop working.
Do you have any suggestion on how to overcome that?
Anyway, you are able to reproduce the issue, right? So it should be possible for you to do the bisection.
Do you have any suggestion on how to overcome that?
I'd suggest creating a venv, activating it, and installing specific versions of Mercurial with pip. Something like pip3 install -U mercurial==5.8 or whatever version is needed. That will leave whatever Mercurial you have on your system alone, but will use this version if you run thg with the venv's python.
Anyway, you are able to reproduce the issue, right? So it should be possible for you to do the bisection.
I haven't tried recently. This doesn't affect me, so I'm not going to spend lots of free time debugging it. That's why if you can isolate where it broke, it's more likely to get fixed. (Also note the version of hg when confirming where it works, because it's possible that it broke on the hg side somehow.)
I'd suggest creating a venv, activating it, and installing specific versions of Mercurial with pip
I tried but it's a nightmare. I don't know what specific version of mercurial I need for any given version of thg to begin with. I tried random old versions, but then I get all sorts of error messages (NOT thg complaining for the wrong version of mercurial, but rather "this thing does not have a thing with that name" kind of errors).
And when I tried to pip-install mercurial 5.1 I got an error telling me that I need to use python 2 and not 3.
Any other idea to help you isolate the issue, that doesn't involve finding the exact version where it appeared, which was more than 2 years ago?
I've tried to look into the source code (not even knowing Python, let alone having the slightest clue how Mercurial or TortoiseHg work), and found out that here:
Thanks for digging into this. Having the exact point of regression is very helpful, especially since we need to avoid swapping it for regressing the bug fixed in 1efa4478fa44.
I don't have time to dig into it right now, but a quick skim of patch.difffeatureopts looks like it would work if you replaced that line with patch.difffeatureopts(repo.ui, whitespace=True). I need to understand the original bug fix better to make sure this isn't breaking that before submitting a patch.
I don't know what specific version of mercurial I need for any given version of thg to begin with.
For future reference, the thg version and hg version should be the same x.y value (though hg y-1 is also supported).
Why don't you just revert 1efa4478fa44?
Whatever that was meant to fix, it wasn't the right way to fix it, as it caused this regression.
Let that blow up, and then you'll figure out how to fix that the right way.
TortoiseHg is unusable with this bug for languages where indentation doesn't matter.
Again my other account was blocked when submitting a new issue by the idiotic anti-spam filter, so I'm going to submit it as a comment to an existing completely unrelated issue. Please copy it to a new issue. (this way at least it won't block my account and if it blocks my comments I can retry).
The antispam filter is unhinged. Somebody needs to do something FFS.
Issue: Description column gets immediately resized to very small width when starting to resize window.
To reproduce:
Make sure the TortoiseHg window is not maximized, so you can resize it
Open a repository
Enlarge the Description column (which is usually stupidly small by default to begin with
Start resizing the window by dragging the right edge, but just move it by the tiniest amount. And just for laughs, drag it to the right to increase the width of the window rather than reducing it
Expected:
No significant change in the width of any column should happen if you change the size of the window of an infinitesimal amount. No matter what the criteria are for resizing the columns, a 1px total change in size cannot produce a more than 1px change in size in any given column. Furthermore, if I'm enlarging the window, I may expect column to get wider but no one column should shrink.
Observed:
The instand you start dragging the window edge, no matter in what direction, the width of the Description column jumps to a stupidly small width, probably the same that it initially was by default.
This is one of many bugs in the sizing of columns which in general is utter chaos, but at least this one can easily be described.