From: "Pavel Valena" <pvalena(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Thursday, November 30, 2017 5:02:49 PM
Subject: Re: How to manage a fork
----- Original Message -----
> From: "Vít Ondruch" <vondruch(a)redhat.com>
> To: devel(a)lists.fedoraproject.org
> Sent: Thursday, November 30, 2017 2:55:50 PM
> Subject: Re: How to manage a fork
>
>
>
> 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@pagure.io/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.
AFAIK this is not a problem anymore (as long as upstreams' `master` is
`forward-only`, because GH rebases seamlessly for you.
Note that I've not tested this with pagure, but it would make definitely a good RFE.
Pavel
>
> Pavel
>
> >
> > 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
> >
> >