On Sun, 20 Mar 2011 12:26:36 +0100 Dieter Plaetinck <[email protected]> wrote:
> On Sun, 20 Mar 2011 08:31:39 +0100 > René Mayrhofer <[email protected]> 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 [email protected] http://lists.madduck.net/listinfo/vcs-home
