Open glehmann opened 6 years ago
✨🍰✨
I realize this is a non backward compatible change. Any idea for a better implementation is welcome!
The current implementation is consistent with git push
, i.e. both git push <REMOTENAME> <BRANCHNAME>
but breaks backward compatibility.
On the other hand, git publish <BRANCHNAME> <REMOTENAME>
will not introduce non backward compatible change, but may feels confusing since the order is reversed as git push
.
Maybe git publish [branch] [--to remote_name]
?
And the corresponding option for unpublish
is git unpublish [branch] [--from remote_name]
?
git clone git@github.com:kennethreitz/legit.git
git checkout -b my_branch
# code
git commit -am "my changes"
git fork
git publish --to glehmann
git pull-request
# after merging pull request
git unpublish --from glehmann
Another choice is let legit to be a bit "smart",
if it detects there are two remotes naming origin and USER
(USER is github.user in ~/.gitconfig, if not set, falling back to login name),
then legit assumes origin is readonly and both publish/unpublish use USER as remote.
This also applies to sync
, though the logic will be a bit complicated,
i.e. fetch from origin but push to USER.
Just some random thoughts.
@glehmann Are you done with the changes? Can you please update the PR. Thanks
Another idea just occurred to me.
If legit detect there is a remote named foo
, then publish foo
will use foo
as the remote.
Otherwise foo
will be considered as a branch name, and publish foo
will publish the branch to origin.
Strictly speaking, this is still a non backward compatible change, but it probably will affect less issues to existing users since few people use the same name for both the branch and the remote.
this is especially useful when working with github's hub (https://github.com/github/hub), to submit a pull request: