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 <here>:<there> 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" <keybou...@gmail.com>
Sent: Saturday, August 27, 2016 6:07 PM

On 2016-08-27, at 6:18 AM, Philip Oakley <philipoak...@iee.org> 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 more options, visit https://groups.google.com/d/optout.

Reply via email to