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

61–70 of 169 posts

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

#61

Post by pyre »

viraptor wrote: post #55
pyre wrote: post #37

Earlier quoted context omitted.

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

Not a good comparison. "rm" stands for remove; "f" stands for force. Neither "git" nor "checkout" indicate anything irreversible or destructive.

Well you should be using more than just the 'name of the command' as your determination of whether or not you should just run a command with little to no understanding of the consequences... Unless the command is 'do-something-completely-safe' and it doesn't live up to it's name, then I'm failing to see the issue. 'git checkout' doesn't convey safety or danger, so I would think that one should try to have a grasp of what it does before randomly running it.

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

#62

Post by barrkel »

pyre wrote: post #57
barrkel wrote: post #52

Earlier quoted context omitted.

I'll tell you what happens when I use svn and there's been an upstream change: I never update my local tree with local modifications. Instead, I extract all my local changes into a diff, then I update my local tree, and then I merge my diff back into the updated tree and commit. When I need three-way merging, which isn't often - usually patch can resync simple things like line offsets - it's handled by a file compari…

I would suggest using git-svn rather than versioning your local changes with diffs, but I guess that's just personal preference. {edit} Just to add that: > I'll tell you what happens when I use svn and there's been an upstream change: I never update my local tree with local modifications. Instead, I extract all my local changes into a diff, then I update my local tree, and then I merge my diff back into the updated t…

Sure, if I wanted to solve a problem I didn't have.

I found this answer enlightening:

http://stackoverflow.com/questions/747075/how-to-git-svn-clo...

git-svn doesn't look like it deals terribly well when it only has a shallow copy of the repository. I may be entirely wrong of course, but I'd hate to have to pull down 100+GB of data over VPN onto my 80G SSD just to keep git happy. (Yes, there are binaries in there, rather too much of them for me to update every day.)

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

#63

Post by pyre »

Qz wrote: post #9

All the people suggesting various git commands he should be using are completely missing the point.

The point -- as I understand it -- is that the author feels that a version control system should act like X. So he takes a random version control system, reads about it briefly, and then tries to use it assuming that it acts like X. The version control system doesn't act like X, which leads to problems for the author. Author writes a blog post about how random version control system sucks because it doesn't meet his assumptions.

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

#64

Post by codavid »

lars512 wrote: post #31
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…

Mercurial also has had rebase built-in for some time. For git users who have compared both, what features made you choose git over hg?

I think git is much better than hg, but I think most complaints made in the post are fair. Git UI is truly awful. IMO, The two killer features of git are the index and content-based tracking.

First the index makes dealing with OP situation much better once you understand it. For example, in hg (or any other VCS I know of), when you merge something and there is a conflict, every change is in your tree, and you don't know what's correctly merged from what's not through the VCS command. For example, hg diff will show you changes of both merged and unmerged stuff, but thanks to the index, git diff will show only the unmerged stuff. When you start fixing conflicts, when you add files with git add, those are not shown anymore with git diff (but are through git diff --cached). The index has a high learning curve, though.

The other killer feature is code tracking: git blame -C -M is extremely powerful. It can tells you that which changes are coming from which file (through heuristics, so it also works for code converted to git, e.g. git-svn). I explained this in more details there http://cournape.wordpress.com/2009/05/12/why-people-should-s....

I think in the end, git is actually simpler than hg - that is, the UI is awful, but the underlying model is simple. For example, the branching model in git is simpler than hg. In hg, you have branch-through-clone, bookmark, branches created by hg branch ( http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...). This is maybe a matter of personal opinion, but I hate simple version numbers in DVCS (I changed from bzr to git because I wasted a lot of time with bzr so-called simple numbers). With DVCS, it is impossible to have a consistent version scheme (that is at some point, you will have several branches with the same simple version referring to different commits). One thing to understand is that you almost never need to use the raw id in git, because most commands understand a lot of different syntax such as HEAD^, HEAD~, branch names and tags. If I need to refer to a commit more than once, I use a tag for it.

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.

Going back to svn is insane if you ask me, at least for usual usage of source-code only (DVCS currently suck at assets management). I agree with the OP that branching is sometimes used too much by git users, but branching for release management, code reviews, etc... has saved me hours of work as a release manager on several middle-sized open source projects (through git-svn).

