git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philip Oakley <philipoakley@talktalk.net>
To: _g e r r y _ _l o w r y _ 
	<gerry.lowry@abilitybusinesscomputerservices.com>,
	git@vger.kernel.org
Subject: Re: if YOU use a Windows GUI for Git, i would appreciate knowing which one and why
Date: Mon, 5 Nov 2018 12:26:08 +0000	[thread overview]
Message-ID: <2f1855a2-58c4-d7d6-cd62-41ce877f11b6@talktalk.net> (raw)
In-Reply-To: <1b8a01d47466$9775c130$c6614390$@abilitybusinesscomputerservices.com>

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@laposte.net/ 
on the release management issue
> 
> 
> if you are uncomfortable replying to git@vger.kernel.org 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@abilitybusinesscomputerservices.com
> 

Education is the answer, especially for the lower quartile.
Kruger & Dunning. "Unskilled and unaware of it" 1999.

-- 
Philip

  reply	other threads:[~2018-11-05 12:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-04 17:48 if YOU use a Windows GUI for Git, i would appreciate knowing which one and why _g e r r y _ _l o w r y _
2018-11-05 12:26 ` Philip Oakley [this message]
2019-04-28  9:33   ` David Aguilar
2019-05-01 18:12 ` Jakub Narebski
2019-05-01 18:42 ` Martin Langhoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f1855a2-58c4-d7d6-cd62-41ce877f11b6@talktalk.net \
    --to=philipoakley@talktalk.net \
    --cc=gerry.lowry@abilitybusinesscomputerservices.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).