Re: [git-users] gitlab CE vs gitlab EE vs bitbucket (on-prem) or something else

[Paul Smith]

On Sat, 2016-08-27 at 10:07 -0700, Michael wrote:
> if someone forked my repository, did work on "master", and submitted
> it to go onto my "master", then how do I say "No, come in on a branch
> named devB instead"?

Something important to understand is that your local repository and
every remote you register all have their own "namespaces" for branches.
Because of this, in fact someone else's "master" can never interfere
with your "master" or a different remote's "master".

The default name for the remote you cloned from is "origin".  That means
there's an "origin/master", "origin/foo", "origin/bar", etc. for every
branch ("master", "foo", "bar") that exists on the remote.  So you can
see what the remote's master contained with "git log origin/master" (as
of the last time you fetched from that remote).  You can compare them
with "git diff origin/foo foo", etc.

You also have your own branches, "master", "foo", "baz", etc. which are
local to your repository and don't exist in the remote.

And if you add a second remote (which of course has to have its own
name, not "origin") then you will get all of its branches imported into
your repository, but under that remote's name, so "other/master",
"other/foo", "other/boz".

So there's really no reason to be concerned about other people using
"master", since that's their "master" and is not your "master".  They
are in different namespaces and Git won't get them confused.

However, people soon discovered that _much_ of the time, you really only
have a single remote and the extra command line fu needed to keep
everything straight was annoyingly redundant.  So Git has a concept of a
"tracking branch", which is a local branch which is tracking a branch in
one of your remotes.  If your local branch is a tracking branch for some
remote's branch, then when you pull from that remote Git knows to merge
from that remote's branch into your branch.

Note there's no reason at all that the remote branch and the local
tracking branch have to have the same root name.  A local branch "foo"
could be tracking a remote "other/fubar".  So, you could have a local
branch "master" which tracks "origin/master" and a different local
branch "master_other" which tracks "other/master".

You might try reading
https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches which I
think explains this fairly well.

-- 
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.

Re: [git-users] gitlab CE vs gitlab EE vs bitbucket (on-prem) or something else

[Michael]

On 2016-08-27, at 2:48 PM, Philip Oakley  wrote:

> Hi Michael,
> 
> There are probably three things to look at here, one is how to generate a 
> 'refspec' (see `git help glossary` : A "refspec" is used by fetch and push to 
> describe the mapping between remote ref and local ref) which has the form 
> : which can do any number of name conversions. This is now 
> particularly bad for me, looking at both git.git and git-for-windows, which 
> both have a 'master' branch, but they are different! I've retained the old 
> msysgit 'devel` name (locally) for the GfW master branch.
> 
> The second thing is the distinction between Github "Pull Requests", and the 
> Git command that generates an email containing a pull request statement for 
> others. They are different beasts. The email PR allows the recipient to 
> choose what to do in an open manner. The Github PR can be more confused, but 
> does hide that master v master issue.
> 
> The third is to understand "remotes", which are anything but remote!. A rtb 
> (remote tracking branch) is actually a local branch that tracks (i.e. has a 
> recently synced copy) of a remote's branch, and, it is in your own DAG, with 
> it's tip pointer hidden under the refs/remotes/ namespace (if what they have 
> matches something you have, then your DAG is unchanged, it's just their sha1 
> pointer that could be to a different commit). It takes a while to realise 
> that origin/master has little to do with master in any formal sense. Its only 
> the presumptions of convention that keeps folk confused (when they want 
> something not quite exactly that convention).
> 
> The syncing issue is in many ways a social and consistency issue. There is a 
> special form of the ref spec (with a leading +) that says to do a forced 
> update, but that's where making sure it gets stuffed into an rtb makes all 
> the difference - if they've updated stuff, that's the stuff you want, but 
> ref'd separately in the rtb namespace.
> 
> 
> For another book, look at "Git for Teams" - which I haven't read, but it just 
> came up on the main git list in the last few hours - it may have some tidbits 
> (available as pdf).
> 
> 
> Yes, the mindset shift is complete and total - Obtuse doesn't come anywhere 
> near for those parts that aren't being grokked (now you'll have to read that 
> book on grokking..)

...

Ok, I understand grokking, a martian term that literally translates as "drink" 
(yes, I know my old science fiction). And, I understood that I need to find the 
book "Git for Teams".

...

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?

---
Entertaining minecraft videos
http://YouTube.com/keybounce

-- 
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.

Re: [git-users] gitlab CE vs gitlab EE vs bitbucket (on-prem) or something else

[Philip Oakley]

Hi Michael,

There are probably three things to look at here, one is how to generate a 
'refspec' (see `git help glossary` : A "refspec" is used by fetch and push 
to describe the mapping between remote ref and local ref) which has the form 
: which can do any number of name conversions. This is now 
particularly bad for me, looking at both git.git and git-for-windows, which 
both have a 'master' branch, but they are different! I've retained the old 
msysgit 'devel` name (locally) for the GfW master branch.


