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

161–169 of 169 posts

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

#161

Post by pyre »

phaylon wrote: post #137
Xurinos wrote: post #98

Earlier quoted context omitted.

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

When you 'checkout' something from the library, you are not 'having a peek at it' in the 'Hey! Come check this out!' usage of the word. Words can have multiple meanings depending on context. 'git checkout' has no context, so you can't just assume what the author meant when the command was named as such.

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

#162

Post by pyre »

kuahyeow wrote: post #126
pyre wrote: post #109

Earlier quoted context omitted.

'git gc' ? ;-)

http://www.kernel.org/pub/software/scm/git/docs/git-gc.html "git gc tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote tracking branches, refs saved by git filter-branch in refs/original/, or reflogs (which may reference commits in branches that were later amended o…

If you have an object that's no longer referenced by anything you can lose it when you garbage collect, which was my point. I was only being half-serious, which is what the wink was meant to convey.

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

#163

Post by dlsspy »

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.

If it fast-forwarded, it's because you haven't added any changes that aren't already upstream. If you're losing information, it's when you considered starting a branch.

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

#164

Post by prodigal_erik »

pyre wrote: post #75
prodigal_erik wrote: post #71

Earlier quoted context omitted.

> you can pick and choose what you want to commit How is that supposed to be a reasonable thing to do? Unlike my working directory, I can't build and test the contents of the index. To me, making a commit that I've never tested is somewhere between sloppy and negligent, so why is git encouraging me to do it?

I think that your issue is that you're thinking of a commit in git in the same way that you would think of a commit in svn. They are not the same. To commit in svn you are forced to push to the remote repo. Therefore you screw everybody up if your commit hoses things. In git, you can commit locally, and you are not even required to push those changes out. You could trash those commit without anyone ever knowing that…

After some reading, it looks like it's actually possible to use git-checkout-index after an uncommitted merge to get the index contents out where I can test them. I'm still mystified that the preferred workflow is to blindly commit stuff that may not even run, which leaves you with the problem of somehow knowing which of the commits are actually useful points to roll back to or start new work from.

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

#165

Post by MikeTaylor »

weavejester wrote: post #131
MikeTaylor wrote: post #116

Earlier quoted context omitted.

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 t…

Many thanks, WJ. As you may have seen already, I went ahead and posted at http://reprog.wordpress.com/2010/05/13/you-could-have-invent... Much appreciated!

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

#166

Post by phaylon »

pyre wrote: post #161
phaylon wrote: post #137

Earlier quoted context omitted.

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

When you 'checkout' something from the library, you are not 'having a peek at it' in the 'Hey! Come check this out!' usage of the word. Words can have multiple meanings depending on context. 'git checkout' has no context, so you can't just assume what the author meant when the command was named as such.

I know, and having multiple meanings for a single word that's used as a technical command without visible content is not a good idea. That's what I'm saying

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

#167

Post by pyre »

phaylon wrote: post #166
pyre wrote: post #161

Earlier quoted context omitted.

When you 'checkout' something from the library, you are not 'having a peek at it' in the 'Hey! Come check this out!' usage of the word. Words can have multiple meanings depending on context. 'git checkout' has no context, so you can't just assume what the author meant when the command was named as such.

I know, and having multiple meanings for a single word that's used as a technical command without visible content is not a good idea. That's what I'm saying

> without visible content

There is a manual... You don't blame a drill press company just because someone thought it was a good idea to use their drill press to pierce their nose, do you? What's the point of providing people with documentation, if you are going to rail on the product for not being 'so easy' that people don't need to read the documentation?

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

#168

Post by phaylon »

pyre wrote: post #167
phaylon wrote: post #166

Earlier quoted context omitted.

I know, and having multiple meanings for a single word that's used as a technical command without visible content is not a good idea. That's what I'm saying

> without visible content There is a manual... You don't blame a drill press company just because someone thought it was a good idea to use their drill press to pierce their nose, do you? What's the point of providing people with documentation, if you are going to rail on the product for not being 'so easy' that people don't need to read the documentation?

This is about catching mistakes. No manual will help you there. Documentation doesn't even come into the mix.

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

#169

Post by amanfredi »

MikeTaylor wrote: post #19
llimllib wrote: post #17

Earlier quoted context omitted.

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.

This is a bit of a late reply, but the reason it's committing everything that your colleague changed is that it's the definition of a merge commit.

I find that it's desirable to avoid merges to reduce the number of overall commits. To do this, do git pull --rebase instead of just git pull when your commit is rejected.

Post reply on HN