Unix as IDE • Hacker News Board

Re: Unix as IDE

#211

Post by blakeyrat » Sun, Oct 09, 2016, 4:54 PM UTC

noir_lord wrote: post #210

blakeyrat wrote: post #208

Earlier quoted context omitted.

I want to thank you for posting. I know that the groupthink around Git, especially on forums like this one, is so powerful that by even mentioning that Git has flaws and isn't some kind of angelic perfect software from heaven runs the risk of having a billion down votes.

People get silly when it comes to tools they've invested time in, lots of people don't like to think they made the wrong choice and will defend it often to the extreme, I don't get invested in tools I use what works for me and switch when it seems reasonable. Git is a necessary evil basically.

Well like I said above, I look at it as a "condition of employment" piece of software. Nobody would us Lotus Notes for email if they had their own choice in the matter. Nobody would use OracleApps for time keeping if they had their own choice in the matter. No, you have to use it to be employed.

Unfortunately, software in that particular niche has to be really good or it'll engender a lot of hate. If you're Skype, people generally don't mind because Skype is relatively easy and pleasant to use. If you're Git, people are going to hate you.

Re: Unix as IDE

#212

Post by josteink » Mon, Oct 10, 2016, 6:28 AM UTC

blakeyrat wrote: post #207

josteink wrote: post #149

Earlier quoted context omitted.

> We knew about user testing, about UX. Git makes use of zero of those concepts. In fact, it seems to be actively hostile towards its users^. I was with you all the way here, and then suddenly... > We also had source control packages that were not only easier to use, but had more features: TFS let you Suddenly you mention TFS as an example of something good. Mind blown. TFS is absolutely among the worst "popular" ver…

> Suddenly you mention TFS as an example of something good. You need to work on your reading comprehension. The only claim I made about TFS is that it has a feature (locking files) that Git doesn't. I cited it as an example that Git has fewer features than its competitors. I never said anything about its quality. > This has nothing to do with Git specifically. This is a difference between centralized and distributed.…

> I cited it as an example that Git has fewer features than its competitors. I never said anything about its quality.

Fair enough.

> This is a difference between centralized and distributed... Fine; but that's not the point. The point is it's a feature that I want.

But file-locking is realistically just not implementable in a distributed source-control system. This sort of mechanism does only have a home in centralized architectures.

> I'm not a fan of newer software having fewer features than older software.

This may be a nitpick about the way you decided to express yourself, but just in case: Your math is wrong here.

You've had 1 capability you appreciate removed, while having tons of others added. That still yields you new software with more features, not fewer.

Re: Unix as IDE

#213

Post by blakeyrat » Mon, Oct 10, 2016, 7:10 PM UTC

josteink wrote: post #212

blakeyrat wrote: post #207

Earlier quoted context omitted.

> Suddenly you mention TFS as an example of something good. You need to work on your reading comprehension. The only claim I made about TFS is that it has a feature (locking files) that Git doesn't. I cited it as an example that Git has fewer features than its competitors. I never said anything about its quality. > This has nothing to do with Git specifically. This is a difference between centralized and distributed.…

> I cited it as an example that Git has fewer features than its competitors. I never said anything about its quality. Fair enough. > This is a difference between centralized and distributed... Fine; but that's not the point. The point is it's a feature that I want. But file-locking is realistically just not implementable in a distributed source-control system. This sort of mechanism does only have a home in centraliz…

> But file-locking is realistically just not implementable in a distributed source-control system.

Ok. Then I guess it was a bad technical choice to pick that system if it prevents you from matching the features of your competitors, wasn't it?

I get the sense you're still missing my point here, but whatever.

> You've had 1 capability you appreciate removed, while having tons of others added.

Like what? The only one I'm aware of is "work offline". Which TFS also offers in the newer versions.

(Also: again, work on your reading comprehension. I talked about two capabilities that TFS and Subversion have that Git lacks.)

I'd like to hear about these "tons" of features Git provides over its competitors.

Re: Unix as IDE

#214

Post by josteink » Mon, Oct 10, 2016, 7:56 PM UTC

blakeyrat wrote: post #213

josteink wrote: post #212

Earlier quoted context omitted.

> I cited it as an example that Git has fewer features than its competitors. I never said anything about its quality. Fair enough. > This is a difference between centralized and distributed... Fine; but that's not the point. The point is it's a feature that I want. But file-locking is realistically just not implementable in a distributed source-control system. This sort of mechanism does only have a home in centraliz…

> But file-locking is realistically just not implementable in a distributed source-control system. Ok. Then I guess it was a bad technical choice to pick that system if it prevents you from matching the features of your competitors, wasn't it? I get the sense you're still missing my point here, but whatever. > You've had 1 capability you appreciate removed, while having tons of others added. Like what? The only one I…

Git allows you to micro-manage your work by commiting often, and diffing against a previous known good state, with easy rollback an option all the way.

But this is not really friendly to issue in a PR for, so git also allows you to rewrite your commit history by squashing commits, by reordering commits, and basically cleaning up after the fact or before publishing for code-review, or public release or whatever,

If you decide that code you've written in one private repo logically belongs in another public one, you can create a new repo for the select files in your private repo which you want to share without losing version control information or any revision data.

Git has a flexible diff-engine and lets you for instance plug in pandoc for diffing word-processing files, letting you actually handle non-VCS friendly formats like MS Word through Git.

Git is modular and lets you plug in pretty much any thing you like.

And people like to, so there's modules for pretty much everything around.

Like VCS-bridges converting TFS and SVN repos to Git (and allowing you to merge seamlessly, while commiting back to the monolith).

Etc etc. The list goes on.

Git gives me the flexibility I need, to do pretty much anything I can imagine.

Except locking files. I'll hand you that one. It wont let me do that. But I can setup a central Git-server where I'll reject commits which tamper with pre-agreed "locked" files. So work-arounds obviously exist.

I'm not saying Git is perfect, but it works for me, for the needs I have. Which is more than I can say for TFS or SVN.