X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/74baaeba00c90cd7a027e40e2f6d65695341a0e1..58f1ef0784117a6b522c8ac64ec24056e1bbad8f:/doc/rcs/details.mdwn 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