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

11–20 of 169 posts

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

#11

Post by ynniv »

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 open in emacs.

git is awesome, and git is terrible, often for the same reasons. git is a Sharp Knife, which is fantastic if you need one, and horrible if you don't. I personally have basic distributed version control needs and git is far too sharp for my needs. I have managed to not cut anything important off, but I tread carefully around each command, often worrying that I will irrevocably destroy my files.

So, +1 for being way better than previous version control systems, but a friendlier modern version control might easily win.

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

#13

Post by sshumaker »

andreyf wrote: post #8

I think the move back to CVS/Subversion might be the way to go From your complaints, it sounds like you'd really like Mercurial. Give it a shot.

No, mercurial has exactly the same problem he mentioned: You want to push 'some' of your local uncommitted changes, but if the remote head has also changed you often can't. (hg shelve is a poor substitute).

This happened to my team enough in practice that they rebelled and forced a switch back to SVN.

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

#14

Post by greendestiny »

amanfredi wrote: post #4

'git commit -a' is not the answer to your merge problem. You should 'git add ', then commit.

You'd still need to commit the files you pulled (that have changes) though right? Which is sort of fundamental to the whole distributed VCS, it doesn't matter that they were committed in the pulled repository, you have to commit them in the new one.

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

#15

Post by MikeTaylor »

amanfredi wrote: post #4

'git commit -a' is not the answer to your merge problem. You should 'git add ', then commit.

That doesn't work. The "git add README.md" completes with no output, but thereafter, "git commit README.md" still fails with "fatal: cannot do a partial commit during a merge."

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

#16

Post by llimllib »

amanfredi wrote: post #4

'git commit -a' is not the answer to your merge problem. You should 'git add ', then commit.

Also, doesn't it tell you to do thst when the conflict happens?

edit, yup:

    $ git status
    # On branch master
    # Your branch and 'origin/master' have diverged,
    # and have 1 and 1 different commit(s) each, respectively.
    #
    # Unmerged paths:
    #   (use "git add/rm ..." as appropriate to mark resolution)
    #
    #       both modified:      readme
    #
    no changes added to commit (use "git add" and/or "git commit -a")

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

#17

Post by llimllib »

MikeTaylor wrote: post #15
amanfredi wrote: post #4

'git commit -a' is not the answer to your merge problem. You should 'git add ', then commit.

That doesn't work. The "git add README.md" completes with no output, but thereafter, "git commit README.md" still fails with "fatal: cannot do a partial commit during a merge."

just "git commit" after that, not "git commit README.md"

edit: it's infuriating that yc won't let me reply to you, so I have to reply in this edit. Anyway.

"git commit" says to git: "move anything in the index (i.e. things which I have 'git add'ed, or which have been merged) into the local repository".

"git add FILE && git commit" says "put FILE in the index and then commit the whole index to the local repository"

"git commit FILE" says "assume the index is clear, and only commit FILE" to which git says the logical response, "sorry, dude, the index isn't clear, I can't do that"

perhaps this will help: http://osteele.com/archives/2008/05/commit-policies

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

#18

Post by MikeTaylor »

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 most other tools because they are, by nature, shared by groups.

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

#19

Post by MikeTaylor »

llimllib wrote: post #17
MikeTaylor wrote: post #15

Earlier quoted context omitted.

That doesn't work. The "git add README.md" completes with no output, but thereafter, "git commit README.md" still fails with "fatal: cannot do a partial commit during a merge."

just "git commit" after that, not "git commit README.md" edit: it's infuriating that yc won't let me reply to you, so I have to reply in this edit. Anyway. "git commit" says to git: "move anything in the index (i.e. things which I have 'git add'ed, or which have been merged) into the local repository". "git add FILE && git commit" says "put FILE in the index and then commit the whole index to the local repository" "g…

Oh! Well, thank you. Yes, I see that that works.

But:

(A) I see that it still commits everything, just like "commit -a", including all the files that I didn't change but that my colleague did in the branch that I'm pulling; and

(B) Why would "git add FILE; git commit" but "git commit FILE" not work? I bet it's something to do with the index.

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

#20

Post by MikeTaylor »

llimllib wrote: post #16
amanfredi wrote: post #4

'git commit -a' is not the answer to your merge problem. You should 'git add ', then commit.

Also, doesn't it tell you to do thst when the conflict happens? edit, yup: $ git status # On branch master # Your branch and 'origin/master' have diverged, # and have 1 and 1 different commit(s) each, respectively. # # Unmerged paths: # (use "git add/rm ..." as appropriate to mark resolution) # # both modified: readme # no changes added to commit (use "git add" and/or "git commit -a")

Nope.
Post reply on HN