I use it every day, but there's always some aspect of its behaviour that it turns out I didn't understand the first time round. Perhaps that's because I jumped into the project with only a very rudimentary understanding of Om, just enough to complete a certain ticket. I've since then spent a lot of time going through the docs, but it just conceptually doesn't sit well with my brain. Sorry I can't give a more useful answer. Reagent on the other hand, which I haven't used in production, just "feels" better every time I play with it.
The thing that helped my understanding most was a recent project where I got to work with React directly. Also, reading the source.
So yes, it's mostly because I'm a little lazy, but Reagent doesn't seem to punish me for that same laziness. 😆
I realize this is a pretty broad question, but what is it about Git that people find painful? Could be Stockholm Syndrome on my part, but I have a pretty hard time understanding why someone can't spend a week getting up to speed with a tool they intend to use for years to come.
IMO this all boils down to the Git CLI just being terrible e.g. “git add” to stage versus “git reset HEAD” to unstage. Pretty much everything is like that. And there are always edge cases so that a command works in this case but not in that one. Want to edit a commit message? "git amend". But only if the last one. Otherwise it's "git rebase -i" (even though your intent is not to do a rebase, go figure). Well, not if it's a merge actually, you'd need "git rebase -p" or something... Even if something is conceptually simple, Git CLI manages to make it complicated. And GUI tools don't help much as they just wrap the Git CLI.
Of course it does make sense if you know how Git is built internally, but that's irrelevant to getting the job done :)
Anyway, with GitUp, the idea is to have an interactive live map instead, where operations and UI actually make sense, while still being 100% compatible with Git under the hood.
Considering the top 5 questions of all time on SO for most technologies are trivial/basic cases or homework. Yeah, when I first used Git I had to look things up.
Now that I use Git daily a tool like this seems like a terrible plan. I don't even trust basic scripts for git commands I haven't written/read totally, something which I'm not prepared to do for this tool.
>Anyway, with GitUp, the idea is to have an interactive live map instead
I like the idea of a live map, but the "interactive" part seems silly.
> Considering the top 5 questions of all time on SO for most technologies are trivial/basic cases or homework.
To a certain degree, yes, but we're talking here about the top 5 question across all technologies and tools used by developers on the most popular reference site and by far. And Git stands out by far, not anything else ;)
> Now that I use Git daily a tool like this seems like a terrible plan.
Trust is important indeed. In case this helps, GitUp comes with snapshots and undo/redo and you'll always have the reflog as well. It's actually really really hard to lose committed work in Git.
Yeah, I was coming here to post that Git is already painless. It's a tool you are intimately using if you're doing anything other than Hello World projects with your team; it doesn't seem too much to ask to actually learn how it works. And once you know it's painless.
Edit: I was thinking about it a bit more and it's actually one of the least painful tools I have ever used on a computer...
unknown unknowns. Odd choices for flags and commands. Inability to search for explanations of some commands.
These are all valid commands that do radically different things:
git checkout patch
git checkout --patch
git checkout -- patch
Yet, googling to find the difference is difficult (because search engines). If, eventually, you decide to search for 'dash dash', you'll start to find good results.
So, if a user had a file named 'patch' that they want to 'revert' back to the last committed version, they might try the first one (after all, it works for 'git checkout somefile.txt'). But IF they have a branch named patch, it would attempt to switch to it. It might succeed, it might fail, depending on the state of the tree, giving a very strange message compared to what the user wanted to do.
Despite it's ubiquity in the man pages, I haven't been able to find 'official' documentation or explanation for it, rather a bunch of blog posts and stack overflow questions. I find it hard to believe that a user who spent their time reading through docs and man pages would be able to work out the meaning on their own.
This is one example, but there are a TON of examples in StackOverflow as to what people find difficult. Most of my git knowledge comes from having to fix something that went awry. It's hard to 'spend a week getting up to speed' on a tool whose sole purpose is to manage other work.
> "Most of my git knowledge comes from having to fix something that went awry."
Can relate to this.
> "spend a week..."
I didn't mean it in a literal sit-down-and-read-all-the-man-pages sense, but frequent use does get common commands wired into your muscle memory. Also, if you're working in a team, which takes code review seriously, then your VCS is nearly as important as your language runtime. Yes, it's about managing process, but I feel it's just as integral to shipping as writing code.
> but I have a pretty hard time understanding why someone can't spend a week getting up to speed with a tool they intend to use for years to come.
Because it may not be for enough years. I've used CVS, SVN, Git in less than 15 years. I still have clients on SVN because Git is too much to get to grips with.
> what is it about Git that people find painful?
Why is there no built-in 'tree' command? I am lost without my .gitconfig and the aliases I have set up to give me a visual view of the repository.
Also, the difference between HEAD^3 and HEAD~3. I have muscle memory to do what I need, but for more occasional tasks I am searching StackOverflow.
I haven't used other DVCS so I don't know if the pain points are Git, or they're the complexities that DVCS brings. I look forward to the next (r)evolution in source control, when I hope we have power but more human-friendliness.
I still like a GUI from time to time. I use SourceTree. I can use GIT on the command-line and I'm a competent developer but I like to be able to click files and see the changes and just drag them into a commit. It may not be the fastest way, or the most advanced but it works for me.
Git command-line works fine, but I am not expert. Once something goes wrong, I find it impossibly hard to figure from Git command-line what is going on. Visualizing the repository (using SourceTree for example) makes understanding the problem trivial. Working 100% on the command-line with Git feels like having to move things around while being blind.
Not convinced? Try to stop using a whiteboard, drawing diagrams to explain things, using body language, etc. for a while.
I am been wishing for a tool like this GitUp for a long time, even thought about building one myself except that I see a lot of anti-GUI sentiment amongst many Git users, aka potential customers. Glad someone is making it.
I've also used some visual tools, but I always end up abandoning them after a short while, since I don't feel that they add to my workflow. Probably just a matter of taste and familiarity then. It's possible that I'd be marginally more productive with a GUI tool, but I'm too comfortable with my current process to bother. I'll admit to straying and using Github for Mac when I've made lots of changes without doing frequent small commits :-) It often beats `git add -p` in UX terms.
That was my hope 1198 days ago when I started the website https://news.ycombinator.com/item?id=3589963 :-) I would have titled it "Free Computer Books" otherwise. If you know of any books that fulfill the "free" condition, that would appeal to a curious mind - however you choose to define that, then feel free to submit them.
> "loose definition"
How so? I state quite explicitly what sort of content is welcome. If the contents of the book are available for free from a site controlled by the author(s) or publisher, it is free enough for the purposes of the site. If you care enough and find a book that doesn't meet that standard, you can flag it, and I can have a look to confirm this.
It also says "community curated". The books are crowdsourced. Most contributors are clearly what you'd refer to as hackers, but there's nothing stopping you from posting a Philosophy book. I think it mostly points to the fact that (I'm willing to bet) most authors who'd willingly make their books available free of charge are of a technical bent. There are philosophy, economics, psychology books on the site. If you find any and you've got some time to spare, you're welcome to add to the site.
It's a little presumptuous to assume that everyone who could possibly need access to a technical book has a loose $15 to spare. I know I didn't when I built it, as a 2nd year undergrad not living in a First World economy. The authors who chose to make them free obviously had a wider audience in mind than people who can afford their books. I can, and do, buy books now that I can afford them, but you'd be hard pressed to find a better introduction to Python than Zed Shaw's Learn Python the Hard Way, a free book.
Just one thing, browsing by topic doesn't seem to have any sort of rhyme or reason in its ordering aside from some vague first-letter ordering. For example, there are numerous "I" categories, with one "I" for "interactive" and another one for "Interactive". One grouping of "I"'s includes tags "ios", "iOS", and "ip", but the next "I" grouping below just contains "IP"
Edit: I see the ordering issue now. There's a list of topics. The list is printed out in alphabetical order. But for some reason when the first letter of a topic changes between capital letter and a lowercase letter, a new letter grouping is created. Probably it's creating a new category whenever the first character changes, but it did not take into account capital and lowercase characters being different.
Thanks for this. I was happy to see 'Patterns for Time-Triggered Embedded Systems' on your list, though the link appears broken - new link: . I remember working through that book and porting everything from C to Assembly (my boss at the time was too cheap to buy me the nice Keil compiler). Once I had that library in hand, I was knocking out his projects in days instead of weeks.
In the past month or so I've been using it astoundingly often. I really enjoy having such a site available and I appreciate the generosity of it all, but it could really (IMHO) use a cleanup. Perhaps a pass over the book URLs for 404s, cleaning/merging the duplicate categories, and perhaps a more rigorous way of preventing them from happening again (suggesting existing topics on the submit form?)
I'm sure there are plenty of people here that would be happy to contribute content, code, design, or whatever.
I had the same feeling about Clojure, but it mostly has to do with non-standard libs. It's forced me to rely on reading source code a lot more than I did in other languages, so I'm not entirely sure that's a mark against it. I'm curious why you think that about Python, though. Care to illustrate?