Re: How to manage a fork

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

 




Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
> On Thu, Nov 30, 2017 at 10:15:14AM +0100, Vít Ondruch wrote:
>>    Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
>>
>>  On 11/29/2017 10:53 AM, Matthew Miller wrote:
>>
>>  On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
>>
>>  As as you have a fork, my understanding is that you should just use
>>  traditional gut commands. I’m not aware of a fork being used for much
>>  more than spec PRs.
>>
>>  Or traditional _git_ commands -- whatever. :)
>>
>>  Personally, I find that when working with forks of something where I'm
>>  a casual contributor, I end up doing this a lot:
>>
>>    git remote add upstream https://pagure.io/fedora-docs/quick-docs
>>
>>    git fetch upstream
>>    git reset --hard upstream/master 
>>
>>
>>  (repeat last two steps)
>>
>>  I'm sure places like github have docs on this too, but pagure also does:
>>
>>  https://docs.pagure.org/pagure/usage/forks.html
>>
>>    Sorry to say that, but I consider this page ill advised. E.g. suggesting
>>    to do:
>>
>>    ~~~
>>
>>  $ git clone ssh://git@xxxxxxxxx/forks/jcline/pagure.git
>>
>>    ~~~
>>
>>    is totally wrong IMO.
> That is most definitively just your opinion :)
>
> I know many people seeing it the other way around. They fork their repo,
> potentially add upstream as another remote, push to their fork, open their PR
> and practically will only pull from upstream if upstream asks them to rebase or

And that is the major problem with that approach. In this case upstream
has often to tell something to people submitting their PR and just
because the plain "git pull" can't do the right and natural thing.
People then start their branches from obsolete master etc.

If you clone the upstream repository, then you never have to pull
anything from your fork. You are using the fork in "push only" mode.

> if they need to do another change.
>
>> I would go as far as saying you should never "git
>>    clone" forked repository. You should always "git clone" the upstream and
>>    then add the remote for your fork if you need.
> It's really potato vs potato, clone your fork and add upstream as a remote or
> clone upstream and add your fork as a remote, at the end what matters is that
> you know which approach you used (and if you don't git remote -v will tell you)
> and know how to work with it.

Not really, it is matter of attitude. Clone of upstream is always good
to have. Just for observing the project or to prepare source tarball or
whatever else. Fork itself is useless unless you want to contribute.


Vít

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux