Hi Gerry,
I'll give my view, as someone approaching retirement, but who worked as
an Engineer in a mainly Windows environment.
On 04/11/2018 17:48, _g e r r y _ _l o w r y _ wrote:
PREAMBLE [START] - please feel free to skip this first section
Forgive me for asking this question on a mailing list.
stackoverflow would probably kill such a question before the bits were fully saved to a server drive.
Let me explain why i am asking and why i am not being a troll.
[a] i'm "old school", i.e., > 50% on my way to being age 72 [born 1947]
8 years behind..
[b] when i started programming in 1967, most of my work input was via punched cards
'69, at school, post/compile/run/wait for post; 1 week
(Maths club)
[c] punching my own cards was cool
Pin punching individual chads ;-)
[d] IBM System/360 mainframe assembler was cool and patching previously punched card encoded machine code output was a fun risky but
at times necessary challenge.
Eventually the 370 at university.
[e] using command windows and coding batch files for Gary Kildall's CP/M and the evil empire's PC/MS-DOS was how i accomplished many
tasks for early non-GUI environments (i still continue this practice even in Windows 10 (a.k.a. please don't update my PC O/S behind
my back again versions of MS Windows)).
Engineer in electronics; software was an interlinked part of electronics
back then....
[f] my introduction to Git was via a command line based awesome video that has disappeared (i asked this community about that in a
previous thread).
Discovered in 2011 via 'Code News' article - Spotted immediately that it
solved the engineers version control issue because it 'distributed' the
control. I've tried a few of the Gui's.
BOTTOM LINE: virtually 100% of my Git use has been via Git Bash command line [probably downloaded from https://git-scm.com/]
For me, and i suspect even for most people who live with GUI platforms, [a well kept secret fact] using the keyboard is faster than
using the mouse [especially when one's fingers are already over one's keyboard-example, closing one or more "windows" via Alt+F4.
Also for me, i am happy to change some code and/or write some new code, Alt+Tab to Git Bash frequently, ADD/COMMIT, then Alt+Tab
back to whatever IDE i'm using [mostly LINQPad and vs2017]; i know that's quite a bit schizophrenic of me-command line Git but GUI
IDE.
PREAMBLE [END]
----------------------------------------
QUESTION: if YOU use a Windows GUI for Git, i would appreciate knowing which one and why
i have been asked to look at GUI versions of Git for Windows.
I presume that this is for a client who isn't sure what they want
http://www.abilitybusinesscomputerservices.com/home.html
https://git-scm.com/download/gui/windows currently lists 22 options.
That's nearly as bad as choosing a Linux distro ;-)
if i had more time left in my life and the option, because of my own nature, i'd likely download and evaluate all 22 - Mr.T would
pity the fool that i often can be.
CAUTION: i am not looking for anyone to disparage other Git Windows GUIs.
Let me break down the question into 4 parts:
[1a] Which do you prefer: Git GUI, Git command line?
I use the three parts provided as part of regular Git and Git for
Windows, that is git-gui, gitk and git cli in a terminal (mintty)
[1b] What is your reason for your [1a] preference?
I have been in a general Windows environment for decades. The Gui format
with single buttons/drop downs that do one thing well, without finger
trouble side effects, is good in such environments. One cannot be master
of everything.
The cli is good for specialists and special actions, especially
precision surgery. The key is to avoid the "the surgery was a success
but the patient died" results.
[2a] if applicable, which Git GUI do you prefer?
git-gui and gitk are now the only two I use.
[2b] What is your reason for your [2a] preference?
Many of the other Gui's hide the power of Git and its new abstraction of
no longer actually being about "Control" (by 'management'). Now it is
about veracity. If you have the right object ID (sha1/sha256) you have
an identical original [there are no 'copies', all Mona Lisas with the
hash are the same]. Management can choose which hash to accept upstream.
Most other Gui's try to hide behind the old school Master-copy view
point that was developed in the 19th century for drawing office control.
If you damaged the master drawing the ability to make things and do
business was lost. Protecting the master drawing was everything. They
were traced before they went to the blue print machine. Changes were
batched up before the master could be touched (that risk again).
Too may Gui's (and their Managements!) still try to work the old way,
loosing all the potential benefits. They are still hammer wielders
looking for nails, and only finding screws to smash.
I've heard reasonable things about SmartGit but that costs money so I
haven't tried it. I tried TortoiseGit and GitExtensions, but gave up on
them as they would (to me) hide the real operations behind old concepts.
The one are that could be improved is having manuals for the two guis,
and a better explanation, with practical examples, for the gitk viewer,
which has far more power than I have fully delved into.
Ultimately it is a management problem. As a systems engineer, what needs
to be researched is the mind set - weltanschauung of the client, their
management style and its operations.
See the recent discussion with Nicolas Mailhot
https://public-inbox.org/git/1290947539.4254.1508496039812.JavaMail.zimbra@xxxxxxxxxxx/
on the release management issue
if you are uncomfortable replying to git@xxxxxxxxxxxxxxx please feel free to reply directly to my e-mail address.
i look forward to hearing from members of this Git community.
Thank you for reading and thank you for your valuable time.
gerry (lowry)-wasaga beach-ontario-canada
gerry.lowry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Education is the answer, especially for the lower quartile.
Kruger & Dunning. "Unskilled and unaware of it" 1999.
--
Philip
