Re: [PATCH] doc:clarify which remotes can be used when contributing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Daniele Sassoli via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>  https://github.com/gitgitgadget/git and open a PR either with the "New pull
>  request" button or the convenient "Compare & pull request" button that may
>  appear with the name of your newly pushed branch.
> +If you're using https://github.com/git/git as your remote, you will need to
> +open the pull-request from your fork, selecting `git/git` as base.
> +
> +The differences between using `gitgitgadget/git` and `git/git` as your base can
> +be found [here](https://gitgitgadget.github.io/#should-i-use-gitgitgadget-on-gitgitgadgets-git-fork-or-on-gits-github-mirror)

Looking at the table, there is no advantage to use git/git at all.

Instead of telling them that they can use either (with reduced
capabilities if you pick one of them instead of the other), wouldn't
it be easier for the user if this section taught them how to switch
their fork that they originally created out of git/git to be based
on gitgitgadget/git instead?  Something along the lines of

    ... If you originally forked from https://github.com/git/git/,
    you can easily correct it by running (you only need to do this
    once):

    $ git remote set-url origin https://github.com/gitgitgadget/git/
    $ git fetch --prune origin

    A pull request at https://github.com/gitgitgadget/git/ can be
    opened once you do so.

but you'd need to validate the procedure, as I didn't try it myself.

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux