Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I hate about Git (2012)

stevebennett.me

Post reply on HN
Print view View original

81–83 of 83 posts

Re: Things I hate about Git (2012)

#81

Post by justinjlynn »

dispose13432 wrote: post #30
justinjlynn wrote: post #6

"it's complicated": yes,it is. it's a product designed and built for people who deal with complex systems and information models on a daily basis; they're the equivalent of a professional pilot... not your feeble, senile grandmother. You wouldn't buy your feeble senile grandmother a 787, chuck her in with no training and simple expect her to fly to Bali, would you? "I don't like it and here's a heap of examples which…

The difference is that to fly 787s you need quick response and muscle memory so all controls have to be available, and you've got to be able to fix errors in-flight. And even then you don't want to create a joystick which pulls up when pushing forward.

In all honesty, I think we're saying the same thing.

Re: Things I hate about Git (2012)

#82

Post by ubernostrum »

greggman wrote: post #20
ubernostrum wrote: post #10

Earlier quoted context omitted.

hg's command-line interface is far better organized, yes, at least in the sense that it appears to have been organized rather than organically slapped together and papered over with "well it'd make sense if only you understood more about it". Blaming users for not understanding a bad interface is one of the classic mistakes.

hg's original workflow didn't encourage git style branches at all nor did it have any kind of stage IIRC. They've since been optionally added. Is that workflow in hg more intuitive or is only its far less powerful original workflow more intuitive? It took me a while make the mental jump from svn style branches to git style and from no stage to having a stage but I'd never want to go back now that I understand them.

This is not about workflow (though I do prefer hg's model of multiple types of branch-like constructs). This is about the command-line interface used to interact with it. Where git overloads commands (the same command can do vastly different things depending on options or context), or cannot make up its mind whether to implement functionality through top-level commands or flags to existing commands, hg is much more consistent in having a set of commands whose names match the operations they perform and are not overloaded with multiple contextual meanings.

Re: Things I hate about Git (2012)

#83

Post by stevage »

sigsergv wrote: post #31

Once you get the essence of git (objects, graph, commits as snapshots etc) everything becomes really easy. You don't need to memorize all command just need to understand some basic concepts. And some points about the article. Git is a framework actually, you need some workflow to use it in a team. So git requires a lot of discipline from all team members. You can't just "commit" as in subversion, you must understand…

Author here. Yeah, the lack of authorship (and any kind of user awareness, really) is a pain.

There are so many ways in which Git has simply failed. It was basically an experimental piece of software designed for a hypothetical world which never really eventuated. Truly distributed version control (code shared between different servers) turned out to be a fringe use case, and the vast majority of all collaborative developed source code has a primary repository. So it has all these features built around the edge case, and a lack of features for the primary case (many users, with different levels of trust, contributing to one repo).

Gitless is pretty cool. http://gitless.com/

Post reply on HN