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

> On Sun, 20 Mar 2011 08:31:39 +0100
> René Mayrhofer <r...@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
_______________________________________________
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Reply via email to