nickgerace / gfold Goto Github PK

Describe the issue.

The "origin" resolved during is_unpushed is from the main remote branch, and not the remote of the local branch being tracked. Regardless of the fix, we may need to check if a remote exists for the local branch.

Is this a bug report, feature request, or another type of issue?

bug report

Are you using Windows, macOS, Linux, or another OS?

all supported platforms

Are you using a pre-built binary? If not, how did you obtain gfold?

build from source

We are running unversioned clap-rs, grabbing the latest from its main branch. It may be worth considering using structopt until clap-rs v3 releases (even after that too).

Currently, the release Action runs and the its title/description are manually changed afterwards. This could be automated into the release Action itself: https://github.com/nickgerace/gfold/blob/0.7.0/.github/workflows/release.yml

Relevant issue: rust-lang/rust#73908
Current guide: https://github.com/shepmaster/rust/blob/silicon/silicon/README.md

The gfold library should not log. The application should, if needed. Since the architecture is mainly a small CLI backed by a library, logging might even be removed entirely.

In addition, the logging from gfold 1.2.1 and before was very opinionated and included text that could become out of date or be incorrect.

Minimize issue filing process to have as minimal questions as possible.

OS type

Exact version number would no longer be required (such as Windows 10 2004, macOS 11.0, and Ubuntu 20.10

Prebuilt-binary or not

High-level obtainment method required (ex: build from source, crates.io, GitHub release download, etc.)

Type of request

RFE, bug, other.

Hey! I came to your tool from 📝 How I Read "The Rust Programming Language".

I noticed that the binary panics on bare repositories.

➜  tmp RUST_BACKTRACE=full /Users/kyle/.cargo/bin/gfold
thread 'main' panicked at 'failed get statuses: cannot status. This operation is not allowed against bare repositories.; class=Repository (6); code=BareRepo (-8)', src/gfold.rs:71:27
stack backtrace:
   0:        0x1067e61fe - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h13e6f26430148ff2
   1:        0x1068038cc - core::fmt::write::h45a9bd04db15c24f
   2:        0x1067e3629 - std::io::Write::write_fmt::h8ae61696f13218d5
   3:        0x1067e7e75 - std::panicking::default_hook::{{closure}}::hc98fe2390b6284e5
   4:        0x1067e7bb2 - std::panicking::default_hook::h9a63cea866a4c14a
   5:        0x1067e83d5 - std::panicking::rust_panic_with_hook::h4d446ca45c8e1faa
   6:        0x1067e7fa2 - rust_begin_unwind
   7:        0x10680f1db - std::panicking::begin_panic_fmt::h0f7b83f993394bc5
   8:        0x1066fedb0 - gfold::gfold::walk_dir::h7ce7a797048a9dd9
   9:        0x1066fc1b9 - gfold::main::h9a34aaa0573dc180
  10:        0x1066fc4e6 - std::rt::lang_start::{{closure}}::h1185fef6ccb1df63
  11:        0x1067e86a9 - std::rt::lang_start_internal::hecbcda5e1a75a865
  12:        0x1066fc4d9 - main

Steps to reproduce

$ mkdir repos
$ cd repos
$ git clone --bare https://github.com/octocat/Spoon-Knife
$ gfold

Reference: https://doc.rust-lang.org/cargo/reference/publishing.html

This might leverage tokio, async-await, rayon, etc. Green threads, or OS threads? We will see.

Description

Refactor library into driver and util files. This will help organize the gfold API for future refactors and changes.

Environment Details

Please feel free to add any additional details beyond the questions below.

Is this a bug report, feature request, or another type of issue?

Feature request

Are you using Windows, macOS, Linux, or another OS?

Windows, macOS, and Linux on amd64

Are you using a pre-built binary? If not, how did you obtain gfold?

Build from source

Hi,
I came across your project and I liked it. It looks promising for sure. 🚀
I'm also a Rust developer and I maintain AUR packages in my spare time. So I created the following packages for the installation of gfold on Arch Linux and other distributions that support installing packages from AUR:

• gfold (builds from source)
• gfold-git (VCS/development package)

Installation can be made simply by a AUR helper such as yay. (e.g: yay -S gfold)

Feel free to update your documentation regarding to the AUR packages and installation. (I would propose a PR if requested)

Take care,
orhun.

Spent the last few months closely re-reading "The Book", and it's time to at least re-evaluate the codebase.

For example: we may switch to using lib.rs to drive most of the crate. main.rs should be as minimal as possible.

GitHub has made this process simple, and there is no reason not to do it 😄!

Describe the issue:

Add -k flag to give kubectl-like output. This involves combining all results into one table with headers similar to kubectl.

Is this a bug report, feature request, or another type of issue?

feature request

Are you using Windows, macOS, Linux, or another OS?

all (maintainer)

How did you obtain the application?

all (maintainer)

Paste the output of gfold -V:

% gfold -V
gfold 1.4.0

There are many panic scenarios in gfold currently. This issue aims to recover on as many errors as possible, if not all of them.

Ideally, we would like main.rs to make every decision on how to handle the errors, and avoid panics in the library.

The run function is the only public struct, function, etc. and needs a small description on its inputs (args) and outputs (returned objects or actions): https://docs.rs/gfold/0.7.0/gfold/

Summary

gfld was an experiment to try to make a smaller, and faster, alternative to gfold. The results have been that gfold is much faster, despite it's larger size. Thus, the following should happen:

• Removal of gfld
• Learned optimizations to be integrated into gfold
• Return to a single crate repository structure (has the bonus benefit of being easier to maintain)

Details

• On average, the runtime speed of gfld 1.0.4 is ~105% slower than the runtime speed of gfold 1.0.4
• The binary size of gfld 1.0.4 is about ~40% smaller than gfold 1.0.4

Estimates

• gfold can potentially have its binary size reduced to ~60% of the size of gfold 1.0.4
• gfold runtime speeds will either be the same, better, or more consistent with proposed optimizations

Located at: https://github.com/orhun/PKGBUILDs

This will help with availability to both macOS and Linux users. The question will be whether to use dynamically linked, or statically linked binaries for Linux (most likely: dynamic, which is ehhhhhhh...?).

Docs page: https://docs.brew.sh/Adding-Software-to-Homebrew

For recursive search, add option to combine tables together into one massive table. The output could look similar to kubectl get pods -A.

Note: gfld had this output structure, but is slated for removal.

The below example may not represent the final design, but it summarizes the idea.

[user at hostname in ~/git] (0)
$ gfold --include-directories-that-are-not-repositories
repository  clean  main  [email protected]:username/repo.git
directory   -      -     -

This needs to be part of the GitHub Actions process: https://github.com/nickgerace/gfold/blob/0.7.0/.github/workflows/release.yml

Describe the issue. Feel free to be descriptive.

Instead of using expect and panic frequently, return the errors instead. It would be preferred to recover on many of these errors rather than simply "returning" them from the calling function, but this is a good first step.

What are you attempting to do, and/or what did you expect? In other words, what is the motivation and context to this issue?

The motivation is to clean up the codebase to return nearly all panic scenarios to main.rs. This is stepping stone towards recovering on more errors.

Is this a bug report, feature request, or another type of issue? If this is a bug report, describe how to reproduce the issue.

Feature enhancement

Are you using a pre-built binary? If not, please specify.

Yes

What OS are you using, and at what version number?

All OSes with corresponding GitHub releases, using the latest major version of each

What CPU architecture are you using? If you do not know, it is most likely amd64 or x86_64.

amd64

Additional information (optional)

None.

Might use an existing code of conduct.

Error seen as follows...

'failed to get sub directories: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }'

Describe the issue.

According to the cargo workspace documentation, all packages should share a common Cargo.lock file which should be present in the workspace root.

All packages share a common Cargo.lock file which resides in the workspace root.

Also AUR packages will become non-reproducible due to this issue since --locked flag causes the build to fail. (because Cargo.lock doesn't exist in the workspace root)

==> Starting build()...
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   /build/gfold/src/gfold-1.0.0/gfld/Cargo.toml
workspace: /build/gfold/src/gfold-1.0.0/Cargo.toml
    Updating crates.io index
error: the lock file /build/gfold/src/gfold-1.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.
==> ERROR: A failure occurred in build().

Solution is simply removing Cargo.lock from .gitignore and pushing it.

Is this about gfold, gfld, or both?

Both, about Cargo workspaces.

Is this a bug report, feature request, or another type of issue?

Bug report.

Paste the output of the relevant application(s).

# to reproduce the build error
git clone "https://aur.archlinux.org/gfold-git"
cd gfold-git/
extra-x86_64-build

We do not need an extended backtrace. gfold should remain lightweight. Since the codebase is relatively small, the file and line number should be enough to help determine the cause of the error. Custom errors are probably not necessary.

I use a lot of repos for work and maybe it could be nice to know if I didn't push my changes.

• in the table rows, one could have a clickable repository url
• and of course a state against the local repo : upgradable (5 commits)

with colors, in term of importance (new version > commits > minor commit > ...)

my 2 cents, I wanted to build the same tool, and I'm surprised how compact the code is, bravo!

Requires rust-lang/rust#72110 to be closed, and for the feature to be integrated into the tier 1, stable Rust toolchains.

We should add binaries for every tagged release with the minimum being...

• Linux: linux-gnu-amd64
• macOS: darwin-amd64
• Windows 10: windows-amd64

Describe the issue:

Since Clap v3 will be the successor to StructOpt and Clap v3 beta releases have been relatively stable, we should move to using Clap v3 (beta).

Is this a bug report, feature request, or another type of issue?

refactor

Are you using Windows, macOS, Linux, or another OS?

n/a

How did you obtain the application?

n/a

Paste the output of gfold -V:

n/a

Starting this issue just to keep track of release 1.0.0. This version will be considered "stable" for at least one binary, probably macos-amd64.

Describe the issue:

Add release action, but don't add hosted binaries yet. Using a package manager is always ideal.

Is this a bug report, feature request, or another type of issue?

feature (meta)

Are you using Windows, macOS, Linux, or another OS?

n/a

How did you obtain the application?

n/a

Paste the output of gfold -V:

n/a

Supporting MUSL requires using Docker at the moment. Since there are few users of gfold at the moment, we should suspend usage to minimize bloat in the CI pipeline.

However, if there's user interest, we should consider adding back statically-linked Linux (amd64) binaries to the pipleline.

Describe the issue.

It's weird, I don't seem to see any results. with strace I see that some git files are read.

~/dev
❯ gfold
There are no results to display.

gfold 0.8.0

Is this a bug report, feature request, or another type of issue?

bug

Are you using Windows, macOS, Linux, or another OS?

Linux

Are you using a pre-built binary? If not, how did you obtain gfold?

cargo install gfold

Describe the issue:

Since gfold's library API is not consumed by any other application, nor is it fully designed to be, we should revert back to an application-driven structure to reduce complexity. This may also enable logging to return in a fully capacity since all code will not be library code. Moreover, this would likely result in the removal of lib.rs.

Is this a bug report, feature request, or another type of issue?

refactor

Are you using Windows, macOS, Linux, or another OS?

n/a

How did you obtain the application?

n/a

Paste the output of gfold -V:

n/a