-I shall file another ticket for above comment (and validation)...
I'll file new epic for entire ics_dnsmasq organizing works.- (Added as INSTRM-71)

I have pulled JHU-only files into a JHU branch.

From slack conversation, what Craig is doing is not the one as ticket description targets.
This ticket targets, moving existing all configuration into branch, and place 'production at Subaru' as master.

arnaud.lefur fmadec
I've branched LAM from master now. Change your site to your branch when you are ready to work on facility reconfiguration.
As in last ICS/SpS telecon, any content in master will be squashed following works on INSTRM-71 at any time.

In general, I don't think branches will need to have much content.

One observation is that any given piece of networked hardware can only be at one site, so master can be (and I think should be) the sole branch for all flight hardware (hardware to be part of the final instrument at Subaru). Any hardware which is used with the expectation that it will eventually be delivered to Subaru should be on master.

Except for machine.conf, any of the site branches should always be able to merge from master w/o conflicts. If we agree to keep our strange site and commissioning hosts in site-named files on site-named branches there should not be much trouble.

I agree with Craig here. You can handle branches pretty easily with git (`git rebase master`), but there will be conflicts every time any one changes the config file on master, and I think that there is only marginal gain.

How many site files are really involved? Why not put them in a sites subdirectory, and use a symbolic link as part of closing the package?

I don't understand why you are commenting here but not INSTRM-71, and am not sure you read there.
Also we (might be with cloomis and arnaud.lefur but not rhl?) have discussed several times, simple rebase based flow will not work for entire files but could work only on pair of mac and hostname.

I think I like this site-named branches, that is may be a bit brutal and not very fancy but that's pragmatical, it's the configuration which has been used at a given time.
We just have to keep in mind that if the config file has to be updated, which I suspect will not happen too often, it has to be done also in site's branches.
That's the only inconvenient I see but in most cases it's simple and it went very smoothly when we have received the new r2 cryostat.

In a ideal world, you just merge LAM branche with master, plug the SM1 in and "Voila" !

We (Atsushi, Arnaud, and I) discussed this yesterday, and I believe that we agreed NOT to use branches. Instead, each site can have a site-specific directory, to which each of us makes a link. That directory should contain all and only the local and non-deliverable hosts, as well as any site-specific configuration (external DNS server, internal interface name, etc).

This will probably require some tweaking of the slightly peculiar dnsmasqd options which tell the program which configuration files and directories to load.

now we tend not to use branches for site management, so just closing this as WONTFIX and will have another ticket for work when we agreed on INSTRM-71 for configurations.