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

81–90 of 169 posts

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

#81

Post by AngryParsley »

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…

Git checkout also switches branches. "Checkout" sounds pretty safe, and svn has a checkout command (Which doesn't do anything but print an error message if you're in a working directory. It's the equivalent of git clone.). Finally, in most commands, git is paranoid about not destroying your changes. Combine all of these and you're in for a nasty surprise.

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

#82

Post by viraptor »

weavejester wrote: post #79
viraptor wrote: post #72

Earlier quoted context omitted.

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…

I expect to need exactly the same level of knowledge to work with a DVCS, because I'm editing files. SVN was very close to providing that in many ways and it worked. I don't want to know about a staging area unless I explicitly use it, for example. I don't want to know about the design or patch handling, unless I explicitly request or apply a patch. Merging is merging - it's good couple of levels of abstraction above patches.

Basically - I want my DVCS to require as much knowledge as cp, diff, patch. I could live with them, if I had to (see - `quilt`). Now a DVCS should be easier to use, not harder. Otherwise, what's the point?

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

#83

Post by jrockway »

AngryParsley wrote: post #73
jrockway wrote: post #47

Earlier quoted context omitted.

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

No, it will not.

Yes it will. Imagine you check out revision 1, which consists of two files:

    foo:
      a

    bar:
      b
You do some hacking, and end up with:

    foo:
      a
      

    bar:
      b
      d
While you were doing that, though, someone else committed, revision 2, which is:

    foo:
      a
      b

    bar:
      c
You go to commit your changes, and svn tells you you can't, because you are out of date. So you have to svn update. Now you have:

    foo:
      a
      b

    bar: CONFLICT
      >>>>
      b
      d
      ====
      c
Now, how do you roll back to what you had before you updated? The state of "foo" has been lost forever by the successful merge.

For example, git checkout filename is equivalent to svn revert filename.

Annoying, maybe, but this is user error, not design error. With git, if I want to losslessly discard my working copy, I can just "git stash". If I want to losslessly update my svn working copy, though, I have to make a copy myself, and then manage the copy.

By your logic, "rm" is flawed because it doesn't ask for confirmation when you pass -f instead of -i. Well, yeah. Sorry.

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

#84

Post by viraptor »

donaq wrote: post #80
itistoday wrote: post #29

Earlier quoted context omitted.

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 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 about an abstract "you" anymore.

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

#85

Post by jrockway »

barrkel wrote: post #53
jrockway wrote: post #47

Earlier quoted context omitted.

"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 has never randomly deleted my work, but then I never willingly do an svn update with local changes. svn update with local changes gives me this dialog: Conflict discovered in 'test.pas'. Select: (p) postpone, (df) diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: However, I would normally just abort at this point, and make sure my local changes are packed up into a diff l…

So basically, you've written your own revision control system that integrates with Subversion. Fine.

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

#87

Post by fr0sty »

AngryParsley wrote: post #73
jrockway wrote: post #47

Earlier quoted context omitted.

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

Here's another crazy idea: don't run 'git checkout ...' on a dirty work tree. Problem solved.

Another one: don't reuse filenames as branch-names.

To be honest: I have the same problem with careless invocations of 'rm' ruining my day but when I'm muttering curses it is at my lazyness/stupidity and not at bash completions or the behavior of 'rm'

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

#88

Post by arantius »

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…

> 'git checkout ' == 'replace with the version of in the index' (if the index is empty, then index == HEAD)

Well, really: "git checkout foo" means:

1) Switch the branch, if foo is a branch.

2) Destroy all local modifications, if foo is a file.

These are two drastically different actions, and they're given the same name. The "rm" command has one name, and does one thing: remove files. It isn't also, sometimes, used to gain access to otherwise inaccessible files. I think, ultimately, the names are the worst part of git for me.

There's checkout, which is ambiguous. I'm used to using "svn revert" in the past, but I have to use "git checkout" to do that ... at least for individual files. If I want to do them all, "git reset" is, usually, what I'm looking for in this case. The "git revert" command also exists, but does something different (apply past commits in reverse). Git has three different commands for the "put the files back the way they used to be" concept (at least, are there more I don't know about yet?).

Then there's "the in between thing". From the man pages:

If you're doing "git add" then it "updates the index using the current content found in the working tree" and "the content staged for the next commit". If you're doing "git reset" then you have to ask for "--mixed" or "--hard" in order to "resets the index". If you're doing "git diff" then you have to ask for "--cached" to get the "changes you staged for the next commit". Then there's "git ls-files" which talks about "the file listing in the directory cache index" and "--cached Show cached files" and "--stage Show staged contents object name". Wait, "--cached" and "--staged" are different options?

So what is it? Is it "the index" or "the stage" or "the cache"? Do I have to pass "--hard" or "--cached" or "--index"? Whoops, I made that last one up! But wouldn't it be nice if it had one name, and that's always the name I used to refer to it? I know there's something between "files I edit on disk" and "files in the repository" but the documentation does anything but make it clear what that something is even called.

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

#89

Post by fr0sty »

viraptor wrote: post #82
weavejester wrote: post #79

Earlier quoted context omitted.

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

I expect to need exactly the same level of knowledge to work with a DVCS, because I'm editing files. SVN was very close to providing that in many ways and it worked. I don't want to know about a staging area unless I explicitly use it, for example. I don't want to know about the design or patch handling, unless I explicitly request or apply a patch. Merging is merging - it's good couple of levels of abstraction above…

People use DVCS for its features and capabilities. Because it can do more things not because it is easier to use. In the case of git the 'simple' workflow runs into some troubles because git is designed to accommodate much more complex workflows and as a result some of the core concepts have been tweaked in what people consider to be 'unintuitive' ways.

People choose vi/emacs over notepad/ed/pico for many of the same reasons and people complain about many of the same things (it's unintuitive, complicated, confusing, and so on...)

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

#90

Post by dlsspy »

dasil003 wrote: post #67

The complaints about git porcelain are totally understandable. The UI is horrendous. However the internals are elegant and actually much simpler than subversion, so if you understand the internals and do a little rote memorization then suddenly you can manipulate your repository expertly, creating better commits and handling unusual needs with ease. It's the difference between being good with a unix shell and running…

> Why hasn't someone who knows git created a better porcelain yet? Probably because once you know git well enough you don't want to give up any of it's native power just to satisfy some noob's anxiety attack.

They exist. gitx, magit, etc... are all great tools.

Most people who use it for any length of time seem to be just fine with it, though. I can recognize a few things as... silly (e.g. checkout), but not so much as to try to introduce a new verb and redefine the semantics just to come up with a better separation when I already know what I'm doing with the tool.

I certainly don't have enough of a problem to write an entirely new interface when the existing one continues to get incrementally better.

Similarly vi and emacs are both great editors whose power cannot be harnessed by those who don't spend time trying to learn them. The vested are less affected by idiosyncrasies.

Post reply on HN