Live data from Hacker News

Simple Revision Control

catb.org

161–170 of 179 posts

Re: Simple Revision Control

#161

Earlier quoted context omitted.

Thank you for locating this. After reading, I'm not sure what to think. I do not have the subject matter familiarity necessary to take a position on his claims, nor does he cite anything other than personal experience and his own research. If his historical claims with regard to homosexuality are correct, then I can say with great certainty that his other claim as to how these facts will be interpreted in the modern…

ESR's general observation that the ancients often saw homosexual as being about dominance is probably correct. However, the framing makes it sound like this is specific to homosexual relationships. In fact ancient cultures often saw ALL male sexual relationships as being about dominance. Of course they didn't really need to spend a lot of time discussing who was being dominated in a heterosexual relationship: it was…

This point appears to deflate the whole blog post.

Re: Simple Revision Control

#162
post #70

Earlier quoted context omitted.

http://esr.ibiblio.org/?p=1063

Thank you for locating this. After reading, I'm not sure what to think. I do not have the subject matter familiarity necessary to take a position on his claims, nor does he cite anything other than personal experience and his own research. If his historical claims with regard to homosexuality are correct, then I can say with great certainty that his other claim as to how these facts will be interpreted in the modern…

> The only value judgement made therein is that (assuming the information used to reach this conclusion is correct) that historically, homosexuality been associated with some pretty ugly and downright evil things.

> If they're not correct, then this amounts to a very, very disgusting and ugly smear piece worthy of groups like the infamous Westboro church.

> So now I wonder.. which is it?

Well, that's tricky. Most of the historical associations he makes are roughly correct as stated, but what is misleading is the implicit claim that underlines the whole piece -- that equivalent historical associations don't exist to each of those for heterosexuality, which they do -- romantic heterosexuality only became a cultural norm (rather than something portrayed as exceptional, often dangerous, and very frequently as a source of deviance from cultural norms relating to the family) in the Western world only fairly recently historically. The "massive reinvention" of (male) homosexuality that ESR refers to is real, but its part and parcel of a broader reinvention of sexuality in general from a very similar starting point and in a very similar direction.

Re: Simple Revision Control

#164
post #153

Earlier quoted context omitted.

> It's about not giving yourself the impression that the learning curve is insurmountable, you can do it Perhaps I can, but with mercurial around I dont see why I need to. I think no one in their right mind claims git cannot be grokked. They question whether that effort is well spent given there are equally effective alternatives that people find simpler to use. Other than github I fail to see a compelling reason goi…

I find this comment very telling https://news.ycombinator.com/item?id=8602259 I would rather do without all that. That comment goes out of its way to make things seem complicated. The different synonyms for things are confusing, and are evidence of the fact that Git has evolved over time rather than springing forth fully formed. That said, the staging area is one of the most useful features of Git, and if you don't w…

> The staging area allows me to make a few simple changes in the order that they occur to me, but add and commit them (using git add -p) in the order that makes the most sense for code review.

Ah, but note that "git commit" also takes a "--patch" argument. So the add-and-commit case you are describing can in fact be done in one step. That step uses the index, but only for its implementation; you're not aware of it. "git commit --patch ..." appears to move selected changes from the working copy straight to a new commit on HEAD. The command could be implemented in a version of git that doesn't have an index.

Those little commits you make in preparation for review are your true staging area.

Re: Simple Revision Control

#165

Earlier quoted context omitted.

"a nice enough guy" Nope: http://esr.ibiblio.org/?p=26

Eric Raymond, everybody: "Nor is it any good thing that “youths” now behave as though they think they’re operating with a kind of immunity. We saw this in Ferguson, when Michael Brown apparently believed he could could beat up a Pakistani shopkeeper and then assault a cop without fearing consequences. (“What are you going to do, shoot me?” he sneered, just before he was shot) As he found out, eventually that shit’ll…

