On 2021-06-09 13:32, Jonas Bernoulli wrote:

• I think magit-repolist-column-flags should be added in a separate commit, before all the rest. (And use pcase-let like in magit-repolist-column-flag. The line-break after mapconcat seems unnecessary.)

• magit-repolist-sort-column should probably also be added in a separate commit.

OK, then. I just finished re-doing those as separate commits and pull requests and also a third for the "working.." message.

You didn't give me feedback on the main operation for all this effort, which was to offer a speedy and snappy default listing, with option to subsequently display data that can have a long wait time (in my case ~20 seconds, for only about a dozen repositories, none particularly large, all on the same local hdd).

-- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0

• This is the third of several expected PR's to redo #4399 which included several things together.

• A new function magit-repolist-column-flags' offers a column to present all the flags of variablemagit-repolist-column-flag-alist' instead of only the first, as offered by the current function `magit-repolist-column-flag'.

• A new function magit-repolist-status-flags' offers a column to present a more complrehensive collection of flags than does functionmagit-repolist-column-flags', to include columns for stashes (heading 'z'), unpulled (heading '↓'), and unpushed (heading '↑'). For each these, the actual value is either: blank, for none; an integer 1-9; or '+' for greater than 9.

  • The motivation for this presentation option is that it's horizontally compact, comprehensive, and hopefully with the blanks instead of zeros won't be often terribly crowded to read.

• This commit DOES NOT actually force these options onto the user.

  • That is expected to be another redo of aforesaid PR #4399 which included this and more, bundled into a single neat complete package with a few more features yet (see there).

• This is the second of several expected PR's to redo #4399 which included several things together.

• The first time I evaluated function `magit-list-repositories' it took so long (> 20 seconds) that I thought it had hung. This commit is one step in addressing that in just simply letting the user know the operation may take a while.

  • A follow-up could be to set-up a timer to add a period every two-seconds until the operation is complete. I didn't include that in this commit because in the final product of #4399 the initial run of the command is so much speedier, but it could be done anyway.

  • A follow-up could be to figure out why the operation is so slow to begin with, but that wasn't the direction of #4399.

• The default sort column for the result buffer was changed from being hard-coded to being a defcustom.

• The default sor column was changed from "Path" to "Name"

  1. Paths can be long, and their most important (right-most) part is most likely to be truncated by the buffer window width;

  2. Duplicate names become easier to spot.

• This is the first of several expected PR's to redo #4399 which included several things together.

The same image as above but without having to click five times and start another application :grin:

Hi,

I noticed that using Magit while using a big font is a little difficult, see this attached example : Seeing only a portion of the transient map with no truncated lines

Accessing informations on a regular prefix map can be done with [prefix-map-keybinding C-h], unfortunately Magit does seem to expose such functionality ; we can access all the keybinding with [C-h m] but this is not the same command nor result.

When displaying a transient map, we can still navigate inside with scroll horizontally and vertically commands, however having to scroll-left|right to see the different columns feel a little clunky and less accessible than a regular help buffer. Also letting the user use some of the others navigation commands may help a little because the commands cited above are quite brutal.

So I believe there is two way to improve the accessibility of the magit transient maps :

1. Or the transient map put his columns one after another vertically when the width is not sufficient to display them horizontally
2. Or the transient map expose a command help similar of what we can have for prefix map and the user can fallback on it.

I rather prefer 1. because it believe it will be still difficult for a new user to understand the dash options commands in a regular help buffer.

Is there a reason for this?

(To be applied to the crm branch.)

In magit-completing-read-multiple*, this avoids changing the return value of split-string. With this, selectrum's crm function works correctly instead of signaling an error.

