From: Philip Oakley Date: Sat, 03 May 2014 20:24:44 GMT Subject: Re: Pull is Mostly Evil Message-ID: In-Reply-To: <20140502225342.GQ9218@google.com> From: "Jonathan Nieder" Sent: Friday, May 02, 2014 11:53 PM > Hi, > > Philip Oakley wrote: > >> That assumes that [git pull] doing something is better than doing >> nothing, >> which is appropriate when the costs on either side are roughly >> similar. > > I think the conversation's going around in circles. I agree it's going around, but it's a non-exact recurrence. Issues are being surfaced. > > Potential next steps: > > a. Documentation or test patch illustrating desired behavior > > b. More traditional formal design doc explaining desired behavior and > the thinking behind it ("problem", "overview of solution", > "alternatives rejected", "complications", "example", "open > questions"). > > c. Implementation patch > > d. Someone takes an existing patch and figures out the next step > toward getting it ready for application. > > My preference is for (a), I guess. I disagree about the leap to the presentation & discussion of a 'solution' in these awkward scenarios (the old joke about "if I were you I wouldn't start from here", when asking for directions tends to apply). This is the same point made by Brooks in the 'Mythical Man Month'. A leap to code is no guarantee of success. > > The point being that something more concrete (code or a design doc) > makes it easier to avoid talking past each other. And having > something concrete to edit makes the stakes clearer so people can make > it incrementally better without being distracted by unimportant parts. We've had Junio's training wheel, and now Filipe's n'th attempt at code examples, so my bad code wouldn't help ;-). As a systems engineer I've seen these confusions quite a few times in different guises. I tend to fall back to P Checkland's "Systems Thinking, Systems Practice" model of the various processes that have to go on [1] to improve the situation (note he doesn't expect a solved solution in most cases, just an improvement in the situation). At the moment most of the discussion is in the "unstructured" parts of the processes. He also identifies 6 elements 'CATWOE' [2] that need to be considered when studying these problems. Most of the discussion/arguments here are about the different 'Weltanshaung's" (world views) of the contributors. In terms of the new user pull problem, what needs to be modeled is the new user's and their weltanshaung, not how we ('experienced' users?) might 'solve' the problem. The pull problem is, I believe part of the bigger problem of the mind-set shift required for the transition to a DVCS for most new users. Git has grown organically, so still has some soft (unclear) edges, which probably needs more than just a transition plan for Filipe's pull changes, and its choice of the final default (or lack of). For example, if users aren't understanding the differences between remote branches, remote tracking branches, and branches, which is part of the pull problem; have we made it easy for them to understand? [They already have to comprehend the 'staging' concept, so are already cognitively fully loaded]. For the branch type example, some cleaner naming may help, such as: 'remote branch', 'Tracking branch', and '(local) branch', which excludes the noiseword 'remote' from 'Tracking branches' (my deliberate 'T' emphasis). Though that does still leave the confusion between remote servers and remote repos, where the latter may actually be local, and if a file path, be the local '.' repo itself! > > Thanks and hope that helps, Sorry if this went off at a tangent, but I believe it's important to get to the bottom of the new user problems, which are deeper than just a few command defaults. > Jonathan > -- Philip -- [1] http://40qx6d15vq6j25i83v3ks8nxfux.wpengine.netdna-cdn.com/files/2012/08/seven-steps2.gif or http://portals.wi.wur.nl/spicad/?Soft_Systems_Methodology Checkland's 7 Steps. [2] CATWOE: customers, actors, transformation, weltanshaung, owners, environment.