:: Re: [DNG] The figure of commits beh…
Góra strony
Delete this message
Reply to this message
Autor: Anto
Data:  
Dla: Jude Nelson
CC: dng@lists.dyne.org
Temat: Re: [DNG] The figure of commits behind the upstream on github


On 24/07/15 05:19, Jude Nelson wrote:
> Hi Anto,
>
> [snip]
>
>     does anybody have any suggestion how to easily find out that our
>     fork repositories need updating without keep checking the upstream
>     repositories?

>
> You're going to have to pull changes upstream periodically. That's
> just the way git is designed--if you're not hosting the repository
> that the original project developers push to, then you're by
> definition going to be pulling from their repository.
>
> However, from your description, it sounds like you could make your
> workflow a little bit easier:
> 1. fork the original repository
> 2. add the original repository as a remote for pulls (i.e. git add
> remote ...)
> 3. make your changes and push them to your forked repository
> 4. pull from the original repository (i.e. git pull <name of original
> remote>)
> 5. resolve merge conflicts
> 6. repeat steps 3-6 periodically
>
> If your changes are unlikely to be in conflict by pushes to the
> original, you might consider creating a cron job to periodically run
> steps 3 through 6 for you, and have it email you when there are merge
> conflicts (step 5) that can't be automatically resolved.
>
> HTH,
> Jude
>


Hello Jude,

Thanks a lot for spending your time looking at my problem.

I have actually already done all steps on your list. My questions are
mainly related to point 4 on your list, on how to easily know that my
fork repositories need updating. And further to that, how to know the
new commits that have been added into the original repository.

What I have been doing so far, I manually check my repositories and
compare that with the original ones every day. If there are differences,
then I check the new commits on the original repositories. I have just a
few fork repositories so far. All of them are only for my own private
use. And most of them are stored locally on my PC. The one on github is
only a test for me to understand if it is easier to manage it there than
on my PC as most original repositories are on github. As I explained, it
looks like having the repository on github is not easy as well because I
had to check each individual files due to the confusing figure differences.

So the main reason I started this thread is to get suggestions in
maintaining fork repositories. I am quite sure that people who have a
lot more repositories than me, do not do the same as I am doing every
day. They might have used an automated system (most probably like the
cron job that you suggested), to notify them on which fork repository
needs updating, without manually check each repository one by one every
day. It would be a bonus if that automated system can also do the
merging. So I am hoping that one of them would be willing to share their
setup with us.

Cheers,

Anto