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

diff --git a/doc/rcs/details.mdwn b/doc/rcs/details.mdwn
index b9b3c7ead..449e129bd 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 
@@ -221,3 +352,5 @@ merge again with a merger that inserts conflict markers.  It commits this new
 revision with conflict markers to the repository.  It then returns the text to the
 user for cleanup.  This is less neat than it could be, in that a conflict marked
 revision gets committed to the repository.
+
+## [[bzr]]