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

41–50 of 169 posts

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

#41

Post by d0mine »

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…

Once files are added to git it is almost impossible to destroy them irrecoverably. So my impression of git is the opposite I perform any command without fear to lose anything. If the command doesn't do what I need I just rollback to the last known good state.

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

#42

Post by ableal »

MikeTaylor wrote: post #35
itistoday wrote: post #29

Earlier quoted context omitted.

And the problems shouldn't exist in the first place.

But, yes, I do also like to bitch about them :-)

Watch out for the flying door-knobs. ( http://news.ycombinator.com/item?id=1272779 )

Seems that the peasants who have binaries should use rsync manually, instead of expecting tools to do the job.

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

#43

Post by fr0sty »

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…

If you are having trouble with git losing your changes you shouldf really be committing more often. Once a change is in git it is very hard to lose but until it is in git losing it is very easy.

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

#44

Post by llimllib »

MikeTaylor wrote: post #36
llimllib wrote: post #21

Earlier quoted context omitted.

see above, I edited to add what I'm talking about

My bad, I was wrong on this. I would just delete my comment, but that would leave your replies looking dumb. Instead, feel free to downvote my earlier "Nope." into oblivion.

No worries, color me unoffended. I should have generated the message I was talking about before I posted anyway.

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

#45

Post by jrockway »

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 supposed to manually stage the fixed conflicts, and then plain "git commit". Simple. It works exactly like anyone who understands git would expect it to.

Now, if you don't like the index, then git simply isn't for you. It's a core concept, you just can't avoid it. (Personally, when I was using non-git version control systems, I often had a separate working copy I used exactly like git's index. So having that built in is a joy for me.)

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

#46

Post by barrkel »

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…

'svn checkout ' isn't a valid svn operation; checkout applies to directory urls. Actually, beyond svn revert, I struggle to think of an easy way for you to lose your local modifications. If you really just wanted the latest version of , I guess you might use svn cat, but you'd have to redirect it to overwrite the other file yourself. For svn update, it won't overwrite local modifications.

svn revert seems to be better named for this purpose.

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

#47

Post by jrockway »

pyre wrote: post #39

I sort of take issue with this statement: “git is bad for me because it makes assumptions about how I work that don’t match how I actually work” I think that it's the other way around. git was built with a specific type of workflow in mind. If you take git and try to insert it into your current workflow with a minimal understand of git (or its intended workflow), then isn't it really you that are making assumptions a…

"svn update" will randomly delete your work with no way to ever get it back.

I don't think new git users migrating from svn actually understand that they can rollback any changes git makes. If a pull goes bad and you don't want to deal with it, just reset to your last head. All is forgotten until you feel like fixing it. And no data is ever lost.

(svn loses data by merging everything it can with your uncommitted changes, and then barfing when it can't do the merge. You're left with a bunch of conflicted file, and a bunch of merged files, with no way to ever get the unmerged files again. With git, this simply cannot happen. Git will not touch untracked files or unstaged changes, it will just die. And what it does automatically merge can be unmerged with reset. Or, you can commit the conflict markers to a separate branch, deal with it later, undo that commit, and move on with your life. Git makes easy things a little harder, but hard things easy. Subversion makes anything except hair loss very difficult.)

Oh, and also, the OP really wants his tree to end up like:

    A--B--D--C
This can be achieved with "git pull --rebase" (or automagically with the config key branch..rebase = true). That is what Subversion does, modulo the ability to revert to your original branch.

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

#48

Post by kscaldef »

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…

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.

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

#49

Post by jrockway »

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.

What else should a one-line summary of syncing master -> master say?

"Hello dear user. The remote server refuses to accept your branch, because it would delete information. As a result, your request has been rejected. Please rebase and try again. If you need help, hang up, and then dial your operator."

Personally, I am fine with [rejected]. I figured it out, after all...

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

#50

Post by DTrejo »

moe wrote: post #10

Don't give up faith my friend. Git and mercurial are not the end of the story. I'm optimistic that, within another few years (give or take a decade), someone will come up with a VCS that's both powerful and usable. :-) Other than that: I enjoyed your article. Very nice walk through some of the problems and hair-pulling that I'm going through regularly, too. Pro-Tip: My life with git got a bit easier since I keep this…

link to your 14-liners?
Post reply on HN