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

Still hatin' on git: now with added Actual Reasons

reprog.wordpress.com

Post reply on HN
Print view View original

141–150 of 169 posts

Re: Still hatin' on git: now with added Actual Reasons

#141

Post by gte910h »

kscaldef wrote: post #48
jrockway wrote: post #45

Earlier quoted context omitted.

Isn't the message intuitive? Git usually says, "merge conflict, fix the conflict, stage the fix, and run git rebase --continue". If you follow the instructions exactly, everything works. Now, I know he wasn't doing a rebase (but should have been), but still; when you edit things in git, you stage them, and then commit them. After a merge, the index is mostly ready to be committed, except for the conflicts. So you are…

No, “! [rejected] master -> master (non-fast forward)” is not intuitive. The example you give is one of the pleasantly surprising examples of a good error message from git. But, by and large, git's error messages are pretty awful.

1> Intuitive is not everything

2> To actually make said message more intuitive, it could have a "type git help error ffwd for an explanation"

Re: Still hatin' on git: now with added Actual Reasons

#142

Post by gte910h »

weavejester wrote: post #59

Mike, Git seems unintuitive because you don't have a good grasp of what it does behind the scenes. Imagine trying to get to grips with a Unix shell, if you had no concept of files or directories. In such a scenario, even a simple command like "cat" would seem incomprehensible. If you'll indulge me, I'd like to propose a thought experiment. * * Designing a patch database * * Consider you're responsible for administeri…

>Mike, Git seems unintuitive because you don't have a good grasp of what it does behind the scenes

I actually believe that's what "Unintuitive" means.

However intuitiveness is not everything. Power is often more useful than easy to learn.

Re: Still hatin' on git: now with added Actual Reasons

#143

Post by moe »

tow21 wrote: post #114
ewjordan wrote: post #111

Earlier quoted context omitted.

Mike, Git seems unintuitive because you don't have a good grasp of what it does behind the scenes. In other words, Git's abstraction is leaky. That's usually considered a bad thing in our profession. Except that since it's Git, we all use it, and it's better than the alternatives, we all pretend that's a good thing in this case. I'm fine with the way Git works internally, and by now I've come to deal with the fact th…

In other words, Git's abstraction is leaky No, it means you're using the wrong abstraction. As you change your codebase, files are modified. To the untrained eye, it looks like this a simple linear progression of history, and you just want to record savepoints as you go along. CVS lets you pretend this is the case. Actually, that's not the case at all. What you actually want to record is the changes you're making, an…

No, it means you're using the wrong abstraction.

It seems a large number of users prefers to work at a different level of abstraction than git requires.

git makes you face up to the fact that your abstractions are wrong.

Strangely mercurial tackles the exact same abstractions, yet has a much friendlier user-interface. The standard-rebuttal at this point will be "Fine, use mercurial then". I wonder if, at some point, more users will start doing that than the git-community would like. I, for one, am certainly tempted, but have so far held out due to the switching cost and because hg is, of course, not without flaws either.

However, I don't think this "If it hurts then you're doing it wrong"-attitude can be healthy for git in the longterm.

A bad user-interface remains a bad user-interface, no matter how you spin it. The big problem I see is not even with git currently having this bad user-interface, but rather with the widespread reluctance in git-circles to even think about ways to improve it.

Re: Still hatin' on git: now with added Actual Reasons

#144

Post by avar »

ynniv wrote: post #100
pyre wrote: post #37

Earlier quoted context omitted.

> I wince every time I have to revert a file, as "git checkout" is friendly but "git checkout " is destructive without warning. From my point of view, that's like saying that 'rm -rf' is destructive 'without warning.' It does what it was meant to do, you can't expect everything to warn you all the time in an effort to save you from yourself. It would get really annoying, really fast if it asked you to confirm every t…

