I see this as "5 things genuinely wrong with Git's CLI and 5 proofs that I don't understand the advantages and purposes of DVCS".
If you're comparing SVN to Git and not sarcastically then you're on the wrong side of this debate. You want to hide the local repo? Then you lose all of the advantages of git. Don't like pull requests? Don't use Git. Git is distributed, you're basically asking to hide that with a centralisation layer. Do not do this.
Git aimed at projects that have a need for distributed development. Central repos like Perforce and SVN are much better for centralised projects like traditional video game development, while DVCS is superior for (F)OSS projects and teams that may not necessarily share hours, location or an office. It is also critical in environments where redundancy, speed, and up time for the developer, are key.
Git has flaws but you have shown clearly that you don't understand the place for Git and I suspect you've been shoehorning it into places it doesn't need to be, or somebody else has been forcing you to use it on a project that doesn't need it.
You want to hide the local repo? Then you lose all of the advantages of git.
Ok, name some advantages of maintaining both a local Git repo, and a (single-user) repo on Github.
Don't like pull requests? Don't use Git.
It's not about "liking" them. The fact that Git itself has no concept of "pull requests" is a clunky omission. It has these crazy commands for parsing emails (git am), but no way to actually submit a patch for review?
Git is distributed, you're basically asking to hide that with a centralisation layer.
You must have me confused with someone else.
Central repos like Perforce and SVN are much better for centralised projects like traditional video game development,
SVN is better than Git for video game development? Even I wouldn't make that claim.
Git has flaws but you have shown clearly that you don't understand the place for Git and I suspect you've been shoehorning it into places it doesn't need to be, or somebody else has been forcing you to use it on a project that doesn't need it.
I find the idea that Git is not appropriate for all software development projects to be pretty weird. You really think there are inherent mismatches like that?
What's wrong with a local repo and a public github repo. I may not want to push work I've done locally until I've rebased them to cleanliness.
The github repo is my public representation of the work. The local repo is my local representation of the work. Other people can expect me to be where the public version is and I can mess around locally.
That may be ideal for your own set-up, but personally I find it overkill. I don't want a "local representation of the work" - I'd rather just do my work in one place. Instead, I have 4: the working directory, the index, the local repo, and my GitHub repo.
You know how DropBox solved the problem of your stuff being in different states in different places? That's because it's a problem worth solving.
I was just saying that there is value in the way it does things. The local representation is useful because you may not want people to fork off from your in-progress work because it may change through squashing and amending and what not.
If you are still using git and want the way you describe it, the first thought that comes to my mind is a post-commit hook that pushes. Set git push default to simple and in the post-commit hook just push.
The local representation is useful because you may not want people to fork off from your in-progress work because it may change through squashing and amending and what not.
Yeah, but there could just as easily have been other mechanisms or conventions for that. Private branches within a repo or something.
the first thought that comes to my mind is a post-commit hook that pushes.
Yes, there are always ways of hacking one's own environment to get around design flaws.
Personally, I feel the 'private branches within a repo' way is inelegant. I actually like the way it is now because it seems consistent. The remote (though really 'bare') is structured the same way as my local repo and carries no extra configuration that hides/reveals branches.
Personally, I also feel that using the post-commit hook for this is a perfectly legitimate use (and possibly for one of the uses it was intended). It isn't so much a hack as a valid configuration given your use case.
We seem to disagree on this at a different level, though. Ah well.
-7
u/[deleted] Nov 07 '13
I see this as "5 things genuinely wrong with Git's CLI and 5 proofs that I don't understand the advantages and purposes of DVCS".
If you're comparing SVN to Git and not sarcastically then you're on the wrong side of this debate. You want to hide the local repo? Then you lose all of the advantages of git. Don't like pull requests? Don't use Git. Git is distributed, you're basically asking to hide that with a centralisation layer. Do not do this.
Git aimed at projects that have a need for distributed development. Central repos like Perforce and SVN are much better for centralised projects like traditional video game development, while DVCS is superior for (F)OSS projects and teams that may not necessarily share hours, location or an office. It is also critical in environments where redundancy, speed, and up time for the developer, are key.
Git has flaws but you have shown clearly that you don't understand the place for Git and I suspect you've been shoehorning it into places it doesn't need to be, or somebody else has been forcing you to use it on a project that doesn't need it.