git stack --pull panics

Bouke commented 3 years ago

[X] I have searched the discussions
[X] I have searched the existing issues

Description

I'm trying out git stack on an existing git repo with lots of branches. git stack produces output, to the non-initiated a somewhat complex tree, but I assume I'll get understand that once I start using git stack. However trying git stack --pull causes a panic and asks me to report here:

git stack --pull From XXX

branch master -> FETCH_HEAD Well, this is embarrassing.

git-stack had a problem and crashed. To help us diagnose the problem you can send us a crash report.

We have generated a report file at "/var/folders/z3/r5mpk9zx2x9g2ldj8jsxbgw80000gn/T/report-9c6ecca9-5db4-4561-9140-3e5559a8306d.toml". Submit an issue or email with the subject of "git-stack Crash Report" and include the report as an attachment.

We take privacy seriously, and do not perform any automated error collection. In order to improve the software, we rely on people to submit reports.

Thank you kindly!

With the report:

name = 'git-stack'
operating_system = 'unix:OSX'
crate_version = '0.2.9'
explanation = '''
Panic occurred in file '/Users/bouke/.cargo/registry/src/github.com-1ecc6299db9ec823/git-stack-0.2.9/src/git/repo.rs' at line 256
'''
cause = 'called `Option::unwrap()` on a `None` value'
method = 'Panic'
backtrace = '''

   0: 0x101f18ca3 - _rust_begin_unwind
   1: 0x101f671df - core::panicking::panic_fmt::h446d8c458c19157b
   2: 0x101f67137 - core::panicking::panic::h85502d0e50e703a1
   3: 0x101d11450 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once::h9ecb1bc90fa5c413
   4: 0x101d31d2f - itertools::Itertools::join::h4b45a05693d61724
   5: 0x101d1494e - <git_stack::git::repo::GitRepo as git_stack::git::repo::Repo>::cherry_pick::hab31fb3c8eef972a
   6: 0x101d1f299 - git_stack::git::commands::Executor::stage_single::h239b0e44ccfd388e
   7: 0x101d1e61c - git_stack::git::commands::Executor::run_script::h033a775e85b41783
   8: 0x101d1e72f - git_stack::git::commands::Executor::run_script::h033a775e85b41783
   9: 0x101cd5632 - git_stack::stack::stack::h9f0791288d249293
  10: 0x101cf1a45 - git_stack::run::ha8a1ec3ceed92a08
  11: 0x101cf1519 - git_stack::main::h1da7007d8ebff9ef
  12: 0x101cfa33a - std::sys_common::backtrace::__rust_begin_short_backtrace::h1b4ffa0fc3d9cb95
  13: 0x101cfa35c - std::rt::lang_start::{{closure}}::hb98685e2ce96d9de
  14: 0x101f36c37 - std::rt::lang_start_internal::hab60970306655577
  15: 0x101cf1be9 - _main'''

Version

0.2.9

Steps to reproduce

No response

Actual Behaviour

No response

Expected Behaviour

No response

Debug Output

Skipping most of the output which seems to work fine, near the end is the following:

[TRACE git_stack::git::commands] Applying `XXX`
[TRACE git_stack::git::commands] Script: [
        SwitchMark(
            6b7f0d8c79319c342608ed1f54d5b0d316817c15,
        ),
        CherryPick(
            68406090405df0275e110e4fd581c21a4f04d7b1,
        ),
        CreateBranch(
            "XXX",
        ),
    ]
[TRACE git_stack::git::commands] git checkout 6b7f0d8c79319c342608ed1f54d5b0d316817c15  # Merged PR 2545: XXX
[TRACE git_stack::git::commands] git cherry-pick 68406090405df0275e110e4fd581c21a4f04d7b1  # XXX

epage commented 3 years ago

Thanks for reporting and sorry your first experience is less than ideal! This has been my daily driver for the last several months but I've only recently started to advertise it more and so it doesn't have the polish yet of many user experiences.

I'm trying out git stack on an existing git repo with lots of branches. git stack produces output, to the non-initiated a somewhat complex tree, but I assume I'll get understand that once I start using git stack.

Feel free to create an issue about the stackview being overwhelming. Hopefully we can find safe weighs for communicating what your workflow is like that makes it so overwhelming so we can figure out alternatives, steps, or different defaults we might want

However trying git stack --pull causes a panic and asks me to report here:

Huh, if I'm reading this correctly, there is a conflict without a their or our path.

If you don't mind, could you reproduce what is happening to see what the conflict is? I'd like to better understand what this case is. If you want to see what git-stack was attempting, run git stack --rebase --dry-run

In the mean time, I'll go attempt a fix

epage commented 3 years ago

v0.2.10 is in the process of being released, with this fix and several others.

gitext-rs / git-stack