X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/74baaeba00c90cd7a027e40e2f6d65695341a0e1..8b31c53366bbee51b36501443eafd0f712ee6a4c:/doc/rcs/details.mdwn?ds=inline

diff --git a/doc/rcs/details.mdwn b/doc/rcs/details.mdwn
index b9b3c7ead..6b9ffb91f 100644
--- a/doc/rcs/details.mdwn
+++ b/doc/rcs/details.mdwn
@@ -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