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. 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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org