AndrewRadev/splitjoin.vim

Missing master branch breaks update

bodograumann opened this issue ยท 7 comments

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.

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.

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.

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.

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.

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.

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 ๐Ÿ‘.

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.