----- Original Message ----- > From: "Vít Ondruch" <vondruch@xxxxxxxxxx> > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > 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@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. AFAIK this is not a problem anymore (as long as upstreams' `master` is `forward-only`, because GH rebases seamlessly for you. 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 > > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
