On Thu, 10 Mar 2016 15:03:23 -0500 Maxime Boissonneault <[email protected]> wrote:
> My experience is that in a workshop, people become actually > interested in git when they pair up and start collaborating and > working on the same project *at the same time*. > > I would say that this is the biggest strenght of Git versus SVN. > SVN is just fine if you are working alone, or if you are not working > at the same time as others in your group. But once you start getting > conflicts, this is where Git starts shinning. I have to totally disagree here. Git (or mercurial, or whatever distributed version control system) is *much* better than SVN for working alone. In fact I mostly work alone and for me, coming from SVN, git was totally a game changer. There's nothing like "mkdir /my/project; cd /my/project; git init" in SVN; this is like magic from a SVN point of view. It's version control for free! > A good approach might be to start with the Github web UI rather than > with git commands, and then go down to the commands. The question is, > is it possible to teach the concepts of push/pull/merge before the > concepts of add/commit ? > > I'm not sure it is. Surely it isn't. You can not push before commiting. So the a,b,c is init, add, commit, in your local /my/project folder. Everything builds on this and comes later. Inigo > > Maxime > > > > Le 2016-03-01 08:23, Greg Wilson a écrit : > > Re-reading Arjun Raj's post > > > (http://rajlaboratory.blogspot.ca/2016/02/from-reproducibility-to-over.ht > ml), > I've got a couple of thoughts. First, I think some of the > disparaging > comments on Twitter and elsewhere were unhelpful: > they're unlikely to > get the author to change his mind, and it > discourages other people > from talking about what they do. > > > > Second, we all make the same decision he does most of the time. For > > > example, people tell me I'd be more productive if I used Haskell > > > > instead of Python, or the Atom editor, or Slack, or blah blah > > > > blah. In > almost every case, I compare the time I have to make > > > > the change, the > time it'll take for the change to pay off, > > > > and the likelihood of the > technology's fans being right about > > > > the benefits, and decide "nope" - > and I'm willing to bet you > > > > do too. I'm probably wrong in some cases, > but with so many > > > > new things flying around, I can't be certain which > ones, and > > > > hey, deadlines... > > > > So here are my questions: > > > > 1. What's LD50 [1] for version control, i.e., how long would people > > > have to use it (or watch someone else use) for half of them to be > > > > convinced it's worth adopting? I think LD50 for the Unix shell > > > > is > less than an hour, because that's how long it takes us to > > > > introduce > pipes and loops, which most workshop participants > > > > find compelling. At > what point do at least half of workshop > > > > participants find Git > compelling enough to actually adopt it? > > > > 2. What should we say to someone like Arjun? It's clear from his > > post > that he knows the arguments in favor of version control, and > > has > actually tried it. It's also clear that he cares about doing > > things > well - what can we do to convince someone like that? > > > > Thanks, > > Greg > > > > [1] https://simple.wikipedia.org/wiki/LD50 > > > > _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
