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

71–80 of 169 posts

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

#71

Post by prodigal_erik »

pyre wrote: post #34
MikeTaylor wrote: post #19

Earlier quoted context omitted.

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.

> (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 'git commit' commits everything that is currently in the index. 'git commit -a' commits all files currently tracked by git in their current state (if the version in the index and in the working directory differ, IIRC, the version in the working…

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

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

#72

Post by viraptor »

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…

I see this mentioned so many times:

"Git seems unintuitive because you don't have a good grasp of what it does behind the scenes"

but I fail to see why this is true. Do we need to understand the implementation of block allocation, snapshots, atomic writes, etc. to save files? Do we need to know the ip checksumming algorithm to connect to use internet? Do we need to understand congestion control algorithms to browse websites? {and many other examples}

No - we don't and many of us do not know those things. Then why are we expected to know the internals of git to use it? (use - not modify, analyse, edit without an interface, etc.) Why can't we get a tool which gets an address and makes the file appear on the local storage? (or any equivalent to VCS workflow)

"Designing a patch database" - No, I want to use a VCS, not design it. If it works on pixie dust, I'm ok with that. It's just a tool. It's supposed to help me do the real work, not give more stuff to think about on every step. Why is "you don't understand how it works" an acceptable answer here? Where's the iphone of VCS-es?

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

#73

Post by AngryParsley »

jrockway wrote: post #47
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 chan…

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

No, it will not.

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.

Umm... no? Take a look at conflicted-filename.mine. Whenever there is a conflict, svn appends .mine to your copy of the file. After that, it creates conflicted-filename.r123 and conflicted-filename.r124, and goes crazy with the angle brackets in conflicted-filename.

I've lost plenty of data with git. Most of it has to do with innocuous-sounding commands that don't ask for confirmation when deleting data. For example, git checkout filename is equivalent to svn revert filename. Of course git checkout branchname does something completely different. If a branch and a file share the same name, git will default to switching branches, but that doesn't stop bash autocomplete from ruining the day.

Here's a crazy idea: If you have an innocuous action and a dangerous action, do not label them with the same command.

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

#74

Post by pyre »

sshumaker wrote: post #69
pyre wrote: post #56

Earlier quoted context omitted.

> 1. If you have other uncomitted changes, you're simply hosed. You can't continue with the merge process with local changes at all. That's what 'git stash' is for. It stores away all changes to the local tree and index (but leaves ignore and untracked files alone). Then you can perform operations like changing branches, doing merges, etc. Then you run 'git stash pop' or 'git stash apply' to pull back your changes. (…

1. Yes, git stash is an option. Unfortunately, if it's anything like mercurial's shelve, it's not a good one. What happens when you 'unstash'? Does it properly give you conflict markers, or does it generate patchfiles? The latter is mercurial's behavior, and it sucks. To do the former, the stash command needs to also track the repo version that the local changes were based upon, so it has the historical information t…

> many programmers are in the habit of reviewing their changes before committing. Does GIT let you easily tease out these differences?

I'm unsure what you're asking here. I can say that 'git diff' shows you the difference between the working tree and the index and 'git diff --cached' shows you the difference between the index and the most recent commit (i.e. HEAD). Both of those accept a filename as an argument to just git the diff of that file in the respective spaces. All of the changes that cleanly merged are in the index, and all of the unresolved conflicts are not when you first enter the 'unresolved conflicts' state while attempting a merge.

If your asking something more specific than that you'll have to rephrase or explain for me.

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

#75

Post by pyre »

prodigal_erik wrote: post #71
pyre wrote: post #34

Earlier quoted context omitted.

> (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 'git commit' commits everything that is currently in the index. 'git commit -a' commits all files currently tracked by git in their current state (if the version in the index and in the working directory differ, IIRC, the version in the working…

> 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 you made them. You could make small atomic commits of small changes, and when the feature is ready to be pushed out to the 'canonical' repo, you could squash all of those small commits into one large commit, then push it out.

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

#76

Post by fragmede »

MikeTaylor wrote: post #38
ionfish wrote: post #24

Earlier quoted context omitted.

I presume you haven't come across Hg-Git, then. http://hg-git.github.com/

I've seen things like this. I would be very wary about trusting them with my precious source code, wouldn't you? However good they are, they're an additional layer in which (A) things can go wrong, and (B) you're insulated from the reality that you need to access to fix problems. I fear that Hg-Git would be one of those things that is an absolute delight for as long as it Just Works, then abruptly transitions into an…

I suspect that many people feel the same about computers in general...

I don't use Hg-Git, but I do use git-svn. Just like Hg-Git, I'm sure there are some caveats, but what finally got me to switch is that (at least for git-svn) it's a real live Git repo. Which means the code I write, my actual work, is all still there. The fix to my nightmare scenario? I do a fresh svn checkout to a new directory, and I do git checkout, I copy the files out, I do an svn commit of that version of files.

Definitely far from ideal, to be sure, but in my mind, knowing that was the worse case scenario, put me quite at ease. (Sure I'd read about git svn dcommit, but knowing that did set my mind at ease.)

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

#77

Post by viraptor »

avar wrote: post #68
itistoday wrote: post #26

Earlier quoted context omitted.

Thank you. I suspect these folks were OK with spending hours learning about their DVCS, but for most others, this just seems like unnecessary tedium and frustration, "When can I get back to worrying about the code?" Someone needs to make the Mac of a DVCS, i.e. one that doesn't require a 20+ page tutorial to figure out, is completely intuitive and "just works." I currently use Mercurial, and while I don't think it qu…

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?

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

#78

Post by moe »

DTrejo wrote: post #50
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?

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
  git merge $my_branch

  # push to master
  git push origin master

  # go back to local branch
  git checkout $my_branch
I didn't originally come up with all that, mind you. It's pulled from a workflow tutorial and you'll find basically the same procedure recommended in every tutorial (keywords: feature branches and "don't work directly on master").

And yes, I paste that multiple times per day and still throw up a little bit inside my mouth every time.

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

#79

Post by weavejester »

viraptor wrote: post #72
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…

I see this mentioned so many times: " Git seems unintuitive because you don't have a good grasp of what it does behind the scenes " but I fail to see why this is true. Do we need to understand the implementation of block allocation, snapshots, atomic writes, etc. to save files? Do we need to know the ip checksumming algorithm to connect to use internet? Do we need to understand congestion control algorithms to browse…

"Do we need to understand the implementation of block allocation, snapshots, atomic writes, etc. to save files?"

No, but consider what you need to know about file systems to use them. At the barest minimum, you need to know that:

* Data is stored in files

* Files have names

* Files are contained in directories

* Directories have names

* Directories can contain directories

If you had no understanding of what a file or a directory was, I'd imagine you'd find the behaviour of "grep" or "cat" completely unintuitive.

You don't need to know how Git stores data internally, but you do need to have a basic understanding of its design, just as you need a basic understanding of a filesystem in order to use it.

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

#80

Post by donaq »

itistoday wrote: post #29
Qz wrote: post #28

Earlier quoted context omitted.

The point being that the solutions are problematic.

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

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 expecting it to be svn++ and then complain that it isn't. That's like a Windows user declaring that Linux sucks because it isn't Windows. It wasn't meant to be.

Although, complaining about Ubuntu not doing things the way they "should" is more valid, since Ubuntu is targeted at everyone. :)

Post reply on HN