Git can't be this terrible, what am I doing wrong?

[Aristos Queue]

I have a theory for what a good UI for GIT would look like, and it is a bit different from the existing ones. 

I think there should be a picture of the current state of the world. You draw a picture of the state you want. Then the tool generates the command line commands that get you from A to B. This serves two purposes: rather than taking an action and then seeing if that did what you want, it puts the UI in charge of figuring out how to get you textually what you're specifying graphically. Second, it shows the user what the commands are that it is executing so that you figure out "oh, that's how that is done" so that when the UI inevitably hits its limits (for whatever reason, GIT seems to exceed the complexity of all UIs used to render it), then the user is already are familiar with the commandline interface. 

I don't think I'll ever be motivated to write this UI, but I figured I'd toss out that bit of brainstorming in case anyone decides to chase that albatross.

[JKSH]

57 minutes ago, Aristos Queue said:

I think there should be a picture of the current state of the world. You draw a picture of the state you want. Then the tool generates the command line commands that get you from A to B. This serves two purposes: rather than taking an action and then seeing if that did what you want, it puts the UI in charge of figuring out how to get you textually what you're specifying graphically.

Spoken like a true LabVIEW dev 😁

 

59 minutes ago, Aristos Queue said:

Second, it shows the user what the commands are that it is executing so that you figure out "oh, that's how that is done" so that when the UI inevitably hits its limits (for whatever reason, GIT seems to exceed the complexity of all UIs used to render it), then the user is already are familiar with the commandline interface. 

That's a really good idea

[felipe.foz]

I believe most of the people who does not get along with Git, it is because they had a bad experience in first uses. The first impression is always a problem.

In Git, Command Line is your friend (believe it). In 90% of the time you always need the same commands for managing source code.

git checkout -b newbranch

Edit your code

git add (file)
git commit -m "Message"
git push origin new_branch
git checkout master
git merge new_branch

If you don't like to repeat steps, you can use aliases to group commands.

But when people start trying using features like rebase, cherry pick, things can get very messy. Don't go that way.

For managing visually your history, Git Platforms like Gitlab, Github, Bitbucket and others help a lot, including integration with issues, milestones, releases and package storage.

Edit: I did a QD plugin for opening the Git bash. It is way faster than clicking in three, four places.
 

Edited July 22, 2020 by felipe.foz

[drjdpowell]

I've been experimenting with Git Submodules, as a way to deal with a large repo that supports multiple different Test Stations with lots of common code.  It again demonstrates Git is powerful, but also how horrible the UX design is.  It's like I want to do an obvious thing, so I do the obvious action, but because I missed the non-obvious step needed first, I am now in a state where I have to spend 10 minutes coming up with a series of multiple actions that will undo the damage.

[Neil Pate]

2 hours ago, drjdpowell said:

I've been experimenting with Git Submodules, as a way to deal with a large repo that supports multiple different Test Stations with lots of common code.  It again demonstrates Git is powerful, but also how horrible the UX design is.  It's like I want to do an obvious thing, so I do the obvious action, but because I missed the non-obvious step needed first, I am now in a state where I have to spend 10 minutes coming up with a series of multiple actions that will undo the damage.

I have found submodule interation in GirKraken pretty self-explanatory actually. I have of course managed to screw things up a few times but have so far been able to recover my mistakes.

[drjdpowell]

The problem I had is that submodules are connected to a specific commit, rather than branch, so when one checks them out originally one must remember to manually create a branch, else if you commit changes they are a "detached head", which is then fixable, but a pain.  

I find Git to be very much "'Oh, you should have used the "engage safety" and "don't_point_at_foot" options when you called the "git new_gun" command'.

 

[Neil Pate]

2 hours ago, drjdpowell said:

The problem I had is that submodules are connected to a specific commit, rather than branch, so when one checks them out originally one must remember to manually create a branch, else if you commit changes they are a "detached head", which is then fixable, but a pain.  

I find Git to be very much "'Oh, you should have used the "engage safety" and "don't_point_at_foot" options when you called the "git new_gun" command'.

 

hmm, that is not my experience with GitKraken. I could work without creating a branch and it would just tell me that I needed to commit the submodule changes.

I did get the detatched head a few times though.

[drjdpowell]

2 hours ago, Neil Pate said:

I did get the detatched head a few times though.

That's what I mean.  You'll fix that problem, but a junior programmer will not know what to do, and just carry on, possibly losing commits if the problem isn't seen in a month.  

[drjdpowell]

Just for info: my recipe to fix a "detached head" is (using SourceTree)

1. Create a temporary branch on the detached head commit (I prefer to name it "GitIsStupid")
2. "Checkout" the real branch it should be on (usually)
3. "Merge" the temporary branch into the current branch (no actual code merge occurs, so this is non-intuitive to me)
4. Delete the now-unneeded temporary branch

Git: making the easy things hard, and the hard things possible.

 

[JKSH]

3 hours ago, drjdpowell said:

Just for info: my recipe to fix a "detached head" is (using SourceTree)

Shorter alternative A, involving a console:

> git branch -f <real_branch>
> git checkout <real_branch>

The first line forces real_branch's pointer to move from its old spot to your current spot.
The second command moves your HEAD from your anonymous branch to your named branch.

Shorter alternative B, involving a strong stomach:

1. Delete <real_branch> (yes, you read that right).
2. Create a branch called <real_branch> on the detached head commit.
3. (If the original <real_branch> tracked a remote branch) In SourceTree's "Branches" nav pane, right-click <real_branch> and click "Track remote branch".

 

