wbthomason / packer.nvim

A use-package inspired plugin manager for Neovim. Uses native packages, supports Luarocks dependencies, written in Lua, allows for expressive config
MIT License
7.82k stars 266 forks source link

Unknown option rebase=false #1014

Closed rongcuid closed 1 year ago

rongcuid commented 2 years ago

Features: +acl +iconv +tui See ":help feature-compile"

system vimrc file: "$VIM/sysinit.vim" fall-back for $VIM: " /home/runner/work/neovim/neovim/build/nvim.AppDir/usr/share/nvim"

Run :checkhealth for more info


- `git --version`:

git version 1.8.3.1


- Operating system/version:CentOS 7

### Steps to reproduce

Use an old git version.

return require('packer').startup({function(use)
-- [[ Plugins Go Here ]]
use 'wbthomason/packer.nvim'
end,
config = {
package_root = vim.fn.stdpath('config') .. '/site/pack',
git = {
update = 'pull --ff-only --progress --no-rebase',
install = 'clone --depth %i --no-single-branch --progress',
fetch = 'fetch --depth 999999 --progress',
checkout = 'checkout %s --',
update_branch = 'merge --ff-only @{u}',
current_branch = 'branch --show-current',
diff = 'log --color=never --pretty=format:FMT --no-show-signature HEAD@{1}...HEAD',
diff_fmt = '%%h %%s (%%cr)',
get_rev = 'rev-parse --short HEAD',
get_msg = 'log --color=never --pretty=format:FMT --no-show-signature HEAD -n 1',
submodules = 'submodule update --init --recursive'
}
}})


Try to install or update

### Actual behaviour

Errors: error: unknown option `rebase=false' usage: git fetch [] [ [...]] or: git fetch [] or: git fetch --multiple [] [( | )...] or: git fetch --all [] -v, --verbose be more verbose -q, --quiet be more quiet --all fetch from all remotes -a, --append append to .git/FETCH_HEAD instead of overwriting --upload-pack path to upload pack on remote end -f, --force force overwrite of local branch -m, --multiple fetch from multiple remotes -t, --tags fetch all tags and associated objects -n do not fetch all tags (--no-tags) -p, --prune prune remote-tracking branches no longer on remote --recurse-submodules[=] control recursive fetching of submodules --dry-run dry run -k, --keep keep downloaded pack -u, --update-head-ok allow updating of HEAD ref --progress force progress reporting --depth deepen history of shallow clone --unshallow convert to a complete repository



Despite not having `rebase=false` anywhere in config or in Packer, this still fails.

### Expected behaviour
Package installs
akinsho commented 2 years ago

@rongcuid this appears to be similar to other issue you reported that relates to progress and git versions. Tbh ultimately the decision is down to @wbthomason, but I think it's reasonable for packer to target/assume a git version more recent than the one you use. I guess you have some special reason why you can't update but in this case I think as was mentioned in the other issue that rather than bending over backwards to support a 6-year-old version of git you should tweak all the git commands packer uses to their equivalent for your git version.

There has to be a line somewhere, packer is hard enough to maintain (see the 200+ issues) without also having to support very old versions of git

EdenEast commented 2 years ago

The version of git you are using is not even v2 of git. This is not something that packer should try and support as this git version if not even on the latest major version. (1.8.3.1 came out on 10-Jun-2013). I would suggest updating your git version. I have done this before on Centos 7. If you really cant update then I would suggest overriding all of the git commands like I mentioned in #747.

rongcuid commented 2 years ago

I understand the problem about Git version. However, this is not about having an old git version, but somehow Packer uses an option that is not specified in the config. Unless I am misunderstanding something, the --rebase=false should not appear anywhere.

My config above already overrides all git commands for compatibility.

akinsho commented 2 years ago

@rongcuid --rebase is a flag for git pull not git fetch if you do git pull -h on a version of git (v2+) you should see (I see)

usage: git pull [<options>] [<repository> [<refspec>...]]

    -v, --verbose         be more verbose
    -q, --quiet           be more quiet
    --progress            force progress reporting
    --recurse-submodules[=<on-demand>]
                          control for recursive fetching of submodules

Options related to merging
    -r, --rebase[=(false|true|merges|preserve|interactive)] <========= Here
                          incorporate changes by rebasing rather than merging
    -n                    do not show a diffstat at the end of the merge
    --stat                show a diffstat at the end of the merge
    --log[=<n>]           add (at most <n>) entries from shortlog to merge commit message
    --signoff[=...]       add a Signed-off-by trailer
    --squash              create a single commit instead of doing a merge
    --commit              perform a commit if the merge succeeds (default)
    --edit                edit message before committing
    --cleanup <mode>      how to strip spaces and #comments from message
    --ff                  allow fast-forward
    --ff-only             abort if fast-forward is not possible
    --verify-signatures   verify that the named commit has a valid GPG signature
    --autostash           automatically stash/stash pop before and after
    -s, --strategy <strategy>
                          merge strategy to use
    -X, --strategy-option <option=value>
                          option for selected merge strategy
    -S, --gpg-sign[=<key-id>]
                          GPG sign commit
    --allow-unrelated-histories
                          allow merging unrelated histories
rongcuid commented 2 years ago

No, the log shows usage for git fetch. See the report above. I also overrode git pull to use --no-rebase instead, which should work for the pull command.

akinsho commented 2 years ago

@rongcuid I'm not sure what log you are referring to since you haven't linked a log file, if you mean the snippet you pasted in the issue description, it's not immediately clear to me where this comes from.

Grepping through the entire packer codebase it only ever uses --rebase=true with git pull it never uses it by default with git fetch unless you have changed something in your config

rongcuid commented 2 years ago

Yes, I am referring to the snippet. This comes from the error message of the PackerInstall/PackerUpdate command after pressing Enter.

And the fact that Packer doesn't use git fetch confuses me too.

EdenEast commented 2 years ago

Currently packer decides to use fetch if commit or tag are present. If these are present it will have to do a checkout anyways. If they are not present then it will use pull.