4

I'm toying with the idea of providing some kind of Git access to resources used by a SaaS application to it's users. This will allow users to edit and push content through the Git interface as well as through the application's native web-based interface. My main concern is how to reconcile merge conflicts when a user edit's the content in the web-based interface (I'm not so concerned about merge conflicts from the Git interface since Git and their Git client should handle that). This is very similar to how GitHub allows both Git-based and web-based access to their Wikis, and I'm curious how they handle this situation as a pattern for others to follow when providing both web-based and Git-based access to content.

If a user goes to edit a Wiki page on GitHub through the web interface and another user pushes a change to the Wiki repository branch before they finish, what happens when they save their changes? Does it use a "last one wins" or a "sorry, redo all your changes on the new version"?

I found a related SO post that discussed the problem in general, but I'm very curious how GitHub specifically handles it since it's backed by Git which already has some merging capabilities baked in.

Community
  • 1
  • 1
daveaglick
  • 3,600
  • 31
  • 45
  • I think the best is to try by yourself on a sample github repo – CharlesB May 11 '12 at 15:27
  • 1
    @CharlesB - I tried some different scenarios but could never get it to show me anything in the web interface. I assume it was either auto-merging the differences (which appeared to happen in most cases) or otherwise resolving by choosing one or the other, but that doesn't really give me a definitive answer since my few tests probably didn't cover all possible cases. My guess is that it attempts a merge first and then uses the most recent on a conflict, but I'm not positive. – daveaglick May 11 '12 at 15:59

2 Answers2

4

Every change made to a GitHub wiki, regardless of whether it's done in the web interface or through git, is its own commit in the repository.

If you add, edit, or delete a wiki page through the web interface and then git pull the wiki repository, you can see the edit with git history. If you're the owner or a collaborator on the project that the wiki belongs to, you can even revert that commit and push the changes back to GitHub using git (I've personally had to do this to recover a page that was accidentally deleted).

For the situation you describe, it appears (according to this issue) that the last edit wins and the content of the first edit is lost.

For a more specific answer than that, you might want to take a look at the Gollum project, which is what GitHub uses to manage its git-backed wikis.

stevenh512
  • 545
  • 2
  • 8
2

I'm developing a git-backed wiki engine similar to Gollum named Waliki.

In particular, it's a bit smarter merging changes: instead of a hard 'newer wins' approach, Waliki handle every edition in a detached branch and merge them on save.

If there is an external change in a page during an edition and git can merge it automatically, the user is notified. If the merge fails, the page is still saved but the editor is reloaded asking the user to fix the conflict.

I'll be glad to receive some feedback.

tin_nqn
  • 106
  • 4