3 hours ago, drjdpowell said:

(no actual code merge occurs, so this is non-intuitive to me)

If it helps, think of it as merging the commit histories of the 2 branches, rather than merging code. Its formal name is a "fast-forward merge".

Edited September 10, 2020 by JKSH

[drjdpowell]

If only there was a

> git fast-forward <new branch>

One step, and no scary "-force" or "delete" involved.

[Neil Pate]

5 hours ago, drjdpowell said:

If only there was a

> git fast-forward <new branch>

One step, and no scary "-force" or "delete" involved.

Have you tried GitKraken? I know every harps on about how the only way to use git is from the command line but I don't actually think that is a good way to get to know something as complicated as git. Sure, move onto to the command line but don't start there. Learning a new VCS should happen slowly and mostly painlessly, who has the time to spend getting intimately acquainted with a new tech that does not actually help get the bill-paying project out the door?

[drjdpowell]

Tried GitKraken a bit.  Couldn't see enough improvement over SourceTree to consider a paid product (but I may be missing something).   If I were going command line, I would first look into Gitless, and attempt by Computer Scientists to fix the flaws of Git.  There is a paper on it here: Purposes, Concepts, Misfits, and a Redesign of Git.  

Quote

Abstract of  "Purposes, Concepts, Misfits, and a Redesign of Git"

Git is a widely used version control system that is powerful but complicated. Its complexity may not be an inevitable consequence of its power but rather evidence of flaws in its design. To explore this hypothesis, we analyzed the design of Git using a theory that identifies concepts, purposes, and misfits. Some well-known difficulties with Git are described, and explained as misfits in which underlying concepts fail to meet their intended purpose. Based on this analysis, we designed a reworking of Git (called Gitless) that attempts to remedy these flaws. To correlate misfits with issues reported by users, we conducted a study of Stack Overflow questions. And to determine whether users experienced fewer complications using Gitless in place of Git, we conducted a small user study. Results suggest our approach can be profitable in identifying, analyzing, and fixing design problems.

 

Edited September 11, 2020 by drjdpowell

[LogMAN]

12 hours ago, Neil Pate said:

I know every harps on about how the only way to use git is from the command line but I don't actually think that is a good way to get to know something as complicated as git. Sure, move onto to the command line but don't start there.

I agree that git in its entirety has become very complex. So much even, that they literally have to divide commands into categories... 🤦‍♂️ Talk about feature creep...

However, a typical git user needs maybe 10 commands regularly and perhaps the same amount occasionally for specific tasks (like recovering from a detached head) and edge cases (like rewriting history). I found it actually much easier to just teach those few commands, than to increase the learning curve by adding another tool on top of that. Don't get me wrong, UI tools are very useful - specifically for users that are entirely new to the idea of VCS. Anyone familiar with concepts like branching, merging, and wandering the history of a project, however, should at least consider (and perhaps try for a few days) to work with the command line interface. It's just text (although the stories it tells are sometimes a bit scary) 😄

47 minutes ago, drjdpowell said:

I would first look into Gitless, and attempt by Computer Scientists to fix the flaws of Git.  There is a paper on it here: Purposes, Concepts, Misfits, and a Redesign of Git.

Haven't heard of it, but it is certainly something worth looking into. Thanks for sharing!

[drjdpowell]

 

On 9/11/2020 at 9:41 AM, LogMAN said:

I found it actually much easier to just teach those few commands, than to increase the learning curve by adding another tool on top of that.

TortoiseGit is an interesting middle way between command line and a "full-featured" UI tool, as it mostly just replaces text commands with menu selections, and it can be configured to show the basic few commands (with a submenu for less-used commands):

 

Then on top of commands is the "log", which is a visual representation of the repo.

Edited September 14, 2020 by drjdpowell

[Conner P.]

I use TortoiseGit for most operations, but do frequently reach for the command line, especially when trying to hunt down specific commits. I agree with the others who say it is a pain in the ass but it is better than the alternative of not having source control. I tried SVN for a while since it is NI recomended but having already been exposed to git from line coding I just felt more comfortable with git.

[Rolf Kalbermatter]

On 1/19/2021 at 3:33 PM, Conner P. said:

I use TortoiseGit for most operations, but do frequently reach for the command line, especially when trying to hunt down specific commits. I agree with the others who say it is a pain in the ass but it is better than the alternative of not having source control. I tried SVN for a while since it is NI recommended but having already been exposed to git from line coding I just felt more comfortable with git.

My experience comes from the other side. We have started with SVN some 15 years ago or so and while it has limits it worked quite well for us. There are additional limitations because of the binary character of LabVIEW files, but GIT doesn't add anything to the game there really. I have been exposed to GIT in recent years because of customers using it and also from dabbling in some Open Source projects that use GIT and I have to say the experience is overwhelming at first. SVN certainly has its limits but it's working model is pretty simple and straightforward to understand. And it has always worked reliably for me, which I would consider the most important aspect of any source code control system. One of the reasons Microsoft Source Safe has failed miserably was the fact that you could actually loose code quite easily and the Microsoft developers seemed to have completely lost all motivation to work on those hard to tackle problems.

With GIT I have painted myself into a corner more than once and while there are almost always some ways to do a Baron Munchausen trick and drag yourself out of that corner by your own hair, it's been sometimes a pretty involved exercise. 😀

Edited January 22, 2021 by Rolf Kalbermatter