After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 776828 - Meld recursively auto expand directories sub-tree
Meld recursively auto expand directories sub-tree
Status: RESOLVED DUPLICATE of bug 759683
Product: meld
Classification: Other
Component: dirdiff
git master
Other Linux
: Normal normal
: ---
Assigned To: meld-maint
Depends on:
Reported: 2017-01-03 18:13 UTC by oniola
Modified: 2017-01-03 21:56 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description oniola 2017-01-03 18:13:39 UTC
Meld recursively expand all directories where it detects changes. This is fine but I think there should also be an option that just marks these directories as different without having to expanding them.

I find that sometimes when I am comparing large code base such as Linux Kernel in order to determine my current position I have to collapse each tree sub-directories which can be time consuming.

I am currently using version 3.17.1. I but I also tried on earlier 3.xx versions.

At the back of my mind I was sure that this behaviour I am describing existed on earlier Meld builds so I have just been few a of the old releases and came to notice that the last version that exhibits this featuer was 1.8.6.

This behaviour is different from version 3.xx upwards.
Comment 1 Kai Willadsen 2017-01-03 21:56:06 UTC
I'm sorry, but we won't add options like that; options at that granularity are not something that I think we should support.

Also, we definitely expanded subtrees back in the 1.8 versions, and have for as long as I can remember. If you're seeing different behaviour in 1.8.x then it's either a bug that was fixed, or there's something more complicated going on.

It's possible that your request would be better fixed by someone working on bug 131231 or bug 131232, but the first of those is quite difficult given our current tree model, and the second needs some UI/preference design before anyone even starts to actually work on it.

However, I'm actually going to mark this as a duplicate of bug 759683, because that's a direct workflow suggestion that I think would fix your problem.

Thanks anyway for your bug report.

*** This bug has been marked as a duplicate of bug 759683 ***