Re: this additional complexity Rochelle points out is introduced by git GUIs, the sixth git command I generally teach (after git init, add, commit, status, and log) is `gitk --all`. This is a git gui that typically comes with git installations, and critically is essentially a *read-only* GUI. Because it only gives more information about the git graph without providing new ways to interact it, learners find it a useful tool alongside git status and git log for introspecting the current state of their repositories.
Prior to this I spend more time drawing graphs of hypothetical repositories on the board when teaching, but it was more difficult to connect that image with the learner's repository. Tom On Tue, Sep 6, 2016 at 12:31 PM, Rochelle Terman <[email protected]> wrote: > Hi All, > > There appears to be a common assumption being made that "GUI could get > people faster on board to use Git." I would like to gently challenge that > notion. I've taught git using both CMI and GUI and found that the GUI was > confusing and overwhelming to folks. > > The reality is, the majority of beginners cycle through the same 3-4 > commands when using git/hub (add commit push pull). This is how they first > engage with git as a system. A GUI may be easier than CMI when you want to > do more complicated tasks, but for a simple workflow, the command line is > the better choice pedagogically. A GUI has too many bells and whistles, and > distracts from this simple workflow. > > Just my two cents, > Rochelle > > > On Tue, Sep 6, 2016 at 8:48 AM, Juan Nunez-Iglesias <[email protected]> > wrote: > >> Hi all, >> >> Sorry, in all honesty I didn't mean to start a flame war; I just thought >> as instructors we would agree on this point. =) Three points about *why* I >> think it's broken: >> >> 1) the entertaining and informative Git Koans: http://stevelosh.com/bl >> og/2013/04/git-koans/ >> >> 2) a couple of additional examples from my own observation: >> >> "git reset HEAD <file>" to unstage (huh???) >> "git push --set-upstream <remotename> <branchname>" to set a remote >> tracking branch, but "git fetch <remotename>; git checkout --track >> <remotename>/<branchname>" to set a local branch to track a remote. >> >> I consider git alias a hack, not a solution, because it's additional load >> for the learners and it is not portable. >> >> 3) I saw once a post (that I can't currently find) comparing the current >> state of the git interface to the state of imperative programming before >> goto was phased out: powerful, yes, but hard to follow and easy to mess up >> with. Eventually, the git UI, both command line and GUI, will converge on >> something minimal that *only allows* the patterns that programmers have >> settled on as useful. (e.g. Git flow, and GitHub flow.) >> >> Titus's point about HPC is a good one. I'll point out that when I taught >> with GUIs, I mirrored everything in the command line as well. I also >> explicitly recommended GUIs that stayed close to the command line model. >> >> Juan. >> >> On 7 September 2016 at 12:53:50 AM, Ivan Gonzalez ([email protected]) >> wrote: >> >> I think there are a few good points in this thread that justify why we >> teach the Git on the command line: >> >> 1. Different GUIs offer different experiences and would be hard to agree >> on one. >> 2. Git CLI is used to reinforce what's learned during the Unix shell >> lesson. >> 3. The very important use case of a remote machine (cluster, AWS, ...) >> with only terminal access. >> >> I agree that a GUI could get people faster on board to use Git, but I >> also think they'll have more trouble >> understading the model or switching to another tool later. >> >> I might choose teaching a GUI for a shorter lesson, or if the Unix shell >> is not being covered, or if there is a >> group of people that is going to work together and the whole group agrees >> on using the same tool and can help >> each other in the long run (help for the GUI tools is scarce and often >> falls back to CLI magic). >> >> Best, >> >> Ivan >> >> On Tue, Sep 6, 2016 at 9:34 AM, P Lijnzaad <[email protected]> wrote: >> >>> I concur with Juan Nunez-Iglesias, the git command line interface is >>> horrendously complicated (or should I say inconsistent *), even for >>> experienced programmers. This is of course partly due to the git data >>> model, which is also very complicated (with >= 5 places to mentally keep >>> track of things: working copy, index, repository, remotes, and stash). I >>> had good experiences with Easy Git (eg; see >>> https://people.gnome.org/~newren/eg/) when transitioning from svn. But >>> it is aimed at exactly that (svn -> git), and I'm not sure it's maintained >>> anymore. To further the goal of reproduceable research, anything that makes >>> it easier to use git should be welcomed. >>> >>> (*) of course, *Consistency is the last refuge of the unimaginative* >>> (Oscar Wilde), but still ... >>> >>> Philip >>> >>> >>> >>> _______________________________________________ >>> Discuss mailing list >>> [email protected] >>> http://lists.software-carpentry.org/listinfo/discuss >>> >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> http://lists.software-carpentry.org/listinfo/discuss >> >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> http://lists.software-carpentry.org/listinfo/discuss >> > > > > -- > Rochelle Terman, Ph.D. > Stanford University > > email: [email protected] > www.rochelleterman.com > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.software-carpentry.org/listinfo/discuss >
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
