]> sipb.mit.edu Git - ikiwiki.git/blobdiff - doc/rcs/details.mdwn
web commit by http://diabolist.myopenid.com/: Clarification of original comment
[ikiwiki.git] / doc / rcs / details.mdwn
index b9b3c7eadd17133dc08215dff18dbf7d30d28e4f..6b9ffb91ff10b21e7b9d05079ba9f4fb6ddd5cb9 100644 (file)
@@ -62,7 +62,7 @@ rcs\_commit().  Is rcs\_prepedit() suitable?
 It follows that the HTML rendering and the CGI handling can be completely
 separated parts in ikiwiki.
 
-What repository should [[RecentChanges]] and [[History]] work on?  R1?
+What repository should [[RecentChanges]] and History work on?  R1?
 
 #### Rationale for doing it differently than in the Subversion case
 
@@ -125,12 +125,128 @@ I have been testing it for the past few days and it seems satisfactory.  I
 haven't observed any race condition regarding the concurrent blog commits
 and it handles merge conflicts gracefully as far as I can see.
 
+(After about a year, git support is nearly as solid as subversion support --[[Joey]])
+
 As you may notice from the patch size, GIT support is not so trivial to
-implement (for me, at least).  Being a fairly fresh code base it has some
-bugs.  It also has some drawbacks (especially wrt merge which was the hard
-part).  GIT doesn't have a similar functionality like 'svn merge -rOLD:NEW
-FILE' (please see the relevant comment in mergepast for more details), so I
-had to invent an ugly hack just for the purpose.
+implement (for me, at least). It has some drawbacks (especially wrt merge
+which was the hard part).  GIT doesn't have a similar functionality like
+'svn merge -rOLD:NEW FILE' (please see the relevant comment in `_merge_past`
+for more details), so I had to invent an ugly hack just for the purpose.
+
+> I was looking at this, and WRT the problem of uncommitted local changes,
+> it seems to me you could just git-stash them now that git-stash exists.
+> I think it didn't when you first added the git support.. --[[Joey]]
+
+
+>> Yes,  git-stash had not existed before.  What about sth like below?  It
+>> seems to work (I haven't given much thought on the specific implementation
+details).  --[[roktas]]
+
+>>         # create test files
+>>         cd /tmp
+>>         seq 6 >page
+>>         cat page
+>>         1
+>>         2
+>>         3
+>>         4
+>>         5
+>>         6
+>>         sed -e 's/2/2ME/' page >page.me # my changes
+>>         cat page
+>>         1
+>>         2ME
+>>         3
+>>         4
+>>         5
+>>         6
+>>         sed -e 's/5/5SOMEONE/' page >page.someone # someone's changes
+>>         cat page
+>>         1
+>>         2
+>>         3
+>>         4
+>>         5SOMEONE
+>>         6
+>>
+>>         # create a test repository
+>>         mkdir t
+>>         cd t
+>>         cp ../page .
+>>         git init
+>>         git add .
+>>         git commit -m init
+>>
+>>         # save the current HEAD
+>>         ME=$(git rev-list HEAD -- page)
+>>         $EDITOR page # assume that I'm starting to edit page via web
+>>
+>>         # simulates someone's concurrent commit
+>>         cp ../page.someone page
+>>         git commit -m someone -- page
+>>
+>>         # My editing session ended, the resulting content is in page.me
+>>         cp ../page.me page
+>>         cat page
+>>         1
+>>         2ME
+>>         3
+>>         4
+>>         5
+>>         6
+>>
+>>         # let's start to save my uncommitted changes
+>>         git stash clear
+>>         git stash save "changes by me"
+>>         # we've reached a clean state
+>>         cat page
+>>         1
+>>         2
+>>         3
+>>         4
+>>         5SOMEONE
+>>         6
+>>
+>>         # roll-back to the $ME state
+>>         git reset --soft $ME
+>>         # now, the file is marked as modified
+>>         git stash save "changes by someone"
+>>
+>>         # now, we're at the $ME state
+>>         cat page
+>>         1
+>>         2
+>>         3
+>>         4
+>>         5
+>>         6
+>>         git stash list
+>>         stash@{0}: On master: changes by someone
+>>         stash@{1}: On master: changes by me
+>>
+>>         # first apply my changes
+>>         git stash apply stash@{1}
+>>         cat page
+>>         1
+>>         2ME
+>>         3
+>>         4
+>>         5
+>>         6
+>>         # ... and commit
+>>         git commit -m me -- page
+>>
+>>         # apply someone's changes
+>>         git stash apply stash@{0}
+>>         cat page
+>>         1
+>>         2ME
+>>         3
+>>         4
+>>         5SOMEONE
+>>         6
+>>         # ... and commit
+>>         git commit -m me+someone -- page
 
 By design, Git backend uses a "master-clone" repository pair approach in contrast
 to the single repository approach (here, _clone_ may be considered as the working
@@ -145,6 +261,21 @@ Note that, as a rule of thumb, you should always put the rcs wrapper (`post-upda
 into the master repository (`.git/hooks/`) as can be noticed in the Git wrappers of
 the sample [[ikiwiki.setup]].
 
+Here is how a web edit works with ikiwiki and git:
+
+* ikiwiki cgi modifies the page source in the clone
+* git-commit in the clone
+* git push origin master, pushes the commit from the clone to the master repo
+* the master repo's post-update hook notices this update, and runs ikiwiki
+* ikiwiki notices the modifies page source, and compiles it
+
+Here is a how a commit from a remote repository works:
+
+* git-commit in the remote repository
+* git-push, pushes the commit to the master repo on the server
+* the master repo's post-update hook notices this update, and runs ikiwiki
+* ikiwiki notices the modifies page source, and compiles it
+
 ## [[Mercurial]]
 
 The Mercurial backend is still in a early phase, so it may not be mature