Python script for automatic synchronization based on inotify

[Dieter Plaetinck]

On Sun, 20 Mar 2011 12:26:36 +0100
Dieter Plaetinck <dieter at plaetinck.be> wrote:

> On Sun, 20 Mar 2011 08:31:39 +0100
> René Mayrhofer <rene at mayrhofer.eu.org> wrote:
> 
> > Am Freitag, 18. März 2011, 22:59:07 schrieb Dieter Plaetinck:
> > > Note if you do this, server:test.git won't actually have a master branch yet.
> > > So when i touch ~/autosync/test, I get this:
> > > 
> > > No refs in common and none specified; doing nothing.
> > > Perhaps you should specify a branch such as 'master'.
> > > fatal: The remote end hung up unexpectedly
> > > error: failed to push some refs to 'server:autosync.git'
> > > 
> > > workaround is typing `git push origin master` once. after that it works fine.
> > 
> > You're right. I've never actually tried it on a completely empty repository. We should either document this in README (the setup process) or make the script realize when there is no master branch and do a "git push origin master" in this case. I will need to dig into the git remote command a bit more to see what the best option is here (I don't like parsing the output if I can avoid it).
> > 
> > best regards,
> > Rene
> 
> I also thought of some options.
> What about always explicitly pushing the current branch? unfortunately there is nothing like `git push origin --currentbranch`, so we would need to do ask git "what is the current branch", and then `git push origin $branchname`, but that involves an extra process; we could try to cache the result but that gets ugly quickly (you need to know when to invalidate the cache, i.e. when the user creates a new branch).  on the other hand, something like this would transparently allow the user to work with multiple branches; as far as i see there is currently no notion of the branch in autosync.py (i.e. "master" is always assumed), if we always do `git push master` we can fix the problem at hand (but then the user is restricted to the master branch, if he creates a new branch and we do a push of master, his new branch won't be pushed), if we do `git push $currentbranch` and also have a notion of the involved branch in the jabber messages, then the user could transparently use multiple branches.
> Either way I don't think we should query the remote for "what do you have", frankly we shouldn't care.  we only care about pushing (explicitly enough) the thing that we need to push.
> 
> If you only want to support a master branch, hardcoding `git push origin master` is a good choice, but I don't like restricting ourselves like that. We can also say in the readme "every time you create a new branch, push it manually once", from then on, we can just `git push origin` and it will do the right thing.  it involves a tiny bit of manual work, but maybe this is the most sensible.

oh, one more thing.
you can query the current branch in a pure-python way, by reading .git/HEAD
that way the user doesn't need to bother about pushing the branch the first time, and it's probably not a noticeable performance overhead to look at the current branch every time you want to commit/push.
there are some python libraries for git as well, by depending on them, we could use such a library to abstract some of these things for us; and they might come in handy for other things in the future as well (like checking ignore rules?)

Dieter