Linux - partly off topic - searching for a new workflow

[Warfley]

TortoiseGit is not good. There are some git GUI tools which are not terrible, but they are all proprietary. If that is not an issue GitKraken is Ok-ish.

But the problem is that git is designed through and through to be a command line tool, meaning it's not just a program with discrete operations, which can be easily integrated into a GUI, it's a set of commands that are intended to be combined and chained as somewhat of a language to interact with your repository. This is something that GUI tools are fundamentally not really capable of map intuitively.

For example you work on a repository where someone made a force push. In that case you want to just fetch the data, inspect what was changed, was it just an amendmend to an existing commit, was it a reabse, was something deleted from the history, or a full restructuring of the branch, and in each of those cases you need to do something different. A GUI tool fundamentally cannot do that, it will usually see that fast forawrd was not possible and either ask you if you want to do a 3 Way Merge or a reset, the former can completely undo rebases, deletions or restructuring, the latter can completely nuke your whole work.
This is simply not something that can be easily displayed in a message dialog with a discrete number of options.

I had so many headaches already in projects where developers used GUI git tools and nuked branches, reverted changes etc.
If you want to use git, learn to use git. There are no shortcuts and no fancy GUI software that makes it easy to use without getting to know the underlying system

[Thaddy]

I recommend to start with

Code: Bash  [Select][+][-]

1. man giteveryday

This skips any super-advanced features and shows you the basic set of useful commands for beginners.
There are many real world examples in this man.
It is how I started with git after the move from svn, which I, admittedly, did not like very much at the time.
No longer true: git is much better, well, flexible, except maybe for your own local repositories.
There are many books about git, but you can simply start with the man.

[Thaddy]

TortoiseGit is not good. There are some git GUI tools which are not terrible, but they are all proprietary.

Yes, agree with the "not good" part, not with the GUI part.
Nope. Not all, not at all.
https://git-scm.com/downloads/guis?os=linux
Take your pick.
I only use it from the command line, though.

[cdbc]

Hi
@Thaddy: man giteveryday is excellent advice =^ (<- thumbs up)
For those of you who don't feel familiar with man-pages, attached is a text-file representation of those pages...
Regards Benny

[Thaddy]

@cdbc

As suggested on the development page, for FreePascal you need
just a one time git clone and subsequently a recurring git pull every week or so.
I only do a rebase if Warfley has anything interesting and I have to apply a patch to test..

[cdbc]

Hi Thaddy
Same as I do, mind you I only pull when I feel like it, not on a weekly basis, 'cause stability is more important to me than all the new shiny gizmos, that I don't have time to figure out anyway... (I'm building a new terrasse/deck for  the mrs. - pheewww)
Regards Benny

[Martin_fr]

TortoiseGit is not good.

That depends...

It does make some alternation to how some git features a wrapped, it still shows that it comes from svn. That will affect people who make use of the index, and add stuff, but commit much later (in the added form, ignoring the worktree)

It also doesn't expose all features.

But it gives a good base line to work with. And it is well integrated into the OS (for people who like to call it from the context menu of the windows explorer).
Actually, if you don't access it via windows explore, then you are indeed probably left with very very little.

One thing I was missing, but able to tweak via the registry was a custom argument to "git log" (viewing all branches, except a list of filtered out).

For example you work on a repository where someone made a force push. In that case you want to just fetch the data, inspect what was changed, was it just an amendmend to an existing commit, was it a reabse, was something deleted from the history, or a full restructuring of the branch, and in each of those cases you need to do something different. A GUI tool fundamentally cannot do that, it will usually see that fast forawrd was not possible and either ask you if you want to do a 3 Way Merge or a reset, the former can completely undo rebases, deletions or restructuring, the latter can completely nuke your whole work.
This is simply not something that can be easily displayed in a message dialog with a discrete number of options.

Well ok, with command line you can have a script, that contains your favourite (re-)actions.
Though that difference between commandline and gui is not git specific.

But otherwise if I do "git pull" or "git fetch" or "git remote update" from commandline, then it will also download, and then try either ff or rebase depending on my "git config", and if that doesn't work, it leaves me with my old state. So does the GUI (at least Tortoisegit on any repo I have used it with).

So then on the command line, I also have to deal with the forced update. Exactly like on the GUI.

And on the GUI I can also make other choices. Once I said "do nothing, leave me with the diverted branches", then I can perform any operation that git has. (Assuming the GUI has an implementation that provides complete access to all git commands)

Besides:

the latter can completely nuke your whole work.

No, it can and does not.

Well, that is unless you mean:
- Not yet committed changes in the worktree  (or index: added but not committed).
- You keep ignoring that something went wrong, for weeks until it then eventually actually gets "nuked"
- You do a "prune" (gc) to confirm that you want your accident to be unrecoverable.

By default, your local branch (which is what you most likely stand to "reset" by accident) has a reflog => and that saves the old state for 6 weeks. (You can make that longer).
So you have 6 weeks to restore your work, if you indeed made a bad decision and did something that "reset" your branch.

Even if you don't have a reflog, git does not remove the "loose objects" for 2 weeks. So within those 2 weeks you can use "git fsck" to find those objects and restore them (that however is a lot of work... / so better go with the reflog).

And to be clear, if someone isn't going to look at the result of their actions (and not noting something went wrong)... If they don't do that, not even when using a GUI that - if nothing else - does make it easy (easier) to look at a log and associated diffs)... Well, then that person most certainly would not check the result of what they did, if they had used command line.