The second thing is the distinction between Github "Pull Requests", and the 
Git command that generates an email containing a pull request statement for 
others. They are different beasts. The email PR allows the recipient to 
choose what to do in an open manner. The Github PR can be more confused, but 
does hide that master v master issue.


The third is to understand "remotes", which are anything but remote!. A rtb 
(remote tracking branch) is actually a local branch that tracks (i.e. has a 
recently synced copy) of a remote's branch, and, it is in your own DAG, with 
it's tip pointer hidden under the refs/remotes/ namespace (if what they have 
matches something you have, then your DAG is unchanged, it's just their sha1 
pointer that could be to a different commit). It takes a while to realise 
that origin/master has little to do with master in any formal sense. Its 
only the presumptions of convention that keeps folk confused (when they want 
something not quite exactly that convention).


The syncing issue is in many ways a social and consistency issue. There is a 
special form of the ref spec (with a leading +) that says to do a forced 
update, but that's where making sure it gets stuffed into an rtb makes all 
the difference - if they've updated stuff, that's the stuff you want, but 
ref'd separately in the rtb namespace.



For another book, look at "Git for Teams" - which I haven't read, but it 
just came up on the main git list in the last few hours - it may have some 
tidbits (available as pdf).



Yes, the mindset shift is complete and total - Obtuse doesn't come anywhere 
near for those parts that aren't being grokked (now you'll have to read that 
book on grokking..)


--

Philip


- Original Message - 
From: "Michael" 

Sent: Saturday, August 27, 2016 6:07 PM

On 2016-08-27, at 6:18 AM, Philip Oakley  wrote:

You said "submits a pull request from their master to your master -- which 
is as close to a "no-no" as I can imagine, I want their stuff to come in 
on a branch."


- I think in this case we fall into the trap of the accidental confusion 
of IIUC 'nominative determinism' (the name isn't the thing | cest ne pas 
une pipe). If they simply renamed their master branch to 'feature', it 
doesn't really change anything - it's the same sha1. If the merge-base is 
far away then perhaps its an issue and they should have rebased first;-).


(Rhetorical) Maybe we need to have a Rose branch, which by any other name 
would smell just as sweet (I wonder if a patch to change master to Rose 
would be acceptable upstream ;-)


Actually, it's not even that.

In none of the git documentation on working with multiple users have I seen 
what should be the first thing taught: How to control where someone else's 
changes come in.


From what I have seen in the docs -- reading the git manual, reading the 
pages on github about pull requests, and reading the git book -- if someone 
forked my repository, did work on "master", and submitted it to go onto my 
"master", then how do I say "No, come in on a branch named devB instead"?


** THAT SHOULD BE THE FIRST THING TAUGHT FOR WORKING WITH MULTIPLE DEVS **

The issue isn't that the Sha's are the same. Frankly, I'm not sure if the 
sha's are the same.


Even if you were to teach me how to control where it comes in on my 
repository, what happens when they try to then sync their repository with 
mine, given that now our two master branches look nothing alike?


I don't have the slightest clue how to handle this.
If it is documented, it is the second most obtuse set of docs, only slighter 
harder to find than "how to use the low-level plumbing commands". Note that 
I can find the docs on those, just not how to put them all together.


Oh, wait -- someone wrote "Git from the bottom up". That probably explains 
how to use them.


---
Entertaining minecraft videos
http://YouTube.com/keybounce

--
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.

--
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 

Re: [git-users] gitlab CE vs gitlab EE vs bitbucket (on-prem) or something else

[Michael]

On 2016-08-27, at 6:18 AM, Philip Oakley  wrote:

> You said "submits a pull request from their master to your master -- which is 
> as close to a "no-no" as I can imagine, I want their stuff to come in on a 
> branch."
> 
> - I think in this case we fall into the trap of the accidental confusion of 
> IIUC 'nominative determinism' (the name isn't the thing | cest ne pas une 
> pipe). If they simply renamed their master branch to 'feature', it doesn't 
> really change anything - it's the same sha1. If the merge-base is far away 
> then perhaps its an issue and they should have rebased first;-).
> 
> (Rhetorical) Maybe we need to have a Rose branch, which by any other name 
> would smell just as sweet (I wonder if a patch to change master to Rose would 
> be acceptable upstream ;-)

Actually, it's not even that.

In none of the git documentation on working with multiple users have I seen 
what should be the first thing taught: How to control where someone else's 
changes come in.

>From what I have seen in the docs -- reading the git manual, reading the pages 
>on github about pull requests, and reading the git book -- if someone forked 
>my repository, did work on "master", and submitted it to go onto my "master", 
>then how do I say "No, come in on a branch named devB instead"?

** THAT SHOULD BE THE FIRST THING TAUGHT FOR WORKING WITH MULTIPLE DEVS **

