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.
My setup seems to be almost the simplest case. I have a server, with code on it, which is at a stable ip address. We'll call that A. I have my local development machine, with code on it, which is behind a router. Call it B. Both need to have at least one instance of git to connect between them, which brings repo A and repo B into existence. I could: 1. Always pull into each repository, never make use the push command at all. With local machine B as a moving target, this would require jumping through hoops each time to determine the ip address of machine B, provide outside access etc etc. It would also require the same jumping through hoops for anyone else who wanted to put code into repository A. 2. Create an additional bare repository, repo C, push and pull only between it for both A and B. This creates additional upkeep and complication for the upkeep of repo C and the space that it takes, makes the data in repo A mostly redundant and unused, and adds the pull step into to the process of duplicating changes. Option 3: The closest that I can see to a simpler solution is to create a branch on the server devoted completely to being the working branch, check that branch out on the server, and just never make commits to that branch, instead just from the server merging branches onto that staging branch. I'm not sure that that'll solve every issue, at this point, but I think it's got to be better than saying essentially "never use the push command" or "create 3 repositories in order to move code between 2 points". On Sep 5, 1:04 pm, "Matt Todd" <[EMAIL PROTECTED]> wrote: > >> you should pull from one repo to the other, instead of pushing. > > Herein lies the resolution to your complaint. > > > I love git, but some things are so counter-intuitive about it it's > > annoying. > > In the Rails development world, there's a saying that if you try to do > something that's different than the normal 80% that it's going to be > hard and awkward. This applies to Git, too, in some ways... if you try > to do things the "wrong" way, it will be awkward and difficult. > > If you're fighting Git, you may be doing it wrong. If that's the case, > take some time to read deeper into how it works. Things become pretty > clear once you've gained a firm grasp of how it works. > > Matt --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
