----- Original Message ----- From: "Michael" <keybou...@gmail.com>
To: <git-users@googlegroups.com>
Sent: Saturday, August 27, 2016 10:59 PM
Subject: Re: [git-users] gitlab CE vs gitlab EE vs bitbucket (on-prem) or something else


The rest of that is as confusing as you would expect it to be.

Ok, so a remote tracking branch isn't actually a remote branch. Origin/master is not master. You've actually got the case of two different "masters" in two different versions of the same project that you (maintain? Help maintain? Sign-off on?). And a pull request is not a pull request.

Did I understand that correctly?

Yes you understand correctly in that 'there are many meanings for the same phrase, and somethimes they are different things".... just working through my situation..

for the rtb's I have a remore that I call 'junio' which is the upstream *nix version of git and Junio is the maintainer, and a remote called 'dscho-git' which is the upstream Git for Windows maintained by dscho. Both have a 'master' branch. Dscho has a set of Windows specific patches he keeps rebased on top of Junio's git. I call my own github repo 'my'. I try to contribute a few patches at the periphery, which have mainly been around the help and documentation, so I need to respect both 'master' branches.

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


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 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to