On Thu, Nov 30, 2017 at 8:55 AM, Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > > > 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. This is going to be a pointless never ending debate. Git is flexible enough to let you do this in multiple ways, people are going to have their preferences. Just agree to disagree and move on. I mean, come on. It took years for vim to win the editor wars. We don't have time to waste on another debate like that ;) josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