Git got the low-level stuff right, but I think we have barely seen what's possible with DVCS. Bug-tracker integration, code-review integration, etc... are still in infancy.

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

#65

Post by pyre »

barrkel wrote: post #62
pyre wrote: post #57

Earlier quoted context omitted.

I would suggest using git-svn rather than versioning your local changes with diffs, but I guess that's just personal preference. {edit} Just to add that: > I'll tell you what happens when I use svn and there's been an upstream change: I never update my local tree with local modifications. Instead, I extract all my local changes into a diff, then I update my local tree, and then I merge my diff back into the updated t…

Sure, if I wanted to solve a problem I didn't have. I found this answer enlightening: http://stackoverflow.com/questions/747075/how-to-git-svn-clo... git-svn doesn't look like it deals terribly well when it only has a shallow copy of the repository. I may be entirely wrong of course, but I'd hate to have to pull down 100+GB of data over VPN onto my 80G SSD just to keep git happy. (Yes, there are binaries in there, ra…

It was just a suggestion (I use git-svn at work for our svn repositories). But none of our repos are 100+GB, so it wouldn't work in your use-case. Though I shudder to think of what maintaining a SVN repo of that size must be like (from the back-end of trying to keep it running and performant).

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

#66

Post by jodrellblank »

IsaacSchlueter wrote: post #23

We all need to throw a tantrum sometimes when things don't work the way we like. It's ok. Let it out. We're computer users, we understand. ...feel better? Now shut up and learn how to use your tools.

It's true. www.ventatme.com isn't registered...

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

#67

Post by dasil003 »

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 windows configuration wizards to do everything.

I don't expect the OA to grok that, however one thing that I hope the author takes to heart is this:

With git plumbing it would be fairly straightforward to create a new porcelain VCS combining any balance of elegance, simplicity and power that you desire. With subversion on the other hand, it is almost unimaginable that they would ever be able to correctly track a merge without a hundred bizarre edge cases due to the fact that their repository structure muddles branches and directories.

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.

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

#68

Post by avar »

itistoday wrote: post #26
Qz wrote: post #9

All the people suggesting various git commands he should be using are completely missing the point.

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" without also destroying history.

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

#69

Post by sshumaker »

pyre wrote: post #56
sshumaker wrote: post #40

Earlier quoted context omitted.

There's two problems with this approach: 1. If you have other uncomitted changes, you're simply hosed. You can't continue with the merge process with local changes at all. 2. It pollutes your change list with unrelated, unconflicted changes belonging to your teammate (the whole changeset).

> 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 to present conflict markers (effectively, enough info for a 3-way merge).

FWIW, This is actually the only thing holding my team back from switching back to hg. If hg shelve were part of the standard distribution and rock solid (multiple shelves would form a queue, no chance of corruption, and unshelve preserved historical information so it could properly merge conflicts), the world would be a better place. :)

2. Yes, I know WHY it does what it does. But the way it presents this info is unfortunate, because after a merge it's far more difficult to know exactly which changes you were making - many programmers are in the habit of reviewing their changes before committing. Does GIT let you easily tease out these differences?

[edit: call to action]

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

#70

Post by tednaleid »

sshumaker wrote: post #40
lars512 wrote: post #25

Earlier quoted context omitted.

Looks to me like he had two problems. The first was that git gave very poor error messages and needed a confusing series of command-line options. In mercurial, this is much better; the pull creates a new head, and tells you what to do if you want to merge them. Commit is one-step, instead of via the staging area. It just gives more feedback, more usefully, and requires less knowledge about the underlying representati…

There's two problems with this approach: 1. If you have other uncomitted changes, you're simply hosed. You can't continue with the merge process with local changes at all. 2. It pollutes your change list with unrelated, unconflicted changes belonging to your teammate (the whole changeset).

There are a number of ways to do this in mercurial. If you've got a set of uncommitted changes, only some of which you want to push out. Just commit the files (or use the record extension to commit only parts of files). Then, update back to the previous revision and commit the remaining changes.

This makes 2 heads. You can then update back to the first commit and nudge those changes out ("hg push --rev .", which will only push the current version and any unpushed parent revisions).

Switch back to the other revision to finish off your work there and merge the 2 heads together when you're done and ready to push it all.

You're basically working with anonymous branches at that point, but if you understand that the commits are really just nodes in a DAG, it's pretty easy to visualize what to do.

Post reply on HN