{"thread":{"id":"20655","subject":"Simple commit mechanism for non-technical users","startedAt":"2009-08-18T16:05:32Z","lastAt":"2009-08-19T14:40:43Z","messageCount":7,"participants":["D Sundstrom","Chris Packham","Johannes Schindelin","Jakub Narebski","Matthieu Moy","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"121111","messageId":"ef72456d0908180905u18593b63tdc850b8552db30b9@mail.gmail.com","threadId":"20655","inReplyTo":null,"subject":"Simple commit mechanism for non-technical users","fromName":"D Sundstrom","fromEmail":"sunds@peapod.net","sentAt":"2009-08-18T16:05:32Z","receivedAt":"2009-08-18T16:05:32Z","isPatch":false,"sender":{"key":"sunds@peapod.net","avatar":null},"body":"I use git to manage all project artifacts, including documentation,\nproposals, presentations, and so on.\n\nHowever, I have a hard time convincing non-technical staff to learn\nenough about git or to take the time to go through the effort of\ncommitting changes to a repository.  So the steady stream of email\nattachments with \"Acme Specification v3\" or \"final final spemco\nproprosal\" continues.\n\nI'd hoped there was a simple web interface that would allow a user to\nupload and commit a file to a repository, but I've had no luck finding\none.  (I've used cgit for browsing, but it is read-only).\n\nIs anyone aware of a simple way I can have my non-technical users\nmanage their documents against a git repository?  Ideally this would\ninvolve no installation of software on their machine (unless it were\ncompelling, for example, the Finder plugin for SVN on the mac was a\ngreat tool for these users; or at least those on a mac...)\n\n-David\n"},{"id":"121211","messageId":"a038bef50908182309i2c4a9cd8leac7d1136726247e@mail.gmail.com","threadId":"20655","inReplyTo":"ef72456d0908180905u18593b63tdc850b8552db30b9@mail.gmail.com","subject":"Re: Simple commit mechanism for non-technical users","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2009-08-19T06:09:32Z","receivedAt":"2009-08-19T06:09:32Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Wed, Aug 19, 2009 at 4:05 AM, D Sundstrom<sunds@peapod.net> wrote:\n> I use git to manage all project artifacts, including documentation,\n> proposals, presentations, and so on.\n>\n> However, I have a hard time convincing non-technical staff to learn\n> enough about git or to take the time to go through the effort of\n> committing changes to a repository.  So the steady stream of email\n> attachments with \"Acme Specification v3\" or \"final final spemco\n> proprosal\" continues.\n>\n> I'd hoped there was a simple web interface that would allow a user to\n> upload and commit a file to a repository, but I've had no luck finding\n> one.  (I've used cgit for browsing, but it is read-only).\n>\n> Is anyone aware of a simple way I can have my non-technical users\n> manage their documents against a git repository?  Ideally this would\n> involve no installation of software on their machine (unless it were\n> compelling, for example, the Finder plugin for SVN on the mac was a\n> great tool for these users; or at least those on a mac...)\n>\n> -David\n> --\n\nActually this is one situation that I'd say there are better solutions\nthan git _ducks_.\n\nThe solution I've been trying to push people toward at my day job is\nusing a wiki (we chose mediawiki but all the extra markup might still\nscare non-techies). Wiki's are version controlled (in a simple,\ncentralized fashion) and allow editing from multiple authors and can\nbe updated quickly. The only client software you need is a web\nbrowser. Plenty of open source projects use wikis for their living\nspecifications.\n\nYou may also want to look around for other content management systems\nbut the only one I've used kinda sucked. Not sure if there are any\ngood open source ones (but then again I haven't really looked).\n\nIf you still want to use git as your version control system for these\nkinds of documents it shouldn't actually be too hard to implement and\nsimple uploader to complement a viewer like cgit or gitweb.\nUnfortunately I don't know of any that exist but maybe someone else on\nthe list does.\n"},{"id":"121219","messageId":"alpine.DEB.1.00.0908190940430.5594@intel-tinevez-2-302","threadId":"20655","inReplyTo":"ef72456d0908180905u18593b63tdc850b8552db30b9@mail.gmail.com","subject":"Re: Simple commit mechanism for non-technical users","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-08-19T07:49:50Z","receivedAt":"2009-08-19T07:49:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Aug 2009, D Sundstrom wrote:\n\n> I use git to manage all project artifacts, including documentation, \n> proposals, presentations, and so on.\n> \n> However, I have a hard time convincing non-technical staff to learn\n> enough about git or to take the time to go through the effort of\n> committing changes to a repository.  So the steady stream of email\n> attachments with \"Acme Specification v3\" or \"final final spemco\n> proprosal\" continues.\n> \n> I'd hoped there was a simple web interface that would allow a user to\n> upload and commit a file to a repository, but I've had no luck finding\n> one.  (I've used cgit for browsing, but it is read-only).\n> \n> Is anyone aware of a simple way I can have my non-technical users\n> manage their documents against a git repository?  Ideally this would\n> involve no installation of software on their machine (unless it were\n> compelling, for example, the Finder plugin for SVN on the mac was a\n> great tool for these users; or at least those on a mac...)\n\nYou contradict yourself here, the Finder plugin needs to be installed, and \nSVN, too.\n\nAs for your problem: I think you need a specific solution.  If I \nunderstand you correctly, files which have the same name (but maybe a \nsuffix \"v3\" or similar before the extension), and they should be \ncommitted to a Git repository.\n\nThen you have a bunch of people who do not want to care about learning \nproper version control.\n\nThis is what I would do: write a very simple .cgi (I'd use Perl for that), \nwhich has a file upload button, takes the name as commit message (or maybe \nadds a field where you can type in a commit message, but that might be \nasking your bunch of Aunt Tillies too much), strips the \"v3\"-like suffixes \n($name =~ s/[-_ ]*v\\d+(\\.[A-Za-z0-9]{1,5})$/$1/;), set author and \ncommitter information according to IP (and refuse if the IP is not in the \ninternal mapping) and commit.\n\nThe whole script would probably not be larger than 50 lines, and require \nGit to be installed on the server.\n\nThe bigger problem is that your Aunt Tillies most likely would not love \ngitweb, so you need a fancier interface.\n\nCiao,\nDscho\n"},{"id":"121221","messageId":"m37hx0ns13.fsf@localhost.localdomain","threadId":"20655","inReplyTo":"ef72456d0908180905u18593b63tdc850b8552db30b9@mail.gmail.com","subject":"Re: Simple commit mechanism for non-technical users","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-08-19T08:10:03Z","receivedAt":"2009-08-19T08:10:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"D Sundstrom <sunds@peapod.net> writes:\n\n> I use git to manage all project artifacts, including documentation,\n> proposals, presentations, and so on.\n> \n> However, I have a hard time convincing non-technical staff to learn\n> enough about git or to take the time to go through the effort of\n> committing changes to a repository.  So the steady stream of email\n> attachments with \"Acme Specification v3\" or \"final final spemco\n> proprosal\" continues.\n> \n> I'd hoped there was a simple web interface that would allow a user to\n> upload and commit a file to a repository, but I've had no luck finding\n> one.  (I've used cgit for browsing, but it is read-only).\n\nSome of git web interfaces or git hosting software offer editing via\nweb interface.  Neither gitweb nor cgit offers this; it is available\nAFAIK in GitHub (but it is not open source, and server version GitHub:FI\nisn't cheap).\n\nYou can use some wiki (there are some wikis with git backend,\ne.g. ikiwiki, see http://git.or.cz/gitwiki/InterfacesFrontendsAndTools)\nor CMS like Drupal instead.  Note that wikis usually work in \nlock-edit-unlock mode (no merging changes), and have per page (per file)\nversioning.\n\n\nAlternate solution would be to use one of GUIs for Git, like\ne.g. git-gui or QGit, or filemanager integration / shell extension\nlike (for MS Windows) TortoiseGit or Git Extensions.\n\n> Is anyone aware of a simple way I can have my non-technical users\n> manage their documents against a git repository?  Ideally this would\n> involve no installation of software on their machine (unless it were\n> compelling, for example, the Finder plugin for SVN on the mac was a\n> great tool for these users; or at least those on a mac...)\n\nWhat operating system?  What do you use currently?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"121223","messageId":"vpqvdkkus5h.fsf@bauges.imag.fr","threadId":"20655","inReplyTo":"alpine.DEB.1.00.0908190940430.5594@intel-tinevez-2-302","subject":"Re: Simple commit mechanism for non-technical users","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-08-19T08:25:30Z","receivedAt":"2009-08-19T08:25:30Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Then you have a bunch of people who do not want to care about learning \n> proper version control.\n\nOTOH, my experience with non-technical people and revision control is:\nthey send you an email with the file attached, saying they promise\nthey will learn the tool one day, but not right now because they don't\nhave time, and then you have to find out how to merge and commit\nyourself.\n\nAnd unfortunately (also from my experience), this is not limited to\nnon-technical people ...\n\nFor this category of people, a simple web-based commit tool will not\nteach them anything (which is bad), but at least reduces the work of\nthe technical guys (which is somehow good).\n\n-- \nMatthieu\n"},{"id":"121238","messageId":"20090819102036.GC28920@sigill.intra.peff.net","threadId":"20655","inReplyTo":"alpine.DEB.1.00.0908190940430.5594@intel-tinevez-2-302","subject":"Re: Simple commit mechanism for non-technical users","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-19T10:20:36Z","receivedAt":"2009-08-19T10:20:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 19, 2009 at 09:49:50AM +0200, Johannes Schindelin wrote:\n\n> Then you have a bunch of people who do not want to care about learning \n> proper version control.\n> \n> This is what I would do: write a very simple .cgi (I'd use Perl for that), \n> which has a file upload button, takes the name as commit message (or maybe \n> adds a field where you can type in a commit message, but that might be \n> asking your bunch of Aunt Tillies too much), strips the \"v3\"-like suffixes \n> ($name =~ s/[-_ ]*v\\d+(\\.[A-Za-z0-9]{1,5})$/$1/;), set author and \n> committer information according to IP (and refuse if the IP is not in the \n> internal mapping) and commit.\n> \n> The whole script would probably not be larger than 50 lines, and require \n> Git to be installed on the server.\n> \n> The bigger problem is that your Aunt Tillies most likely would not love \n> gitweb, so you need a fancier interface.\n\nActually, I think there is a technical problem here. You get Aunt\nTillie's v3, but you don't necessarily know what it is based on. So if\nsome other Aunt Tillie has submitted a v3 in the meantime, what do you\ndo with her file? Commit on top? Try to guess where her v2 was, branch\nfrom there, and merge?\n\nIf you commit on top, then you are potentially erasing the other\nperson's work. If you do a merge, you are likely to get conflicts\n(especially because Aunt Tillie likes to use horrible binary formats)\nthat _somebody_ will have to resolve.\n\nI guess you can throw each Tillie on their own branch and then let\nsomebody clueful do the merging, but then you do not really have people\nworking together.\n\nI think this is a fundamental issue. Most version control systems (and\nespecially distributed ones) are about doing concurrent work and\nmerging, and merging requires a bit of a clue. The Aunt Tillies of the\nworld really need a locking system to manage concurrency.\n\n-Peff\n"},{"id":"121253","messageId":"ef72456d0908190740h597320e2vaa01f86edf59579c@mail.gmail.com","threadId":"20655","inReplyTo":"20090819102036.GC28920@sigill.intra.peff.net","subject":"Re: Simple commit mechanism for non-technical users","fromName":"D Sundstrom","fromEmail":"sunds@peapod.net","sentAt":"2009-08-19T14:40:43Z","receivedAt":"2009-08-19T14:40:43Z","isPatch":false,"sender":{"key":"sunds@peapod.net","avatar":null},"body":"Thanks to all that responded.\n\nIt might help to frame things from Aunt Tillie's point of view.\nHer workflow consists of editing office documents (word, powerblower, etc)\nin collaboration with her peers.  They email these back and forth and\ncome up with whatever ad-hoc \"version control\" they think of at the\nmoment, such as file names, dates, verbal communication, etc.\n\nI'm technical product manager and I need to coordinate reviews of\nthese documents as well as my release process.  I also face audits\nand accreditation from my customers.\n\nWe previously chose and implemented GIT for our scm system based\non a number of considerations. Primarily we have distributed teams and\nalso there is a review and sign-off process before code is \"blessed\" into\nour official repository.  For this, GIT fits well.\n\nI'm going to put all the project artifacts into this repository, including\nthe aforementioned office documents.  They just get versioned as binary\nblobs, which is fine for this application.  I just need to know which one\nis current and maintain prior versions.\n\nAunt Tillie may someday appreciate our scm enough to install a client\non her machine and learn how to use it.  But that is a big jump from\nthe simple workflow she has today.  My thought is that I might get her\nto upload this document to a SMB/CIFS or webdav file share, or use\na simple webapp, but that is about it for now.\n\nMy thought is to just have a process that watches for these files and\ncommits them as they arrive.  I wouldn't do any filename magic, I would\njust train Aunt Tillie to use the same name every time.  If two people\nstep on each other's work, they tend learn from the experience and\ncoordinate amongst themselves the next time.  There are only a\nfew people touching any given document.\n\nA wiki doesn't seem appropriate because we are dealing with office\ndocuments rather than \"wiki-like\" content.  This is more of a\ndocument management system, albeit a very simple one.\n\nThe Aunt Tillies are all on windows (XP or later).  The development\nteam is all over the map, windows, osx, linux.\n\n-David\n\n\nOn Wed, Aug 19, 2009 at 5:20 AM, Jeff King<peff@peff.net> wrote:\n> On Wed, Aug 19, 2009 at 09:49:50AM +0200, Johannes Schindelin wrote:\n>\n>> Then you have a bunch of people who do not want to care about learning\n>> proper version control.\n>>\n>> This is what I would do: write a very simple .cgi (I'd use Perl for that),\n>> which has a file upload button, takes the name as commit message (or maybe\n>> adds a field where you can type in a commit message, but that might be\n>> asking your bunch of Aunt Tillies too much), strips the \"v3\"-like suffixes\n>> ($name =~ s/[-_ ]*v\\d+(\\.[A-Za-z0-9]{1,5})$/$1/;), set author and\n>> committer information according to IP (and refuse if the IP is not in the\n>> internal mapping) and commit.\n>>\n>> The whole script would probably not be larger than 50 lines, and require\n>> Git to be installed on the server.\n>>\n>> The bigger problem is that your Aunt Tillies most likely would not love\n>> gitweb, so you need a fancier interface.\n>\n> Actually, I think there is a technical problem here. You get Aunt\n> Tillie's v3, but you don't necessarily know what it is based on. So if\n> some other Aunt Tillie has submitted a v3 in the meantime, what do you\n> do with her file? Commit on top? Try to guess where her v2 was, branch\n> from there, and merge?\n>\n> If you commit on top, then you are potentially erasing the other\n> person's work. If you do a merge, you are likely to get conflicts\n> (especially because Aunt Tillie likes to use horrible binary formats)\n> that _somebody_ will have to resolve.\n>\n> I guess you can throw each Tillie on their own branch and then let\n> somebody clueful do the merging, but then you do not really have people\n> working together.\n>\n> I think this is a fundamental issue. Most version control systems (and\n> especially distributed ones) are about doing concurrent work and\n> merging, and merging requires a bit of a clue. The Aunt Tillies of the\n> world really need a locking system to manage concurrency.\n>\n> -Peff\n>\n"}]}