Straight.el: Swap fork and upstream

[raxod502]

Currently your fork is at the top-level, and is the origin remote, whereas the upstream is in a sub-plist and is the upstream remote. This sounds nice in theory, but it's counterintuitive when it comes time to switch between your fork and the upstream: the origin remote has to be changed, and you have to restructure the formula rather than just changing the sub-plist.

I'd like to name the remotes origin and fork, and then have a :fork sub-plist instead of :upstream.

See also #65.

[dieggsy]

Could you clarify what you mean here a bit better? I like to use origin as my fork's remote, and upstream as the repo that was forked from (kind of as it is now). Besides brevity - what exactly are the plans for switching up the names?

Additionally (perhaps unrelated to straight.el), how do you easily "switch between your fork and the upstream" ? As I see it now, I sorta have to rename remotes anyway, which seems like more work than I should have to do.

[raxod502]

You shouldn't have to do any version-control operations manually if you don't want to. Just run M-x straight-normalize-all to set your remotes correctly, make sure working trees are clean, etc. That will happen automatically before operations like M-x straight-freeze-versions, M-x straight-pull-all, etc. See the manual here and here.

The inelegance is that when switching from no fork to fork+upstream, you need to rename origin to upstream and add a new origin. Whereas in the new model, you just need to add a new fork remote. Similarly when you switch back, you need to delete(!) origin and rename upstream back to origin. Whereas in the new model, you need not do anything. It's much easier. Both on the user and in terms of implementation, since it's nontrivial to decide whether the current origin can in fact be renamed to upstream (i.e. it is compatible) or not.

Also, see #116 and discussion at https://github.com/raxod502/straight.el/issues/113#issuecomment-317617786. Inheritance is much easier for everybody if we have your fork in a sub-plist rather than the upstream. And inheritance means more concise recipes! Which do you prefer:

(esup :host github
      :repo "raxod502/esup"
      :upstream (:host github
                 :repo "jschaf/esup"))

or

(esup (:fork "raxod502"))

If you're not convinced by the convenience of having origin retain the same meaning in all circumstances, I could probably be convinced to add a user option to use the old naming scheme. But I would be less inclined to implement automagic support for that case (i.e. renaming origin to upstream if appropriate) in the normalization logic, without a pull request.

[noctuid]

Which do you prefer:

I'm not sure I understand this point. Straight.el could both use latter syntax and still create upstream and origin.

If you're not convinced by the convenience of having origin retain the same meaning in all circumstances

It's the same location but not necessarily the same meaning; it depends on how you think about it. I think of origin as my repo. origin and upstream is more common/expected; after all if I were to normally clone my fork, it would be origin. That all said, I don't personally care all that much and would be fine with having fork and origin as long as there is an option to automatically set fork as the default remote.

[raxod502]

Straight.el could both use latter syntax and still create upstream and origin.

Point granted. The recipe renaming and remote renaming are orthogonal. However, I do think it is more intuitive for the :fork keyword to cause a remote named fork to be created, rather than one called upstream. At least by default.

It's the same location but not necessarily the same meaning; it depends on how you think about it.

I agree. The reason for my position is that the _location_ is what matters to the implementation, not the _meaning_.

an option to automatically set fork as the default remote.

See #65.

[dieggsy]

FWIW, I think I've come around to preferring your original suggestion now. Something nice that magithub does is name the fork remote after the username, which might be a good way to be able to switch between many different forks.

[raxod502]

This is now done. The testing is not quite as thorough as I'd like, but I realized that if I didn't just publish the change now, it might not get out for at least another month or two.

Check the README for more information, including backwards compatibility.

[Fuco1]

I also prefer to use origin for my fork and upstream for upstream. And I don't understand this :fork feature.

I have this recipe in my init

(helm :repo "[email protected]:emacs-helm/helm.git" :remote "upstream"
      :fork (:repo "[email protected]:Fuco1/helm.git" :remote "origin"))

Yet after installation master is still checked out to upstream/master. This is wrong in my opinion. How can I force straight.el to always use my fork's master as the default checkout?

[raxod502]

You're right, there is clearly some bug going on. It should use the :fork configuration if provided. Could you open a separate issue for this?