Still hatin' on git: now with added Actual Reasons • Hacker News Board

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

#131

Post by weavejester » Thu, May 13, 2010, 1:17 PM UTC

MikeTaylor wrote: post #116

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

You're very welcome to! I had worried it was a little too long, but I'm glad it turned out to be enlightening despite its length.

Git is not without its flaws, but I'm convinced the majority of problems people have with it is because most tutorials on Git seem to focus only on the commands, without giving them any context on how Git actually works. Initially, I had exactly the same problems as you did (and exactly the same disillusionment) until I happened across Git From The Bottom Up (http://ftp.newartisans.com/pub/git.from.bottom.up.pdf). Upon reading that, I also had a lightbulb moment.

Git From The Bottom up is definitely worth reading, but it does tend to be a little too low level at times. So I've been toying around with the idea of writing a "You Could Have Invented Git" article, in the style of You Could Have Invented Monads (And Maybe You Already Have!) (http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...).

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

#132

Post by donaq » Thu, May 13, 2010, 1:56 PM UTC

viraptor wrote: post #130

donaq wrote: post #94

Earlier quoted context omitted.

If many people start using git, we can start expecting things from git. Why? The author of a piece of software is under no obligation to satisfy the expectations of its incidental users, especially if he's not selling it to them.

If they get big enough... no they don't have an obligation, but the idea of many people depending on them should be enough. It's like MS had no obligation to satisfy expectations of IE5 users (not sold directly) - sure they didn't - but many got very annoyed because of that and because of the market share, we had internet-wide consequences for standard-compliant websites. Still - they had no obligation.

That is just wrong on so many levels. Firstly, Microsoft marketed the hell out of IE. The bundling of IE with Windows was their way of getting people to use IE instead of Netscape Navigator. Since their stand (in court, no less!) was that IE was an integral part of Windows, which they sold to users, they did have an obligation to satisfy users' expectations of it. Did anyone force you to use git by bundling it with some other piece of software you were using? Nope.

Secondly, in what crazy alternate universe can git, which is given to you free as in libre as well as beer, be compared with IE? If you think git sucks, but still want to use it for some crazy reason, go ahead and modify it to suit your needs.

Lastly, I cannot imagine a world where anyone would be forced to have to cater for a VCS the way we have to for browsers. They're simply too different in function. It's not like you're in danger of being forced into the business of implementing a service supporting commits and checkouts for two different types of repositories on the same source files... unless you work at GitHub. Heh.

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

#133

Post by phaylon » Thu, May 13, 2010, 2:14 PM UTC

thenduks wrote: post #124

AngryParsley wrote: post #81

Earlier quoted context omitted.

