meld issueshttps://gitlab.gnome.org/GNOME/meld/-/issues2019-02-17T22:23:47Zhttps://gitlab.gnome.org/GNOME/meld/-/issues/61[BZ#701512] show directories containing files removed from source control2019-02-17T22:23:47ZBugzilla[BZ#701512] show directories containing files removed from source control## Submitted by Adam Dingle
**[Link to original bug (#701512)](https://bugzilla.gnome.org/show_bug.cgi?id=701512)**
## Description
>>>
If I've used 'git rm' to remove all files in a directory but have not yet committed the change, t...## Submitted by Adam Dingle
**[Link to original bug (#701512)](https://bugzilla.gnome.org/show_bug.cgi?id=701512)**
## Description
>>>
If I've used 'git rm' to remove all files in a directory but have not yet committed the change, the directory does not exist and Meld doesn't show it or the removed files in it. That's too bad, because the fact that these files have been removed is relevant (and does show up in 'git status', of course). It would be nice if Meld did show directories containing files marked for deletion from source control.
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/60[BZ#701140] command to close all file comparison views2019-02-17T22:23:47ZBugzilla[BZ#701140] command to close all file comparison views## Submitted by Adam Dingle
**[Link to original bug (#701140)](https://bugzilla.gnome.org/show_bug.cgi?id=701140)**
## Description
>>>
When I'm comparing directories or in the version control view, I often open many different file c...## Submitted by Adam Dingle
**[Link to original bug (#701140)](https://bugzilla.gnome.org/show_bug.cgi?id=701140)**
## Description
>>>
When I'm comparing directories or in the version control view, I often open many different file comparison views to look at individual files. Sometimes I want to close them all, leaving my directory or version control comparison open. It might be nice to have a command Tabs->Close All File Comparisons that does this. If we implement this, I'd suggest the keyboard shortcut Shift+Ctrl+W by analogy with gedit's Documents->Close All.
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/59[BZ#700919] CLI - Opening with Single File parameter fails silently2019-02-17T22:23:47ZBugzilla[BZ#700919] CLI - Opening with Single File parameter fails silently## Submitted by Timothy C. Quinn
**[Link to original bug (#700919)](https://bugzilla.gnome.org/show_bug.cgi?id=700919)**
## Description
>>>
I have a usecase where I launch a compare tool from a single file using a shell extension in...## Submitted by Timothy C. Quinn
**[Link to original bug (#700919)](https://bugzilla.gnome.org/show_bug.cgi?id=700919)**
## Description
>>>
I have a usecase where I launch a compare tool from a single file using a shell extension in windows like tortiseXXX tools. When a single file is used the my current compare tool will load with the one file loaded and prompt the users to add more files. This is very handy and something that I use very frequently.
Is it possible to update Meld to accept a single file parameter and load the tool in the "New Comparison" dialog in "File Comparison" mode with the file name pre-loaded in the first file selector?
FYI, Ultra compare can operate in this way and would like to switch my CM tools over to using Meld but I am held back because of this one feature.
In a related note, the tool fails silently in Windows 2007 when a single parameter is passed. I all I see is a flash of a window and then nothing.
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/58[BZ#700683] allow to write commit message while reviewing diff2019-02-17T22:23:47ZBugzilla[BZ#700683] allow to write commit message while reviewing diff## Submitted by Luc Pi
**[Link to original bug (#700683)](https://bugzilla.gnome.org/show_bug.cgi?id=700683)**
## Description
>>>
Currently it happens in two steps:
1. review all diffs
2. write commit message at once
(th...## Submitted by Luc Pi
**[Link to original bug (#700683)](https://bugzilla.gnome.org/show_bug.cgi?id=700683)**
## Description
>>>
Currently it happens in two steps:
1. review all diffs
2. write commit message at once
(the dialog is modal, you can't look at the diff anymore)
I would like to be able to enter the commit message as I am reviewing
In addition, the commit message could be updated automatically with the diff context.
EXAMPLE:
with emacs you
- put the cursor on the change you want to comment on
- launch the command (Ctrl-x + 4 + A)
--> this opens a buffer with the changelog entry
--> the changelog entry is pre-set with the diff context:
- the filename + the nearest enclosing symbol (function, struct, etc.)
-------------->%-------------->%--------------
2013-05-20 Name Surname <email@example.org>
* file (symbol): <_cursor_>
-------------->%-------------->%--------------
This is the GNU std changelog [1] entry. It could be modified with the "std" style of the VCS system used. For example, with git, it could add a Sign-off line.
[1] http://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/57[BZ#700389] display current branch name2023-10-22T16:45:23ZBugzilla[BZ#700389] display current branch name## Submitted by Adam Dingle
**[Link to original bug (#700389)](https://bugzilla.gnome.org/show_bug.cgi?id=700389)**
## Description
>>>
It's pretty useful to know which branch you're on, especially when pulling or pushing. In Meld's...## Submitted by Adam Dingle
**[Link to original bug (#700389)](https://bugzilla.gnome.org/show_bug.cgi?id=700389)**
## Description
>>>
It's pretty useful to know which branch you're on, especially when pulling or pushing. In Meld's version control view, I think it would be nice to display the current branch name in the title bar, e.g.
gtk+ (gtk-3-8) - Meld
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/56[BZ#699689] Push dialog should show what will be pushed2019-02-17T22:23:46ZBugzilla[BZ#699689] Push dialog should show what will be pushed## Submitted by Adam Dingle
**[Link to original bug (#699689)](https://bugzilla.gnome.org/show_bug.cgi?id=699689)**
## Description
>>>
I know that I was the one who asked to be able to 'git push' from Meld. But now that that's impl...## Submitted by Adam Dingle
**[Link to original bug (#699689)](https://bugzilla.gnome.org/show_bug.cgi?id=699689)**
## Description
>>>
I know that I was the one who asked to be able to 'git push' from Meld. But now that that's implemented, it's making me a little uncomfortable that there's a button on the Meld toolbar I can push (no pun intended) which will push commits to the server without asking for confirmation. That's a potentially dangerous operation if I hang around in the master branch with local commits which are not yet ready for prime time (as I sometimes do, for better or for worse).
So now I think I'd like that button to ask for confirmation before pushing. Of course, it would be even nicer if the confirmation dialog showed me the first lines of the log messages for the commits that will be pushed. But if that's hard, even a simple Push/Cancel dialog would be a lot better than nothing.
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/54[BZ#699037] allow conflict resolution to be reverted2019-02-17T22:23:46ZBugzilla[BZ#699037] allow conflict resolution to be reverted## Submitted by Adam Dingle
**[Link to original bug (#699037)](https://bugzilla.gnome.org/show_bug.cgi?id=699037)**
## Description
>>>
All too often, after I've resolved conflicts in a file (but before committing) I realize I've mad...## Submitted by Adam Dingle
**[Link to original bug (#699037)](https://bugzilla.gnome.org/show_bug.cgi?id=699037)**
## Description
>>>
All too often, after I've resolved conflicts in a file (but before committing) I realize I've made an error and I want to go back and merge the changes in that file again. Today, once I've resolved a conflict in Meld there's no way I can go back to the previous unresolved state. In git, the right command to get there is 'git checkout -m':
http://gitster.livejournal.com/43665.html
I think in Meld the Revert command should probably always run 'git checkout -m'. I believe this command will work correctly in the simple case of reverting everyday changes, and it can also restore the state before a merge resolve.
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/53[BZ#699023] indicate when local commits are unpushed2019-02-17T22:23:46ZBugzilla[BZ#699023] indicate when local commits are unpushed## Submitted by Adam Dingle
**[Link to original bug (#699023)](https://bugzilla.gnome.org/show_bug.cgi?id=699023)**
## Description
>>>
In git (and probably other distributed version control systems too) it's all too easy to make com...## Submitted by Adam Dingle
**[Link to original bug (#699023)](https://bugzilla.gnome.org/show_bug.cgi?id=699023)**
## Description
>>>
In git (and probably other distributed version control systems too) it's all too easy to make commits locally and then forget to push them to the server. When there are unpushed local commits, it would be nice if Meld would display an indication to that effect in the 'Status' column for the root directory of the local working copy. The text could read e.g. '2 local commits'.
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/52[BZ#698633] can't run 'git commit' with no filename2019-02-17T22:23:46ZBugzilla[BZ#698633] can't run 'git commit' with no filename## Submitted by Adam Dingle
**[Link to original bug (#698633)](https://bugzilla.gnome.org/show_bug.cgi?id=698633)**
## Description
>>>
Currently if I right click the root of a local repository and select Commit, Meld runs 'git commi...## Submitted by Adam Dingle
**[Link to original bug (#698633)](https://bugzilla.gnome.org/show_bug.cgi?id=698633)**
## Description
>>>
Currently if I right click the root of a local repository and select Commit, Meld runs 'git commit .' Usually that works to commit all outstanding changes, but when a cherry-pick is in progress it fails:
fatal: cannot do a partial commit during a cherry-pick.
Exit code: 128
In this situation only a 'git commit' with no filename will work. I think Meld should run a simple 'git commit' if the user commits when the top-level directory is selected or if nothing is selected at all.
This is similar to [bug 698564](https://bugzilla.gnome.org/show_bug.cgi?id=698564), by the way.
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/51[BZ#698499] refresh view automatically when files appear or disappear in unde...2023-09-09T18:28:42ZBugzilla[BZ#698499] refresh view automatically when files appear or disappear in underlying directory## Submitted by Adam Dingle
**[Link to original bug (#698499)](https://bugzilla.gnome.org/show_bug.cgi?id=698499)**
## Description
>>>
In Meld's directory comparison and version control views, I must use View->Refresh or View->Reloa...## Submitted by Adam Dingle
**[Link to original bug (#698499)](https://bugzilla.gnome.org/show_bug.cgi?id=698499)**
## Description
>>>
In Meld's directory comparison and version control views, I must use View->Refresh or View->Reload to refresh the view when the set of files in the underlying directory has changed. It would be nicer if Meld refreshed the view automatically, just like Nautilus does when files appear in a directory you're viewing there.
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/49[BZ#694536] enhancement: better highlighting choice by diff when several poss...2022-06-13T22:21:37ZBugzilla[BZ#694536] enhancement: better highlighting choice by diff when several possibilities## Submitted by Scott Kostyshak
**[Link to original bug (#694536)](https://bugzilla.gnome.org/show_bug.cgi?id=694536)**
## Description
>>>
Suppose I have "Chile, Colombia" in one text file and "Chile, China, Colombia" in another. If...## Submitted by Scott Kostyshak
**[Link to original bug (#694536)](https://bugzilla.gnome.org/show_bug.cgi?id=694536)**
## Description
>>>
Suppose I have "Chile, Colombia" in one text file and "Chile, China, Colombia" in another. If I do a file diff, the following is highlighted: "hina, C" (see screenshot). This is correct, but it would also be correct and preferable to highlight "China, " or " China,". How can filediff magically know what I would prefer? Out of all the alternatives, it seems the most preferable is likely to be the one whose characters are not separated by white space.
Any thoughts?
Thanks,
Scott
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/47[BZ#685889] support diff3 format files2019-02-17T22:23:46ZBugzilla[BZ#685889] support diff3 format files## Submitted by Gregor B. Rosenauer
**[Link to original bug (#685889)](https://bugzilla.gnome.org/show_bug.cgi?id=685889)**
## Description
>>>
sometimes it's already too late to use meld, and you end up with conflict markers in your...## Submitted by Gregor B. Rosenauer
**[Link to original bug (#685889)](https://bugzilla.gnome.org/show_bug.cgi?id=685889)**
## Description
>>>
sometimes it's already too late to use meld, and you end up with conflict markers in your file(s), like >>>> HEAD and <<< REV x.
For these cases, it would be nice if meld detected the diff3 format markers and automatically show me the common ancestor, local and remote version in a 3-way-merge-view instead of everything in one file.
I'd highly appreciate such a feature, as I think meld is currently the best merge tool available (the interface is way better than kdiff3's, much more like the Eclipse merge view which I find excellent) and often use it with git.
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/45[BZ#677360] Provide tooltip summarising file/folder metadata differences2019-02-17T22:23:46ZBugzilla[BZ#677360] Provide tooltip summarising file/folder metadata differences## Submitted by Kalin Agrawal
**[Link to original bug (#677360)](https://bugzilla.gnome.org/show_bug.cgi?id=677360)**
## Description
>>>
Wishlist item: I am comparing two directories with sets of files that have identical contents. ...## Submitted by Kalin Agrawal
**[Link to original bug (#677360)](https://bugzilla.gnome.org/show_bug.cgi?id=677360)**
## Description
>>>
Wishlist item: I am comparing two directories with sets of files that have identical contents. One side of Meld shows all the icons of folders and files with little stars on them. When I compare the files, they are identical. But I have no way of knowing what that star means.
I understand that across different platforms and color choices there might be different meanings for the different color-codings and icons. So, what if I hovered the mouse over the file or directory, or if I right-clicked it, and a quick summary of the reason for their differences (or similarities) was given. For example, if the files are the same contents but have different meta-data (like modification time or something), then it might say "This file has the same contents as its matched one. This file has been modified more recently than the other one."
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/44[BZ#676104] Show diff between common ancestor and conflicting children2019-02-17T22:23:46ZBugzilla[BZ#676104] Show diff between common ancestor and conflicting children## Submitted by Sami Wagiaalla
**[Link to original bug (#676104)](https://bugzilla.gnome.org/show_bug.cgi?id=676104)**
## Description
>>>
I have diff3 enabled in my .gitconfig:
[merge]
conflictstyle=diff3
Which meld seems to be...## Submitted by Sami Wagiaalla
**[Link to original bug (#676104)](https://bugzilla.gnome.org/show_bug.cgi?id=676104)**
## Description
>>>
I have diff3 enabled in my .gitconfig:
[merge]
conflictstyle=diff3
Which meld seems to be handling correctly. It would be really cool however if meld would show me what has changed remotely that is causing the conflict.
For example in the attached image I had moved a chunk of code to its own function. Someone changed this code remotely but I could not tell what the change was even though I was looking at the remote version(left) vs the common ancestor(center). When I copied the code to files ran diff I found this:
- setProjectRoot(FedoraPackagerUtils.getProjectRoot(eventResource));
+ setProjectRoot(FedoraPackagerUtils
+ .getProjectRoot(eventResource));
:)
If meld highlighted this in a darker red that would be great! You do this in the blue non conflicting changes.
Thanks
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/43[BZ#674557] [PATCH] Patch mode2019-02-17T22:23:46ZBugzilla[BZ#674557] [PATCH] Patch mode## Submitted by Piotr Piastucki
**[Link to original bug (#674557)](https://bugzilla.gnome.org/show_bug.cgi?id=674557)**
## Description
>>>
The attached patch adds patch view mode to meld.
Basic info about the new modules:
1) patch...## Submitted by Piotr Piastucki
**[Link to original bug (#674557)](https://bugzilla.gnome.org/show_bug.cgi?id=674557)**
## Description
>>>
The attached patch adds patch view mode to meld.
Basic info about the new modules:
1) patchparser.py contains a simple unified format patch files parser
2) patcher.py applies patch file in memory and returns details results
3) patchview.py, patchdiff.py provide new UI to review patches
To run meld in patch mode use the following command:
meld --patch <file> [<dir>]
file - patch file, currently unified format patches are accepted
dir argument is optional, current directory will be used when omitted
Additional UI is provided to review and inspect patch files. Each file and each individual hunk affected by the patch file is shown in a tree view. If present, git commit message will be shown above the tree view. Quick diff is shown at the bottom.
More information and some screenshots can be found here - http://piastucki.bdl.pl/meld/patch/
Regards,
Piotr
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/42[BZ#674187] command-line/easy VC switching request2019-02-17T22:23:45ZBugzilla[BZ#674187] command-line/easy VC switching request## Submitted by Tim
**[Link to original bug (#674187)](https://bugzilla.gnome.org/show_bug.cgi?id=674187)**
## Description
>>>
Request for new feature to make it easier to select a specific VC when multiple VCs are available.
For d...## Submitted by Tim
**[Link to original bug (#674187)](https://bugzilla.gnome.org/show_bug.cgi?id=674187)**
## Description
>>>
Request for new feature to make it easier to select a specific VC when multiple VCs are available.
For details, see discussion in [Bug 670734](https://bugzilla.gnome.org/show_bug.cgi?id=670734).
Opening separate issue as requested in comment https://bugzilla.gnome.org/show_bug.cgi?id=670734#c5
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/41[BZ#671958] Hotkeys could be more convenient for diffs across many files2019-02-17T22:23:45ZBugzilla[BZ#671958] Hotkeys could be more convenient for diffs across many files## Submitted by Julian de Bhal
**[Link to original bug (#671958)](https://bugzilla.gnome.org/show_bug.cgi?id=671958)**
## Description
>>>
Created attachment 209556
ctrl+alt+page up/down -> alt+page up/down for previous/next tab
My ...## Submitted by Julian de Bhal
**[Link to original bug (#671958)](https://bugzilla.gnome.org/show_bug.cgi?id=671958)**
## Description
>>>
Created attachment 209556
ctrl+alt+page up/down -> alt+page up/down for previous/next tab
My use case is double-checking the result of a search-and-replace script across my code-base, so it's very small changes but lots of them and across lots of files (49 files, but averaging only 2-3 changes per file).
With the ctrl I'm alternating between alt+down and ctrl+alt+page-down, but having stripped out the ctrl I can just hold down alt and hit down until there are no more changes, and then page-down for the next file, and it feels fantastic.
It's hard to communicate how much better it feels - please try it. Just do something like a search and replace across a codebase e.g. swap "the" for "teh":
for file in `find -name *.cpp`; do cat $file | perl -pe 's/\bthe\b/teh/' > $file.tmp && mv $file.tmp $file; done
The specific modifiers don't really matter, as long as they're shared for "next change" and "next tab". Having a second hotkey for either function to achieve this would work too.
**Patch 209556**, "ctrl+alt+page up/down -> alt+page up/down for previous/next tab":
[alt-pagedown-for-next-tab.diff](/uploads/4924ecf5ff0e5c240e9d1bb34ef6b05a/alt-pagedown-for-next-tab.diff)
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/40[BZ#671607] Support command line text filters2019-02-25T12:10:38ZBugzilla[BZ#671607] Support command line text filters## Submitted by Adam Russell
**[Link to original bug (#671607)](https://bugzilla.gnome.org/show_bug.cgi?id=671607)**
## Description
>>>
I often times find myself wishing meld supported more command line options similar to diff, espe...## Submitted by Adam Russell
**[Link to original bug (#671607)](https://bugzilla.gnome.org/show_bug.cgi?id=671607)**
## Description
>>>
I often times find myself wishing meld supported more command line options similar to diff, especially regarding ignoring whitespace. It is inconvenient to have to start meld, manually check/uncheck the text filters I want in the preferences, and then restart meld with the actual diff I desire. Instead, I'd rather just be able to pass in options to meld in a similar fashion to diff, e.g.:
-i, --ignore-case
ignore case differences in file contents
-E, --ignore-tab-expansion
ignore changes due to tab expansion
-b, --ignore-space-change
ignore changes in the amount of white space
-w, --ignore-all-space
ignore all white space
-B, --ignore-blank-lines
ignore changes whose lines are all blank
-I, --ignore-matching-lines=RE
ignore changes whose lines all match RE
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/36[BZ#664624] Showing only xx lines around changes2021-12-22T20:51:36ZBugzilla[BZ#664624] Showing only xx lines around changes## Submitted by Marko Struna
**[Link to original bug (#664624)](https://bugzilla.gnome.org/show_bug.cgi?id=664624)**
## Description
>>>
It would be great if Meld would have option that it would display only XX lines around the chang...## Submitted by Marko Struna
**[Link to original bug (#664624)](https://bugzilla.gnome.org/show_bug.cgi?id=664624)**
## Description
>>>
It would be great if Meld would have option that it would display only XX lines around the changes.
If we compare two very long files and changes are only at the beginning, middle and at the end of the files, user must scroll through entire file to see the changes (or use shortcut option, Go To Next Difference).
Instead Meld could have possibility to show only 3 (configurable) surrounding lines around changes and one (maybe gray) line where it is written how many lines are skipped.
Option would be placed in Meld Preferences Window in tab Editor:
Show only __ lines of context
Example with 3 surrounding lines:
- 8<------ BEGGING OF FILE ------------ >8 --
Skipped 10 lines
11 line 3
12 line 2
13 line 1
14 CHANGE 1
15 line 1
16 line 2
17 line 3
Skipped 513 lines
530 line 3
531 line 2
532 line 1
533 CHANGE 2
534 line 1
535 line 2
536 line 3
Skipped 312 lines
848 line 3
849 line 2
850 line 1
851 CHANGE 3
852 line 1
853 line 2
854 line 3
Skipped 31 lines
- 8< ------------- END OF FILE ------------ >8 --
Best regards
Marko
>>>https://gitlab.gnome.org/GNOME/meld/-/issues/35Extension system for filters2023-09-10T14:08:18ZBugzillaExtension system for filters## Description
**[Link to original bug (#662333)](https://bugzilla.gnome.org/show_bug.cgi?id=662333)**
The use-cases for both file and directory filters are very wide-ranging, and it would be awesome to be able to allow users more fl...## Description
**[Link to original bug (#662333)](https://bugzilla.gnome.org/show_bug.cgi?id=662333)**
The use-cases for both file and directory filters are very wide-ranging, and it would be awesome to be able to allow users more flexibility in how filtering was applied. However, neither our current backend or UI can handle this in a sensible way.
One option is to provide a plugin/extension-based system that allowed more extensive and configurable ways to filter both text and files.
One use case would be to use a large database of ignore-worthy files such as https://github.com/github/gitignore
Another use case would be to provide a domain-specific text-transformation plugin so that complicated formats could be easily translated to diff-able versions.