I had so many headaches already in projects where developers used GUI git tools and nuked branches, reverted changes etc.

And people using the command line do never make mistakes? Well, in my experience they do. When something does not work as they want, they start using "-f" and override stuff. Calling "git reset" is easy enough. Creating a branch with force too. And with "git switch" all it takes is an uppercase -C, that can happen very easily, even by mistake instead of the lowercase -c

And as for any statistical relevance between those errors, and GUI users: Are you sure they show the right cause vs effect relationship.

If (assumed for arguments sake) GUI user make more mistakes, does that mean:
- the GUI leads to mistakes
- people who don't want to spend time to understand are more likely to use GUI
?

Because the latter means, if they did not have a GUI, the still would do minimum investment to understand, and they would make the errors using command line too.

If you want to use git, learn to use git.

Yes, of course. Learning and understanding it is important.

But you can do that with a gui too. You just have to be willing to understand what you actually have the GUI do.
But then on the command line, you have to also be willing to learn.

[Warfley]

Well ok, with command line you can have a script, that contains your favourite (re-)actions.
Though that difference between commandline and gui is not git specific.

But otherwise if I do "git pull" or "git fetch" or "git remote update" from commandline, then it will also download, and then try either ff or rebase depending on my "git config", and if that doesn't work, it leaves me with my old state. So does the GUI (at least Tortoisegit on any repo I have used it with).

So then on the command line, I also have to deal with the forced update. Exactly like on the GUI.

There are two kinds of GUIs for warpping command line tools. Those that just wrap the primitives, like the git gui that is shipped with git for windows, with those things you are completely right, there is not much of a difference. But these tools are either incomplete or hardly usable, because they need to encode all the options and combinations of the command line tool and replace the need of typing with an overwelmingly cluttered gui of dozens of checkboxes, buttons and co. Also there is absolutely no benefit for beginners as these GUIs have exactly the same complexity as the command line interface, just tend to be incomplete (because the commandline has so many options that not all will be included)

The other kind of GUI application is like Tortoise Git or Git Kraken, which try to streamline git workflows into GUI processes. Here they make deliberate decisions on what command is executed when, which imposes massive restrictions on what the user can (easily) do and often get the user in some weird situations if anything does not happen as the designers of the GUI have forseen.

Well, that is unless you mean:
- Not yet committed changes in the worktree  (or index: added but not committed).
- You keep ignoring that something went wrong, for weeks until it then eventually actually gets "nuked"
- You do a "prune" (gc) to confirm that you want your accident to be unrecoverable.

Of course if you don't do a prune the commits might still be there. But I am talking explicitly about the situation where someone is so inexperienced with git that they don't know what a reset is and accidentally did a reset because when the GUI application encountered an error it had two buttons, 3 way merge and reset and they decided to click reset because they thought this will get it back to their previous state.

And people using the command line do never make mistakes? Well, in my experience they do. When something does not work as they want, they start using "-f" and override stuff. Calling "git reset" is easy enough. Creating a branch with force too. And with "git switch" all it takes is an uppercase -C, that can happen very easily, even by mistake instead of the lowercase -c

And as for any statistical relevance between those errors, and GUI users: Are you sure they show the right cause vs effect relationship.

If (assumed for arguments sake) GUI user make more mistakes, does that mean:
- the GUI leads to mistakes
- people who don't want to spend time to understand are more likely to use GUI
?

Well it's much easier to accidentally click a button "reset" than it is to accidentally type in "git reset --hard origin/branchname". With a command line you must actively seek out what you are doing in order to type things up. In a GUI that just presents buttons to you you can just click.
This is specifically a problem because most git GUI tools are sold under the premise that they make git easy and that you don't need to learn the complex command line tools. But thats the fallacy here, if you don't want to learn how git works internally, you will end up in situations as described above. And if you want to learn how git works, the best way is to use the command line where every command you write gives you immediate feedback, where when you mistype you get suggestions what you might wanted to type, and where the program gives very useful hints in every command.

If you decide to use a GUI afterwards, thats fine, even though I would argue that if you know what you are doing the CLI will be always faster and more comfortable, but recommending beginners a GUI (especially if it has very specialized workflows) because they don't need to learn raw git that way is just a recipe for disaster

