Hi all,
Just wanted to share an issue and a quick workaround I found for it in case
anyone else has the same problem. I believe a cmd2 update is causing
pySim-shell to fail. After installing it on a fresh install of Ubuntu
Server 20.04 and getting the following error when I run "python3
pySim-shell -p0":
>Using PC/SC reader interface
>Autodetected card type: sysmoUSIM-SJS1
>AIDs on card:
> USIM: a0000000871002ffffffff8907090000
>Traceback (most recent call last):
> File "pySim-shell.py", line 512, in <module>
> app = PysimApp(card, rs, opts.script)
> File "pySim-shell.py", line 59, in __init__
> super().__init__(persistent_history_file='~/.pysim_shell_history',
allow_cli_args=False, use_ipython=True, auto_load_commands=False,
command_sets=basic_commands, >startup_script=script)
>TypeError: __init__() got an unexpected keyword argument 'use_ipython'
If you run into this you can fix it by uninstalling cmd2 and reinstalling
cmd2 with "pip3 install cmd2==1.5".
Best,
Bryan
Hi,
I had a problem placing MO GSM calls from a Siemens S11E: The calls
were dropped immediately; Osmo-MSC reports "Cannot compose Channel
Type from bearer capabilities"
After investigating the SETUP request from the S11E, the phone does
not use octet 3a (no extension bit set in IE 3). Wireshark decodes the
radio channel requirement as "Full rate support only MS/fullrate
speech version 1 supported", so I added a condition to the gsm48_ie.c
function of libosmocore to include at least GSM FR in the list of
available speech_ver in case octet 3 has no extension.
Attached to this message are the Abis-IP PCAP traces of MO calls, and
the patch for gsm48_ie.c.
Regards,
Lennart
Hi,
My name is Brackley Cassinga Form DRC, we run a community network called
pamoja net where we offer gsm services using osmocom open source software
and OC Base station.
Recently I have tried to install another base station as the same installed
but I could not find any resource guiding through all the steps to take to
run NIB on a base station.
I'm currently running Ubuntu and I will appreciate if you could guide me on
the installation of BSC,hlr,MSC , in order to run a basic gsm network.
Thank you. Regards
--
*Ir Brackley heshima Casinga **Pacifique*
*CEO and Founder of kwanzatechnologie*
KwanzaTechnologies ,GlobalElectronics
+243977265291 | +243977265291 | Pcassinga(a)gmail.com/
brackley(a)ensemblepourladifference.org
www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> |
Skype: Brackley cassinga <https://webapp.wisestamp.com/#>
Av Semliki N 43
Dear Osmocom Community,
I have noticed that the wiki page for OpenBSC GPRS at
https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS has
not been updated for four years, and since then, there have been
significant updates to the software. As a result, the information on the
GPRS/EDGE Setup page may be outdated, and I am struggling to configure GPRS
on my system.
I have attached my configuration files below for your review.
ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel
state DOWN group default qlen 1000
link/ether ec:8e:b5:41:cb:90 brd ff:ff:ff:ff:ff:ff
3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP group default qlen 1000
link/ether b8:8a:60:4f:59:02 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.109/24 brd 192.168.1.255 scope global dynamic
noprefixroute wlp1s0
valid_lft 7152sec preferred_lft 7152sec
inet6 fe80::649b:2ab5:6dd3:8779/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Hello Osmocom,
I have written a new specification, in the style of 3GPP specs, for
enhanced RTP transport of FR and EFR codec frames in an IP-based GSM
RAN, addressing problem areas where the general standard RTP format
for these codecs creates functional regressions relative to the
original T1/E1 Abis architecture with TRAU frames. The new spec has
its official home here:
https://www.freecalypso.org/specs/tw-ts-001-v010001.txt
and here is a pair of patches adding OsmoBTS support for accepting
this TW-TS-001 format in RTP input and optionally (per vty config)
emitting it in RTP output:
https://cgit.osmocom.org/osmo-bts/log/?h=falconia/rtp_traulike
The code patches are just for better context - they will go to Gerrit
for review later - but right now I am soliciting a review of the
specification, rather than code implementation. I am not aware of any
established process in Osmocom for reviewing new specifications
(different from code review), as writing new 3GPP-style specs is not
something this community does often. But in the present case I am
genuinely convinced that the Internet standard RTP format for GSM-FR
and GSM-EFR (written with VoIP rather than GSM RAN in mind) is truly
deficient for GSM RAN purposes, especially for those who wish to
deploy their GSM networks in a retronetworking fashion, and the only
way to bring back the full set of E1 Abis bells and whistles over IP
is to invent our own (completely optional) pseudostandard format that
will likely only be used within {Osmocom+Themyscira} community.
With this context in mind, I cordially invite all of you, esteemed GSM
FOSS developers, to review the new specification linked above.
Sincerely,
Mother Mychaela
Hi Harald,
I tested and can confirm that the Nokia code cannot handle a situation
when the first TRX is not the first physical TRX in the cabinet. This
affects MetroSite and UltraSite and all other variants that can handle
more than one TRX. Given the fact these units are getting 20+ years
old, backplane or other HW issues can force a user to not start with
the first physical TRX and in that case the RSL bootstrap fails as the
BTS receives a config starting with trx1 while the unit may has trx2
or trx3 etc.
Question is how to handle this?
One option is that on Nokia, each TRX has its own RSL TEI, and that is
a 1:1 match as much as I know. Physical TRX1 has TEI1, TRX2 has TEI2
etc. So we can make a check during fu_config to first determine the
first physical TRX based on the RSL TEI, and then check at each
iteration which is the next one. For example you can have trx2 and
trx4 as well, so we cannot expect that the TRX-es are in a continuous
order nor that they always start with trx1.
Another option is to introduce a new Nokia specific TRX variable that
describes the physical location of the TRX inside the cabinet and do
the above mentioned checks with that.
Or there is a 3rd option I am not thinking about :-)
Any and all opinions are welcome.
Regards,
Csaba
Dear Harald,
Sorry for the delay, the UltraSite cabinet has some massive
backplane/interconnect issues, I tried to sort those out in the last
couple days (with not much success).
I had some time to further investigate the Nokia UltraSite situation,
and here are the outstanding issues I faced:
1. 2-3 seconds after BTS_RESET the OML LAPD link is reestablished
(coming from the BTS itself), and the signalling logic tries to
bootstrap OML (sometimes RSL as well) during the BTS performing the
reset. This tries do fail of course. Not sure if this causes any
practical error, although it does not look nice. Maybe adding some
logic state checks can help?
2. Sometimes on the OML LAPD link (and only on that one) I can see
these error messages:
DLLAPD lapd_core.c:1315 (0:1-T1-S62) S frame response with F=1 error
DLLAPD lapd_core.c:421 (0:1-T1-S62) sending MDL-ERROR-IND cause 6 from
state LAPD_STATE_MF_EST
Sometimes they arrive in batches, sometimes only a few. FYI the BTS
and the TRE both runs the latest SW ever released for UltraSite
(CX8.2).
3. Moving the RSL bootstrap to after "NOKIA_BTS_CONF_COMPL" received
seems to be working fine, this way we don't need to add another timer,
and Osmo-BSC can wait long enough to make sure all the TRXes loaded
the SW, configured and waiting for LAPD. In case more than one TRX is
used, the TRXes reach the "waiting LAPD" state in different order.
Did you had time to maybe try with InSite? I dont think my patch can
brake it, but I remember InSite was an odd ball within the Site
family.
I also started to re-introduce RF/BB hopping control for Nokia, if you
- or anyone -
can review it that would be lovely:
https://github.com/dchard/osmo-bsc/commit/41f6cd4723961700c5e5eceab4c92e7ce…
I was not able to try it out yet, as due to my backplane issues with
the cabinet, only TRX1 and TRX3 and TRX4 slots are working. And for
some reason if I try to use TRX3 and 4, the RSL bootstrap fails. I
wonder if the Nokia code has some limitation if the first TRX is not
actually the first? I tried to configure Osmo-BSC to start with "trx
2" but it does not want to start anything other than "trx 0". Of
course the question is what OsmoBSC sends during OML bootstrap. As
much as I can see, the Nokia code does not take into account if the
first TRX is not the first physically in the unit, but I am not a 100%
sure yet. Some help or hint here would be very welcome.
This is where I am now. The HW issues with the unit makes it pretty
time consuming to focus on the SW side, for now.
If you or anyone has any ideas or comments, please let me know.
Regards,
Csaba
Hi! I just purchased a used Ericsson RBS 6000 chassis with a DUS 31 module in it. From what I have read, this module should be compatible with Open5GS for the LTE side, but I wanted to inquire about the status of support for it on the GSM side under OsmoBSC. As far as I know, it should work the same as the DUG series which is supported, with the only difference being it's use of Ericsson packetAbis/IP rather than hardware T1 lines for the voice backhaul connectivity. Will these units work with osmocom for GSM, or will I have to purchase a DUG unit for my enclosure? Is there anything else I should be aware of?
Thank you,
Enzo D'Amato
Dear Osmocom community,
Over the past several months I've been working almost exclusively on
improving FR1 and EFR speech handling in the Osmocom GSM network
implementation. All of my Gerrit patches since March have been in
this area, and my two Themyscira-branded public domain libraries for
GSM codecs are also primarily intended for use together with Osmocom,
specifically for implementation of transcoding media gateways that
interconnect an Osmocom GSM network with a non-GSM outside world
such as G.711 PSTN.
Given the knowledge I've gained over months of working in this area,
and seeing that many other Osmocom developers aren't particularly
familiar with these aspects of the specs (understandable: GSM is huge,
can't keep everything in one's head), I would like to do an OsmoDevCall
presentation on the topic of GSM speech handling with traditional
non-AMR codecs. I would like to cover the following subtopics:
* What metadata bits (BFI, UFI, SID, TAF) are defined in the specs for
transport of encoded speech between network elements, beyond the
familiar speech codec bits themselves.
* What exactly are regular speech frames, SID frames, silence frames
(a "silence frame" for FR1 codec is NOT the same thing as a SID frame!)
and bad frame gaps, and which of these categories are allowed or not
allowed to exist at each of the interfaces in the spec-defined GSM
architecture.
* Which transformations are supposed to happen where: which network
elements are responsible for bad frame handling, error concealment,
comfort noise insertion or SID propagation.
* How these architectural principles, originally defined for the T1/E1
environment with TRAUs, can be carried over to an RTP environment.
* Relevant Osmocom components: OsmoBTS and the aspect of OsmoMGW that
interfaces from RTP to T1/E1 Abis.
* What behavior changes have been effected by my patches to OsmoBTS and
supporting libraries that have already been merged, and which behavior
changes are still on my wish list or to-do list to implement and
hopefully get merged.
Looking at the OsmoDevCall wiki page, I see absolutely nothing
scheduled past May, and there was no OsmoDevCall in April - are we out
of presenters? But we have just one problem: it seems that some
people in the senior leadership of Osmocom organization don't want me
presenting on OsmoDevCall, and recently even asked specifically for
presentation ideas from "anyone other than Mychaela". I see two
possible solutions to this problem:
Option 1: If the leaders in question could set aside their personal
dislike of me and allow me to present on highly Osmocom-relevant
topics (such as the FR/HR/EFR codec presentation proposal above) no
different from other Osmocom developers, that would be the best
solution.
Option 2: If those who control the scheduling of presentations on the
official OsmoDevCall platform (the official BigBlueButton instance for
ODC) are not willing to budge, the alternative will be for me and Das
Signal (my dear friend and FreeCalypso sysadmin) to set up our own BBB
instance on our own server, configure it to look and feel exactly like
the official one used for ODC, hold presentations there during those
months when no official ODC presentation takes place due to lack of
non-excluded willing presenters, and invite everyone from Osmocom to
join those unofficial ODC-like presentations.
So - which of the two is it going to be?
Sincerely,
Mother Mychaela,
operator of a non-profit GSM network based on Osmocom,
contributing to Osmocom CNI development in conjuction with that
network operation.
Hello GSM community,
I just put a new release of Themyscira GSM codec libraries and
utilities package:
ftp://ftp.freecalypso.org/pub/GSM/codecs/gsm-codec-lib-r2.tar.bz2ftp://ftp.freecalypso.org/pub/GSM/codecs/gsm-codec-lib-latest.tar.bz2
(symlink)
The two libraries in this package (libgsmefr and libgsmfrp) are
intended for people who develop gateway software interconnecting
Osmocom-based GSM networks to PSTN or other networks, gateways which
include a speech transcoding function that terminates the GSM codec
leg.
If anyone is currently interconnecting an Osmocom GSM voice network to
the outside world using software which you did not write yourself
(Asterisk, FreeSwitch, Kamailio, whatever) and you care about the plain
old FR codec, and/or care about EFR, beyond just AMR, I encourage you
to investigate your current non-Osmocom gateway software to see exactly
how it implements FR and EFR. Because there were NO pre-existing FOSS
libraries that correctly implement FR and EFR decoding prior to my
Themyscira gsm-codec-lib development, most pre-existing gateway
software probably implements these codecs in a flawed manner:
FR codec: Everyone to my knowledge implements this codec using classic
libgsm, a library that dates back to 1990s. It's a good library, it's
a fully correct implementation of GSM 06.10 spec, and I use it too.
However, it implements _only_ a bare 06.10 encoder and a bare 06.10
decoder, without any DTX functions of GSM 06.31 and related specs. In
the encoder direction having no DTX isn't really a problem (you won't
be able to do DTXd anyway unless you got lots of spectrum and are
running multi-ARFCN cells), but the lack of an Rx DTX handler per GSM
06.31 *is* a real problem: if you feed the uplink from a GSM call (RTP
stream from a BTS) to a bare GSM 06.10 decoder such as gsm_decode()
function in libgsm, you won't get correct handling of SID frames,
which every standard GSM MS will transmit, and you won't get correct
handling of BFI frame gaps, which will always occur. The correct
solution is to insert a call to a GSM 06.31 Rx DTX handler (it is more
than an ECU) just before the call to gsm_decode(), and my libgsmfrp
offering is that GSM 06.31 Rx DTX handler.
EFR codec: Everyone other than me implements EFR (if they support it
at all) using an AMR library such as libopencore-amrnb. I have seen
totally broken implementations that schlep 244-bit payloads directly
between supposed-to-be-EFR RTP and the AMR library, without reordering
those bits per gsm690_12_2_bitorder[] - those implementation have
exactly zero chance of ever actually working with a real GSM-EFR MS on
the other end - and I've also seen implementations that do perform this
bit reordering and are thus closer to correct. But even the latter
implementations are still wrong when it comes to SID handling: EFR is
equivalent to the highest MR122 mode of AMR only for regular speech
frames, but not for SID. There does exist a special encoding format for
representing GSM-EFR SID in AMR frame interfaces, but libopencore-amrnb
does not support GSM-EFR SID in any way at all. If you take the uplink
from a GSM-EFR call and feed it to libopencore-amrnb decoder, any time
the GSM MS emits a SID frame, strange noise sounds will appear at the
output of that decoder, instead of the correct comfort noise.
Themyscira libgsmefr is a proper encoder and decoder library for EFR,
based on the EFR reference code from ETSI, in exactly the same way how
libopencore-amrnb is based on the AMR reference code from ETSI/3GPP.
It still has some performance problems which I will be working on later
(the goal of getting it to perform no worse than libopencore-amrnb has
not been achieved yet), but at least it is correct.
Hasta la Victoria, Siempre,
Mychaela aka The Mother
Dear Harald,
A long time passed since I worked with the Nokia Site family and
OpenBSC. I managed to save an UltraSite cabinet from scrap, so I try
to revive it for a museum.
On the old NITB versions I managed to make this work once, now I am
trying with the new (at least to me) Osmo-BSC implementation.
To keep it simple, only one TRX is configured:
OML <--> E1 TS 1 (64kbit)
RSL <--> E1 TS 2 (64kbit)
TRXSIG <--> E1 TS 3 and 4
DAHDI is used with a Digium Wildcard TE110P T1/E1 Board.
Osmo-BSC is able to do the OML bootstrap, but the RSL waits for LAPD endlessly.
My first question is: should Osmo-BSC be able to bootstrap the BTS
fully (all the way to "on air" mode) if it is not (yet) connected to
any other core element (MGW, MSC, STP) ?
This is the Osmo-BSC log (after the NOKIA_BTS_RESET command + the
reset_wait_time passed):
DLLAPD input/lapd.c:245 (0:1-T1-S62): LAPD Allocating SAP for SAPI=62
/ TEI=1 (d l=0x56284cfbd220, sap=0x56284cfbd200)
DLLAPD input/lapd.c:255 (0:1-T1-S62): k=1 N200=3 N201=260 T200=1.0 T203=10.0
DLLAPD input/lapd.c:519 (0:1-T1-S62): LAPD DL-ESTABLISH request TEI=1 SAPI=62
DLLAPD input/lapd.c:654 (0:1-T1-S62) LAPD DL-ESTABLISH confirm TEI=1 SAPI=62
DNM bts_nokia_site.c:63 (bts=0) bootstrapping OML
DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM
DNM bts_nokia_site.c:1573 (bts=0) Rx (0x82) NOKIA_BTS_OMU_STARTED
DNM bts_nokia_site.c:1583 (bts=0) Rx BTS type = 17 (UltraSite GSM 900)
DNM bts_nokia_site.c:1098 (bts=0) Sending NOKIA_BTS_START_DOWNLOAD_REQ
DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM
DNM bts_nokia_site.c:1573 (bts=0) Rx (0x84) NOKIA_BTS_MF_REQ
DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM
DNM bts_nokia_site.c:1573 (bts=0) Rx (0x88) NOKIA_BTS_CONF_REQ
DNM bts_nokia_site.c:1098 (bts=0) Sending NOKIA_BTS_ACK
DNM bts_nokia_site.c:1260 (bts=0) Sending multi-segment 0
DNM bts_nokia_site.c:1260 (bts=0) Sending multi-segment 1
DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM
DNM bts_nokia_site.c:1573 (bts=0) Rx (0x81) NOKIA_BTS_ACK
DNM bts_nokia_site.c:1604 (bts=0) Rx ACK = 1
DLLAPD input/lapd.c:245 (0:2-T1-S0): LAPD Allocating SAP for SAPI=0 /
TEI=1 (dl= 0x56284d252a20, sap=0x56284d252a00)
DLLAPD input/lapd.c:255 (0:2-T1-S0): k=2 N200=3 N201=260 T200=1.0 T203=10.0
DLLAPD input/lapd.c:519 (0:2-T1-S0): LAPD DL-ESTABLISH request TEI=1 SAPI=0
DLLAPD lapd_core.c:421 (0:2-T1-S0) sending MDL-ERROR-IND cause 1 from
state LAPD _STATE_IDLE
DLLAPD input/lapd.c:658 (0:2-T1-S0) LAPD DL-RELEASE indication TEI=1 SAPI=0
DLLAPD input/lapd.c:282 (0:2-T1-S0): LAPD Freeing SAP for SAPI=0 /
TEI=1 (dl=0x5 6284d252a20, sap=0x56284d252a00)
DCHAN lchan_fsm.c:1779
lchan(0-0-0-CCCH_SDCCH4-0)[0x56284d251770]{UNUSED}: (type =NONE) lchan
allocation failed in state UNUSED: LCHAN_EV_TS_ERROR
DCHAN lchan_fsm.c:197
lchan(0-0-0-CCCH_SDCCH4-0)[0x56284d251770]{UNUSED}: (type= NONE) lchan
activation failed (lchan allocation failed in state UNUSED: LCHAN_EV
_TS_ERROR)
DCHAN lchan_fsm.c:1779
lchan(0-0-0-CCCH_SDCCH4-1)[0x56284d2519b0]{UNUSED}: (type =NONE) lchan
allocation failed in state UNUSED: LCHAN_EV_TS_ERROR
DCHAN lchan_fsm.c:197
lchan(0-0-0-CCCH_SDCCH4-1)[0x56284d2519b0]{UNUSED}: (type= NONE) lchan
activation failed (lchan allocation failed in state UNUSED: LCHAN_EV
_TS_ERROR)
DCHAN lchan_fsm.c:1779
lchan(0-0-0-CCCH_SDCCH4-2)[0x56284d251bf0]{UNUSED}: (type =NONE) lchan
allocation failed in state UNUSED: LCHAN_EV_TS_ERROR
DCHAN lchan_fsm.c:197
lchan(0-0-0-CCCH_SDCCH4-2)[0x56284d251bf0]{UNUSED}: (type= NONE) lchan
activation failed (lchan allocation failed in state UNUSED: LCHAN_EV
_TS_ERROR)
DCHAN lchan_fsm.c:1779
lchan(0-0-0-CCCH_SDCCH4-3)[0x56284d251e30]{UNUSED}: (type =NONE) lchan
allocation failed in state UNUSED: LCHAN_EV_TS_ERROR
DCHAN lchan_fsm.c:197
lchan(0-0-0-CCCH_SDCCH4-3)[0x56284d251e30]{UNUSED}: (type= NONE) lchan
activation failed (lchan allocation failed in state UNUSED: LCHAN_EV
_TS_ERROR)
Would be nice to make this old beast running again.
Much appreciate any and all help.
Regards,
Csaba
Hello Osmocom,
I know a lot of people here have salvaged T1/E1 BTS equipment from
Nokia, Ericsson etc. But what about the next level up - has anyone
been able to salvage a classic T1/E1 BSC that goes with those BTSes?
And given the hardware, does anyone in our community know how to get
one of those beasts working?
I am interested in the TRAU component of the classic GSM BSS
architecture, and I would really love to lay my hands (remotely, via
OCTOI, would be just fine) on one of those beauties. Specifically, I
seek to feed custom-crafted bits to the TRAU's Abis input and capture
what it puts out on the A interface G.711 side, and vice-versa.
What can be learned from such experiments? Several things:
* I would love to play with TFO: see the TFO_REQ in-band signaling
messages the TRAU should put out on its own during the first 5 s or
so, then send our own TFO_REQ and TFO_ACK to the TRAU, do the whole
protocol, and get the TRAU to actually enter TFO mode. Reading the
spec is one thing, but seeing it in action would be so much more fun!
I've also been wanting to write my own FOSS implementation of in-band
TFO within G.711 RTP, but it would be an impractical task without
having some other existing implementation to test against.
* If we can get TFO to work, we'll be able to see exactly how real
TRAUs handled the onerous requirements of TS 28.062 section C.3.2.1.1.
Implementing those rules for FR1 would be quite easy, but try doing
the same for EFR or HR1 - *very* daunting! It would be lovely to see
exactly what actual historical implementations did here.
* Outside of TFO, we should be able to get the TRAU into a known state
by feeding it spec-defined encoder and decoder homing frames, and then
craft our own test sequences (beyond the standard ones it was surely
tested with by its designers) to exercise those parts of the codec
implementation where the specs allow implementors to innovate,
particularly everything to do with error concealment.
But doing all of the above requires access to some old-style T1/E1 BSC
that contains such a TRAU. Does anyone in our community have access
to such hw?
M~
Should I change the way I do private branches in osmocom?
I push a lot of private branches everywhere. I was asked in PM if I could cut
down on branches a bit because it clutters other developers' view of the git
history. My immediate response was: the other developer should simply not fetch
my branches, or invoke tig or gitk in a way that shows only selected branches.
But I reflected a bit and would like to ask generally how we want to do it.
For osmocom it apparently is mostly me pushing private branches a lot. What if
we all did that...
In linux kernel development it seems to be more like each developer has her own
public repository to make a mess in.
So, i could make git clones of our main repositories in gitea and keep my
private branches there. It seems like maybe i should do that out of common
courtesy.
But it also adds a bunch of overhead for me, keeping separate repositories
synced. Having multiple remotes affects git commandline behavior. I used to
have separate fetch/push URLs for a while, but it was annoying in some ways.
I can change my ways, but only if i really have to.
Any opinions? Are my branches annoying?
Aspects:
- backup of my ongoing work. (daily)
- offering preliminary work to customers for manual build. (weekly)
- seeing what others are up to. (rare but happens)
- limiting branch clutter. (all the time for everyone)
thanks!
~N
