How Wired Published Its GitHub Story on GitHub

#1

Post by llambda » Fri, Feb 24, 2012, 11:38 PM UTC

How Wired Published Its GitHub Story on GitHub
wired.com

Re: How Wired Published Its GitHub Story on GitHub

#2

Post by mcrider » Sat, Feb 25, 2012, 1:22 AM UTC

Merging people's writing together doesn't seem to be as obvious as merging people's code together -- code is a means to an end, so whatever is the best solution should be merged into master. Writing is subjective, so if your paragraphs cause a merge issue, its not so simple to choose a winner.

Re: How Wired Published Its GitHub Story on GitHub

#3

Post by krallja » Sat, Feb 25, 2012, 1:49 AM UTC

mcrider wrote: post #2

Merging people's writing together doesn't seem to be as obvious as merging people's code together -- code is a means to an end, so whatever is the best solution should be merged into master. Writing is subjective, so if your paragraphs cause a merge issue, its not so simple to choose a winner.

Pull request:

- its not so simple to choose

+ it's not so simple to choose

Re: How Wired Published Its GitHub Story on GitHub

#4

Post by ghayes » Sat, Feb 25, 2012, 2:29 AM UTC

I'd contrast this situation to Wikipedia, which allows unfettered access to collaboration. The benefit of MediaWiki is that people can build their changes directly on previous changes, being continually pulled into master. Alternatively, Wikipedia suffers from authorities having less weight than experienced editors with little domain knowledge (and constant fights against vandalism, esp. on trending articles).

There is a likely a middle-ground between Wikipedia's open editing, and GitHub's "what does it really mean to fork a story and make a pull request." Interesting experiment none-the-less for Wired.

Re: How Wired Published Its GitHub Story on GitHub

#5

Post by rcthompson » Sat, Feb 25, 2012, 3:32 AM UTC

mcrider wrote: post #2

Merging people's writing together doesn't seem to be as obvious as merging people's code together -- code is a means to an end, so whatever is the best solution should be merged into master. Writing is subjective, so if your paragraphs cause a merge issue, its not so simple to choose a winner.

Well, basically, in the case of prose in version control, you don't want automatic merges for anything more than simple grammar or punctuation. Other than that, there's not really that much different.

Re: How Wired Published Its GitHub Story on GitHub

#6

Post by AncientPC » Sat, Feb 25, 2012, 3:34 AM UTC

mcrider wrote: post #2

Merging people's writing together doesn't seem to be as obvious as merging people's code together -- code is a means to an end, so whatever is the best solution should be merged into master. Writing is subjective, so if your paragraphs cause a merge issue, its not so simple to choose a winner.

At the same time it solves a collaboration issue that is limited to always online services like Google Docs.

I remember my distributed computing professor checking out his LaTeX paper from a Subversion repo that had something like 2000+ commits between himself and other collaborators.

Re: How Wired Published Its GitHub Story on GitHub

#7

Post by mhartl » Sat, Feb 25, 2012, 3:57 AM UTC

krallja wrote: post #3

mcrider wrote: post #2

Merging people's writing together doesn't seem to be as obvious as merging people's code together -- code is a means to an end, so whatever is the best solution should be merged into master. Writing is subjective, so if your paragraphs cause a merge issue, its not so simple to choose a winner.

Pull request: - its not so simple to choose + it's not so simple to choose

You can put in a couple of spaces before each line to make the diff look even better:

  - its not so simple to choose
  + it's not so simple to choose

Re: How Wired Published Its GitHub Story on GitHub

#8

Post by mmahemoff » Sat, Feb 25, 2012, 5:11 AM UTC

mcrider wrote: post #2

Merging people's writing together doesn't seem to be as obvious as merging people's code together -- code is a means to an end, so whatever is the best solution should be merged into master. Writing is subjective, so if your paragraphs cause a merge issue, its not so simple to choose a winner.

This would imply wikipedia and other wikis don't work. It's really the next step in evolution beyond the centralized wiki.

Re: How Wired Published Its GitHub Story on GitHub

#9

Post by istvanp » Sat, Feb 25, 2012, 5:22 AM UTC

mcrider wrote: post #2

Merging people's writing together doesn't seem to be as obvious as merging people's code together -- code is a means to an end, so whatever is the best solution should be merged into master. Writing is subjective, so if your paragraphs cause a merge issue, its not so simple to choose a winner.

You also have to consider that conventional version control was designed specifically for programming code where diffs are done per line (as each line in programming typically serves a single purpose, e.g. assigning a variable). With written language however, that is typically less true. You would only put line breaks after paragraphs and such. Most of the line breaks end up being automatic margin wraps which serve no purpose other purpose than helping readability... Unless you work in version control. What you end up doing is making each paragraph a single line which destroys readability if you don't have virtual text wrapping. Case in point: https://github.com/WiredEnterprise/Lord-of-the-Files/blob/ma...

Re: How Wired Published Its GitHub Story on GitHub

#10

Post by mhartl » Sat, Feb 25, 2012, 5:40 AM UTC

mhartl wrote: post #7

krallja wrote: post #3

Earlier quoted context omitted.

Pull request: - its not so simple to choose + it's not so simple to choose

You can put in a couple of spaces before each line to make the diff look even better: - its not so simple to choose + it's not so simple to choose

Dear downvoter: this was a simple, helpful comment about the formatting supported by this site, and it didn't deserve your ire. Please go visit a site other than Hacker News. You are not welcome here.