Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple Revision Control

catb.org

Post reply on HN
Print view View original

151–160 of 179 posts

Re: Simple Revision Control

#151

Post by jxf »

aidenn0 wrote: post #133
jxf wrote: post #98

Earlier quoted context omitted.

Here's a very obvious use-case: You have a single file with many historical changes. That file moves to a new directory that is not a subdirectory of its current directory. In git, the file vanishes from the repo and can't be tracked easily anymore. You lose all of its past history if you put it into a new repo. In SRC the history moves with the file.

the .git directory need not be in the same place as your working files. I keep my /etc in git with no issues.

I'm not saying that any of the stuff suggested can't be done with git. The point is that this is not the use case git was designed for, so it doesn't accommodate it easily -- you must write all the exceptions and special cases into your repository, which is cumbersome.

Re: Simple Revision Control

#152

Post by avar »

sofal wrote: post #146
InclinedPlane wrote: post #130

Earlier quoted context omitted.

Git is terrible. Git is typical of a tool built by engineers. It has good primitives but a clunky overall design and horrible UI. It does not naturally encourage the most effective modes of use. Hell, even the "best practices" of the git community are highly questionable (just rewrite history for aesthetic reasons, what could go wrong?). Git is highly tuned to the use case of serving linux kernel development. Many ot…

just rewrite history for aesthetic reasons, what could go wrong? I have never understood the problem that some people have with the idea of rewriting history. It's as if the very idea of it offends them. Do file system writes also put you off? Is it important that I see the history of every single keystroke you made while twiddling with your config file? When you fixed a typo you made in a comment before publishing y…

What people are really saying when they say you shouldn't write history is that your SCM shouldn't support work in progress checkins. Not supporting that just makes your SCM inflexible.

Re: Simple Revision Control

#153

Post by srean »

click170 wrote: post #59
kazinator wrote: post #43

Earlier quoted context omitted.

> I dropped out of highschool and attended no postsecondary and I don't have any problems with Git. Git problems arise when people want to do moderately sophisticated things, beyond just committing changes and viewing logs and diffs. > If git commit and git checkout are too complicated, If "If git commit and git checkout are too complicated" is your argument, then you aren't doing anything more sophisticated with git…

I think you may have misunderstood my comment, of course there is more to it then checkout and commit. Those are the basics, that's where you start. Then you get stuck somehow, and you read more . That's what I did at least. IMO It's about not giving yourself the impression that the learning curve is insurmountable, you can do it. Starting with the basics and growing up is, I thought, common knowledge for acquiring a…

> 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 going for git apart for the linux kernel development workflow of course. Its not a bad tool but not quite the "you possibly cannot and should not do without it" that it is made out to be.

I find this comment very telling https://news.ycombinator.com/item?id=8602259 I would rather do without all that.

Re: Simple Revision Control

#154

Post by jude- »

plikan13 wrote: post #96
icebraining wrote: post #82

Earlier quoted context omitted.

(ESR aside) Why not? If I believe that someone's exposed views are harmful, doesn't it make sense to avoid increasing his/her overall influence? I mean, the fact that we're discussing ESR's views on pedophilia shows that his influence in an unrelated area (software) increases the exposure of those views. If he was just a nobody like me, would we be discussing his blog post on Catholic priests? Not likely. Do you chec…

Why not respond to bigotry with love, instead of hating back? This is not some zero-sum game. If anyone needs a little bit of success in life, it's a bigot.

Tolerating intolerance is not an act of love, but of apathy--both towards the bigot, and the bigot's targets.

Re: Simple Revision Control

#155

Post by lawtguy »

Karunamon wrote: post #77
tptacek wrote: 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…

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 always the woman in pretty much all pre-modern civilizations.

This makes his second point about a supposed biological predisposition towards domination sex really apply to all men. If gay men are struggling with this "biological headwind" then so are straight men.

Re: Simple Revision Control

#156

Post by forrestthewoods »

npsimons wrote: post #95
muyuu wrote: post #31

Earlier quoted context omitted.

It's actually a good idea. People often don't bother version-controlling simple stuff because it's a hassle. I routinely use my own rdiff/rsync scripts but this is not something you find in every system and also not something most people would use. A barebones, simple, no-install, easy, not-necessarily-for-experienced-developers VCS is a good thing to have. BTW it's going at 1 release per day. Heh :-)

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.

Re: Simple Revision Control

#157

Post by pbreit »

e12e wrote: post #46
mrb wrote: post #22

He claims he did not use Mercurial because (a) it stores the history in binary blobs, (b) it does not have sequential revision numbers, and (c) its CLI syntax is ugly, see [1]. Unfortunately he is wrong about (b) and (c). Mercurial assigns automatic sequential revision numbers (perfect for a single non-distributed repo) and its CLI syntax is so neat that this is the reason I do use it a lot to track changes to single…

I'm nit particularly fond of git, I much prefer mercurial - but they are of course pretty much equivalent. Either way I have a hard time seeing which usecases aren't covered by the duo of RCS and mercurial (actually I'm very hard pressed to see why one would ever use RCS over mercurial, but no question RCS is simpler). At least something like fossil have some actually unique features....

To a newbie, they don't seem that equivalent. Mercurial is much easier to understand, imo.

Re: Simple Revision Control

#158

Post by jfb »

jotux wrote: post #150
sofal wrote: post #146

Earlier quoted context omitted.

just rewrite history for aesthetic reasons, what could go wrong? I have never understood the problem that some people have with the idea of rewriting history. It's as if the very idea of it offends them. Do file system writes also put you off? Is it important that I see the history of every single keystroke you made while twiddling with your config file? When you fixed a typo you made in a comment before publishing y…

I see the ability to change local history as a huge benefit. Not only can I track changes but before I publish them I can make decisions about how to make them more presentable/understandable to other developers.

Exactly this. I get all the benefits of a DVCS, pushing and pulling from my private fork, distributing development between my home and office machines, never losing changes; and then when I'm ready to publish, I can go back and rationalize my commits (many of which are "git commit -am 'oh sbt'" sorts of things) into a useful history and issue a PR for the rest of the team to code review.

It's taken me a while to come around, but you'd have to pry rebase out of my cold dead hands now.

Re: Simple Revision Control

#159

Post by nitrogen »

srean wrote: post #153
click170 wrote: post #59

Earlier quoted context omitted.

I think you may have misunderstood my comment, of course there is more to it then checkout and commit. Those are the basics, that's where you start. Then you get stuck somehow, and you read more . That's what I did at least. IMO It's about not giving yourself the impression that the learning curve is insurmountable, you can do it. Starting with the basics and growing up is, I thought, common knowledge for acquiring a…

> 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 want to use it, you can largely ignore it. 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.

Also: I highly recommend setting up shell aliases for the most commonly used commands, whether you use Git or anything else. "gco" is much faster to type than "git checkout", etc.

Re: Simple Revision Control

#160

Post by digisign »

npsimons wrote: post #95
muyuu wrote: post #31

Earlier quoted context omitted.

It's actually a good idea. People often don't bother version-controlling simple stuff because it's a hassle. I routinely use my own rdiff/rsync scripts but this is not something you find in every system and also not something most people would use. A barebones, simple, no-install, easy, not-necessarily-for-experienced-developers VCS is a good thing to have. BTW it's going at 1 release per day. Heh :-)

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…

I'm liking git for it's internals, but the UI is pretty bad in places:

    # undo commit
    git reset --soft HEAD~1
    hg rollback

    # undo changes
    git checkout -- 
    hg revert
etc. I look up the git equivs up on stack overflow every time I need them.
Post reply on HN