Re: How to manage a fork

[Matthew Miller]

On Thu, Nov 30, 2017 at 11:05:52AM -0500, Pavel Valena wrote:
> > That is, can i push new release with 'fedpkg' or make additional changes
> > to original RPMs? If not, are they useful for what?
> You use them to create pull-requests to the original repo. See
> https://docs.pagure.org/pagure/usage/pull_requests.html

It'd be pretty awesome to have a button to build in copr from a fork.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Pavel Valena]

- Original Message -
> From: "Pavel Valena" <pval...@redhat.com>
> To: "Development discussions related to Fedora" 
> <devel@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" <vondr...@redhat.com>
> > To: devel@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://g...@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
> > 
> >
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Pavel Valena]

- Original Message -
> From: "Antonio Trande" <anto.tra...@gmail.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Thursday, November 30, 2017 4:50:24 PM
> Subject: Re: How to manage a fork
> 
> On 29/11/2017 13:03, Antonio Trande wrote:
> > Hi all.
> > 
> > I have created a fork on https://src.fedoraproject.org/ but i don't know
> > how to manage it.
> > Can i use 'fedpkg'?
> > Documentation?
> > 
> > 
> 
> Maybe, i was unclear with my question.
> 
> If i create a fork of **https://src.fedoraproject.org/rpms/hdf5** like
> *https://src.fedoraproject.org/fork/sagitter/rpms/hdf5**, can i use the
> fork like it was the original project?
> That is, can i push new release with 'fedpkg' or make additional changes
> to original RPMs? If not, are they useful for what?

You use them to create pull-requests to the original repo. See

https://docs.pagure.org/pagure/usage/pull_requests.html

Pavel

> 
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x5E212EE1D35568BE
> GPG key server: https://keys.fedoraproject.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Pavel Valena]

- Original Message -
> From: "Vít Ondruch" <vondr...@redhat.com>
> To: devel@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://g...@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.

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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Antonio Trande]

On 29/11/2017 13:03, Antonio Trande wrote:
> Hi all.
> 
> I have created a fork on https://src.fedoraproject.org/ but i don't know
> how to manage it.
> Can i use 'fedpkg'?
> Documentation?
> 
> 

Maybe, i was unclear with my question.

If i create a fork of **https://src.fedoraproject.org/rpms/hdf5** like
*https://src.fedoraproject.org/fork/sagitter/rpms/hdf5**, can i use the
fork like it was the original project?
That is, can i push new release with 'fedpkg' or make additional changes
to original RPMs? If not, are they useful for what?

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Todd Zullinger]

Vít Ondruch wrote:

Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
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.


If you clone from the fork and add the upstream as a remote, you have 
a clone of the upstream. All that really differs is which one is named 
origin.  And that's only the default remote name.  It's easy to change 
that during clone with the --origin option or later with git remote 
rename.


Depending on the audience and their familiarity with git, it may be 
easier to explain one method or the other.  But in terms of what data 
the git repository contains, they're essentially identical.



Fork itself is useless unless you want to contribute.


That's precisely the audience for the forks documentation, as far as I 
can see.  The documentation states that in the second sentence. :)


I don't particularly think it's needed, but perhaps someone who does 
would want to submit something like this to the documentation:


 8< 
diff --git i/doc/usage/forks.rst w/doc/usage/forks.rst
index 362280d4..dfc46412 100644
--- i/doc/usage/forks.rst
+++ w/doc/usage/forks.rst
@@ -42,6 +42,12 @@ example::
This lets you pull in changes that the upstream repository makes after you
forked. Consult Git's documentation for more details.

+Alternatively, if you already have a clone of the upstream, you can add your
+fork as a remote.  For example::
+
+$ cd pagure
+$ git remote add -f my-fork ssh://g...@pagure.io/forks/jcline/pagure.git
+

Pushing Changes
---
 8< 

And if there is some reasonable documentation online which further 
explains the benefits of each approach it might be worth adding as a 
link below.  For all I know, the ProGit "Distributed Workflows" page 
which is referenced at the beginning of the Pagure forks documentation 
covers this.


