Bug#775310: ikiwiki: git mv on directories results in git merge/overwrite errors

2016-01-18 Thread Luke Kenneth Casson Leighton
simon, hi, many apologies for not following up: my friend running the
server discovered, after around 18 months of puzzled investigation,
that he had (or perhaps had not) added a certain critical
system-required file to .gitignore as part of the upgrade to
gitolite3.  exact details are hard to remember (plus it wasn't me
doing the investigating) but this was very obscure, but finally
solved.

the typical ikiwiki git arrangement was as you described.  although it
would only be a kludge, the "manual recovery" i propose(d) would be an
"rm -fr * and a git clone", or a "git reset --hard".  this would at
least permit people in similar circumstances to at least run a
functioning web site from a remote laptop whilst there was a sysadmin
(2nd person) who could only respond on a delayed schedule.

l.



Bug#775310: ikiwiki: git mv on directories results in git merge/overwrite errors

2016-01-18 Thread Simon McVittie
Control: tags 775310 + moreinfo

On Tue, 13 Jan 2015 at 22:31:57 +, lkcl wrote:
> as i am editing a site over which i do not have direct sysadmin control
> (cannot re-generate the wiki by hand nor correct errors in its operation)

I would not particularly recommend the ikiwiki CGI for this particular
use-case, except in very constrained/predictable situations like the one
set up by ikiwiki-hosting. Making a normally-interactive version control
system fully automated is not something that ikiwiki's maintainers can
make 100% reliable in our spare time.

I would recommend either shared hosting with a shell (there are specific
instructions for NearlyFreeSpeech and DreamHost on its wiki, but most
similar providers should work); a virtual machine that you control (I
use ikiwiki-hosting on a VM from mythic-beasts.com); or the hosting
service branchable.com, for which ikiwiki-hosting was written,
and which is co-maintained by the original author of ikiwiki.

If these are not an option for your site, I will need information from
the sysadmin of your ikiwiki installation.

> to reproduce:
> 
> * create some files and subdirectories (any method is ok)
> * using direct git access (bypassing ikiwiki) perform
>   a "git mv" operation
> * perform a direct "git push" operation.

Using direct git access to what? What repositories do you have here?
Is it a typical ikiwiki git arrangement like this?

e.g. a laptop| VCS server   |  web server
 |  |
mywiki---|-->   mywiki.git  |-> $srcdir -> $destdir
   push  git hook   ikiwiki

where mywiki and $srcdir are both non-bare git clones of the bare git
repository mywiki.git, and you are doing the "git mv"/"git commit"
in your local clone on your laptop or whatever, then pushing to the
VCS server?

> the only method of recovery is to have sysadmin rights *on the target
> system* (which is not available in this specific instance) and to
> perform a manual recovery.
> 
> ideally such a manual override / recovery should be available as
> an option on the preferences/admin page.

What is involved in this manual recovery? Do you have a specific
proposed action that ikiwiki should take to recover?

> error: Your local changes to the following files would be overwritten by 
> merge:
>   community_ideas/laptop_13in.mdwn

This means that at some point in the past, there was a change to this
file on the server (probably via the CGI) which was not committed correctly.
Obviously, that isn't something that's meant to happen in the first place.

Is there anything about that file in the web server's error log?
(ask your sysadmin)

Are there any other uncommitted changes? (ask your sysadmin to run
"git status" in the wiki's working copy, which is the directory that
was configured as the $srcdir for ikiwiki)

If the sysadmin runs something like

git commit -a -m "import uncommitted changes from web server"

in the srcdir, as the uid that would run the CGI hook and with the
environment variables that would typically be seen by the CGI hook,
what happens?

One thing that might have broken commits is that recent versions of git
will refuse to commit if the user (in ikiwiki's case, whatever user will
run the CGI hook) doesn't have a configured git identity. The next
ikiwiki release will work around this by using "IkiWiki "
as a fallback. If this is what's happening, your sysadmin can resolve
this in current ikiwiki by setting GIT_COMMITTER_NAME="IkiWiki" and
GIT_COMMITTER_EMAIL="ikiwiki.info" (or any other suitable placeholder)
in the CGI script's environment.

S



Bug#775310: ikiwiki: git mv on directories results in git merge/overwrite errors

2015-01-13 Thread lkcl
Package: ikiwiki
Severity: normal
Tags: upstream

as i am editing a site over which i do not have direct sysadmin control
(cannot re-generate the wiki by hand nor correct errors in its operation)
this emphasises a need for ikiwiki to be always 100% functional or
recoverable.

the problem is that it is not recoverable: going in as an administrator
for the wiki and regenerating the HTML does *not* fix the problem,
merely repeats the same error which came from the initial merge
conflict.

to reproduce:

* create some files and subdirectories (any method is ok)
* using direct git access (bypassing ikiwiki) perform
  a "git mv" operation
* perform a direct "git push" operation.

at this point the error below is reported at the console (git post-commit
hook).  follow-up attempts to go in via the ikiwiki preferences, and
to hit "save setup" result in exactly the same error.

the only method of recovery is to have sysadmin rights *on the target
system* (which is not available in this specific instance) and to
perform a manual recovery.

ideally such a manual override / recovery should be available as
an option on the preferences/admin page.




generating wrappers..
refreshing wiki..
error: Your local changes to the following files would be overwritten by merge:
community_ideas/laptop_13in.mdwn
Please, commit your changes or stash them before you can merge.
Aborting
'git pull --prune origin' failed:  at /usr/share/perl5/IkiWiki/Plugin/git.pm 
line 218.
done

-- System Information:
Debian Release: 7.4
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org