Full text: http://esr.ibiblio.org/?p=6286

Re: Simple Revision Control

#167
post #45

Earlier quoted context omitted.

> Because, for one thing, "one" sometimes doesn't have the computer science degree and years of experience to even begin to understand Git, for one thing. With respect, I call shenanigans on this my good friend. I dropped out of highschool and attended no postsecondary and I don't have any problems with Git. I started with the basics and read more as I got myself into tighter and tighter jams. I feel like this myth i…

git commit and git checkout are fine. git pull and git push are where the problems start. as I got myself into tighter and tighter jams I suppose this is the thing; if you're happy to learn that way, fine. It's just that git is particularly prone to "I've trashed local state and lost work" / "I've just pushed a huge mess and will have to lose time cleaning it up, if that's even possible".

I love git, but even git checkout is asinine. It's fine for checking out a tag/branch/rev/treeish, but why on earth does it also revert files to their checked in state if given a path argument?

I don't think git should be prone to trashing local state due to how it usually yells at you when it's about to do that, but then I've been working with a student this quarter who seems to do that every time I push something to github and she needs to pull. I think if the git community got together, did a usability study on how people actually use git, and renamed/split out commands into names that made sense, it would be a huge boon for general usability.

Re: Simple Revision Control

#168

Earlier quoted context omitted.

I sometimes use git this way on local files: git init # make a local repo git add foo.txt # add the file [edit] git add -u # add changes to commit git commit -m"made a change" # check in changes git log # see commits git status # what has changed That's really all you need to know.

> git add -u This is a wasteful step; you can commit all your changes with "git commit -a" which adds the modified files to the index, and commits, in one step. The index is a completely pointless idea in git that has no purpose; the next major version of git should factor it out. Git would really improve if it lost the index thing. You're already using distributed version control where you can have a whole swath of…

Ugh, this is terrible, the index is git's best feature. I kind of see where you're coming from with the idea of squashing together commits before pushing but it seems like a lot of awkwardness and overhead for the really basic use case of committing a bunch of files without doing it all in one command. Maybe it's just my OCD tendencies but I actually do spend time crafting the perfect commit, picking only the hunks/lines that matter and all that.

I think if people are taught git focusing on the index/staging area, it makes a lot more sense and you have much fewer problems.

Re: Simple Revision Control

#169

Earlier quoted context omitted.

I am not entirely sure I understand why one wouldn't use git for this role. Because, for one thing, "one" sometimes doesn't have the computer science degree and years of experience to even begin to understand Git. For many users, using Git means cutting and pasting command line recipes scoured from desperate web searches, and crossing their fingers. This does not go away when you use Git just for personal use with a…

> Because, for one thing, "one" sometimes doesn't have the computer science degree and years of experience to even begin to understand Git, for one thing. With respect, I call shenanigans on this my good friend. I dropped out of highschool and attended no postsecondary and I don't have any problems with Git. I started with the basics and read more as I got myself into tighter and tighter jams. I feel like this myth i…

Nah, it's not _that_ bad. Only way one may realize Git is hard is to compare it with other DVCSes, so avoiding that makes him confident enough to spread wishful speculations of it's something is wrong with people, not Git.

Re: Simple Revision Control

#170

Earlier quoted context omitted.

It's actually a good idea. People often don't bother version-controlling simple stuff because it's a hassle. Here's the thing that's funny to me: git is easy . Everyone (especially mercurial users) goes on about how horrible the UI is, but when I think of git, I think of how similar it is to RCS: easy, quick, and simple. With both, I can diff things and check in changes very quickly. I have a bunch of single files in…

Git is so easy a good search for "git tutorial" returns 2.7 million results. I've lost track of how man HN Front Page posts there have been trying to explain just how easy git is. The sheer volume of posts desperately trying to show how easy git is should be enough evidence to prove that it is infact not easy, simple, or intuitive.

I look at it the same way.
Post reply on HN