Tracking multiple git masters - what works?

61 views
Skip to first unread message

Philip Oakley

unread,
Dec 6, 2014, 1:30:25 PM12/6/14
to git-w...@googlegroups.com
Hi folks,

I'm looking to resolve my confusions over the best way of tracking the
different 'master' branches for git.

These upstreams include:
* Junio (https://github.com/git/git and/or
https://github.com/gitster/git),
* MSysGit (https://github.com/msysgit/git) and
* here (https://github.com/git-for-windows/git).

What technique have you folks found most useful to locally disambiguate
between the name clashes, especially of 'master' when fetching from
these remotes? i.e. local naming conventions.

And how does that integrate with the naming on your distant server [1]
(mine would be https://github.com/PhilipOakley/git)

Historically MSysGit used 'develop' as it's main branch, so wasn't a
naming problem. Since then I thought I'd updated my fetch refspec to
retain that mapping, but I've mainly worked directly on the Junio's. Now
I'm trying to get msvc-build to work again I need to update my MSysGit
environment (among other things), so I'm looking to find out what
best/good/workable practices folks have for this tricky problem.

kind regards,

--
Philip
[1] Home and distant signals (c.f. servers)
http://en.wikipedia.org/wiki/Railway_semaphore_signal#Distant_signals

Johannes Schindelin

unread,
Dec 7, 2014, 5:34:35 AM12/7/14
to Philip Oakley, git-w...@googlegroups.com
Hi Philip,

On Sat, 6 Dec 2014, Philip Oakley wrote:

> These upstreams include:
> * Junio (https://github.com/git/git and/or
> https://github.com/gitster/git),
> * MSysGit (https://github.com/msysgit/git) and
> * here (https://github.com/git-for-windows/git).
>
> What technique have you folks found most useful to locally disambiguate
> between the name clashes, especially of 'master' when fetching from
> these remotes? i.e. local naming conventions.

The technique I use is to simply use nick names for the remotes:

git remote add -f junio https://github.com/git/git
git remote add -f msysgit https://github.com/msysgit/git

(and I cloned from https://github.com/git-for-windows/git which is
consequently nicknamed "origin").

Therefore, the different 'master' branches are: junio/master,
msysgit/master and origin/master.

Whenever I make any changes, the first thing is always to name the branch:

git checkout -b stuff-for-philip

In the Git for Windows project, we try very hard to follow the Pull
Request model, therefore I also have another remote for my personal fork
to which I push all of my work.

So I guess the short answer is that I do not think of those branches as
'master', but instead as 'junio/master', 'origin/master', etc

Ciao,
Johannes

Philip Oakley

unread,
Dec 7, 2014, 3:17:07 PM12/7/14
to Johannes Schindelin, git-w...@googlegroups.com
From: "Johannes Schindelin" <Johannes....@gmx.de>
> Hi Philip,
>
> On Sat, 6 Dec 2014, Philip Oakley wrote:
>
>> These upstreams include:
>> * Junio (https://github.com/git/git and/or
>> https://github.com/gitster/git),
>> * MSysGit (https://github.com/msysgit/git) and
>> * here (https://github.com/git-for-windows/git).
>>
>> What technique have you folks found most useful to locally
>> disambiguate
>> between the name clashes, especially of 'master' when fetching from
>> these remotes? i.e. local naming conventions.
>
> The technique I use is to simply use nick names for the remotes:
>
> git remote add -f junio https://github.com/git/git
> git remote add -f msysgit https://github.com/msysgit/git

At the moment I've ended up with 7 remotes for git!
Router (supposed file space), jrn, junio, kernel, mingw, origin (my
GitHub) and upstream (msysgit/git), so its easy [for me] to be confused.
>
> (and I cloned from https://github.com/git-for-windows/git which is
> consequently nicknamed "origin").

Yes, trying to decide which one should be origin can be fun. Calling one
'upstream' may also have been a bad choice.

>
> Therefore, the different 'master' branches are: junio/master,
> msysgit/master and origin/master.

My problem is the desire to have "my own copy of [each of] their
master(s)" in my own name space (I suspect others have a similar
cognition problem). That's when it gets tricky deciding what to call all
those masters...

However some of this is probably a semantic problem because 'having
one's own copy' doesn't actually create a copy, rather it simply create
the extra branch pointer to the same place. But it always feel good to
have your own stuff;-)

I had some problems a while back when I accidentally created a branch
called 'origin' which made all the expected DWIMing go haywire and took
me a while to understand what was happening and then to fix it.

I noted that on Karsten's GitHub repo he had a lot of kb/<branches>
though they may be duplicates of his patch series on junio's. It just
made me think there may be a few common conventions on local naming.

>
> Whenever I make any changes, the first thing is always to name the
> branch:
>
> git checkout -b stuff-for-philip

I usually do that, but 'from my local copy', so either I need to get my
head around my wrong semantics of mine/theirs (which gets awkward with
Junios pu and next when they get re-wound - I'd like mine not to re-wind
till I say so!)

>
> In the Git for Windows project, we try very hard to follow the Pull
> Request model, therefore I also have another remote for my personal
> fork
> to which I push all of my work.

I need to a bit of practice on that as I've not used it yet - too many
patch attempts to junio [mainly documentation and beginner help stuff].
>
> So I guess the short answer is that I do not think of those branches
> as
> 'master', but instead as 'junio/master', 'origin/master', etc

One option I'm toying with is to have a local namespace 'my', so I'd get
'my/origin/master' but I have a feeling I'm just digging my hole
deeper!.

>
> Ciao,
> Johannes
>
Many thanks for the feedback. It's useful to write out the issues. It
helps clear the confusions.

regards

Philip
(now it's back to sorting my local install of msysgit 1.9.4, to
investigate the msvc-build fixes, so I can use VS2008, when/then looking
at passing symrefs in git bundle;)

Johannes Schindelin

unread,
Dec 8, 2014, 5:46:27 AM12/8/14
to Philip Oakley, git-w...@googlegroups.com
Hi Philip,

On Sun, 7 Dec 2014, Philip Oakley wrote:

> From: "Johannes Schindelin" <Johannes....@gmx.de>
>
> > Therefore, the different 'master' branches are: junio/master,
> > msysgit/master and origin/master.
>
> My problem is the desire to have "my own copy of [each of] their
> master(s)" in my own name space (I suspect others have a similar
> cognition problem). That's when it gets tricky deciding what to call all
> those masters...

Having remote branches, i.e. locally-cached versions of what you fetched
from remote repositories, is pretty my "my own copy of each of their
masters"...

So I have the suspicion that you want to do something in addition to
adding (and updating) remotes, but that there is really no need to.

Ciao,
Johannes

Philip Oakley

unread,
Dec 8, 2014, 5:34:26 PM12/8/14
to Johannes Schindelin, git-w...@googlegroups.com
From: "Johannes Schindelin" <Johannes....@gmx.de>
> Hi Philip,
> On Sun, 7 Dec 2014, Philip Oakley wrote:
>> From: "Johannes Schindelin" <Johannes....@gmx.de>
>>
>> > Therefore, the different 'master' branches are: junio/master,
>> > msysgit/master and origin/master.
>>
>> My problem is the desire to have "my own copy of [each of] their
>> master(s)" in my own name space (I suspect others have a similar
>> cognition problem). That's when it gets tricky deciding what to call
>> all
>> those masters...
>
> Having remote branches, i.e. locally-cached versions of what you
> fetched
> from remote repositories, is pretty my "my own copy of each of their
> masters"...
It's perhaps something we don't say enough...
>
> So I have the suspicion that you want to do something in addition to
> adding (and updating) remotes, but that there is really no need to.
>
I've a script that fetches and updates my local repo, which includes a
few 'warnings' about forced cahnges - I'll need to update it a little to
match the new perception...

Philip.


Reply all
Reply to author
Forward
0 new messages