[Martin_fr]

To summarise: It's not GUI in particular that will get you to make error that lead to loss (down the road).
It's a subset of GUIs, that are badly designed.

Tortoise has never ask me that particular question. So I never had that danger.

Of course it has "reset" in the context menu. So if I am blindly looking for an option... Then I will pay the price.
But to that I uphold, command line is not much difference. At least from what I observe. Few people in such a situation are studying the manpage (as they don't know which "git xyz" command they need the manpage for). Instead the most often taken course is stackoverflow (or similar), and that way it is fairly easy to get a "git reset ....". (I have seen cases exactly like that)

I started on a mix of GUI and command line, and despite looking through manpages,  I did make mistakes in the first few month of learning (and a more than fair share of them from commandline). I don't recall all of them. But they ended in me having to backup, delete, and create a new repo with whatever files I had managed to save (and loss of history).

So I can attest from my own experience, and from that of others whom I have helped => commandline does not prevent getting stuck. Not a bit.
Getting stuck is part of the learning.


I do agree so, certain more specialized task will require command line (or be easier on cmd line). I don't see any point in putting every last option behind a GUI.

But, all the day by day stuff, can be wonderfully done via GUI.

- A visual log, with the ability to click one of the changed files to see the diffs, rather than to have to type the name of the file on the cmd line.
- A tool to add/commit, to allow inspection of the diffs, in the same "by click" manner.
- A visual blame tool
- even basic interactive rebase => to quickly select the branches involved. And arrange the picked commits (again being able to see diffs "by click")

Sure a good shell can reduce the typing a lot. But it still leaves you with toggling between shells, if you hold the log in one shell, and use another to view diffs for some entry on the log...

[Warfley]

Of course it has "reset" in the context menu. So if I am blindly looking for an option... Then I will pay the price.
But to that I uphold, command line is not much difference. At least from what I observe. Few people in such a situation are studying the manpage (as they don't know which "git xyz" command they need the manpage for). Instead the most often taken course is stackoverflow (or similar), and that way it is fairly easy to get a "git reset ....". (I have seen cases exactly like that)

My main experience was leading a team where no one had experience with git except for me, and it was a really nice case study of the differnt UI tools. I had people use Tortoise Git, the Github git tool, GitKraken and some used the command line tool. And from my experience those that expressly wanted to learn how to use the command line tool and read up on that had the least problems and were most willing to learn. When the ones using the GUI fucked something up and I had to fix it, they didn't even bother trying to understand what I do because they felt like they won't be using the cli anyway so why bother checking what I am doing there.

Again, if you want to learn git, you should learn all of the git commands and their options, and the best way for doing this is the command line.

- A tool to add/commit, to allow inspection of the diffs, in the same "by click" manner.

Have you tried patch adding (git add -p)? This will show you each of the changes and let's you decide on a change by change basis if you want to stage, discard it or just ignore it.

[Martin_fr]

those that expressly wanted to learn how to use the command line tool and read up on that had the least problems and were most willing to learn.

Ah, but that is what I meant by cause and effect.

- The GUI did not cause people to make more errors.
- It was chosen by people who were more error prone to begin with.

I.e. people who wanted to short circuit the learning (leading to them making more errors) wanted to use the GUI.
But, if people who would not proper read up, would have been given the command line, I would expect it likely they would have failed too.
Trying to learn (and really understand) git from its manpages (or even some real tutorial), is much more time consuming than searching for a few "ready to use examples". Only the "ready to use examples" will likely get you to the same mistakes that were made using the GUI.

If you take 2 people, who are equally willing to do the learning. And who both actually invest the time into learning, then I would not expect that the choice GUI vs Cmd-line had a huge impact.


Well, yes. Some GUIs may have bad design, and mislead...
But, even the command line git utility has bad design (less in terms of misleading, more in terms of memorize-ability), when it comes to naming of some of the commands. That is why some of the GIT team members started to replace parts of it (introducing "git switch"). Unfortunately, it's not perfect either, and the efforts into it have stalled over time... (apparently).

[Martin_fr]

Just to say: git is often described as Swiss army knife. It is not. It is more like that weapon from 5th element (search youtube for "5th element red button". You need to learn it, or you get harmed.

[CM630]

There was CVS, then SVN, now another fashion - GIT...
GIT has some benefits for ultaparanoids, but is it worth learning it ? Maybe something new and trendy will come up in September...

[Warfley]

There was CVS, then SVN, now another fashion - GIT...
GIT has some benefits for ultaparanoids, but is it worth learning it ? Maybe something new and trendy will come up in September...

Git is around for 20 years now and is the industry standard for like 10-15 of those years. And there have been other (and in some ways definitely better) approaches liker Mercurial, but git is so well established by now, I do not think that it will be gone anytime soon. If it dies out it will be like SVN a process of years if not decades. So if you learn git today you'll be good for probably the next decade