Git checkout also switches branches. "Checkout" sounds pretty safe, and svn has a checkout command (Which doesn't do anything but print an error message if you're in a working directory. It's the equivalent of git clone.). Finally, in most commands, git is paranoid about not destroying your changes. Combine all of these and you're in for a nasty surprise.

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.

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

#134

Post by phaylon » Thu, May 13, 2010, 2:22 PM UTC

jrockway wrote: post #60

stevelosh wrote: post #58

Earlier quoted context omitted.

Mercurial says this in the same situation: abort: push creates new remote heads on branch 'default'! (you should pull and merge or use push -f to force) Yes, it's two lines. I think we all have large enough monitors now that an extra line of output to be a bit friendlier is a good thing.

Where does it end? Should a compiler say "unknown identifier 'foo': perhaps you need to import a header file that defines foo, or spell it better, or write code that works instead of this garbage" instead of a simple "unknown identifier: foo"? No. You just look up the error in the manual, and never think about it again.

It theoretically ends where it's most comfortable for a wide range of people, experienced or not. And hyperbole doesn't help. Telling me to pull first so it can incorporate the remote changes isn't a big deal I think. Where does this idea come from that the interface has to be cryptic?

If it isn't in there because nobody has done it, fine, that's cool and understandable. Actively arguing against better user messages is simply weird to me.

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

#135

Post by phaylon » Thu, May 13, 2010, 2:25 PM UTC

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?

But you're not committing, you're adding.

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

#136

Post by avar » Thu, May 13, 2010, 2:27 PM UTC

viraptor wrote: post #77

avar wrote: post #68

Earlier quoted context omitted.

Why yes, a lot of us are just fine spending "hours" learning something that we'll probably spend more than a few years using. 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. You're not going to come up with some solution that allows the user to "just do it"…

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

My post was unfortunately worded. That's what you get for posting late at night I guess.

What I meant to say is that you're not going to get away with using any sort of complex system without understanding what it's doing. This seems to be the sentiment expressed in the original posting, and some of the replies here.

Sure, Git's UI could be improved. But managing several divergent histories and correctly merging them together is a non-trivial problem. If you make a tool that allows the user to just plow on without understanding the underlying paradigm the results are going to suffer.

It's like asking for a RDBMS that allows you to "just do it". You might get away with that for a while, but not for long.

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

#137

Post by phaylon » Thu, May 13, 2010, 2:28 PM UTC

Xurinos wrote: post #98

pyre wrote: post #63

Earlier quoted context omitted.

The point -- as I understand it -- is that the author feels that a version control system should act like X. So he takes a random version control system, reads about it briefly, and then tries to use it assuming that it acts like X. The version control system doesn't act like X, which leads to problems for the author. Author writes a blog post about how random version control system sucks because it doesn't meet his…

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

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

#138

Post by phaylon » Thu, May 13, 2010, 2:33 PM UTC

donaq wrote: post #94

viraptor wrote: post #84

Earlier quoted context omitted.

Git is gaining a lot of attention lately. It's becoming "the dvcs" now. And that means, if you start using it for your project, you should consider what does it mean for contributors / users. If it creates an additional step where someone will say - "it will take me more time to learn, than creating the patch itself", you've lost. If many people start using git, we can start expecting things from git. It's just not a…

If many people start using git, we can start expecting things from git. Why? The author of a piece of software is under no obligation to satisfy the expectations of its incidental users, especially if he's not selling it to them.

Nobody is telling Linus he messed something up. Are we not allowed to raise issues, discuss and bring forth our perceived problems? "Use it as it is or GTFO" doesn't seem like the Open Source way.

The problem here is that there are people telling everybody that "git is easy," "everybody should use git," and then every time someone raises a concern someone brings up the argument above. I wonder, what is your goal? Are you trying to get people who "don't get it" to stop using git? Do you think killing discussions about it will further progress? Are you afraid the interface you learned might change?

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

#139

Post by barrkel » Thu, May 13, 2010, 3:01 PM UTC

thenduks wrote: post #122

barrkel wrote: post #53

Earlier quoted context omitted.

svn update has never randomly deleted my work, but then I never willingly do an svn update with local changes. svn update with local changes gives me this dialog: Conflict discovered in 'test.pas'. Select: (p) postpone, (df) diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: However, I would normally just abort at this point, and make sure my local changes are packed up into a diff l…

Well, this begs the question, why not just let git do all that diff-packing and 99% of the conflict resolution crap for you? As long as you don't mind spending a weekend or a few evenings reading about the new tool and how it works (like any new addition to your skillset), that is.

I'm afraid the git clone behaviour is unusable for the svn repository I work from. A clean pulled tree is over 1GB at the moment I believe, and contains many binary files (static libraries etc.) that aren't rebuilt that often, but often enough to make the repository as a whole very large. I don't know exactly how large it is, but it's large enough that it would take many weeks to download over VPN. Just getting a fresh tree takes over 24 hours as it is.

As for diff packing, it's as simple as this on the bash command line:

    collect-patch $(now)-hint.patch foo/{bar,baz}

The collect-patch script will do an svn diff over foo/bar and foo/baz from the root of my working directory, and deposit the results in a file in my current directory (e.g. 2010-05-13_15-50-whatever.patch).

Then, I can revert local changes:

    revert 2010-05-13_15-50-whatever.patch

(This reverts changes to the files listed as modified in the patch.) Because it's a file, I get completion on that. And to apply (e.g. after an svn update):

    apply 2010-05-13_15-50-whatever.patch

If things get more complicated, and there are conflicts in the lines modified by my patch and the updated source (which is less than 1% of the time), then I do:

    manual-merge 2010-05-13_15-50-whatever.patch

That uses a tool (BeyondCompare 3) to do three-way merging between the original revision of my patch, my local edit to the original revision, and the new revision that's been gotten locally. BC3 can auto-merge for all non-conflicting edit sections, but be interactive with a nice diff display and editing if there's a conflict (/automerge and /reviewconflicts arguments to bcomp).

I'm sure I could migrate this scheme onto an analogous git scheme that could keep track of the merges better, but in practice this scheme is enough - and because I wrote it, I'm intimately familiar with its mechanics, so I can extend it, and I'm not at risk of file loss, etc.

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

#140

Post by moe » Thu, May 13, 2010, 3:21 PM UTC

dlsspy wrote: post #92

moe wrote: post #78

Earlier quoted context omitted.

Sadly I guess they most of them don't make much sense without context or the discussion/thinking that led to them. But for example, this is my snippet for merging my current branch into master and pushing that to origin (hopefully merging/cleaning up in between as appropiate): # on local branch git fetch origin master git rebase origin/master # tidy up git rebase -i origin/master # merge to master git checkout master…

Your first two commands can be replaced with (one time): git config --global branch.autosetuprebase always Then "git pull" Without doing the config change, you can just do a "git pull --rebase" Your "git push origin master" is typically what I spell "git push" (recommend "git config --global push.default tracking" just to make sure you're pushing the same stuff that's tracked automatically). So, my every day workflow…

I guessed I'd have something like that coming and yes, that might work.

Except when you regularly need to create new working copies on varying git versions where those config details tend to differ in subtle ways. Too often did I have to wrestle problems on someones MacBook simply because the config or command syntax changed slightly between a few git revisions.

I'd go as far as to say that local (i.e. not repository-wide) config settings that change the semantics of how the commands work are deeply harmful in a team-setting.

It's yet another layer of complexity that you have to keep in mind when debugging problems.

Sure, it can save typing when everyone involved uses the same git version and has a good understanding of git. Unfortunately neither has been the case on most projects I've been involved with.