(The first commit doesn't change behaviour, only formatting, to make the second commit easier.)

You could experiment with something like "[^\\]," as crm-separator. Look at how that regexp is used and how that might allow you to implement/fake quoting.

@tarsius Right. I understand that comma is a file separator. Is there any way to escape the separator so that it is parsed as a part of the file name? This problem would apply to every separator I choose. Having an escape character would be the best solution.

I don't know how rare your preference is, but, at least until it becomes clear that it's a bit more common, I'm in favor of leaving this as is.

:-(

Thanks for looking into it!

Hello,

Currently when I run a log with --, opening a log diff with enter opens the diff limited to files specified to --. I have to press DF to see the full diff. I am usually more interested in seeing the full diff and would like to have the filter off by default, and I can turn it on by pressing DF. man git-log has the option --full-diff so that can be used as the option name I think.

Following gh-4390, the snippet above should achieve the behavior you're after (file filter off by default). I don't know how rare your preference is, but, at least until it becomes clear that it's a bit more common, I'm in favor of leaving this as is.

In revision/status/diff buffers long lines (minified javascript for instance) make the buffer slow to load and slow to scroll.

It should be possible to remove the problematic text just after the result of the git command.

PS: Maybe there is a hook ? PS: so-long.el is fine for displaying the content but it breaks the jump to file, folding etc...

Since this issue is not limited to Magit but affects all buffers that have exceptionally long lines I do not intend to add any magit-specific workarounds. My recommendation is to avoid using magit when adding minified javascript (which could be considered some form of binary data). Commit it on the command-line and if you really need to look at the diff, then use some other tool or follow @phil-s' advice.

• I think magit-repolist-column-flags should be added in a separate commit, before all the rest. (And use pcase-let like in magit-repolist-column-flag. The line-break after mapconcat seems unnecessary.)
• magit-repolist-sort-column should probably also be added in a separate commit.

Okay, I've added a cross-reference.

When creating a squash! commit, magit should prompt for a commit message. From the manpage for git commit:

       --squash=<commit>
           Construct a commit message for use with rebase --autosquash. The commit message subject line is taken from the specified commit with a prefix of "squash! ". Can be used with additional commit message options
           (-m/-c/-C/-F). See git-rebase(1) for details.

When creating a squash commit, you can add additional message lines which will be appended in the suggested commit message when you rebase --autosquash later. Here is an example workflow:

$ git init
$ echo 'initial' >f
$ git add -A; git commit -m 'initial commit'      
[master (root-commit) 7674652] initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 f
$ echo 'feature' >f
$ git add -A; git commit -m 'feature'             
[master 278200d] feature
 1 file changed, 1 insertion(+), 1 deletion(-)
$ echo 'edited' >f 
$ git add -A; git commit --squash HEAD -m 'edited'
[master 57a6fc6] squash! feature
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git log --graph --pretty=format:'%h%n%n%w(0,4,4)%B' | cat
* 57a6fc6
| 
|     squash! feature
|     
|     edited
| 
* 278200d
| 
|     feature
| 
* 7674652
  
      initial commit
$ git rebase --autosquash --interactive HEAD^^
hint: Waiting for your editor to close the file... Waiting for Emacs...

At this point the todo list given is

pick 278200d feature
squash 57a6fc6 squash! feature

After accepting that list, the suggested commit message that pops up is

# This is a combination of 2 commits.
# This is the 1st commit message:

feature

# This is the commit message #2:

squash! feature

edited

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
...

After accepting that message...

[detached HEAD 566cd8e] feature
 Date: Wed Jun 9 11:27:48 2021 -0400
 1 file changed, 1 insertion(+), 1 deletion(-)
Successfully rebased and updated refs/heads/master.
$ git log --graph --pretty=format:'%h%n%n%w(0,4,4)%B' | cat
* 566cd8e
| 
|     feature
|     
|     squash! feature
|     
|     edited
| 
* 7674652
  
      initial commit

I think it is important that the user be able to add messages to squash commits. Admittedly, I am relatively new to squash and fixup commits, but I believe the ability to add messages is the main distinction of squash commits vs fixup commits