Poll: Which Git client do you use?

[joerg.hampel]

MKr,

a bit of history for context: I'm an Apple user. On my Apple computers, I run virtual machines (VMware) with Windows for the various LabVIEW versions I need. Up until Windows 7, I used to have my repositories cloned in MacOS to a shared folder, and then work with these "shared files" inside the Windows VMs. With Windows7, though, using files from a shared folder started to become really slow, so I had to move the repos inside my VMs. Today, I'm using git mostly on Windows, less often on MacOS.

I used to use various UI-enabled git clients on my Mac but never enjoyed using them. For some, you could tell from the UI that they were not native Mac OS applications, written in some cross-platform language like Java. Others were native to Mac OS, but didn't really live up to the high standards of Mac OS application design.

When I stumbled upon Git Tower somewhere in late 2014(?), I immediately jumped on it as it has been a native Mac app from the very beginning. The UX was so nice!

In 2017, I started using git much more on Windows, and luckily, the Git Tower app was also released for Windows soon after. 

Now, for a current comparison of the two tools, I still prefer Git Tower. That is probably due to me being used to it, but I find that little details are much better implemented in Tower. Examples are:

- Full support for GitLab (I can browse my GitLab repos in Tower and clone them with one mouse click)

- When creating a new feature branch with Gitflow, Tower automatically stages and applies changes from the current branch (and that happens all the time: I start hacking away, I want to commit, I realize I forgot to create the feature branch)

- Prettier UI (this one is purely subjective)

- The way the number of commits your local branch is behind or ahead the origin branch is presented, both in the sidebar and in the visual history

- The way the currently selected branch in the sidebar is represented in the history visualisation

- Visualisation of merge conflicts

- The way submodules are visually represented in Tower is more straightforward for me

- The online help/documentation is awesome!

The support team of Fournova (the company behind Git Tower, located perhaps one hour south of my place in Germany) is super fast to reply, very helpful and competent. When they released the Windows version, there very quite a few kinks that had to be ironed out. The guys there were always thankful for the feedback, and more than once they would build a new release right ahead to address things we found out together. 

Reading back this comparison, it feels a bit like comparing Mac to Windows. I can get everything and anything done on both operating systems. My personal choice is Apple, no questions asked. And it's the same with Git Tower: I find the overall UX much nicer, I think it's worth the money, hence I'll keep using it. 

Edit: I posted an updated version of this on LinkedIn

[Harti]

I'm using Tortoisegit as it's easy to configure with lvcompare et lvmerge. But to commit pull and push, i'm using the command line wtih the wsl as i'm on windows, it's easiest to manage the ssh key and faster.

[Harti]

I'm using tortoiseGit as it's easy to configure with lvcompare and lvmerge. but  to commit, push or pull i use the command line on the windows subsystem linux. It's faster and easiest to manage the ssh key.

[r_good]

I have tried several, but I found Git Kraken to be my favorite so far.  Very similar to Sourcetree, nice UI, supports gitflow, supports GitLab and GitHub.  But my reasoning for not using Sourcetree is that I need a cross-platform solution.  I do work in a linux environment often and I don't want to learn several different GUI environments.  Gitflow plugin support is a must for me, the plugin really does make life easier.  I tried a bunch of other free cross-platform GUIs and none seemed to have a gitflow solution.  If I worked only on Windows, I'd just go for Sourcetree.   

I do try to use the git bash command line interface as much as possible though.  It has really helped me to understand what I am doing.

[Taggart]

Curious, how does GitKraken work with the LVdiff and LVmerge?

I know with TortoiseSVN it was fairly simple, but for SourceTree it was a little more complicated.  I too do a lot of work on linux (although non-LabVIEW), so Git Kraken does look very interesting.

[r_good]

---

@Taggart wrote:

Curious, how does GitKraken work with the LVdiff and LVmerge?

I know with TortoiseSVN it was fairly simple, but for SourceTree it was a little more complicated. 

---

I'm struggling a bit with that right now.  The configuration should be the same as for Sourcetree.  It seems to consist of getting your .gitconfig set up to call the right executable.  I'm struggling with Sourcetree as well though.  

[RVallieu]

The issue with Sourcetree and LabVIEW Merge and Compare is that LabVIEW wants the ABS path of the VIs to operate upon and Sourcetree provides RELATIVE paths.

From my testing with Sourcetree (we're rolling out Atlassian suite for SCC and project tracking):

https://community.atlassian.com/t5/Sourcetree-questions/Labview-merge-tool-for-sourcetree-3-0/qaq-p/...

I found that NI is providing a LabVIEW based solution to the LV Compare and LV Merge tool arguments issue.  They have provided the LabVIEW code in a GIT repository.  I just downloaded it and followed the instructions for building the EXEs, distributions and installer on my system and change the Sourcetree Diff and Merge callouts as specified.

I plan to try out the previous steps I implemented changing code in two local repos that point to the same remote repo, simulating two developers working on the same VI and committing/pushing in order to generate a conflict and then seeing if the tools will work as specified to leverage the Compare and Merge tools.

Here is the link to the GIT repository provided by NI: https://github.com/smithed/vicompare

[r_good]

I tried using the NI tools, but they weren't working for me. The exe would launch and crash without launching LVCompare. I searched around and found this post and it worked for me. 

For configuring the diff tool, I used the bash scripts found here:

https://endigit.com/2017/11/using-labviews-diff-tool-sourcetree

I edited my global .gitconfig to have

[diff]
    tool = vidiff

[difftool "vidiff"]
    cmd = \"C:/<path-to-script>/_LVCompareWrapper.sh\" \"$LOCAL\" \"$REMOTE\"

The one issue I have so far is that is will only launch the last version of LabVIEW used.  I want to give the NI version another run, I have not really poked around enough to find out where the issue is.  I plan on adding a utility to choose which version of LV to launch based on the file type.  

I haven't tried with the merge yet, I never use it so it hasn't been a priority.

[RVallieu]

Odd - it worked well for me and a few others.  If I remember correctly you can add a call-out for the LV Version.

You could also try using the Command Line Interface - write your own EXE.

[r_good]

I know I could force a specific version to launch every time using the -lv or -version flag, but I am working on a machine with several versions and maintaining code in several versions.  I am pretty sure this is why the launcher wasn't working.  I have gotten it to work before, so it must be the version issue

I am currently working on adding a provision that will open the version on labview that the vi was last saved in.  I have it almost all finished up.