Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

Comment: Re:Tabs vs Spaces (Score 4, Insightful) 428

by Dynedain (#49426589) Attached to: Stack Overflow 2015 Developer Survey Reveals Coder Stats

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.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49426337) Attached to: 10 Years of Git: An Interview With Linus Torvalds

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.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49425969) Attached to: 10 Years of Git: An Interview With Linus Torvalds

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.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49425937) Attached to: 10 Years of Git: An Interview With Linus Torvalds

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.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49425289) Attached to: 10 Years of Git: An Interview With Linus Torvalds

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.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49425227) Attached to: 10 Years of Git: An Interview With Linus Torvalds

And use as many dev branches as you want in Git.

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.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49423589) Attached to: 10 Years of Git: An Interview With Linus Torvalds

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.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49419539) Attached to: 10 Years of Git: An Interview With Linus Torvalds

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.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49418087) Attached to: 10 Years of Git: An Interview With Linus Torvalds

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.

Comment: Re: "natural-born citizen" is well understood ... (Score 1) 538

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.

The best way to accelerate a Macintoy is at 9.8 meters per second per second.

Working...