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 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
