----- Original Message -----
From: "Michael" <[email protected]>
To: <[email protected]>
Sent: Saturday, August 27, 2016 10:59 PM
Subject: Re: [git-users] gitlab CE vs gitlab EE vs bitbucket (on-prem) or
something else
<snip>
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
Philip
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
