Re: [be] bibledit-gtk 4.1 initial push to remote git repository

[John Marshall]

On 24/09/2010 02:03, Teus Benschop wrote:
> On Thu, 2010-09-23 at 12:37 +1000, John Marshall wrote:
>> It looks like manual intervention is necessary before upload from a
>> bibledit-gtk project to an empty remote repository will work.  Am I
>> missing something?  The Remote Repository wiki page doesn't say anything
>> about the manual intervention I found necessary.  
> 
> The information may not have been obvious at the site. But it is there.
> See
> 
> https://sites.google.com/site/bibledit/gtk/tutorials/collaboration/repository-initialization

Thanks, but that's just an alternative manual intervention.

I've done some more work on this.  I'm not a C (or C++) programmer, so I
decided to mimic the behaviour of src/assistantremoterepository.cpp in a
shell script to see if I could understand what was happening and
discover a solution.

To verify write access to the network repository, bibledit-gtk:
 (a) Clones the remote repository to an empty local directory
 (b) Adds a test file to the newly-cloned local repository
 (c) Commits the added file to the local repository
 (d) Pulls changes from the remote repository
 (e) Pushes changes to the remote repository
 (f) Deletes the test file from the local working directory
 (g) Commits the change to the local repository
 (h) Pushes changes to the remote repository

If the remote repository is newly initialized (empty), then the above
falls over when attempting to pull from the remote repository at step (d).

 "Your configuration specifies to merge with the ref 'master'
  from the remote, but no such ref was fetched."

It can't do a pull because there are no branches on the remote
repository.  The failure means that bibledit-gtk incorrectly concludes
that it does not have write access to the remote repository.

The real write test is at the following step (e).  If the remote
repository is empty, we can skip the pull step (d) and still push (e)
successfully.  The rest of the steps then work fine and bibledit-gtk
knows it can use the remote repository.

At step (a), git knows that it has just cloned an empty repository: it
prints a message to that effect but the exit status gives us no clues.

  "warning: You appear to have cloned an empty repository."

If we explicitly test for this empty repository condition on the local
clone we can safely skip step (d) in that case.  There are lots of ways
we could do this.  I based my decision upon two tests on the local
repository (which is cloned from the empty remote repository):

 - git branch
 - git log -n 1

The 'git branch' will list no branches for an empty repository but will
still return success if the local (empty) repository is initialized
properly.  The 'git log' attempt fails with an error status and the
following message:

  "fatal: bad default revision 'HEAD'"

So, if I test for a successful 'git branch' and a failed 'git log', I
can be fairly certain I have a clean empty repository and can skip step (d).

It is also necessary to alter the 'git push' in step (e) to cater for
pushing to an empty remote repository.  This change could be made
conditional but it will work in both cases.

  Change from: "git push"
           to: "git push ${repository_url} master"

If I could speak C++ I'd offer a patch.  If you would like to see my
shell script, please let me know.

-- 
John Marshall

signature.asc
Description: OpenPGP digital signature