BookmarkSubscribeRSS Feed

French version below for francophones.

 

This idea can be related with previous discussions on this thread :

https://communities.sas.com/t5/SASware-Ballot-Ideas/enable-non-local-git-server-integration/idi-p/31...

 

It would be nice if the development environment of SAS EG became a little bit more integrated.

Providing a git tool without any PUSH/PULL command is not enought for our need and therefore it becomes useless if we have to use an external tool to complete the job.

 

If the development of a full Git GUI is too complex as it seems to be if I refer to the comments in the feed I linked before ; could it be possible, a least, to provide a Git Bash shell in order to allow remote commands directly within SAS EG ?

And if a shell is possible, I could also suggest to provide some shortcuts (basic ones, and with a possibility to write and save our owns) for some frequent tasks.

 

No need for a wonderfull Gui.

But just an access to the full GIT shell (that must be already included somewhere within or along the SAS EG binaries, isn't it ?)

as it is

with PUSH/PULL capabilities

 

It would be very nice.

 

 

Cette proposition peut être reliée aux échanges précédants qui apparaissent dans le fil de discussion ci-dessous :

https://communities.sas.com/t5/SASware-Ballot-Ideas/enable-non-local-git-server-integration/idi-p/31...

 

Actuellement l'environnement de développement SAS EG propose des options sans être totalement abouties ni intégrées.

En l'occurrence, l'outil Git qui est proposé ne répond pas à notre besoin en l'absence des commandes d'émission/réception envers un dépôt central.

Cela nous oblige à utiliser un outil tiers (en l'occurence GitExtension), ce qui rend l'usage de SAS EG bien moins intéressant vis à vis d'autres solutions de développement.

 

Si le développement d'une interface Git complète se trouve être trop complexe, comme cela semble suggeré dans le fil de discussion cité ; serait-il possible, a minima, de fournir un accès Git en ligne de commande pour pouvoir exécuter ses instructions directement dans SAS EG ?

Et si une fenêtre de programmation Git est possible, alors on pourrais aussi imaginer de proposer quelques raccourcis (les commandes les plus fréquentes, ainsi que la possibilité d'ajouter ses propres commandes).

 

Sans avoir besoin de développer une interface fantastique, mais juste rendre l'accès à l'exécutable Git (qui doit déjà être présent dans les binaires d'installation de SAS EG, non ?)

5 Comments
paulkaefer
Lapis Lazuli | Level 10

I voted for this idea because I agree that the existing git integration in SAS EG is lacking.

 

But what's the need for having it within EG to begin with? What is the advantage of having this over using git over the command-line or git-specific GUIs?

Julien_Marandet
Fluorite | Level 6

@paulkaefer  the need cames from a standard workflow in our organization.

 

Because remote Git repositories are within our standards, we constantly need to push/pull our contributions.

This is because we are using Continuous Integration tools, that are triggered on repositories status changes.

 

With this standard in mind, all the other aspects of SAS EG (like auto-completions, query-builder, etc) falls in a second line.

The first line is "ok, I've got to write SAS code and push/pull it to a remote repository".

 

So when it comes to write a code, here is the SAS EG story :

1. pull the code (with GitExtension for now)

2. open a project

3. change some lines

4. do a commit and push it ; but do not care about SAS EG tool because the job would be half done, so switch back to GitExtension.

 

When you work on several projects, steps 1 and 4 are quite time-consuming and a little bit confusing because you always have to switch between diferrent Gui, and different environment.

Like : "ok, when I came back from lunch in SAS EG I changed from project A to project B, but within GitExtension I am still within the project C... did I have to push the staged commit that I found in it ? let me check twice... then I have to switch back in SAS EG from project B to C... ah, my project B was not saved, damned, let's stash it ".

 

 

Because of this need I came to the decision of building my own IDE with Atom and some plugins and shell scripts, and to keep away from SAS EG.

And here is my new story :

1. Open my project

2. Pull it, stashing a work in progress if necessary

3. Change it

4. Commit and push

And because my custom IDE handles Git, I can switch from project A to B without fear, since I can be certain that when it cames to push or pull I wont have to ask myself "is that push concern the right project ?". Everything is clear because at any time I want to push/pull I can see in my IDE the current state of the code.

 

I prefer to have a full integrated development environment with a full support of mandatory Git operations, than a pretty tool that forces me to juggle with tool.

My work forces me to switch between projects, and I feel that I can't use SAS EG because it just add unnecessary pain in my work.

Julien_Marandet
Fluorite | Level 6

in short : this is a question of context.

A SAS EG project is a great concept since it can handle specific contexts (with specific autoexec, for example)

 

But the remote Git repository is also an important part of a project.

 

So, the fact that we have to deal with remote definitions in a different an separated tool can lead to mistakes.

 

 

If remote Git actions where reachabled within SAS EG, then, from my point of view, a SAS EG Project would handle THE clue part of its context.

And then switching X times a day from a project to another would be painless since remote actions would just follow.

fifthand57th
SAS Employee
Status changed to: Under Consideration

Thank you for your suggestion! An existing SAS Enterprise Guide feature request exists for additional EG and Git integration. It is under consideration for a future release. I've added a link to this thread to indicate another EG user has requested this feature.

 

Thanks again!

Julien_Marandet
Fluorite | Level 6

I am glad to read your reply @fifthand57th and looking forward for the next release