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

171–179 of 179 posts

Re: Simple Revision Control

#171

Post by bhaak »

debacle wrote: post #18

ESR, is, if nothing else, the champion of his own relevance. I've never really been fond of his work, though he seems like a nice enough guy. But he's just another OSS hacker. Bruce Perens has accomplished far more with far less controversy and self-fluffing.

> ESR, is, if nothing else, the champion of his own relevance

What an apt description. I never have had much confidence in the coding that ESR has done. Just look at fetchmail and how that one has lost uncountable mails because of poor design.

Although he seems to think highly of his coding skills but I always had the impression that he's one of those hackers that really just hack together solutions. If a problem comes up there's always a fix to be committed. I wouldn't want such a programmer on my team.

But he's always been good with words and as an OSS lobbyist he was a well needed figure that put the software first and not politics as RMS did.

Re: Simple Revision Control

#172

Post by dzsekijo »

jordigh wrote: post #99
dzsekijo wrote: post #91

I don't get how git (or any proper multi-file dvcs) falls behind facilitating the purpose ESR is shooting at. You can use "git log " to track changes of . It's like Gmail drafts. While it's delivered to you as an email stashing feature, I realized that it's the best cloud-based (offline-synced, omnipresent) note application. It can do that even if "note" is not in its name. We can be creative about using the tools at…

What if you'd like to track files at your filesystem root? /.git would be a tad complicated, since you'd need fairly complicated .gitignore rules, right? You wouldn't want "git status" or "git diff" to read your entire filesystem, including all mounted devices.

"git status" recurses only into those dirs where there is managed content. "git diff" restricts its operation to managed files.

That said, if you are into managing particular files and not a file tree, most likely you'd consider all info about other files than the chosen ones to be noise, which can be expressed in .gitignore in a very succinct way: '*'.

Re: Simple Revision Control

#173

Post by antientropic »

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…

Sadly, Git users frequently do rewrite published history, by merging branches via "git rebase" followed by a fast-forward merge (i.e. replaying the branch on top of the target), all to maintain that wonderful linear "history". And that's a bad thing because it destroys information about the context in which a change was made. (I've been baffled a few times by apparently bad commits, before realizing they were rebased and did make sense originally.)

Re: Simple Revision Control

#174

Post by kazinator »

ibrahima wrote: post #167
pjc50 wrote: post #45

Earlier quoted context omitted.

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 t…

> why on earth does it also revert files to their checked in state if given a path argument

Simplification! :) "git checkout file" reverts a file from the index. If it doesn't exist in the index, then from HEAD.

The problem is that you can make a typo, because branches, tags and files are all in the same namespace. Suppose you wanted to type "git checkout foob" which is a tag or branch, but instead you make a mistake and type "git checkout foom" which is the name of a file that happens to have unstaged changes. Oops!

If "file" has unstaged changes, then "git checkout file" should rename it out of the way first to "file.#1#" or whatever. (Hello, look at CVS!)

Re: Simple Revision Control

#175

Post by sofal »

antientropic wrote: post #173
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…

Sadly, Git users frequently do rewrite published history, by merging branches via "git rebase" followed by a fast-forward merge (i.e. replaying the branch on top of the target), all to maintain that wonderful linear "history". And that's a bad thing because it destroys information about the context in which a change was made. (I've been baffled a few times by apparently bad commits, before realizing they were rebased…

If they're rewriting published history, it's even worse than that, because it could change history that you are currently developing on top of, requiring some more advanced git knowledge to get your local repository into a correct state.

I have not found it to happen often though, for two reasons. First, it is widely agreed upon among almost all mildly experienced to highly experienced Git users that rewriting published history is a bad thing. Second, if it becomes a problem with new Git users doing this, you can turn of non-ff updates in the public repository, thereby disallowing this to ever happen, unless you go through all the steps to delete and recreate a branch.

If you're working with your local unpublished history, then it is your responsibility to make sure they still make sense in the context of newer updates from the public repo regardless of whether you rebase or merge. I can see how it would be confusing if people failed at this. I tend to find that more confusion results from people inflating the history with loads of one-commit merge bubbles everywhere rather than just rebasing their small changes.

Re: Simple Revision Control

#176

Post by kazinator »

digisign wrote: post #160
npsimons wrote: post #95

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…

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.

"git checkout -- " does not actually revert a file from the branch. It reverts it from the index. It's only a revert-to-branch operation if you don't have anything in the index. So if you land into one of those "gituations" where use of the index is being foisted upon you, it might not do what you are used to.

There is also the flaw that the -- separator is not required for giving paths: "git checkout " also works. So if you are trying to check out a branch or tag, and make a typo and accidentally type the name of a file which has unstaged changes, you lose them. It doesn't rename the original file to a backup like good old "cvs up -C file".

Re: Simple Revision Control

#177

Post by kazinator »

ibrahima wrote: post #168
kazinator wrote: post #139

Earlier quoted context omitted.

> 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/l…

You can pick out the hunks and lines that matter using "git commit --patch". This does the "git add --patch" and "git commit" in one step, so you never see any index.

Face it, the git index is an exaust manifold bolted on to a bicycle. This can be proven. Any argument you make for how the git index is useful is easily knocked down with a counterargument which shows how it it is redundant, because existing mechanisms uniformly handle that case.

Moreover, the index can be shown to complicate git. For instance when viewing differences with "git diff" you have: index to working ("git diff"), HEAD to index ("git diff --cached") or HEAD to working ("git diff HEAD"). This cruft all goes away if there is no index: you can just have "git diff" for the usual case of "show me what's different between the branch and working copy", like in virtually every other revision control system on the planet.

> 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.

Absolutely no disagreement there. The index is there (complaining won't make it go away), and you have to know about it, otherwise you will not understand what is going on in some situations. People learning git must learn about the index upfront and know things such as "git diff" diffing against the index, or that the successful parts of a merge are in the index whereas the conflicts are unstaged and things of that sort.

Re: Simple Revision Control

#178

Post by jordigh »

kazinator wrote: post #49
cschmidt wrote: post #33

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.

What you need to know is that "git add" has little to do with "foo add" where "foo" is just about any other version control system. Look, you ran "git add" on files that were already added, what? There is this hidden thing called the index that confuses the heck out of everyone. Oh, but it's not always called the index, either: that would be unnecessarily easy. Sometimes it is called "the cache". How to show the diff…

I just read this comment, and I want to quote you in full in my blog or something. I want the world to see what you wrote here.

Re: Simple Revision Control

#179

Post by digisign »

kazinator wrote: post #176
digisign wrote: post #160

Earlier quoted context omitted.

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.

"git checkout -- " does not actually revert a file from the branch. It reverts it from the index. It's only a revert-to-branch operation if you don't have anything in the index. So if you land into one of those "gituations" where use of the index is being foisted upon you, it might not do what you are used to. There is also the flaw that the -- separator is not required for giving paths: "git checkout " also works. S…

IC. I added the " -- " syntax because that's what it recommends when doing a "git status".
Post reply on HN