Hi everyone, Thank you for the lively discussion. I've created a github issue https://github.com/swcarpentry/git-novice/issues/340 for further discussion
Please continue the discussion there. Please focus on ways that one can use GUI tools and recommendations (such as https://www.gitkraken.com/). I think the general CLI vs GUI discussion is probably not worth furthering. Cheers, Cam >>> Thomas Ballinger <[email protected]> 09/06/16 10:39 AM >>> 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/blog/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 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
