Hacker News Reader

Learn Git Branching did a really good job of making git easier to understand:

http://pcottle.github.io/learnGitBranching/

If you take that approach and update with precise but plain english vernacular (redundant?) and domain specific examples, then you are halfway there to making it understandable by regular people.

The most important thing to help people really get it is to promote small commits to their work. The real value of git only makes sense when you start making small commits. Having worked as an editor in a past life, having something like cherry-pick and interactive rebase would have been most dope. In a way, maybe editors are the best audience for driving adoptions among writers in general. For professional editors, version control is a painkiller. For writers, it is a painkiller if the writer is an obsessive editor. For those who write and commit once, but don't go back and review commits and refactor, it doesn't provide much value.

Think about how Apple Time Machine made a stab at operating system backups and snapshotting. Was it perfect? No. But it was a step in the right direction.

Loren and others may not solve all the problems right out the gate, but they will lay the groundwork for new approaches to teaching version control to writers and other audiences.

learnGitBranching is a fantastic resource that I didn't know about. Thanks!

Love this site. Hoping people contribute a few more lessons to it in the near future.

Thanks Alex! I'm working on some lessons around push / pull / rebase right now that I think will be super helpful for learning the next steps.

Progress has slowed a bit since work has ramped up, but now that intern season is over I'm expecting to make some progress

Learn Git Branching is best learning tool I ever tried! With this tool and a little practice on the side I was able to learn the basics of git within a couple of hours so that I can confidently branch, merge, push, pull and rebase and I know what I'm doing! Programmers should invert more learning tool like this!

Whoa! Now that's how you teach anything command-line to non-programmers. Someone should do something like this for unix commands and the like.

> In fact, if there are ways to visually simplify git and make it more intuitive for non-programmers, those techniques could wind up making git even better for programmers too.

That's the goal. I want git to handle everything behind the scenes, and everything that the user touches just 'makes sense' - ie its not all that different from what they're already doing. A 'save' button makes a git commit, editing somebody else's content automatically creates a new branch, 'submitting' that content on the new branch creates a pull request .. etc.

You could combine the advantages of git versioning with wiki style collaboration and make a git-wiki like the parent said, but for writers.

Wikipedia is largely prose, but of a nonfiction variety. This would be a good intersection for git, which was born out of code.

You could call it..."geeky"...too bad it wouldn't be for geeks.

This is a really fantastic idea. I can also imagine writers will get a great deal of use out of git cherry pick.

The intersection of git and wikis is interesting, it's one of those things that sounds compelling but then the details usually end up making it hugely complicated. Worth thinking about.

For general writing collaboration I would seriously consider not allowing arbitrary branches. Most people just get confused managing multiple independent outstanding branches that potentially branched from different points in the history.

One restriction could be that each user gets a single branch (their suggested change). As changes get merged into HEAD each user's branch must be rebased (with a click) before they can add more changes to it. From a programming point of view this is restrictive; why can't I suggest two independent features? But keeping track of dependencies is precisely what's hard for people.

> For general writing collaboration I would seriously consider not allowing arbitrary branches. Most people just get confused managing multiple independent outstanding branches that potentially branched from different points in the history.

Yep, absolutely true.

> One restriction could be that each user gets a single branch (their suggested change). As changes get merged into HEAD each user's branch must be rebased (with a click) before they can add more changes to it.

Heavily considering this approach.

Honestly, I think writers could benefit more from the collaborative editing model than the git branching model.

When do writers need to branch their stories/articles into two forks? If they do that, why not just copy the document and work on it there? The large bodies of text don't have the filesystem dependence that programs do; it doesn't matter what the manuscript is called if nothing #include s it or require()s it.

Instead, it can be quite valuable to have a collaborative text editor: your colleagues' changes are shown in real time as they make them. If you go on a plane ride, they're synced when you get more internet access, with conflicts clearly shown and deliminated so you can resolve them simply.

My wife is a novelist.

The collaborative editing would be useful in the later phases of a book -- i.e., working with an editor and copyeditor, it's be great to have a really efficient way to review changes made to the actual text (instead of reviewing a hard-copy with hand-written corrections, and then hoping those corrections are accurately hand-merged into the text...).

But for most of the life of a manuscript, it's just the author working completely solo (from what I've seen). In the standard flow, there's no editor until the book (in a fairly complete and polished draft) is sold to a publisher. A literary agent may read drafts along the way, but normally wouldn't touch the text, just write up higher-level feedback.

On the other hand, the task of designing a narrative that flows well at the scope of a novel is really hard, and can take a lot of large-scale trial and error to improve. She usually does have several "branches" of her current project, as well as large chunks that she has cut from the current draft but doesn't discard (and sometimes may be re-added).

Her first published novel shed more than 300 pages that were never re-added on its way to the final version... it's hard to keep track of all that. It wasn't like "drop this chapter", generally, more like "remove this subplot from the hundred or so places it shows up".

I'm not sure how well the git model would address the problems -- the big problem is scale, and visualizing large structures made up of lots and lots of tiny little words. They are plenty of pain points worth attacking, though, except that most writers don't have much cash to spend on tools.

For something like that you would need a way to mark parts of text, that deal with certain subplots/plots. Like different colors for different plots, but what happens, when they intersect? Or you could use flags, or something like that.

An easy way to trace a plot throughout the novel. Interestingly, a tool, that enables this could even be used by literature students, when analyzing texts for an interpretation (been there, studied that). The only problem with this is copyright and the inability to get your hands on a digital os-/reader-independent format, to work with in the first place.

I worked mostly with texts from medieval times and it was a pain to get hold of (good) digital versions. May be, that this is because language processing approaches are not that widely used in my former field of study.

So to wrap it up - a great tool, enabling authors with this could enable also a better understanding of novels for literature students alike.

"And the main attraction for users over, say, Google Docs, is that your changes don't overwrite others'. The fact that your edits create a "branch", that then others can accept/reject/modify/merge, is a vast improvement in creative collaboration."

This.

Version control is a capital-P Pain In The Ass for group writing projects. Anything that improves the version control problem in collaborative writing solves a very real need. Perhaps not a huge TAM at first glance, but a real need nonetheless.

Haha! Agreed, but like lots of software things--I think that's mostly because the instructions are written by the programmers. I'm management at my company (don't code), but have never had trouble grasping the conceptual issues and intricacies of code, and that makes me really good at teaching it. You just have to contextualize it properly for their perspective. Writers, or anyone that's not a programmer, doesn't care what a git is or how it work technically. They want to know how it will fulfill their wants/needs, and they want big buttons labeled with those solutions. I could teach my grandma to use to the github client if there was a shortcut to it on her desktop.

I love git, but some of the metaphors and inconsistencies it makes are definitely not good and make it much harder to pick up than it should be. I think with the right set of metaphors and ui it can work.