3 ms·

> $ git push origin gh-pages I think that if you had changed the above to $ git push -u origin gh-pages then everything else would have gone smoothly.

kansface 14y ago
This is what I do personally. We also use rebases liberally at my office which requires us to force push upstream. On-boarding new team members scares the shit out of me.
- encoderer 14y ago
  I hear ya, but as you obv know as long as you're pushing to a location only you are pushing to, a force-push is harmless. Moreover, any loss that does occur is recoverable as long as you keep your clone around. Git doesn't garbage collect refs for at least 30 days. So you're pretty protected if you clone to a location that has regular backups.
lennartregebro 14y ago
That's interesting, and maybe I'll try that in the future. But just as with the "matching" vs "current" why is the default here the thing that is guaranteed to cause problems, instead of what people expect? My point is not that git is impossible to use. It's that the way git behaves by default is insane.
- nessus42 14y ago
  The default probably only seems insane to us because we don't grok whatever workflow Linus was using with Git when he came up with the defaults. The defaults probably make a lot of sense for his workflow. A common mistake people make when bitching about Git, is assuming that their workflow is the only workflow. Git supports a multitude of different workflows, and that fact is both a strength and a weakness.
  - lennartregebro 14y ago
    To be honest, none of the issues I've seen are in any way dependent on workflow. That pull and push by default work on different branches is not a matter of workflow, it's a confusing inconsistency. That it deletes history without somebody issuing an explicit specific command to delete a specific revision is not a matter of workflow, it's bad design.

kansface 14y ago

This is what I do personally. We also use rebases liberally at my office which requires us to force push upstream. On-boarding new team members scares the shit out of me.

encoderer 14y ago
I hear ya, but as you obv know as long as you're pushing to a location only you are pushing to, a force-push is harmless. Moreover, any loss that does occur is recoverable as long as you keep your clone around. Git doesn't garbage collect refs for at least 30 days. So you're pretty protected if you clone to a location that has regular backups.

lennartregebro 14y ago

That's interesting, and maybe I'll try that in the future. But just as with the "matching" vs "current" why is the default here the thing that is guaranteed to cause problems, instead of what people expect? My point is not that git is impossible to use. It's that the way git behaves by default is insane.

nessus42 14y ago
The default probably only seems insane to us because we don't grok whatever workflow Linus was using with Git when he came up with the defaults. The defaults probably make a lot of sense for his workflow. A common mistake people make when bitching about Git, is assuming that their workflow is the only workflow. Git supports a multitude of different workflows, and that fact is both a strength and a weakness.
- lennartregebro 14y ago
  To be honest, none of the issues I've seen are in any way dependent on workflow. That pull and push by default work on different branches is not a matter of workflow, it's a confusing inconsistency. That it deletes history without somebody issuing an explicit specific command to delete a specific revision is not a matter of workflow, it's bad design.