urosm
/
ikiwiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

A few comments. I think git-stash could be used now that it's available. 

Also removed some stuff about the git support not being robust or
well-tested, since it certainly is now.
master
joey 2007-10-21 01:07:31 +00:00
parent 6578f3e847
commit 0914abaaaf
1 changed files with 10 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
doc/rcs/details.mdwn
View File

@ -125,12 +125,17 @@ 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]]
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