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

91–100 of 169 posts

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

#91

Post by arantius »

MikeTaylor wrote: post #18
sqrt17 wrote: post #7

Duh. I've never got the hang of git either, but I figure git is for those people who don't get enough mileage out of Mercurial because they have 42 megatons of source code, or need git rebase, or just want to shock and awe their friends. But no need to hate git for that. No one's forcing you to use it. You don't like vim? Go ahead and use emacs/gedit/eclipse/perl. You don't like git? Use mercurial. Or subversion, if…

"But no need to hate git for that. No one's forcing you to use it. You don't like vim? Go ahead and use emacs/gedit/eclipse/perl. You don't like git? Use mercurial" If only this were true. But it's not: if I work on a project where my colleagues keep the source in git, then I have to use git (whereas if they use vi, I am still at liberty to use emacs). That's the problem with CVSs -- they have a lot more inertia than…

> they have a lot more inertia than most other tools because they are, by nature, shared by groups.

The term you're looking for is "network effect". http://en.wikipedia.org/wiki/Network_effect

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

#92

Post by dlsspy »

moe wrote: post #78
DTrejo wrote: post #50

Earlier quoted context omitted.

link to your 14-liners?

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 (rebasing upstream and building on top of stuff) looks like this:

    git pull
    [edit a bunch of files]
    git add -p
    git commit
    git push
My mouth is minty fresh.

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

#93

Post by dlsspy »

codavid wrote: post #64
lars512 wrote: post #31

Earlier quoted context omitted.

Mercurial also has had rebase built-in for some time. For git users who have compared both, what features made you choose git over hg?

I think git is much better than hg, but I think most complaints made in the post are fair. Git UI is truly awful. IMO, The two killer features of git are the index and content-based tracking. First the index makes dealing with OP situation much better once you understand it . For example, in hg (or any other VCS I know of), when you merge something and there is a conflict, every change is in your tree, and you don't…

> 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 that had artificial commits introduced everytime you tried to sync with the upstream.

You don't lose any information with a ff. There's no information to lose -- you're just not specifically recording a commit that has no code changes, but says "and on this date, I grabbed some upstream code."

I've seen that complaint elsewhere, though. I always do pull --rebase (and only take merge commits in exceptional cases) because I'm on the other end of that spectrum. My history is very easy to read. Glad you can bend it to do what you want, though.

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

#94

Post by donaq »

viraptor wrote: post #84
donaq wrote: post #80

Earlier quoted context omitted.

Linus didn't write git for you. He wrote it for himself. Git works exactly the way Linus (and his merry band of kernel hackers (and others, who thought DVCS was a cool idea when they heard about it and were prepared to relearn SCM to use it)) wants it to work. If you want to learn to use it, cool, welcome to the party. If you aren't prepared to invest the time, that's cool too. But don't try it for like a day expecti…

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.

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

#95

Post by ryanpetrich »

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.

LLVM will attempt to guess the proper name of a misspelled identifier for you: http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-re...

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

#96

Post by ekiru »

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?

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?

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

#97

Post by klodolph »

jrockway wrote: post #45
kscaldef wrote: post #3

> So I edit the file, fix the trivial conflict, and git commit filename. This is a bit vague, but I'm guessing you mean you open up the file in your text editor of choice and edit it directly. What I do these days, probably originally prompted by exactly the sort of frustration you describe, is to run "git mergetool", which I happen to have configured to fire up emerge, but you can use any of a number of tools. Once…

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…

You said he should have been doing a rebase. I disagree. Almost always, if you think you should rebase, you really should merge instead.

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

#98

Post by Xurinos »

pyre wrote: post #63
Qz wrote: post #9

All the people suggesting various git commands he should be using are completely missing the point.

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

I saw the word "intuitive" thrown around... http://www.asktog.com/papers/raskinintuit.html

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

#99

Post by codavid »

dlsspy wrote: post #93
codavid wrote: post #64

Earlier quoted context omitted.

I think git is much better than hg, but I think most complaints made in the post are fair. Git UI is truly awful. IMO, The two killer features of git are the index and content-based tracking. First the index makes dealing with OP situation much better once you understand it . For example, in hg (or any other VCS I know of), when you merge something and there is a conflict, every change is in your tree, and you don't…

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

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

#100

Post by ynniv »

pyre wrote: post #37
ynniv wrote: post #11

I have read a fair amount of documentation on git. I still don't even know what most git commands do. When people recommend a rebase, I pretty much just pretend that my repository isn't going to die. I wince every time I have to revert a file, as "git checkout" is friendly but "git checkout " is destructive without warning. I once destroyed a number of local files (I don't remember how) that were thankfully still ope…

> 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 (destructive and non-destructive) have no syntactical differences. "git checkout X/Y" is non-destructive if X is the name of a remote and Y a file, and destructive if X is the name of a folder and Y a file. Deep down, you know this just isn't right.

The chief problem with git is that the user interface is a simple reflection of the mechanics and vocabulary used to implement it. That first part is great for performance, and the whole thing might seem like a good idea if you happen to be a filesystem hacker, it's arbitrary nonsense to the rest of the world.

git has been purposely architected so that you do not lose data. "stash" allows you to temporarily store local changes while you test things out. Extensive branching is key to sharing patches in a trackable way. Most destructive commands actually alert you that data will be lost. I really like this philosophy of never accidentally losing anything.

But the interface is inconsistent and needlessly complex, and should not be defended. git could be vastly improved simply by changing the command structure and vocabulary. Destructive commands could universally prompt unless an option ("-f"?) is specified.

Maybe someone could make "tig", which is a proper version control system organized from an everyday user's perspective, based on git.

Post reply on HN