On 2016-08-29, at 4:09 AM, Philip Oakley <philipoak...@iee.org> wrote:
> So I have junio/master and dscho-git/master, along with my/master (what I
> last had on github), so that's three 'master' branches belonging to remotes,
> and master (my truly local one). As a contributor, I sign my patches, but
> others get to be the uptream committer after review.
> The bit I found hard was to realise that I don't need to both fetch
> junio/master and then have to check it out as 'master' as its local name just
> so I can see what has been done. It then also means that even if jJunio's
> master has moved ahead, I can still use 'junio/master..feature' as the range
> that will list my patches for rebasing them forward.
> In terms of PRs: For Junio's git, patches need to be sent individually by
> email, and a list server provides a historic record of review comments, and
> when acceptable Junio begins the two acceptance process of 'pu' and 'next',
> which are his names for the potential updates branch, and then next those
> that are deemed ready for master. Many folk (devs) take next and build from
> it so at to give it a bit of testing. Junio doesn't use the PR approach, but
> I understand that Linux kernal does use it.
> Meanwhile for the dscho's Git-for-windows, the wider windows community is
> more comfortable with web based tools, review processes etc., so for dscho,
> Github PRs are the easiest way. I create a set of local patches on a feature
> branch started from dscho-git/master but with my local name. I push it up to
> 'my' remote (usually with my local name for the branch). Github then allows
> me to create (on their server) one of their PRs between the two versions
> ([Github]my/local-name) and ([Github]Git-for-Windows/master) and notify him
> that it's waiting. Then on the web interface the usual reviews happen. I
> force push a new version of the series, which updates the PR. rinse and
> repeat till accepted. When dscho accepts the PR github then his master on
> githup leaps ahead to include/pick-up my patches.
> Hope that helps
Several re-reads later, and I think I'm going to have to try to play with this.
It's not quite sinking in by reading, so it's time for doing.
Which, of course, makes me wonder if I set up my repo and remotes correctly.
When you fork a web-hosted (originally from bitbucket; I moved to github just
for the graph of all branches in all forks view) repo, and clone it locally,
and someone else forks yours, and clones that on their system, what is supposed
to refer to what?
(... Still dealing with each person having two repositories, and you don't
actually sync with someone else's repo, but with their secondary repo, despite
the fact that none of the git books/lessons seem to discuss this use-case. ...)
Entertaining minecraft videos
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.