The nominal expansion of tabs is to advance to the next column which is a multiple of 8.
Huh? Since when? On typwriters and early word-processors it was forced to 5 columns. And even most typewriters allowed you to move the tabstops to arbitrary places.
On every editor I've seen in the last 5 years the tab display width is configurable. If you like 2 spaces, great, if you like 8, have at it. It doesn't affect the rest of your team.
The only reason tab characters are a problem is because people mix and match tabs and spaces.
Python's whitespacing is an evil that should be purged with fire.
Yes, I have multiple trees for multiple projects. Why on earth would my life be better if I didn't?
Presumably you're not saying something such as "one directory tree for multiple projects is better than multiple directory trees for multiple projects"; that's just the moral equivalent of tabbed browsing vs. non-tabbed browsing, and some people quite legitimately don't find tabbed browsing to be an improvement for them.
Of course not. Every project should have their own repo. SVN, Git or Otherwise. I've seen many places that try to stick it all into one giant SVN project - and the result is that they end up using it as if it was just a network share.
There is precisely one person touching my repository, and that's me, so there's nobody to trip over. Other people's work is separated from my work by being on other people's machines. The ultimate goal of all of our work is to get our changes into the official common repository on the trunk or a release branch; how do branches either on my machine or in the common repository simplify this task?
How do branches make it more difficult? You're intentionally conflating two different use cases. You want to do all your work in master and periodically push to a central server? Fine. I have my devs working on different branches per bug/feature because they may need to pass incomplete work between different developers depending on skillset or what layers of the application stack are being changed. I want to keep them in a branch so the work doesn't slip into a release. When their work is complete, reviewed, and tested, then we merge into a release candidate branch for client review.
Yes, but "having a branch for fixes to a stable release line", to keep feature work for the next release separate from fixes that go into stable release lines (possibly backported from the trunk), is different from "branching for every change you're working on". The former is useful to the project; I've yet to see any scenario in which the latter is useful.
In Git you don't have to have one or the other scenario. You can have both at the same time. Branching off of a release branch and merging later back into that branch is just as simple as branching off of master. Merging and Pull requests allows for flow management on teams that may have owners of various pieces who need to review anything being committed against their branch/module/whatever.
No, I'm complaining that fans of Git seem to think that, because they believe that some particular way of using Git happens to work better for them, it's the Right Answer For Everybody.
I never said that Git is the Right Answer For Everybody - thanks for putting words in my mouth. If your preferred workflow doesn't map to the Git model, then don't use Git. Over the years I have often found that having a flexible worfklow and allowing it to fit the capabilities of the tools being leveraged often introduces more efficient ways of working that I never would have otherwise considered.
The way SVN tracks individual file parent/child version relationships across branches (as opposed to Git's compressed delta of the whole project state) easily results in corrupt histories and merge conflicts that aren't really in conflict. It also quickly becomes overly complicated if you want a project structure that doesn't follow the "best practice" of trunk/tag/branches folders where the entire project is branched. (note, that's a community consensus to work around SVN's limitations, not something enforced by SVN itself). In SVN, branching from a branch, or from a tag, instead of branching from trunk, can get you into to the bowels of SVN cleanup and merge conflicts very quickly.
Granted, a nice aspect of SVN is you can have a single file exist at a different revision than the rest of your project - powerful, but very dangerous if you miss that a file is in that state.
Without branching, you can only have branch-like behavior by having multiple checkouts. And when you go to resolve those (at least in Git) you will still be doing a merge operation that is identical to merging a branch.
When you have multiple people touching the same project, branching helps keep people's work separated so they aren't tripping over each other, and merging provides a place for reviewing and synchronizing changes across different efforts.
Event CVS and SVN have branching because it is useful. Stop being intentionally obtuse.
You are complaining that you refuse to use one of the very key features of Git, and that somehow that refusal on your part means that Git is hard to use.
In Git, every time you check out a new copy you are getting the ENTIRE project history, not just the specific commit. That's part of the nature of a DVCS.
Hence why branching is built to be so easy, and why switching branches is effectively just essentially just changing a symlink.
If you want to be doing dev in another instance thing while a build is running, that's a good argument for a second checkout. But multiple checkouts just to avoid branching is not a good way to use Git, not a good argument against it.
Different VCS architectures result in different workflow styles. What made sense for SVN and CVS doesn't necessarily apply for Git or Mercurial. In SVN/CVS, branching and merging are monolithic tasks that are very cumbersome, so the best-practices workflows tend to minimize how often this happens. Git and Mercurial are the opposite. Because branching and merging is key to making DVCS work, it's highly encouraged and the process is almost trivial by comparison.
I do. I don't want to use any dev branches, as they provide no obvious benefit to me, so I don't use any.
Well if you don't want to branch, then you're arbitrarily enforcing a condition on yourself that makes things far more difficult then they need to be. Because it is a DVCS, Git it built entirely around the idea of frequent branching. Every time you make a commit you are effectively branching.
Sounds to me like you try to make huge complex commits. Try rethinking your work as smaller modular commits. It makes life so much easier to do diffs and handling complex branch/merging behaviors.
And use as many dev branches as you want in Git. You can always cherry pick which changes you want to bring over into your master/release branch.
What if it takes multiple commits to fix a bug? What if you need to commit to run against a build server? What if you want to switch away to a different branch to work on something else without losing where you're at?
It's one click to delete a branch (and it's a simple checkbox when we merge the pull request using Atlassian's git server product). And you don't have to push your changes out to other users or git servers. You can hold onto it on just your box until you're ready to make it available.
Zillions of branches isn't a problem in Git. They're trivial to create and delete. (delete doesn't destroy history, just hides the branch name so it doesn't show in your list of "existing" branches). That's the whole point. Everything is about branching and merging instead of a linear code history.
Git works well because of how the Linux project is structured - a very large hierarchy, but starts to fall down in a small team where people don't have that arms-length working environment, or where they work on multiple branches at the same time (eg at work, I have my big feature and I have bug fixes that come and go regularly - git doesn't help in that environment unless I have multiple repos checked out)
We've been using Git (with a centralized repo) very successfully with a small team and it has made stuff so much smoother than SVN. Mostly because it encourages branching and facilitates it quite well (compared to the monolithic branding in SVN).
Bug fixes? Create a branch per bug. Make your commits as you go. Commit if you need to (or use Git Stash) and switch to another branch. Easy-peasy. No need to have multiple checkouts. The workflow we've been using with a lot of success is to create a branch per bug/feature, and then use a pull request to get it reviewed and merged back into master.
If it's that clear cut, why all the uproar about Obama's birth certificate? Even on the off chance he had been born outside the U.S., he'd still be a Natural Born Citizen since his mother early was, correct?
Oh that's right - the deffinition is clearly one interpretation if you support Cruz and clearly the opposite interpretation if you oppose Obama.
Yes, we had numerous group projects in architecture and they sucked for the exact same reasons. And in the real world of architecture almost everything is effectively a group project.
Your allegory is fallacious because you are comparing a vendor not carrying a product which they never would (for any customer) to a vendor refusing to sell their primary product to a specific customer because the vendor finds that particular customer objectionable.
It is more akin to a Muslim butcher refusing to sell anything to a Jew.
And that's exactly what Amazon and other online retailers have been complaining about in the U.S. cross-border sales tax collection attempts. 80 varitations? Try thousandsn with every state, county, and city having their own arbitrary sales tax rules and rates.
Yes. Because a Muslim storekeeper wouldn't be selling sell pork chops to anyone (halal and all that), just like I, a web developer, don't sell pink fuzzy slippers to anyone. Distribution of pork chops is not the business your exampled shopkeeper is in.
It would be quite illegal if the Muslim storekeeper was selling pork chops to everyone else, but refused to sell pork chops specifically to Jews.
The specificity is what makes it discrimination, and in the US we have very clearly defined which basis of discrimination are not permitted: religious affiliation, age, gender, race, handicaps, medical conditions, and now sexual orientation is being added to that list.
The whole reason Firefox exists is because a group broke off and built it to remove the feature bloat in Mozilla/Netscape.
Officially-built/supported plugins would be the ideal way to solve this. Use internal devs who know the app inside and out, but serve it as an optional extension rather than an always-available feature requiring more memory to keep running.
I get one or two daily, but never from repeat numbers. So if caller ID doesn't match someone I know, it goes to voicemail. The rob ovals never leave messages.
Dependencies? Node Package Manager, Bower, and others Build scripts? Grunt, Gulp, and others
And the best part of all? All the scripting, configuration files, etc, for these are all in Javascript and JSON (JavaScript Object Notation)... the exact same language and structure you are using for your primary development.
The same code formatting rules, editor configs, syntax highlighting, autocomplete, for your code are used for your config, your build scripts, etc
There's a 4th reason that gets tossed around that I've never seen actually validated with the idea of "reusing code on the backend and the front-end" but I've never seen a case where that was actually a good idea since it involves exposing so much logic.
Check out Meteor, a framework built exactly on that idea - it's pretty crazy how easy it is to setup a rich *reactive* web app that keeps state sync across multilple devices. It's also crazy tiny for transmission size because only micro-snippets of data are exchanged between client and server instead of full page views.
Angular is an event driven framework for web/network apps. Node.JS is an executable that lets you run javascript on the server just like you can any other scripting language (PHP, Perl, etc...)
It is popular because it allows for single-language client/server webapps, which nothing other thean Flash/Flex has been able to do with wide support.
It also is extremely powerful in doing development-side preprocessing for client-side delivery. No need to learn Java in order to automate some JS/HTML/CSS tasks.
Slashdot Mirror
Huh? Since when? On typwriters and early word-processors it was forced to 5 columns. And even most typewriters allowed you to move the tabstops to arbitrary places.
On every editor I've seen in the last 5 years the tab display width is configurable. If you like 2 spaces, great, if you like 8, have at it. It doesn't affect the rest of your team.
The only reason tab characters are a problem is because people mix and match tabs and spaces.
Python's whitespacing is an evil that should be purged with fire.
Of course not. Every project should have their own repo. SVN, Git or Otherwise. I've seen many places that try to stick it all into one giant SVN project - and the result is that they end up using it as if it was just a network share.
How do branches make it more difficult? You're intentionally conflating two different use cases. You want to do all your work in master and periodically push to a central server? Fine. I have my devs working on different branches per bug/feature because they may need to pass incomplete work between different developers depending on skillset or what layers of the application stack are being changed. I want to keep them in a branch so the work doesn't slip into a release. When their work is complete, reviewed, and tested, then we merge into a release candidate branch for client review.
In Git you don't have to have one or the other scenario. You can have both at the same time. Branching off of a release branch and merging later back into that branch is just as simple as branching off of master. Merging and Pull requests allows for flow management on teams that may have owners of various pieces who need to review anything being committed against their branch/module/whatever.
I never said that Git is the Right Answer For Everybody - thanks for putting words in my mouth. If your preferred workflow doesn't map to the Git model, then don't use Git. Over the years I have often found that having a flexible worfklow and allowing it to fit the capabilities of the tools being leveraged often introduces more efficient ways of working that I never would have otherwise considered.
The way SVN tracks individual file parent/child version relationships across branches (as opposed to Git's compressed delta of the whole project state) easily results in corrupt histories and merge conflicts that aren't really in conflict. It also quickly becomes overly complicated if you want a project structure that doesn't follow the "best practice" of trunk/tag/branches folders where the entire project is branched. (note, that's a community consensus to work around SVN's limitations, not something enforced by SVN itself). In SVN, branching from a branch, or from a tag, instead of branching from trunk, can get you into to the bowels of SVN cleanup and merge conflicts very quickly.
Granted, a nice aspect of SVN is you can have a single file exist at a different revision than the rest of your project - powerful, but very dangerous if you miss that a file is in that state.
Without branching, you can only have branch-like behavior by having multiple checkouts. And when you go to resolve those (at least in Git) you will still be doing a merge operation that is identical to merging a branch.
When you have multiple people touching the same project, branching helps keep people's work separated so they aren't tripping over each other, and merging provides a place for reviewing and synchronizing changes across different efforts.
Event CVS and SVN have branching because it is useful. Stop being intentionally obtuse.
You are complaining that you refuse to use one of the very key features of Git, and that somehow that refusal on your part means that Git is hard to use.
In Git, every time you check out a new copy you are getting the ENTIRE project history, not just the specific commit. That's part of the nature of a DVCS.
Hence why branching is built to be so easy, and why switching branches is effectively just essentially just changing a symlink.
If you want to be doing dev in another instance thing while a build is running, that's a good argument for a second checkout. But multiple checkouts just to avoid branching is not a good way to use Git, not a good argument against it.
Different VCS architectures result in different workflow styles. What made sense for SVN and CVS doesn't necessarily apply for Git or Mercurial. In SVN/CVS, branching and merging are monolithic tasks that are very cumbersome, so the best-practices workflows tend to minimize how often this happens. Git and Mercurial are the opposite. Because branching and merging is key to making DVCS work, it's highly encouraged and the process is almost trivial by comparison.
Well if you don't want to branch, then you're arbitrarily enforcing a condition on yourself that makes things far more difficult then they need to be. Because it is a DVCS, Git it built entirely around the idea of frequent branching. Every time you make a commit you are effectively branching.
Sounds to me like you try to make huge complex commits. Try rethinking your work as smaller modular commits. It makes life so much easier to do diffs and handling complex branch/merging behaviors.
And use as many dev branches as you want in Git. You can always cherry pick which changes you want to bring over into your master/release branch.
What if it takes multiple commits to fix a bug? What if you need to commit to run against a build server? What if you want to switch away to a different branch to work on something else without losing where you're at?
It's one click to delete a branch (and it's a simple checkbox when we merge the pull request using Atlassian's git server product). And you don't have to push your changes out to other users or git servers. You can hold onto it on just your box until you're ready to make it available.
Zillions of branches isn't a problem in Git. They're trivial to create and delete. (delete doesn't destroy history, just hides the branch name so it doesn't show in your list of "existing" branches). That's the whole point. Everything is about branching and merging instead of a linear code history.
We've been using Git (with a centralized repo) very successfully with a small team and it has made stuff so much smoother than SVN. Mostly because it encourages branching and facilitates it quite well (compared to the monolithic branding in SVN).
Bug fixes? Create a branch per bug. Make your commits as you go. Commit if you need to (or use Git Stash) and switch to another branch. Easy-peasy. No need to have multiple checkouts. The workflow we've been using with a lot of success is to create a branch per bug/feature, and then use a pull request to get it reviewed and merged back into master.
If it's that clear cut, why all the uproar about Obama's birth certificate? Even on the off chance he had been born outside the U.S., he'd still be a Natural Born Citizen since his mother early was, correct?
Oh that's right - the deffinition is clearly one interpretation if you support Cruz and clearly the opposite interpretation if you oppose Obama.
That right there is pretty damn unclear.
Yes, we had numerous group projects in architecture and they sucked for the exact same reasons. And in the real world of architecture almost everything is effectively a group project.
I find a wonderful sense of schadenfreude every time I consider that Sears shut down their catalog sales only two years before Amazon launched.
Your allegory is fallacious because you are comparing a vendor not carrying a product which they never would (for any customer) to a vendor refusing to sell their primary product to a specific customer because the vendor finds that particular customer objectionable.
It is more akin to a Muslim butcher refusing to sell anything to a Jew.
There's no Shake Shack near me even though I'm in the 2nd largest market in the US and they've opened a location in Dubai.
I'm fucked.
See how stupid that argument sound?
I never said LLC = Incorporation.
A Limited Liability Corporation IS a type of corporation whereas the AC above claimed otherwise.
And that's exactly what Amazon and other online retailers have been complaining about in the U.S. cross-border sales tax collection attempts. 80 varitations? Try thousandsn with every state, county, and city having their own arbitrary sales tax rules and rates.
Yes. Because a Muslim storekeeper wouldn't be selling sell pork chops to anyone (halal and all that), just like I, a web developer, don't sell pink fuzzy slippers to anyone. Distribution of pork chops is not the business your exampled shopkeeper is in.
It would be quite illegal if the Muslim storekeeper was selling pork chops to everyone else, but refused to sell pork chops specifically to Jews.
The specificity is what makes it discrimination, and in the US we have very clearly defined which basis of discrimination are not permitted: religious affiliation, age, gender, race, handicaps, medical conditions, and now sexual orientation is being added to that list.
Pro tip: look up the words that make LLC an acronym
Yet they're bombing ISIS.
The whole reason Firefox exists is because a group broke off and built it to remove the feature bloat in Mozilla/Netscape.
Officially-built/supported plugins would be the ideal way to solve this. Use internal devs who know the app inside and out, but serve it as an optional extension rather than an always-available feature requiring more memory to keep running.
I get one or two daily, but never from repeat numbers. So if caller ID doesn't match someone I know, it goes to voicemail. The rob ovals never leave messages.
The Node.JS ecosystem has this as well
Dependencies? Node Package Manager, Bower, and others
Build scripts? Grunt, Gulp, and others
And the best part of all? All the scripting, configuration files, etc, for these are all in Javascript and JSON (JavaScript Object Notation)... the exact same language and structure you are using for your primary development.
The same code formatting rules, editor configs, syntax highlighting, autocomplete, for your code are used for your config, your build scripts, etc
Check out Meteor, a framework built exactly on that idea - it's pretty crazy how easy it is to setup a rich *reactive* web app that keeps state sync across multilple devices. It's also crazy tiny for transmission size because only micro-snippets of data are exchanged between client and server instead of full page views.
Nope.
Angular is an event driven framework for web/network apps. Node.JS is an executable that lets you run javascript on the server just like you can any other scripting language (PHP, Perl, etc...)
It is popular because it allows for single-language client/server webapps, which nothing other thean Flash/Flex has been able to do with wide support.
It also is extremely powerful in doing development-side preprocessing for client-side delivery. No need to learn Java in order to automate some JS/HTML/CSS tasks.
RMS, is that you?