--
Todd
~~
Stress is when you wake up screaming and you realize you weren't
sleeping.



signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Pierre-Yves Chibon]

On Thu, Nov 30, 2017 at 02:55:50PM +0100, Vít Ondruch 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://g...@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.
> 
> 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.

Which is exactly what this documentation is about :)

Anyway, no point in arguing further I believe. If you think the documentation
can be improved the sources are in the ``doc`` folder in pagure's sources and
suggestions are welcome :)


Pierre


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Josh Boyer]

On Thu, Nov 30, 2017 at 8:55 AM, Vít Ondruch  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://g...@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.
>
> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Matthew Miller]

On Thu, Nov 30, 2017 at 02:55:50PM +0100, Vít Ondruch wrote:
> 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.

I can see the sense in this workflow -- it might be nice to have
documentation for both, and perhaps even showing instructions for
cloning the original and setting the remote for the fork when viewing a
fork.

I bet Pierre would accept patches.



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Vít Ondruch]

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://g...@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.

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



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Pierre-Yves Chibon]

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://g...@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
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.


Pierre


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Vít Ondruch]

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://g...@pagure.io/forks/jcline/pagure.git

~~~

is totally wrong IMO. 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.

The main reason is because you want to follow your upstream. You want to
be able to "git pull" from the master branch and get the latest and
greatest. That is where the development happens. Your fork is mostly
just tool enabling you to send PR and that happens typically just once
in a while if ever.


Vít


>
> There's one big gotcha to note with forks on src.fedoraproject.org:
> You have to be in the packager group to push changes to anything there
> (including forks) at least for now. We want to change this, but it will
> require a fair bit of shifting things around.
>
> You can still of course make a copy of the repo on any other public
> place (pagure.io, github, gitlab, etc) and file "remote pull requests"
> in the mean time.
>
>> Because I don't really want to keep a long-lived fork with local
>> changes and differences and merge. Possibly fedpkg could grow something
>> smart around this?
> Possibly. It's also worth noting that some people use a workflow like:
>
> * fork project
> * make changes, submit PR
> * delete fork
>
> that way the next time you can just refork it and be set.
>
> kevin
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Matthew Miller]

On Wed, Nov 29, 2017 at 11:06:30AM -0800, Kevin Fenzi wrote:
> Possibly. It's also worth noting that some people use a workflow like:
> 
> * fork project
> * make changes, submit PR
> * delete fork
> 
> that way the next time you can just refork it and be set.

Yeah, that's fine too. Especially if you're just making one change.
It's kind of a pain to clean up, though. Oooh:
https://pagure.io/pagure/issue/2808



(Also I found https://pagure.io/pagure/issue/836)


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Kevin Fenzi]

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

There's one big gotcha to note with forks on src.fedoraproject.org:
You have to be in the packager group to push changes to anything there
(including forks) at least for now. We want to change this, but it will
require a fair bit of shifting things around.

You can still of course make a copy of the repo on any other public
place (pagure.io, github, gitlab, etc) and file "remote pull requests"
in the mean time.

> Because I don't really want to keep a long-lived fork with local
> changes and differences and merge. Possibly fedpkg could grow something
> smart around this?

Possibly. It's also worth noting that some people use a workflow like:

* fork project
* make changes, submit PR
* delete fork

that way the next time you can just refork it and be set.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Matthew Miller]

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)

Because I don't really want to keep a long-lived fork with local
changes and differences and merge. Possibly fedpkg could grow something
smart around this?



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Brian Exelbierd]

On Wed, Nov 29, 2017, at 01:03 PM, Antonio Trande wrote:
> Hi all.
>
> I have created a fork on https://src.fedoraproject.org/ but i
> don't know> how to manage it.
> Can i use 'fedpkg'?
> Documentation?

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.
Regards,

bex 

>
>
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x5E212EE1D35568BE
> GPG key server: https://keys.fedoraproject.org/
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

How to manage a fork

[Antonio Trande]

Hi all.

I have created a fork on https://src.fedoraproject.org/ but i don't know
how to manage it.
Can i use 'fedpkg'?
Documentation?


-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org