The issue isn't that the Sha's are the same. Frankly, I'm not sure if the sha's 
are the same.

Even if you were to teach me how to control where it comes in on my repository, 
what happens when they try to then sync their repository with mine, given that 
now our two master branches look nothing alike?

I don't have the slightest clue how to handle this.
If it is documented, it is the second most obtuse set of docs, only slighter 
harder to find than "how to use the low-level plumbing commands". Note that I 
can find the docs on those, just not how to put them all together.

Oh, wait -- someone wrote "Git from the bottom up". That probably explains how 
to use them.

---
Entertaining minecraft videos
http://YouTube.com/keybounce

-- 
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.

Re: [git-users] gitlab CE vs gitlab EE vs bitbucket (on-prem) or something else

[Philip Oakley]

Hi Michael,

I think we are, in general, agreeing about direction of travel, which was my 
little 'rant'. It is far too easy in larger organisations for 'management' 
to create processes that give the message that 'the beatings will continue 
until morale improves', which can become a vicious circle, ending up in even 
more reviews before code is allowed to be tested. Usually followed by other 
catch 22 scenarios such as being unable to provide more test capability 
until the code is good, etc., etc., etc. This often leads to big merges of 
occasional large commits all in one go (but it does self-justify the 
organisation's size and purpose ;-)



As you note, there are grades of approval as code features are pushed up the 
hierarchy, with ultimately a release tag signed by some high up person.


One of the areas that usually has a little bit of local control is in how 
the repo servers are configured, so that there is a buffer layer of personal 
server space between one's personal machine (with all the backup/archive 
issues there-in) and the central server with senior staff commit authority, 
and all the back-up and archive already sorted. By providing a shim layer 
that feels like 'Github' or any of the other on-line 'backup/archive/public 
view.private push' service, but locally within the organisation, one 
'enables' the devs to get ahead of the game. Add in a CI service (for the 
devs, rather than the QA system), and you greatly facilitate productivity, 
and importantly release 'senior staff / management' from (allegedly) picking 
up the dross and actually getting on with what they are meant to contribute 
with is usually a big picture vision and overview of where it's all going 
(rather than inward oversight).


Having the shim layer gets past the 'direct' in your `"trivial" setup of 
every developer pulling directly from each other's branches` by always 
making them properly managed remotes. The upstream also needs to have the 
equivalent of git's pu to show what is being considered at that level.




You said "submits a pull request from their master to your master -- which 
is as close to a "no-no" as I can imagine, I want their stuff to come in on 
a branch."


- I think in this case we fall into the trap of the accidental confusion of 
IIUC 'nominative determinism' (the name isn't the thing | cest ne pas une 
pipe). If they simply renamed their master branch to 'feature', it doesn't 
really change anything - it's the same sha1. If the merge-base is far away 
then perhaps its an issue and they should have rebased first;-).


(Rhetorical) Maybe we need to have a Rose branch, which by any other name 
would smell just as sweet (I wonder if a patch to change master to Rose 
would be acceptable upstream ;-)


I agree that there is a lack of good discussions and reference work that 
shows how to make a dev system work and why Git's approach (and implicitly 
what that approach is - it's too hidden) actually works. As I said all the 
old problems that CM was meant to solve are no longer problems at all (in 
software dev), and the new problems are solved by new tools such as git 
(which doesn't actually *control* revisions, given anyone can fork at any 
time) provide Distributed Revision Authentication and Tagging (DRAT) [ooh I 
like that newly invented acronym]

--
Philip
Aside: I discovered Git in 2011 when I read a blog item and immediatly saw 
that it was 'the answer' to the CM nightmare that most companies impose (I'm 
in engineering). Progress can be slow!


- Original Message - 
From: "Michael" 

To: 
Sent: Friday, August 26, 2016 6:22 PM
Subject: Re: [git-users] gitlab CE vs gitlab EE vs bitbucket (on-prem) or 
something else



On 2016-08-25, at 2:44 PM, Philip Oakley  wrote:


Hi,

I think you should review points 1 and 2 because they try to re-inforce a 
centralised control system. And then pass off the responsibility to a 
machine.


Actually, I think that those points are still relevant even today:


What is important:

• pull requests: would like to kick off build based on approval of code 
review


• branch permissions: we want to disable direct commit to master branch. 
we do not want devA to be able to modify branch created by devB (not a 
deal breaker if unavailable)


The idea that one developer is responsible for the code on a given branch is 
not a bad thing; actually making someone responsible for changes to a setup, 
with the ability to say "approved" or "not approved" is a good thing.


It's perfectly OK for devA to make a suggested change -- a pull request --  
to devB's branch, but devB is the one that says "yea" or "nea". If DevA 
still wants it done, then devA makes and owns their own branch.


There is no "Not my fault" in this approach.

Equally, the first goal of requiring code reviews and pull requests is also 
a good thing.



Given that Gitb is a "distributed control" system,


Git can be a