search

AndrewRadev / splitjoin.vim

Switch between single-line and multiline forms of code
http://www.vim.org/scripts/script.php?script_id=3613
MIT License
1.93k stars 90 forks source link

Missing master branch breaks update #174

Closed bodograumann closed 3 years ago

bodograumann commented 3 years ago

I have installed splitjoin.vim with minpac. Not sure about the details, but it uses git to fetch new versions. What I think happened, is that originally the installation was done from the default branch master. Now that branch is gone, so any remote tracking branches are probably broken.

Not sure what you are trying to achieve with this change, but it is a problem for users of the git repo.

AndrewRadev commented 3 years ago

Hmm, I see that minpac does hardcode master in case an explicit branch is not given. I'd have thought that, at least on checkout, it would simply do a git clone of the URL, although I guess it also needs an update. I feel like minpac could handle this, and fetch the right default branch whatever it happens to be, but it'd need some work.

Github has changed its default branch to "main" and I've started to slowly migrate -- no point in sticking with "master", new plugins are already going to have a default branch as "main". I see in minpac's documentation that you can provide a "branch" key when installing the plugin, could you try removing splitjoin and changing the config to something like call minpac#add('AndrewRadev/splitjoin.vim', {'branch': 'main'})? If this doesn't work and update correctly, it might make sense to open an issue to minpac. I could mirror a "master" branch, but I wouldn't remember to keep it up to date. Maybe I'll tweak the installation instructions, too.

bodograumann commented 3 years ago

My understanding was, that the default branch name is defined per repository. I feel like no tool should rely on any specific name for it, be it master or main. Thus my confusion as to the rename.

You are right though, that minpac has master hardcoded. That should probably be addressed.

johatfie commented 3 years ago

It also breaks the command git submodule foreach git pull origin master. Which is a common way to update all vim plugins when managing them with submodules.

Yes, I did find a work around, which I now have to apply on every machine I use, but this is the only one of about 50 submodules I use with this issue.

AndrewRadev commented 3 years ago

I feel like no tool should rely on any specific name for it, be it master or main.

Yes, I agree, it would be nice not to hardcode this stuff, but it can be an easy shortcut. I've seen repos with "develop", "dev", "release" branches. I'd say minpac's decision was a pragmatic one, and it's thankfully easy to fix with a branch argument. I wish, ideally, we (the Vim community) would work with sensible versioning instead of git branches, but there'd be a lot of work needed to get there :).

Yes, I did find a work around

I'm glad you could work around the problem. Could you share it here, so if other people have the same problem, they can have a solution?

What I found when looking around was that instead of this:

git submodule foreach git pull origin master

The following command should work the same way, fetching the remote's HEAD by default, whatever its branch name is:

git submodule update --remote

I personally had a hard time getting it to work, but that's because I have a very, very messy set of submodules :D. I've got my own forks in mine remotes or occasionally origin is my fork and upstream is the original. Not to mention local changes. I also had some "dangling branches", which seem to be fixable by adding a branch = master in .gitmodules.

But I avoid doing mass updates myself, since things tend to break for me, I usually update specific repos when I see version bumps. Plus, 120 repos apparently take some time to fetch :D.

char101 commented 3 years ago

I use plain git clone with git pull and it failed with no such ref, it is because the local master branch is set to track the remote master branch. It is ok to use whatever main/master branch, but simply don't change it afterwards.

It can be fixed by opening .git\config and changing merge = refs/heads/master to merge = refs/heads/main under the [branch "master"] key.

AndrewRadev commented 3 years ago

It can be fixed by opening .git\config and changing merge = refs/heads/master to merge = refs/heads/main under the [branch "master"] key.

Removing and re-adding is probably an easy way to get things to work, but nice to have a record of the right places where this kind of stuff is tracked :+1:.

AndrewRadev commented 3 years ago

I've installed https://github.com/google/mirror-branch-action to avoid future breakage. This should keep "master" up to date with "main" -- it seems to work fine on initial commit at least.

Because of this, I'll consider this issue closed, but feel free to reopen if you notice any future git weirdnesses.