The benefits of github aside (I want to clean up the code before releasing it to github), I personally don't want to keep track of - another- repo if I can avoid it with a simpler solution (I'm pretty sure that I'm already over my limit, between work projects and this project, it makes something like six git repositories and two svn repositories, which certainly enough for me to keep busy keepin' track of).
Adding a post-receive hook sounds like it would indeed be a solution that would allow for duplicating between two working copies, as long as one working copy is edited very carefully or not at all, so that's a possibility. I'd even be fine with just doing a git checkout . to essentially just always keep the working copy matching the repository, but for whatever reason, running a git checkout or git checkout ./ leaves modified files that don't match the repo. Eventually I may break down and create a bare repository alongside the working copy repository to use as the central point. In the meantime, though, I think that I'm going to try exploring this "create a branch for one working copy and use it only as a staging area" and see problems that I'm missing crop up. Can anyone see what issues would crop up as reasons -not- to use this as a solution to the original problem? Seems like it would make one solution to that original problem be: Use different branches in each repository and only edit them at their specific repository, taking in changes from outside branches merging, and then you can push and pull between the two repositories to your hearts content without messing up working copies. On Sep 5, 2:30 pm, Tekkub <[EMAIL PROTECTED]> wrote: > Heh, Chris is right... it's kinda odd to complain that you don't want to use > a git repo server here in the mailing list of a git repo server! > Anywho, back to the question at hand. Your computer "A" has a stable IP > address, great. Make a bare clone of your repo on it. When you push from > computer "B" push into that bare repo. When you are on computer "A", you > work in the other, non-bare repo. You pull changes from the bare repo that > were pushed from computer "B", and when you're done you push back into the > bare repo. > > Hooks are certainly another solution. But the day you push from "B" when > "A" has uncommitted changes that get nuked, you're gonna be kicking yourself > for not using an intermediary repo to push to. > > But seriously, using GitHub as your repo server is just so much easier... > > --tek > > On Fri, Sep 5, 2008 at 12:02 PM, Chris Wanstrath <[EMAIL PROTECTED]> wrote: > > > On Fri, Sep 5, 2008 at 10:55 AM, Tchalvak <[EMAIL PROTECTED]> wrote: > > > > Uh, the advice of "either use a middleman repository or just always > > > pull instead of pushing" that you cite as the solution is problematic > > > when you're talking about computers that are moving targets on a > > > network or on the internet. Far as I can see, that is likely to be > > > the most common case, as compared to the rarer situation of two > > > machines with stable host/ip addresses. > > > Welcome to the GitHub Google Group for the popular Git hosting site, > > GitHub.com. > > > Please take a moment to familiarize yourself with GitHub. It was > > created to solve the exact problem you discuss (among others). > > > We think you'll really enjoy the site, whether you're using it to > > simulate a centralized model, as a dumb mirror of an existing Git > > repositority, or as a way to coordinate between multiple computers or > > individuals. > > > Thanks, > > -- > > Chris Wanstrath > >http://github.com/defunkt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/github?hl=en -~----------~----~----~----~------~----~------~--~---
