Getting following error when trying to run verco inside a git repo

memory allocation of 18446744073709551609 bytes failedAborted (core dumped)

additional info:

$uname -a

Linux hostname 5.6.10-300.fc32.x86_64 #1 SMP Mon May 4 14:29:45 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Ctrl-c didn't seem to quit? I tried 'q' as well.

Is this Hotel California? :-)

I find tig really good for staging / unstaging files, but tig doesn't have multiple select. Maybe spacebar to select/unselect a file?

The project seems promising - I like tig but it could be snappier.

Hi, I realize that this issue is asking for a significant change in the codebase, but the sooner it's done, the easier the switch will be.

This would add the ability to keep the UI responsive while loading slower commands, and do background loading more easily.

Have you already thought about this?

The current log replacement for shortcuts does not work well when hashes are referred to inside revision descriptions.

This change does 2 things: - Uses a more robust template string that does not exhibit the above bug - Drops one of the two VCS calls necessary to dramatically improve performance in big repositories

This requires the addition of a dependency on regex, which is one of the best crates in the ecosystem and will most likely be used in other future patches.

The current hash shortcut system has some limitations such as:

• only the first 26 visible or something hashes have shortcuts
• you can only use them if you first run the log action
• it makes the log action call to git/hg log twice to get the hashes (although this is fixed by #18)

Some suggestions:

• auto completion (maybe a background job that fetches some hashes for completion)
• a log view that lets us select a commit (and parsing it's hash into a verco register or clipboard, or something) and maybe do something with it
• an action just for copying (or saving to a register) a commit hash. we could have then actions that operate on the clipboard (or saved register)

Attempting to build from the 5.0.0 release tarball with cargo build --release --locked results in an error:

error: the lock file /home/wmoore/Projects/aur/verco/src/verco-5.0.0/Cargo.lock needs to be updated but --locked was passed to prevent this
If you want to try to generate the lock file without accessing the network, use the --offline flag.

I use --locked when building an AUR package to ensure that the build is reproducible. It appears that you have not committed the Cargo.lock file. This is recommended for binary packages to ensure others building from source use the same version of dependencies that you used.

This is to reduce diff size and keep everything clean.

I vote for using 80 characters per line because it fits nicely in all the UIs I use, but that's your call.

Would be nice to have a command to back to previous view, unless I'm missing it. For example, going to details view for a commit and then to diff view for a file, there's no way to go back to previous details view?

Mercurial has had a JSON template output since version 3.1. Using that then generating the graph in Rust could allow for a more robust and flexible log for example. (I know that there are ways of doing so with Git too)

This could be used to facilitate a selection interface, merging caches, customizing the output, etc..

This issue is twofold:

• Like THG and many other VCS UIs, Verco should fill the log pane with as much as needed from the VCS and not just an arbitrary default number (50). Maybe the lc command should remain, as people might find that useful?
• The log view should be scrollable, with the VCS being queried lazily in the background (maybe some margin already preloaded to reduce waiting time) to update the newly visible entries.

This ties into #8, as I don't believe this would be a lot easier to achieve in an async context by leveraging the built-in pager.

Maybe bs could show an interface similar to commit selected and let you both move a cursor and fuzzy filter branches before selecting one to switch to.

Currently, we're making excessive use of mercurial and tortoisehg mainly because the system is pretty good and supporting various merge workflows. Would it be possible to add that to verco too?

I pulled a repository to a new PC, and made some changes and tried to push the changes to a remote. Verco failed to push changes, but there were no errors. I tried plain Git, and I forgot to update user.name and user.email in the new environment.

Would be nice to have an error.

I am note certain what the git equivalent is, so I left it unimplemented (and hidden) for now.

Related: I think the keyboard shortcuts should be part of the config file, although we would have to warn about conflicts and unreachable chords.

I don't want to accidentally do anything with a shortcut, I think a read-only mode (command line argument/config?) to remove all write actions would be super useful.