An Idea Exchange for SAS software and services

Comments
by Regular Contributor
on ‎06-29-2017 09:30 AM

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?

by Occasional Contributor Julien_Marandet
on ‎06-29-2017 10:13 AM

@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.

by Occasional Contributor Julien_Marandet
on ‎06-29-2017 10:29 AM

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.

by SAS Employee fifthand57th
on ‎06-30-2017 10:14 AM
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!

by Occasional Contributor Julien_Marandet
on ‎06-30-2017 10:53 AM

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

Idea Statuses
Top Liked Authors