1. Disconnect network
2. git-pr-create A creates a local, but not a remote branch
3. Connect network
4. git-pr-create A exits nonzero after detecting that the local branch A/123abc already exists, and does not re-attempt to create the remote branch

The actual error is lost here. Create a custom struct that includes exit status and anything else we need.

Originally posted by @calebwherry in #1 (comment)

Relying on shell will be problematic cross-platform. We should re-write in Rust, these are simple programs so shouldn't add too much overhead.

Originally posted by @calebwherry in #1 (comment)

statics don't run destructors, so lazy_static! doesn't allow temp_dir to do its magic.

We have a lot of functions that accept strings as input, but they expect those strings to have certain internal structure. We could take advantage of the type system, and return/accept something like:

struct GitBranchDashA {
    content: String
}

The .gitignore generated by GitHub says:

Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html

so we should do that.

This will let Git client prepare the argument string for git, and this argument string can be unit-tested in memory. Separately, the Command-like type can be integration tested against a much smaller example binary.

Clean up local PR branches which have been accepted

Add windows and MacOS to GitHub actions CI yaml.

Remove all branches for this PR from the local and origin repositories.

This might require a separate pipeline. The idea is that, while everything in trunk should always be in "release-ready" state, we might not want to release every single merge. Pushing tags to trunk gives us the opportunity to define a separate GitHub Action with permission to post its built artifacts to the GitHub API in order to create a release.

How do we combine these?

Originally posted by @calebwherry in #1 (comment)

When installed, git subcommands each come with their own unix manual entries:

• https://git-scm.com/docs/git-merge-base
• https://git-scm.com/docs/git-merge-file
• https://git-scm.com/docs/git-merge-one-file
• https://git-scm.com/docs/git-merge-tree

plus a high-level entry to document the whole subsystem:

• https://git-scm.com/docs/git-merge

We should at least write the high-level man page, and if we can stomach roff, go back and write individual pages for each command in our suite.

Using origin can cause issues with others not using that wordage. Replace with "not slash" match as it can be anything.

Originally posted by @calebwherry in #1 (comment)

Currently, we "touch" the global test state by just printing the state:

println!("TempDir='{:?}'", TEST_STATE.path());

But we should really push this into a macro and call it "init_test_state" or something.

At the moment, running cargo test --release on your local machine will overwrite these settings in your ~/.gitconfig:

$ git config user.name
Your Name
$ git config user.email
[email protected]

all_branches includes remote refs.

Between the git-pr binaries and their associated documentation (#29) we are looking at distributing about a dozen artifacts to end users. What options do we have for installation?

1. Let Cargo Do it

The easiest path may be to distribute via crates.io. While intended for libraries, some binaries are distributed this way, though mostly only stuff intended as Rust development tools (clippy, et al). That might look like this:

$ cargo install git-pr
...downloading...
...compiling...
...installing???

I don't know for sure if cargo supports installing things in system-wide paths, or if it will only install them within the user's home directory. git is smart enough to find the binaries as long as they are in $PATH, but man won't be able to find the documentation unless its in $MANPATH, which users are much less likely to want to customize.

2. Write some bogus script

If we'll always be targeting a bash-capable environment (thinking of GitBash for Windows here), then we could:

1. Find the right analogue of /usr/local/libexec/git, and try to put the binaries there
2. Find an appropriate spot on the filesystem to stick the man pages
3. Figure out what GitBash's interpretation of "sudo" would be on Windows

3. Integrate with package managers

This would be by far the most work, but probably also the best solution for users.

• Chocolatey for Windows
• PkgSrc or Homebrew for macOS
• Apt for Debian / Ubuntu

Does just using the exe name work instead of having to join with the full path?

Originally posted by @calebwherry in #1 (comment)

Some things I think we should do:

• Only allow trunk commits via PR
• Setup security policies
• Add aux files to repo like CONTRIB or other files that GH can use

Probably many more but definitely wanted to get the first 2 done.

At the moment, the tests that depend on fake_git are more-or-less ask the question "have we invoked git with the right arguments?". I am not sure what we get from this.

I think it made sense initially to have fake_git and failing_git so that we could test our strategy for executing subprocesses. I am less sure that it makes sense to keep extending fake_git with new subcommands, only to turn around and write a similar integration test against real git.

Add an additional test line for a "remote branch we are not actually tracking"

Originally posted by @calebwherry in #1 (comment)

Needs things like:

• General info
• Build/release badges
• Platform support

Create a new branch by rebasing against the latest trunk, using trunks hash as the "revision" of the PR. Remove all previous revisions of the PR.

Merge the branch into trunk iff the branch can be fast-forwarded (that is, the branch must contain a descendant of trunk). The branch will then be discarded both locally and on the origin remote.

With the fake git mocks, we want simple binaries with the least number of dependencies. So, for CLI options that are dead simple, we don't want to use CLAP (like we do in the actual product binaries). We ran into an issue with matching on Option that required some ugly looking code:

     let first_arg = env::args().nth(1);
     match first_arg {
         None => exit(1),
         Some(val) => {
             if val == "--version" {
                 println!("fake_git version 1");
             } else {
                 exit(1);
             }
         }
     };

For some reason, we could not match using something like Some("--version"). Should be doable and much cleaner to do it this... but how?

We are doing a moderately good job documenting the code, and we have plans (#29) to write reference documentation for each individual command, but nothing beats a good overall tutorial with usage examples.

GitHub decided that when it runs Actions, it checks out PRs in detached head. See info here: actions/checkout#6

This is a problem for us because we need a working git and repo to run integration tests.

We should probably make this private so external users can't use it. It's really only for out unit test framework.

Originally posted by @calebwherry in #1 (comment)

Should be empty string by default.

How does tab completion work, and can we support it? RipGrep uses clap to automatically generate tab completion files for some shells:

    // Use clap to build completion files.
    let mut app = app::app();
    app.gen_completions("rg", Shell::Bash, &outdir);
    app.gen_completions("rg", Shell::Fish, &outdir);
    app.gen_completions("rg", Shell::PowerShell, &outdir);
    // Note that we do not use clap's support for zsh. Instead, zsh completions
    // are manually maintained in `complete/_rg`.

Zsh-specific

• Completion crash-course for RipGrep devs: https://github.com/BurntSushi/ripgrep/blob/master/complete/_rg#L443
• Official docs: http://zsh.sourceforge.net/Doc/Release/Completion-System.html
• Community style-guide: https://github.com/zsh-users/zsh/blob/master/Etc/completion-style-guide

This bug is sortof speculating that we will eventually accept #24 in something close to its current form; if so, then git-pr-list will want to be aware of branches ending in hexadecimal numbers, rather than just digits:

We don't need Path anymore, because @calebwherry found that we don't need the Path construction stuff that I assumed we needed on Windows. I also didn't realize that String implements a trait called AsRef<OsStr>, meaning that it can be passed as a reference to std::process::Command::new. So that will bring the number of string types in this code from 3 down to 1!

Originally posted by @robertdfrench in #1 (comment)

Create a new local branch with an associated upstream tracking branch for a pull request.

It compiles regexes at first runtime use, not at (rust) compile time. So ends up being the same as if we initialized them normally.