----- Original Message ----- > From: "Pavel Valena" <pvalena@xxxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Thursday, November 30, 2017 5:02:49 PM > Subject: Re: How to manage a fork > > ----- 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. 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 > > > > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
