[Tutor] How to use Git from Windows PC for files on Solaris machine where Git cannot be installed?

[Cameron Simpson]

On 29Apr2015 22:10, boB Stepp <robertvstepp at gmail.com> wrote:
>On Wed, Apr 29, 2015 at 9:40 PM, Cameron Simpson <cs at zip.com.au> wrote:
>> On 29Apr2015 12:12, boB Stepp <robertvstepp at gmail.com> wrote:
>>>> ... (3) install git if needed ...
>>>
>>> It seems Git is needed, but I am not allowed to install it on the
>>> Solaris workstation. So is there a way around this?
>>
>> What do you mean by "install"? Bear in mind that while you may be forbidden
>> from installing git in the main areas (/usr, /usr/local, whatever), you may
>> be free to install it in your own home directory. It is just an
>> executable...
>
>On the smart enterprise where we (now) do our clinical planning they
>are very strict: no installing any external software; no accessing the
>Internet; no email; etc. Not all centers adhere to this level of
>strictness, but ours does. [...] But I am reluctant to do
>anything that I am not allowed to replicate on smart enterprise. I am
>trying to keep it as close to identical to the actual clinical
>environment as I can.

And fair enough too. I frequently wish our developers' dev environments more 
rigorously modelled the target environment.

>Perhaps this is misguided on my part?

Not necessarily.

But I would be inclined to distinguish your working tools from the target 
environment.

For example, I commend you making your dev environment as close to identical to 
the actual clinical environment as you can. But I wouldn't deprive yourself of 
tools that enhance your code management practices without affecting that 
environment.

For example, there is much to be said for tracking your changes with a tool 
like git or hg. It encourages your to annotate your changes, and lets you 
review history to see when and why some change occurred, especially if a new 
bug has arisen. Distributed version control systems like git and hg also make 
it easier to work on distinct changes to the same code as separate work 
processes; of course the price for such a workflow is that you need to merge 
the two things later and ensure that they do not interact badly.

If you're serious about keeping the two environments very similar, you could 
always do your _coding_ on a third platform (a laptop or whatever) using your 
desired tools and _deploy_ the code to the dev (and later, prod) environments 
from there, keeping the dev environment pristine. By "deploy", that can be as 
simple as copying the code to the target.

Just thoughts; of course you must choose practices that suit your needs and 
plans.

Cheers,
Cameron Simpson <cs at zip.com.au>

Nothing is impossible for the man who doesn't have to do it.