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

111–120 of 169 posts

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

#111

Post by ewjordan »

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.

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 that sometimes it takes five commands to carry out what is, in fact, one desired action.

But Git's main point of failure is typical of all young projects that are in any way involved with Linux - there's no effort to make it elegant or pretty, and anyone that points that out and suggests that maybe things could be easier is ridiculed for not understanding it.

Usually "That's not very intuitive" is, in fact, an indication of something that could be improved...

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

#112

Post by rue »

arantius wrote: post #88
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…

> 'git checkout ' == 'replace with the version of in the index' (if the index is empty, then index == HEAD) Well, really: "git checkout foo" means: 1) Switch the branch, if foo is a branch. 2) Destroy all local modifications, if foo is a file. These are two drastically different actions, and they're given the same name. The "rm" command has one name, and does one thing: remove files. It isn't also, sometimes, used to…

> 2) Destroy all local modifications, if foo is a file.

Not exactly. It updates the file to the state from the index.

git-checkout is just poorly overloaded. The idea is the same in both operations (updating some set of files in the working directory to some state from this or some other branch) but the two should be separated.

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

#113

Post by overgard »

I generally agree with the sentiment of this article, though I feel like I need to get better at using git anyway. It's a leaky abstraction and very unintuitive, no doubt, but after using Git regularly I just can't go back to subversion, the workflow in Git is so much nicer (when everything goes as expected, at least...)

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

#114

Post by tow21 »

ewjordan wrote: post #111
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. 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, and the relations between them. In the vanishingly small edge case where you never have any collaborators, never any experimental code, you never need to backtrack, you never need to work on more than one portion of the code at a time - this is isomorphous.

The rest of the time, it's not. CVS & SVN try to stretch the first abstraction to take care of these differences, but fail.

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

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

#115

Post by jwhite »

ewjordan wrote: post #111
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. 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…

You make valid points about open source tools frequently having leaky abstractions, and I often have exactly the same response that you do -- "Why don't people make more effort to make this elegant/pretty/intuitive?"

But the more I use git, the more I actually appreciate the fact that the abstraction is leaky. When I'm manipulating my history, I often really _want_ to have all the guts hanging out so that I can slice and dice them. If git wasn't designed using the "composable tools" idea [1] then it would make this stuff a lot harder.

The tradeoff is that it makes the learning curve a lot steeper. I understand that some developers don't want to know too much about their VCS, but I can't count the number of times when I have appreciated having an in depth knowledge of it [2].

I said this here once before, and I don't mind repeating it: git is a power tool for power users. It is also designed as VCS toolbox, so anyone who wants to write a more intuitive UI layered on top of git is welcome to. There are a couple out there, but they don't seem popular. I'm not sure why.

[1] Although this phrase also conjures the UNIX Hater's Handbook's take on it: "tools for fools"

[2] The next question is how much of the time do I get into these situations _because_ the guts are hanging out? Is that the reason I need the power tools to get me out of trouble? It's hard to judge because I'm too close to the trees to see the forest on this issue.

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

#116

Post by MikeTaylor »

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…

Weavejester, this is utterly brilliant. Like a lightbulb going on. THANK you!

I'd love to post it (with attribution, of course) as a followup article on The Reinvigorated Programmer. Please contact me to let me know whether that's OK -- mike@miketaylor.org.uk

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

#117

Post by MikeTaylor »

pyre wrote: post #108
AngryParsley wrote: post #104

Earlier quoted context omitted.

You didn't lose any data in that scenario. Every line of code you wrote still exists in those files. The problem is that you are in a conflicted state that must be manually resolved. Unfortunately, making updates atomic across a branch has disadvantages. For example, svn lets you update individual files or directories instead of the whole branch. If you want to avoid this pitfall in the future, run "svn merge --dry-r…

> You didn't lose any data in that scenario. Every line of code you wrote still exists in those files. The problem is that you are in a conflicted state that must be manually resolved. I think that the point is that file 'foo' has already been merged, regardless of the conflict in file 'bar'. There is no way for you to revert to the pre-update state. In git, your previous commit still exists in the objects store even…

Still, it can't be right that "get checkout foo" does one of two COMPLETELY different things depending on whether or not there is a file called foo in the current directory. Surely one of those two commands should have a different name.

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

#118

Post by chousuke »

codavid wrote: post #99
dlsspy wrote: post #93

Earlier quoted context omitted.

> One think which git got wrong IMO is fast-forward when pulling: it means you lose branch information, and the history is hard to understand (it complicates life for bisect or continuous integration) - I change the pull command to make pull non fast forward by default in git. That sounds pretty terrible. I would certainly refuse any changesets from you in OSS projects I'm managing if you tried to send me changes tha…

You do loose useful information, because you don't know where branches started/ended. For feature branches, that's very useful: useful for bisect, useful for reverting a branch. For syncing to upstream, that's indeed not so useful.

Git pull/merge etc. have a --no-ff switch that will do a normal merge even if a fast-forward is possible. You can even configure the default, though I don't remember the config variable.

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

#119

Post by viraptor »

ekiru wrote: post #96
viraptor wrote: post #77

Earlier quoted context omitted.

> You're not going to come up with some solution that allows the user to "just do it" without also destroying history. Really? I've got state A and state B. I tell my DVCS to merge them into state C. After reviewing the automatically guessed changes and manually changing the things which could not be guessed, I commit C'. C' is successor to both A and B. What exactly has been lost / destroyed here?

Nothing. Conveniently, git allows you to do exactly that. 1. Checkout B. 2. Merge A into B. 3. Git tells you there's a merge conflict and what to do to fix it: "Auto-merging foo CONFLICT (content): Merge conflict in foo Automatic merge failed; fix conflicts and then commit the result." 4. Edit foo and fix the conflict. 5. "git add foo" 6. Commit. What's the problem?

Parent claimed that it cannot be done, I responded. Not sure what is the problem...

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

#120

Post by viraptor »

fr0sty wrote: post #89
viraptor wrote: post #82

Earlier quoted context omitted.

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…

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.

Post reply on HN