that's like saying that 'rm -rf' is destructive 'without warning.' Well, "rm -r" when run as root does warn. You have specified a flag that explicitly doesn't not ask. Also, "rm" only ever destroys things, whereas "git checkout": - creates a new branch (non-destructive, additive) - switches to an existing branch (non-destructive) - obliterates uncommitted changes to a file (destructive) And the two major modes (destr…

> Well, "rm -r" when run as root does warn.

No it doesn't, but perhaps you're using a distro (like RedHat) where "rm -r" is actually aliased to "rm -ri".

Re: Still hatin' on git: now with added Actual Reasons

#145

Post by weavejester »

viraptor wrote: post #82
weavejester wrote: post #79

Earlier quoted context omitted.

"Do we need to understand the implementation of block allocation, snapshots, atomic writes, etc. to save files?" No, but consider what you need to know about file systems to use them. At the barest minimum, you need to know that: * Data is stored in files * Files have names * Files are contained in directories * Directories have names * Directories can contain directories If you had no understanding of what a file or…

I expect to need exactly the same level of knowledge to work with a DVCS, because I'm editing files. SVN was very close to providing that in many ways and it worked. I don't want to know about a staging area unless I explicitly use it, for example. I don't want to know about the design or patch handling, unless I explicitly request or apply a patch. Merging is merging - it's good couple of levels of abstraction above…

"I expect to need exactly the same level of knowledge to work with a DVCS, because I'm editing files."

From Git's point of view, you're not editing files; you're creating patches.

Git is fundamentally a tool for constructing, sharing and storing patches. You may disagree that this is the best way to approach version control, but if you accept this philosophy, then Git is remarkably simple and logical.

Personally, I feel that treating a version control system like a filesystem is the wrong approach. I'm primarily interested in managing changes to the code, not in tracking chronological changes in individual files.

Re: Still hatin' on git: now with added Actual Reasons

#146

Post by thenduks »

phaylon wrote: post #133
thenduks wrote: post #124

Earlier quoted context omitted.

It's still being paranoid. You shouldn't be checking out anything while you have working copy changes unless you really, really mean to. This is why it's not a big deal that it's named the same. Also, git defaults to working on a branch if the names conflict. If I have branch 'foo' and file 'foo' (both terrible names for files and branches) and try: `git checkout foo` it will switch to the foo branch and not checkout…

That's not being paranoid, that's depending on me being paranoid. People make mistakes, and a clearer separation of these two functions would make it harder to make this mistake.

I don't really want my tool to be the kind of paranoid you're describing. I know what I'm doing, I've never lost changes like that, and I don't want git acting like it knows better. The commands are semantically correct, you just need to use them in conjunction with your brain.

Re: Still hatin' on git: now with added Actual Reasons

#147

Post by weavejester »

viraptor wrote: post #120
fr0sty wrote: post #89

Earlier quoted context omitted.

People use DVCS for its features and capabilities. Because it can do more things not because it is easier to use. In the case of git the 'simple' workflow runs into some troubles because git is designed to accommodate much more complex workflows and as a result some of the core concepts have been tweaked in what people consider to be 'unintuitive' ways. People choose vi/emacs over notepad/ed/pico for many of the same…

The reason why this is important is that dvcs-es are very different from editors. If I don't like emacs, I'll use vi, gedit, ed, ... - we'll get the same file and the same result, it's only the method that's different. If you use git however, I have a choice of a) git b) hg-git c) not working with your code.

Surely the same argument applies to SVN as well? Whichever VCS you use, you're going to force contributors to adapt to a particular version control philosophy.

Re: Still hatin' on git: now with added Actual Reasons

#148

Post by phaylon »

thenduks wrote: post #146
phaylon wrote: post #133

Earlier quoted context omitted.

That's not being paranoid, that's depending on me being paranoid. People make mistakes, and a clearer separation of these two functions would make it harder to make this mistake.

I don't really want my tool to be the kind of paranoid you're describing. I know what I'm doing, I've never lost changes like that, and I don't want git acting like it knows better. The commands are semantically correct, you just need to use them in conjunction with your brain.

Er, first, if you'd like to call me stupid, please do so openly.

Personally, I like safety-features on tools. You know that feature that stops rotating blades when they come into contact with fingers? Would "just don't touch the blade" have been an equal solution to you?

Re: Still hatin' on git: now with added Actual Reasons

#149

Post by Xurinos »

phaylon wrote: post #137
Xurinos wrote: post #98

Earlier quoted context omitted.

That is what I got out of it. A big clue was his "git commit filename". git is not svn. Is git's greatest sin really that it uses a few of the same words with different meanings from how they have been used in the past? Someone in another post mentioned revert. svn revert file == git checkout file, while git revert patches out a whole change. It actually makes sense if you forget about cvs and svn's version of the AP…

You mean it actually makes sense if you forget the other VCS versions of that command, and know git's? Because ignoring all VCS experience I have, "checkout" would indicate to me that I could "check something out" as in "have a peek at it."

In git, it means "checking out the current branch version of a file" or "checking out an entire branch". Pulling all the patches from another resource also makes sense.

Think of checkout as a local thing to do, and pull/fetch as a remote action.

It can make sense if you do not have prior associations. It is not as if the English language is not terribly abused and ambiguous in our languages. What does "cancel" mean? In linux with CUPS, it cancels a print job. To cancel a process, you have to kill it, but you cannot kill print jobs. Shocking.

What is OOP? How does that definition change between C++, Java, Smalltalk, Lisp/CLOS, and vimscript? How about MVC? What about the differences in GUI lingo between Object Windows, McClim, Gtk, and qt? In other words, you have to learn the language of each different tool you use, and it is unreasonable to expect that it is the same as your other tools.

Aside from that, it is terribly unfair to try to compare svn to git in any meaningful architectural sense; they are completely different creatures that accomplish some of the same goals. git does it better. And it uses different language to describe its new approach.

I have not had a difficult time switching between using svn and git after using both for a long time, except for missing nice features like "git log -p" and "git add -p" when I work with svn. It seems petty to me to quibble over command names.

Re: Still hatin' on git: now with added Actual Reasons

#150

Post by koenigdavidmj »

pyre wrote: post #110
itistoday wrote: post #103

Earlier quoted context omitted.

> Git's user interface isn't perfect, but you're not going to get the "Mac of DVCSs" either. There's a reason for the complexity, doing stuff like merging together the work of three people is inherently complex. This is a limitation of your imagination. You can write a DVCS that's easy to use and intuitive. Git has an absolutely terrible UI, it borders on idiotic. One example of a DVCS with a good design and UI is a…

Issues that I've heard of with Bazaar: - Being pure Python it doesn't have the same performance that git does. This may not show up in day-to-day usage, but things like 'convert this svn repo to Bazaar' tend to bring the bottlenecks/performance issues into the light. - Bazaar made this weird design decision to have two revision numbers. a 'r12345' type revision number that is similar to SVN, but only applies to your…

>Being pure Python it doesn't have the same performance that git does.

Well, hg is nearly all Python (if I recall, their diff algorithm is the only C code) and it's quite comfortably fast. Seems to me that it's a design issue with Bazaar, and not something that one can simply blame on Python.

Post reply on HN